Date: Thu, 13 Jan 2011 22:39:13 -0800 From: Chuck Swiger <cswiger@mac.com> To: Bruce Evans <brde@optusnet.com.au> Cc: freebsd-net <freebsd-net@freebsd.org> Subject: Re: igb watchdog timeouts Message-ID: <54D25D8E-ED8C-41E8-BD14-4EB86F4D63C3@mac.com> In-Reply-To: <20110114154326.E27511@besplex.bde.org> References: <20100729215649.GB2615@icir.org> <20110103210209.GA13091@icir.org> <4D2E66C4.5090607@greatbaysoftware.com> <AANLkTinxDryptLu%2B7NRnLPLE7716BHw=CZ==jYOb_Q%2BY@mail.gmail.com> <4D2F20BB.5080204@greatbaysoftware.com> <AANLkTimK8VEQLd-m-zPsw8-%2BoBi-oJ5pc5eScmFXmujy@mail.gmail.com> <4D2F71BE.2080801@greatbaysoftware.com> <0B45B324-A819-4230-BBE3-F8468F2DA88F@mac.com> <20110114154326.E27511@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54D25D8E-ED8C-41E8-BD14-4EB86F4D63C3>