Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Jan 2011 21:12:18 +1100 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        Chuck Swiger <cswiger@mac.com>
Cc:        freebsd-net <freebsd-net@freebsd.org>
Subject:   Re: igb watchdog timeouts
Message-ID:  <20110114204810.Y28741@besplex.bde.org>
In-Reply-To: <54D25D8E-ED8C-41E8-BD14-4EB86F4D63C3@mac.com>
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> <54D25D8E-ED8C-41E8-BD14-4EB86F4D63C3@mac.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 13 Jan 2011, Chuck Swiger wrote:

> 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.

Strangely, my MUA is sending format=flowed, etc., but mails received
from you don't have it.  So when I reply to you and Cc me, then there
are enough newlines in the now-doubly-quoted original in the Cc.
format=flowed apparently even fixes up the quotes, so there are enough
quotes too.  But I don't like this.  Letting the MUA change the format
will mangle source code, diffs and some types of quotes.  It would
take large markup to keep source code separate, and larger MUAs to
understand the difference between it and natural language.  I normally
manually quote source code and diffs using "% ", but cvs commit mail
generators are not so careful and this causes problems with some MUAs.

[fxp's best of 100 Mbps NICs]

>> 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).
>

Here I can see some quote mangling, but mostly by my mailer:
- replies from you have my single ">" quoting preserved for adding one ">",
   giving ">>".  I think newlines line structure is preserved too.
- the Cc comes back with ">>" expanded to "> >" and another "> " for another
   level.  A few levels and there is no space for anything but quotes.
- something is not removing empty quoted lines at the end of quoted material.
   One is visible in the above if it doesn't get mangled in the reply.  This
   is not as bad as adding extra empty lines between quotes.

> Sure-- there are circumstances where a machine would always have traffic to process, for which idle polling was beneficial to enable.

Yes, although polling was designed more to do the opposite -- to reduce
overheads by handling larger number of packets at time.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110114204810.Y28741>