Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)

Thu Dec 15 06:33:23 PST 2005

On 12/15/2005 12:33 AM Sasa Stupar wrote:

>
>
> --On 14. december 2005 20:01 -0800 Ted Mittelstaedt 
> <tedm at toybox.placo.com> wrote:
>
>>
>>
>>> -----Original Message-----
>>> From: Danial Thom [mailto:danial_thom at yahoo.com]
>>> Sent: Wednesday, December 14, 2005 11:14 AM
>>> To: Ted Mittelstaedt; Drew Tomlinson
>>> Cc: freebsd-questions at freebsd.org
>>> Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme
>>> Song)
>>>
>>
>>>> Well, if polling does no good for fxp, due to
>>>> the
>>>> hardware doing controlled interrupts, then why
>>>> does
>>>> the fxp driver even let you set it as an
>>>> option?
>>>> And why have many people who have enabled it on
>>>> fxp seen an improvement?
>>>
>>>
>>> They haven't, freebsd accounting doesn't work
>>> properly with polling enabled, and "they" don't
>>> have the ability to "know" if they are getting
>>> better performance, because "they", like you,
>>> have no clue what they're doing. How about all
>>> the idiots running MP with FreeBSD 4.x, when we
>>> know its just a waste of time? "they" all think
>>> they're getting worthwhile performance, because
>>> "they" are clueless.
>>>
>>
>> I would call them idiots if they are running MP under
>> FreeBSD and assuming that they are getting better
>> performance without actually testing for it.  But
>> if they are just running MP because they happen to be
>> using an MP server, and they want to see if it will
>> work or not, who cares?
>>
>>> Maybe its tunable because they guy who wrote the
>>> driver made it a tunable? duh. I've yet to see
>>> one credible, controlled test that shows polling
>>> vs properly tuned interrupt-driven.
>>>
>>
>> Hm, OK I believe that.  As I recall I asked you earlier to
>> post the test setup you used for your own tests
>> "proving" that polling is worse, and you haven't
>> done so yet.  Now you are saying you have never seen
>> a credible controlled test that shows polling vs
>> interrupt-driven.  So I guess either you were blind
>> when you ran your own tests, or your own tests
>> are not credible, controlled polling vs properly
>> tuned interrupt-driven.  As I have been saying
>> all along.  Now your agreeing with me.
>>
>>> The only advantage of polling is that it will
>>> drop packets instead of going into livelock. The
>>> disadvantage is that it will drop packets when
>>> you have momentary bursts that would harmlessly
>>> put the machine into livelock. Thats about it.
>>>
>>
>> Ah, now I think suddenly I see what the chip on your
>> shoulder is.  You would rather have your router based
>> on FreeBSD go into livelock while packets stack up,
>> than drop anything.  You tested the polling code and found
>> that yipes, it drops packets.
>>
>> What may I ask do you think that a Cisco or other
>> router does when you shove 10Mbt of traffic into it's
>> Ethernet interface destined for a host behind a T1 that
>> is plugged into the other end?  (and no, source-quench
>> is not the correct answer)
>>
>> I think the scenario of it being better to momentary go into
>> livelock during an overload is only applicable to one scenario,
>> where the 2 interfaces in the router are the same capacity.
>> As in ethernet-to-ethernet routers.  Most certainly not
>> Ethernet-to-serial routers, like what most routers are
>> that aren't on DSL lines.
>>
>> If you have a different understanding then please explain.
>>
>>>>
>>>> I've read those datasheets as well and the
>>>> thing I
>>>> don't understand is that if you are pumping
>>>> 100Mbt
>>>> into an Etherexpress Pro/100 then if the card
>>>> will
>>>> not interrupt more than this throttled rate you
>>>> keep
>>>> talking about, then the card's interrupt
>>>> throttling
>>>> is going to limit the inbound bandwidth to
>>>> below
>>>> 100Mbt.
>>>
>>>
>>> Wrong again, Ted. It scares me that you consider
>>> yourself knowlegable about this. You can process
>>> # interrupts X ring_size packets; not one per
>>> interrupt. You're only polling 1000x per second
>>> (or whatever you have hz set to), so why do you
>>> think that you have to interrupt for every packet
>>> to do 100Mb/s?
>>
>>
>> I never said anything about interrupting for every
>> packet, did I?  Of course not since I know what
>> your talking about.  However, it is you who are throwing
>> around the numbers - or were in your prior post -
>> regarding the fxp driver and hardware.  Why should
>> I have to do the work digging around in the datasheets
>> and doing the math?
>>
>> Since you seem to be wanting to argue this from a
>> theory standpoint, then your only option is to do the
>> math.  Go ahead, look up the datasheet for the 82557.
>> I'm sure it's online somewhere, and tell us what it says
>> about throttled interrupts, and run your numbers.
>>
>>> Do you not understand that packet
>>> processing is the same whether its done on a
>>> clock tick or a hardware interrupt? Do you not
>>> understand that a clock tick has more overhead
>>> (because of other assigned tasks)? Do you not
>>> understand that getting exactly 5000 hardware
>>> interrupts is much more efficient than having
>>> 5000 clock tick interrupts per second? What part
>>> of this don't you understand?
>>>
>>
>> Well, one part I don't understand is why when
>> one of those 5000 clock ticks happens and the fxp driver
>> finds no packets to take off the card, that it takes
>> the same amount of time for the driver to process
>> as when the fxp driver finds packets to process.
>> At least, that seems to be what your arguing.
>>
>> As I've stated before once, probably twice, polling
>> is obviously less efficient at lower bandwidth.  In interrupt
>> driven mode, to get 5000 interrupts per second you are most
>> likely going to be having a lot of traffic coming in,
>> whereas you could get no traffic at all with polling mode
>> in 5000 clock ticks.  So clearly, the comparison is always
>> stacked towards polling being only a competitor at high bandwidth.
>> Why you insist on using scenarios as examples that are low
>> bandwidth scenarios I cannot understand because nobody
>> in this debate so far has claimed that polling is better
>> at low bandwidth.
>>
>> I am as suspicious of testimonials as the next guy and
>> it is quite true that so far everyone promoting polling
>> in this thread has posted no test suites that are any better
>> than yours - you basically are blowing air at each other.
>> But there are a lot of others on the Internet that seem to
>> think it works great.  I gave you some openings to
>> discredit them and you haven't taken them.
>>
>> I myself have never tried polling, so I
>> am certainly not going to argue against a logical, reasoned
>> explanation of why it's no good at high bandwidth.  So
>> far, however, you have not posted anything like this.  And
>> I am still waiting for the test suites you have used for
>> your claim that the networking in 5.4 and later is worse,
>> and I don't see why you want to diverge into this side issue
>> on polling when the real issue is the alleged worse networking
>> in the newer FreeBSD versions.
>>
>> Ted
>
>
> Hmmm, here is test with iperf what I have done with and without polling:
> **************
> ------------------------------------------------------------
> Client connecting to 192.168.1.200, TCP port 5001
> TCP window size: 8.00 KByte (default)
> ------------------------------------------------------------
> [1816] local 192.168.10.249 port 1088 connected with 192.168.1.200 
> port 5001
> [ ID] Interval       Transfer     Bandwidth
> [1816]  0.0-10.0 sec   108 MBytes  90.1 Mbits/sec
>
> This is when I use Device polling option on m0n0.
>
> If I disable this option then my transfer is worse:
> ------------------------------------------------------------
> Client connecting to 192.168.1.200, TCP port 5001
> TCP window size: 8.00 KByte (default)
> ------------------------------------------------------------
> [1816] local 192.168.10.249 port 1086 connected with 192.168.1.200 
> port 5001
> [ ID] Interval       Transfer     Bandwidth
> [1816]  0.0-10.0 sec  69.7 MBytes  58.4 Mbits/sec
> ***************
>
> BTW: my router is m0n0wall (FBSD 4.11).
>

Thanks for your post.  Can you please tell me what network card and 
driver your machine uses?

Thanks,

Drew

-- 
Visit The Alchemist's Warehouse
Magic Tricks, DVDs, Videos, Books, & More!

http://www.alchemistswarehouse.com