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

[Ted Mittelstaedt]

>-----Original Message-----
>From: Danial Thom [mailto:danial_thom at yahoo.com]
>Sent: Thursday, December 15, 2005 11:42 AM
>To: Ted Mittelstaedt
>Cc: freebsd-questions at freebsd.org
>Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme
>Song)
>
>
>
>
>--- 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.
>
>
>Yes, going into livelock for a moment is better
>than dropping a bucket of packets. If your
>machine is in constant livelock, then its too
>slow and it doesn't matter whether you run
>polling or interrupts; you need a new machine.
>

Duh, but that wasn't what I asked.  You claim
that dropping packets is terrible and routers
shouldn't do it, and should go into momentary livelock
to avoid it.  I asked you what then about the
scenario where one interface is slower than the
other?  How are you going to avoid dropping some
packets then?

>You also can't grasp the point that clock ticks
>do more than just poll, you're forcing a LOT of
>other stuff to get done a lot more often than
>necessary. You also don't understand that polling
>occurs MILLIONS of times per second on machines
>that aren't loaded. The HZ setting is the minimum
>number of polls per second. Its a perfect example
>of using a setting without having any idea how it
>works just because some idiot falsely claimed it
>was better without really testing it.

Well, your the idiot that's "falsely claiming it's
worse without really testing it" so what's the
difference?

As I said before, your arguing theory.  And the theory
sometimes gets tripped up by what you think is a minor
variable that shouldn't matter.

You keep claiming the pro-polling people haven't tested,
well you haven't tested either.  It's just a big
air-battle.

>> 
>> >> 
>> >> 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.
>
>You said that the throttled interrupts would keep
>the controller from being able to do full
>100Mb/s, which is wrong. So why don't you just
>explain what you meant by that.
>

No, I said 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.  This was to illustrate your assumptions
about throttled interrupts don't have any logical
basis in anything.

I frankly don't believe that this throttled interrupt
rate you keep talking about is anything more than a
figment of your lively imagination.  You have not one
single time mentioned a chip number that this takes 
place with, you have not mentioned the manufacturer
specifications that says this exists, nor CPU speed
nor nothing.  As I said, post the section out of the 82557
datasheet, along with the numbers from that sheet of
what the chip can do, along with your explanation of
what happens on a system with, let's say, a 2Ghz cpu
clock.  Show us by the numbers that not only is polling
worse at low interrupt rates, but it's worse at high
interrupt rates, with some math, not a bunch of hand-waving.

>Your not knowledgable 

You are correct.  I am not knowledgeable about how
polling is worse than interrupt mode at high bandwidth
rates.  I am waiting for you to educate me with some
mathematics.

>or reasonable Ted.

Wrong.  You are making the accusation so the onus is
on you to sustain them with some logic, not a bunch
of testimonial followed by some theory, on hypothetical
hardware that doesen't exist.

>You just
>want me to be wrong, so there's no sense arguing
>religion.
>

No, I am ASSUMING that your wrong because you haven't
supplied anything concrete or repeatable.  I don't
know if the pro-polling people are wrong or not - but
lots of people seem happier with polling turned on
so to me that counts enough so that if I was ever routing
100Mbt through 2 ethernet cards in a FreeBSD system,
I would try it out, rather than dismissing it out of
hand.  Obviously if it didn't work then I'd turn it
off.  And as far as your assertions that the accouting
is all RF'd with polling, sorry but I don't use
the output of top to decide if a system has a
problem, I judge by the amount of time that
applications take to execute.

>Why don't you ask Matt Dillon about interrupt
>moderation vs polling, since I'm sure everyone
>will agree that he's a lot smarter than you, if
>you don't believe that I am. 
>

OK, if your going to rely on Matt for backup, then
start posting some links of his that say what your
saying.

Ted