Traffic shapping kills the ping
-
pfsense rc1. (cvs_sync yesterday).
after running the traffic shapper wizard,
my ping time to the pfsense goes very highwhen 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
rexReply 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 509txi 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.
-
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.
