Traffic shapping kills the ping



  • pfsense rc1. (cvs_sync yesterday).
    after running the traffic shapper wizard,
    my ping time to the pfsense goes very high

    when i remove the traffic shapper, the ping gets down to <1ms immediately.

    even when i give icmp higher priority, it still the same.

    the weird thing is, even when i gets lots of time out, i (sometimes) still able to browse the internet.
    and when i get lots of time out, resetting the states give back good pings.

    any ideas?
    tia
    rex

    Reply from 192.168.18.18: bytes=32 time=1393ms TTL=64
    Reply from 192.168.18.18: bytes=32 time=1442ms TTL=64
    Reply from 192.168.18.18: bytes=32 time=1068ms TTL=64
    Reply from 192.168.18.18: bytes=32 time=1464ms TTL=64
    Reply from 192.168.18.18: bytes=32 time=1749ms TTL=64
    Reply from 192.168.18.18: bytes=32 time=2327ms TTL=64
    Reply from 192.168.18.18: bytes=32 time=2334ms TTL=64
    Reply from 192.168.18.18: bytes=32 time=3003ms TTL=64
    Reply from 192.168.18.18: bytes=32 time=3006ms TTL=64
    Reply from 192.168.18.18: bytes=32 time=3165ms TTL=64
    Reply from 192.168.18.18: bytes=32 time=3693ms TTL=64
    Reply from 192.168.18.18: bytes=32 time=2988ms TTL=64
    Reply from 192.168.18.18: bytes=32 time=3243ms TTL=64
    Request timed out.
    Reply from 192.168.18.18: bytes=32 time=3150ms TTL=64
    Reply from 192.168.18.18: bytes=32 time=3095ms TTL=64
    Reply from 192.168.18.18: bytes=32 time=3194ms TTL=64
    Request timed out.
    Reply from 192.168.18.18: bytes=32 time<1ms TTL=64
    Reply from 192.168.18.18: bytes=32 time<1ms TTL=64
    Reply from 192.168.18.18: bytes=32 time<1ms TTL=64
    Reply from 192.168.18.18: bytes=32 time<1ms TTL=64
    Reply from 192.168.18.18: bytes=32 time<1ms TTL=64



  • Thats a new one on me.  Sounds like something hardware related.

    When I enable the traffic shaper I can saturate 90% of by outbound traffic and maintain a 30ms ping.



  • cpu p3/500mhz, load around 5%
    memory 128mb, usage about 35%
    hdd 4gig
    4 nic, all 3com 509tx

    i just change the nic. before that, i use at2500 with rtl8139c chipset.
    maybe that?

    rgds,
    rex



  • Yes.

    How about a quote from the realtek driver page.  I've sent it to the mailing list in the past:

    taken from /usr/src/sys/pci/if_rl.c

    /*

    • The RealTek 8139 PCI NIC redefines the meaning of 'low end.' This is
    • probably the worst PCI ethernet controller ever made, with the possible
    • exception of the FEAST chip made by SMC. The 8139 supports bus-master
    • DMA, but it has a terrible interface that nullifies any performance
    • gains that bus-master DMA usually offers.
    • For transmission, the chip offers a series of four TX descriptor
    • registers. Each transmit frame must be in a contiguous buffer, aligned
    • on a longword (32-bit) boundary. This means we almost always have to
    • do mbuf copies in order to transmit a frame, except in the unlikely
    • case where a) the packet fits into a single mbuf, and b) the packet
    • is 32-bit aligned within the mbuf's data area. The presence of only
    • four descriptor registers means that we can never have more than four
    • packets queued for transmission at any one time.
    • Reception is not much better. The driver has to allocate a single large
    • buffer area (up to 64K in size) into which the chip will DMA received
    • frames. Because we don't know where within this region received packets
    • will begin or end, we have no choice but to copy data from the buffer
    • area into mbufs in order to pass the packets up to the higher protocol
    • levels.
    • It's impossible given this rotten design to really achieve decent
    • performance at 100Mbps, unless you happen to have a 400Mhz PII or
    • some equally overmuscled CPU to drive it.
    • On the bright side, the 8139 does have a built-in PHY, although
    • rather than using an MDIO serial interface like most other NICs, the
    • PHY registers are directly accessible through the 8139's register
    • space. The 8139 supports autonegotiation, as well as a 64-bit multicast
    • filter.
    • The 8129 chip is an older version of the 8139 that uses an external PHY
    • chip. The 8129 has a serial MDIO interface for accessing the MII where
    • the 8139 lets you directly access the on-board PHY registers. We need
    • to select which interface to use depending on the chip type.
      */


  • i use realtek before i change the nic.
    now, after i change it, it's 3com 509tx.

    so, any recommendation on good nic i should use?

    tia
    rex



  • I generally try to stick with intel or 3com chipsets, but as anything YMMV.


  • LAYER 8 Moderator

    Heard some comments from a kernel hacker I know, that (older) 3com aren't the top, too. Seems they also had some problems in the 3c905-series. 905c looks good to me, on older chipsets there was a bit of lazyness here and there, but only had that on openbsd (or netbsd). But I can fully agree to the intel nics, especially the server cards (small boards they are nowadays). They keep running smoothly without any problems so far.

    Greets
    Grey



  • changed nic to 3com 905c-tx-m

    seems not much change.

    however, downgrade to beta3 (clean install) seems to fix my problem??

    yet another of (my) weird experiences…

    rgds,
    rex



  • Beta 4 has major issues.  If you are not cvs_sync.sh releng_1 your copy then it's broken on beta4.


Log in to reply