On Jan 13, 2011, at 8:54 PM, Bruce Evans wrote: >> To quote an earlier post: >> >> "Polling mode operation generally performs better when using older 100Mbs >> ethernet NICs which do not support interrupt mitigation and various >> capabilities like TSO4; gigabit ethernet NICs are smarter hardware and can >> generally outperform polling mode." > > I think "older 100Mbs" means "low-end 100Mbps". Mega-bit-seconds are > strange units, and 100Mbps NICs with enough buffers don't benefit much > from polling mode.
Insert a "/" into "Mbs" to get "Mb/s" if it makes you happier; I understand that some folks insist upon adding a hyphen to "anal-retentive" for similarly pedantic reasons. > They even avoid dropping the *nix newline character On a good day, my MUA sends "Content-type: text/plain; format=flowed" and should contain line breaks following the 80-character-per-line Usenet conventions, which modern MUAs might well reassemble based upon the user's window size. If it is being re-interpreted after transmission by MTAs, mailing-list MIME filters, or similar, well, that lies beyond my control. >> Polling is well-suited for dedicated routers, firewalls, and other boxes >> which have a constant flow of traffic and for which you are looking for >> well-bounded latency. End-user machines, servers, and the like which have >> bursty traffic tend to do better using normal NIC operation, especially if >> you have decent gigabit NICs which support interrupt mitigation and have >> larger buffers than the old 100Mbs NICs had. > > I never saw any problem with interrupt mode fxp 100 Mbps NICs. Agreed, but fxp's were among the very best of that era of NICs; some of them even supported firmware which implemented an early form of interrupt moderation. For other NICs of that era, the benefits of polling mode compared to interrupt-based operation tended to be greater than they were for fxp's. > They have enough buffers (128 for each of tx and rx IIRC). The only thing > polling mode gave for them was lower latency, but this cost enabling > polling in the idle loop, which wastes 100% of at least 1 CPU and some > power. Without polling in idle, polling gives very high latency (even > worse than low-quality interrupt moderation does). Sure-- there are circumstances where a machine would always have traffic to process, for which idle polling was beneficial to enable. Regards, -- -Chuck _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
