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

[Danial Thom]

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

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

Your not knowledgable or reasonable Ted. You just
want me to be wrong, so there's no sense arguing
religion.

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. 

DT

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com