--- Ted Mittelstaedt <[EMAIL PROTECTED]> wrote:
> > > >-----Original Message----- > >From: Danial Thom > [mailto:[EMAIL PROTECTED] > >Sent: Wednesday, December 14, 2005 11:14 AM > >To: Ted Mittelstaedt; Drew Tomlinson > >Cc: freebsd-questions@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 _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
