RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
actually, I tested the ping-flooder from the my-security.net link and surprisingly it works under W2K. At least, enough to be able to get the FreeBSD system it was targeted at to start instituting ICMP limiting. I have no idea if it could in fact actually saturate a 100BaseT connection, or in fact if any Win2K system could. The presumption was that if Sasa was indeed interesting in running it, we could move on to a bit more sophistication, such as packet-counting access lists on the FreeBSD router that he's publishing stats from. Once we get some numbers from that, we could begin doing some rudimentary math to see what we have. Unfortunately, though, looks like Sasa has lost interest in the project when it started to require some effort to do. :-( Ted >-Original Message- >From: Danial Thom [mailto:[EMAIL PROTECTED] >Sent: Tuesday, December 20, 2005 10:32 AM >To: Ted Mittelstaedt; Sasa Stupar; freebsd-questions@freebsd.org >Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme >Song) > > >LOL. Trying to dig ditches with ice cream sticks >boys? > >--- Ted Mittelstaedt <[EMAIL PROTECTED]> >wrote: > >> >> Sasa, >> >> Try this ping flooder then: >> >> >http://my-security.net/outofsite/ICMP%20Ping%20Flood.zip >> >> Ted >> >> >-Original Message- >> >From: Sasa Stupar >> [mailto:[EMAIL PROTECTED] >> >Sent: Monday, December 19, 2005 12:00 AM >> >To: Ted Mittelstaedt; >> freebsd-questions@freebsd.org >> >Subject: RE: Polling For 100 mbps Connections? >> (Was Re: Freebsd Theme >> >Song) >> > >> > >> >It doesn't work on winxp. I am going to build >> another machine >> >with FreeBSD >> >5.4 and I'll try it then and let you know the >> results. >> > >> >Sasa >> > >> >--On 18. december 2005 14:02 -0800 Ted >> Mittelstaedt >> ><[EMAIL PROTECTED]> >> >wrote: >> > >> >> >> >> In looking at this again, I didn't realize >> you were pinging from >> >> Win2K >> >> >> >> Win2K uses the -f option to set the Do Not >> Fragment bit, UNIX uses >> >> the -f option to flood ping. Win2k ping >> does not have a flood ping >> >> option. You can download a ping for Windows >> from Microsoft here: >> >> >> >> >> >http://research.microsoft.com/barc/mbone/mping.aspx >> >> >> >> that does have an option for flooding >> traffic. ( set the milliseconds >> >> between packets very low) but I have not >> tested it. Doubtless >> >> others are available on the Internet. >> >> >> >> Ted >> >> >> >>> -Original Message- >> >>> From: [EMAIL PROTECTED] >> >>> >> [mailto:[EMAIL PROTECTED] >> Behalf Of Sasa Stupar >> >>> Sent: Sunday, December 18, 2005 6:07 AM >> >>> To: Ted Mittelstaedt; >> freebsd-questions@freebsd.org >> >>> Subject: RE: Polling For 100 mbps >> Connections? (Was Re: Freebsd Theme >> >>> Song) >> >>> >> >>> >> >>> Nothing. From the GUI view it is at 0% of >> utilisation. >> >>> >> >>> Sasa >> >>> >> >>> --On 18. december 2005 3:51 -0800 Ted >> Mittelstaedt >> >>> <[EMAIL PROTECTED]> >> >>> wrote: >> >>> >> >>>> >> >>>> what does the CPU of the router do when >> your doing that? >> >>>> >> >>>> Ted >> >>>> >> >>>>> -Original Message- >> >>>>> From: [EMAIL PROTECTED] >> >>>>> >> [mailto:[EMAIL PROTECTED] >> Behalf Of >> >Sasa Stupar >> >>>>> Sent: Sunday, December 18, 2005 3:00 AM >> >>>>> To: Ted Mittelstaedt; >> freebsd-questions@freebsd.org >> >>>>> Subject: RE: Polling For 100 mbps >> Connections? (Was Re: >> >Freebsd Theme >> >>>>> Song) >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> --On 18. december 2005 2:32 -0800 Ted >> Mittelstaedt >> >>>>> <[EMAIL PROTECTED]> >> >>>>> wrote: >> >>>>> >> >>>>>> >> >>>>>> >
RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
LOL. Trying to dig ditches with ice cream sticks boys? --- Ted Mittelstaedt <[EMAIL PROTECTED]> wrote: > > Sasa, > > Try this ping flooder then: > > http://my-security.net/outofsite/ICMP%20Ping%20Flood.zip > > Ted > > >-Original Message- > >From: Sasa Stupar > [mailto:[EMAIL PROTECTED] > >Sent: Monday, December 19, 2005 12:00 AM > >To: Ted Mittelstaedt; > freebsd-questions@freebsd.org > >Subject: RE: Polling For 100 mbps Connections? > (Was Re: Freebsd Theme > >Song) > > > > > >It doesn't work on winxp. I am going to build > another machine > >with FreeBSD > >5.4 and I'll try it then and let you know the > results. > > > >Sasa > > > >--On 18. december 2005 14:02 -0800 Ted > Mittelstaedt > ><[EMAIL PROTECTED]> > >wrote: > > > >> > >> In looking at this again, I didn't realize > you were pinging from > >> Win2K > >> > >> Win2K uses the -f option to set the Do Not > Fragment bit, UNIX uses > >> the -f option to flood ping. Win2k ping > does not have a flood ping > >> option. You can download a ping for Windows > from Microsoft here: > >> > >> > http://research.microsoft.com/barc/mbone/mping.aspx > >> > >> that does have an option for flooding > traffic. ( set the milliseconds > >> between packets very low) but I have not > tested it. Doubtless > >> others are available on the Internet. > >> > >> Ted > >> > >>> -Original Message- > >>> From: [EMAIL PROTECTED] > >>> > [mailto:[EMAIL PROTECTED] > Behalf Of Sasa Stupar > >>> Sent: Sunday, December 18, 2005 6:07 AM > >>> To: Ted Mittelstaedt; > freebsd-questions@freebsd.org > >>> Subject: RE: Polling For 100 mbps > Connections? (Was Re: Freebsd Theme > >>> Song) > >>> > >>> > >>> Nothing. From the GUI view it is at 0% of > utilisation. > >>> > >>> Sasa > >>> > >>> --On 18. december 2005 3:51 -0800 Ted > Mittelstaedt > >>> <[EMAIL PROTECTED]> > >>> wrote: > >>> > >>>> > >>>> what does the CPU of the router do when > your doing that? > >>>> > >>>> Ted > >>>> > >>>>> -Original Message- > >>>>> From: [EMAIL PROTECTED] > >>>>> > [mailto:[EMAIL PROTECTED] > Behalf Of > >Sasa Stupar > >>>>> Sent: Sunday, December 18, 2005 3:00 AM > >>>>> To: Ted Mittelstaedt; > freebsd-questions@freebsd.org > >>>>> Subject: RE: Polling For 100 mbps > Connections? (Was Re: > >Freebsd Theme > >>>>> Song) > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> --On 18. december 2005 2:32 -0800 Ted > Mittelstaedt > >>>>> <[EMAIL PROTECTED]> > >>>>> wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>>> -Original Message- > >>>>>>> From: > [EMAIL PROTECTED] > >>>>>>> > [mailto:[EMAIL PROTECTED] > Behalf Of > >>> Sasa Stupar > >>>>>>> Sent: Sunday, December 18, 2005 2:21 AM > >>>>>>> To: Ted Mittelstaedt; > freebsd-questions@freebsd.org > >>>>>>> Subject: RE: Polling For 100 mbps > Connections? (Was Re: Freebsd > >>>>>>> Theme Song) > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> --On 18. december 2005 1:33 -0800 Ted > Mittelstaedt > >>>>>>> <[EMAIL PROTECTED]> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> -Original Message- > >>>>>>>>> From: Sasa Stupar > [mailto:[EMAIL PROTECTED] > >>>>>>>>> Sent: Friday, December 16, 2005 5:25 > AM > >>>>>>>>> To: Ted Mittelstaedt; > [EMAIL PROTECTED]; Drew Tomlinson > >>>>>>>>> Cc: freebsd-questions@freebsd.org > >>>>>>>>> Subject: RE: Polling For 100 mbps > Connections? (Was Re: Freebsd > >>>
RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
Sasa, Try this ping flooder then: http://my-security.net/outofsite/ICMP%20Ping%20Flood.zip Ted >-Original Message- >From: Sasa Stupar [mailto:[EMAIL PROTECTED] >Sent: Monday, December 19, 2005 12:00 AM >To: Ted Mittelstaedt; freebsd-questions@freebsd.org >Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme >Song) > > >It doesn't work on winxp. I am going to build another machine >with FreeBSD >5.4 and I'll try it then and let you know the results. > >Sasa > >--On 18. december 2005 14:02 -0800 Ted Mittelstaedt ><[EMAIL PROTECTED]> >wrote: > >> >> In looking at this again, I didn't realize you were pinging from >> Win2K >> >> Win2K uses the -f option to set the Do Not Fragment bit, UNIX uses >> the -f option to flood ping. Win2k ping does not have a flood ping >> option. You can download a ping for Windows from Microsoft here: >> >> http://research.microsoft.com/barc/mbone/mping.aspx >> >> that does have an option for flooding traffic. ( set the milliseconds >> between packets very low) but I have not tested it. Doubtless >> others are available on the Internet. >> >> Ted >> >>> -Original Message- >>> From: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] Behalf Of Sasa Stupar >>> Sent: Sunday, December 18, 2005 6:07 AM >>> To: Ted Mittelstaedt; freebsd-questions@freebsd.org >>> Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme >>> Song) >>> >>> >>> Nothing. From the GUI view it is at 0% of utilisation. >>> >>> Sasa >>> >>> --On 18. december 2005 3:51 -0800 Ted Mittelstaedt >>> <[EMAIL PROTECTED]> >>> wrote: >>> >>>> >>>> what does the CPU of the router do when your doing that? >>>> >>>> Ted >>>> >>>>> -Original Message- >>>>> From: [EMAIL PROTECTED] >>>>> [mailto:[EMAIL PROTECTED] Behalf Of >Sasa Stupar >>>>> Sent: Sunday, December 18, 2005 3:00 AM >>>>> To: Ted Mittelstaedt; freebsd-questions@freebsd.org >>>>> Subject: RE: Polling For 100 mbps Connections? (Was Re: >Freebsd Theme >>>>> Song) >>>>> >>>>> >>>>> >>>>> >>>>> --On 18. december 2005 2:32 -0800 Ted Mittelstaedt >>>>> <[EMAIL PROTECTED]> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>>> -Original Message- >>>>>>> From: [EMAIL PROTECTED] >>>>>>> [mailto:[EMAIL PROTECTED] Behalf Of >>> Sasa Stupar >>>>>>> Sent: Sunday, December 18, 2005 2:21 AM >>>>>>> To: Ted Mittelstaedt; freebsd-questions@freebsd.org >>>>>>> Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd >>>>>>> Theme Song) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> --On 18. december 2005 1:33 -0800 Ted Mittelstaedt >>>>>>> <[EMAIL PROTECTED]> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -Original Message- >>>>>>>>> From: Sasa Stupar [mailto:[EMAIL PROTECTED] >>>>>>>>> Sent: Friday, December 16, 2005 5:25 AM >>>>>>>>> To: Ted Mittelstaedt; [EMAIL PROTECTED]; Drew Tomlinson >>>>>>>>> Cc: freebsd-questions@freebsd.org >>>>>>>>> Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd >>>>>>>>> Theme Song) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> --On 16. december 2005 3:36 -0800 Ted Mittelstaedt >>>>>>>>> <[EMAIL PROTECTED]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -Original Message- >>>>>>>>>>> From: Sasa Stupar [mailto:[EMAIL PROTECTED] >>>>>>>>>>> Sent: Thursday, December 15, 2005 12:34 AM >>>>>>>>>>> To: Ted Mittelstaedt; [EMAIL PROTECTED]
RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
It doesn't work on winxp. I am going to build another machine with FreeBSD 5.4 and I'll try it then and let you know the results. Sasa --On 18. december 2005 14:02 -0800 Ted Mittelstaedt <[EMAIL PROTECTED]> wrote: In looking at this again, I didn't realize you were pinging from Win2K Win2K uses the -f option to set the Do Not Fragment bit, UNIX uses the -f option to flood ping. Win2k ping does not have a flood ping option. You can download a ping for Windows from Microsoft here: http://research.microsoft.com/barc/mbone/mping.aspx that does have an option for flooding traffic. ( set the milliseconds between packets very low) but I have not tested it. Doubtless others are available on the Internet. Ted -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Sasa Stupar Sent: Sunday, December 18, 2005 6:07 AM To: Ted Mittelstaedt; freebsd-questions@freebsd.org Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song) Nothing. From the GUI view it is at 0% of utilisation. Sasa --On 18. december 2005 3:51 -0800 Ted Mittelstaedt <[EMAIL PROTECTED]> wrote: what does the CPU of the router do when your doing that? Ted -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Sasa Stupar Sent: Sunday, December 18, 2005 3:00 AM To: Ted Mittelstaedt; freebsd-questions@freebsd.org Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song) --On 18. december 2005 2:32 -0800 Ted Mittelstaedt <[EMAIL PROTECTED]> wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Sasa Stupar Sent: Sunday, December 18, 2005 2:21 AM To: Ted Mittelstaedt; freebsd-questions@freebsd.org Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song) --On 18. december 2005 1:33 -0800 Ted Mittelstaedt <[EMAIL PROTECTED]> wrote: -Original Message- From: Sasa Stupar [mailto:[EMAIL PROTECTED] Sent: Friday, December 16, 2005 5:25 AM To: Ted Mittelstaedt; [EMAIL PROTECTED]; Drew Tomlinson Cc: freebsd-questions@freebsd.org Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song) --On 16. december 2005 3:36 -0800 Ted Mittelstaedt <[EMAIL PROTECTED]> wrote: -Original Message- From: Sasa Stupar [mailto:[EMAIL PROTECTED] Sent: Thursday, December 15, 2005 12:34 AM To: Ted Mittelstaedt; [EMAIL PROTECTED]; Drew Tomlinson Cc: freebsd-questions@freebsd.org Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song) 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). what are the cpu speeds and operating systems of all devices in the packet path, what is the make and model of switchs in use, provide dmesg output of the bsd box, a network diagram of the setup, etc. etc. etc. The above test results are not replicatable and thus, worthless. Useful test results would allow a reader to build an exact duplicate of your setup, config it identically, and get identical results. Ted OK. The server (192.168.1.200) is FreeBSD 5.4 with Duron 900 and 3C905C The 3com 3c905 is not a very good card under FreeBSD the driver was written without support from 3com and is shakey on a lot of hardware. I would say there's a big question that your server is actually saturating the ethernet. Probably that is why your only getting 90Mbt. NIC; router is m0n0wall (FreeBSD 4.11) with three Intel Pro/100S Nics and Celeron 433; The user computer (192.168.10.249) is Celeron 2400 with winxp and integrated NIC Realtek 8139 series. Switch is CNET CNSH-1600. Once again, the winxp+realtek 8139 is not a particularly steller combo, I would question that this system could saturate the ethernet, either. Diagram: <http://me.homelinux.net/network.pdf> dmesg from the router: $ dmesg Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
In looking at this again, I didn't realize you were pinging from Win2K Win2K uses the -f option to set the Do Not Fragment bit, UNIX uses the -f option to flood ping. Win2k ping does not have a flood ping option. You can download a ping for Windows from Microsoft here: http://research.microsoft.com/barc/mbone/mping.aspx that does have an option for flooding traffic. ( set the milliseconds between packets very low) but I have not tested it. Doubtless others are available on the Internet. Ted >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] Behalf Of Sasa Stupar >Sent: Sunday, December 18, 2005 6:07 AM >To: Ted Mittelstaedt; freebsd-questions@freebsd.org >Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme >Song) > > >Nothing. From the GUI view it is at 0% of utilisation. > >Sasa > >--On 18. december 2005 3:51 -0800 Ted Mittelstaedt ><[EMAIL PROTECTED]> >wrote: > >> >> what does the CPU of the router do when your doing that? >> >> Ted >> >>> -Original Message- >>> From: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] Behalf Of Sasa Stupar >>> Sent: Sunday, December 18, 2005 3:00 AM >>> To: Ted Mittelstaedt; freebsd-questions@freebsd.org >>> Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme >>> Song) >>> >>> >>> >>> >>> --On 18. december 2005 2:32 -0800 Ted Mittelstaedt >>> <[EMAIL PROTECTED]> >>> wrote: >>> >>>> >>>> >>>>> -----Original Message- >>>>> From: [EMAIL PROTECTED] >>>>> [mailto:[EMAIL PROTECTED] Behalf Of >Sasa Stupar >>>>> Sent: Sunday, December 18, 2005 2:21 AM >>>>> To: Ted Mittelstaedt; freebsd-questions@freebsd.org >>>>> Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd >>>>> Theme Song) >>>>> >>>>> >>>>> >>>>> >>>>> --On 18. december 2005 1:33 -0800 Ted Mittelstaedt >>>>> <[EMAIL PROTECTED]> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>>> -Original Message- >>>>>>> From: Sasa Stupar [mailto:[EMAIL PROTECTED] >>>>>>> Sent: Friday, December 16, 2005 5:25 AM >>>>>>> To: Ted Mittelstaedt; [EMAIL PROTECTED]; Drew Tomlinson >>>>>>> Cc: freebsd-questions@freebsd.org >>>>>>> Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd >>>>>>> Theme Song) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> --On 16. december 2005 3:36 -0800 Ted Mittelstaedt >>>>>>> <[EMAIL PROTECTED]> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -Original Message- >>>>>>>>> From: Sasa Stupar [mailto:[EMAIL PROTECTED] >>>>>>>>> Sent: Thursday, December 15, 2005 12:34 AM >>>>>>>>> To: Ted Mittelstaedt; [EMAIL PROTECTED]; Drew Tomlinson >>>>>>>>> Cc: freebsd-questions@freebsd.org >>>>>>>>> Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd >>>>>>>>> Theme Song) >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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. >>>>>>>>> >>
RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
Nothing. From the GUI view it is at 0% of utilisation. Sasa --On 18. december 2005 3:51 -0800 Ted Mittelstaedt <[EMAIL PROTECTED]> wrote: what does the CPU of the router do when your doing that? Ted -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Sasa Stupar Sent: Sunday, December 18, 2005 3:00 AM To: Ted Mittelstaedt; freebsd-questions@freebsd.org Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song) --On 18. december 2005 2:32 -0800 Ted Mittelstaedt <[EMAIL PROTECTED]> wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Sasa Stupar Sent: Sunday, December 18, 2005 2:21 AM To: Ted Mittelstaedt; freebsd-questions@freebsd.org Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song) --On 18. december 2005 1:33 -0800 Ted Mittelstaedt <[EMAIL PROTECTED]> wrote: -Original Message- From: Sasa Stupar [mailto:[EMAIL PROTECTED] Sent: Friday, December 16, 2005 5:25 AM To: Ted Mittelstaedt; [EMAIL PROTECTED]; Drew Tomlinson Cc: freebsd-questions@freebsd.org Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song) --On 16. december 2005 3:36 -0800 Ted Mittelstaedt <[EMAIL PROTECTED]> wrote: -Original Message- From: Sasa Stupar [mailto:[EMAIL PROTECTED] Sent: Thursday, December 15, 2005 12:34 AM To: Ted Mittelstaedt; [EMAIL PROTECTED]; Drew Tomlinson Cc: freebsd-questions@freebsd.org Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song) 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). what are the cpu speeds and operating systems of all devices in the packet path, what is the make and model of switchs in use, provide dmesg output of the bsd box, a network diagram of the setup, etc. etc. etc. The above test results are not replicatable and thus, worthless. Useful test results would allow a reader to build an exact duplicate of your setup, config it identically, and get identical results. Ted OK. The server (192.168.1.200) is FreeBSD 5.4 with Duron 900 and 3C905C The 3com 3c905 is not a very good card under FreeBSD the driver was written without support from 3com and is shakey on a lot of hardware. I would say there's a big question that your server is actually saturating the ethernet. Probably that is why your only getting 90Mbt. NIC; router is m0n0wall (FreeBSD 4.11) with three Intel Pro/100S Nics and Celeron 433; The user computer (192.168.10.249) is Celeron 2400 with winxp and integrated NIC Realtek 8139 series. Switch is CNET CNSH-1600. Once again, the winxp+realtek 8139 is not a particularly steller combo, I would question that this system could saturate the ethernet, either. Diagram: <http://me.homelinux.net/network.pdf> dmesg from the router: $ dmesg Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.11-RELEASE-p11 #0: Wed Sep 7 13:49:09 CEST 2005 [EMAIL PROTECTED]:/usr/src/sys/compile/M0N0WALL_GENERIC Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (434.32-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x665 Stepping = 5 Features=0x183f9ff real memory = 201326592 (196608K bytes) avail memory = 179142656 (174944K bytes) Preloaded elf kernel "kernel" at 0xc1006000. Preloaded mfs_root "/mfsroot" at 0xc100609c. Pentium Pro MTRR support enabled md0: Preloaded image 11534336 bytes at 0xc0504d9c md1: Malloc disk Using $PIR table, 8 entries at 0xc00fdef0 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0:
RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
what does the CPU of the router do when your doing that? Ted >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] Behalf Of Sasa Stupar >Sent: Sunday, December 18, 2005 3:00 AM >To: Ted Mittelstaedt; freebsd-questions@freebsd.org >Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme >Song) > > > > >--On 18. december 2005 2:32 -0800 Ted Mittelstaedt ><[EMAIL PROTECTED]> >wrote: > >> >> >>> -Original Message- >>> From: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] Behalf Of Sasa Stupar >>> Sent: Sunday, December 18, 2005 2:21 AM >>> To: Ted Mittelstaedt; freebsd-questions@freebsd.org >>> Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd >>> Theme Song) >>> >>> >>> >>> >>> --On 18. december 2005 1:33 -0800 Ted Mittelstaedt >>> <[EMAIL PROTECTED]> >>> wrote: >>> >>>> >>>> >>>>> -Original Message- >>>>> From: Sasa Stupar [mailto:[EMAIL PROTECTED] >>>>> Sent: Friday, December 16, 2005 5:25 AM >>>>> To: Ted Mittelstaedt; [EMAIL PROTECTED]; Drew Tomlinson >>>>> Cc: freebsd-questions@freebsd.org >>>>> Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd >>>>> Theme Song) >>>>> >>>>> >>>>> >>>>> >>>>> --On 16. december 2005 3:36 -0800 Ted Mittelstaedt >>>>> <[EMAIL PROTECTED]> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>>> -Original Message- >>>>>>> From: Sasa Stupar [mailto:[EMAIL PROTECTED] >>>>>>> Sent: Thursday, December 15, 2005 12:34 AM >>>>>>> To: Ted Mittelstaedt; [EMAIL PROTECTED]; Drew Tomlinson >>>>>>> Cc: freebsd-questions@freebsd.org >>>>>>> Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd >>>>>>> Theme Song) >>>>>>> >>>>>>>> >>>>>>>> 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). >>>>>>> >>>>>> >>>>>> what are the cpu speeds and operating systems of all devices >>>>>> in the packet path, what is the make and model of switchs in >>>>>> use, provide dmesg output of the bsd box, a network diagram >>>>>> of the setup, etc. etc. etc. >>>>>> >>>>>> The above test results are not replicatable and thus, worthless. >>>>>> Useful test results would allow a reader to build an exact >>>>>> duplicate of your setup, config it identically, and get identical >>>>>> results. >>>>>> >>>>>> Ted >>>>>> >>>>> >>>>> OK. The s
RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
--On 18. december 2005 2:32 -0800 Ted Mittelstaedt <[EMAIL PROTECTED]> wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Sasa Stupar Sent: Sunday, December 18, 2005 2:21 AM To: Ted Mittelstaedt; freebsd-questions@freebsd.org Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song) --On 18. december 2005 1:33 -0800 Ted Mittelstaedt <[EMAIL PROTECTED]> wrote: -Original Message- From: Sasa Stupar [mailto:[EMAIL PROTECTED] Sent: Friday, December 16, 2005 5:25 AM To: Ted Mittelstaedt; [EMAIL PROTECTED]; Drew Tomlinson Cc: freebsd-questions@freebsd.org Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song) --On 16. december 2005 3:36 -0800 Ted Mittelstaedt <[EMAIL PROTECTED]> wrote: -Original Message- From: Sasa Stupar [mailto:[EMAIL PROTECTED] Sent: Thursday, December 15, 2005 12:34 AM To: Ted Mittelstaedt; [EMAIL PROTECTED]; Drew Tomlinson Cc: freebsd-questions@freebsd.org Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song) 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). what are the cpu speeds and operating systems of all devices in the packet path, what is the make and model of switchs in use, provide dmesg output of the bsd box, a network diagram of the setup, etc. etc. etc. The above test results are not replicatable and thus, worthless. Useful test results would allow a reader to build an exact duplicate of your setup, config it identically, and get identical results. Ted OK. The server (192.168.1.200) is FreeBSD 5.4 with Duron 900 and 3C905C The 3com 3c905 is not a very good card under FreeBSD the driver was written without support from 3com and is shakey on a lot of hardware. I would say there's a big question that your server is actually saturating the ethernet. Probably that is why your only getting 90Mbt. NIC; router is m0n0wall (FreeBSD 4.11) with three Intel Pro/100S Nics and Celeron 433; The user computer (192.168.10.249) is Celeron 2400 with winxp and integrated NIC Realtek 8139 series. Switch is CNET CNSH-1600. Once again, the winxp+realtek 8139 is not a particularly steller combo, I would question that this system could saturate the ethernet, either. Diagram: <http://me.homelinux.net/network.pdf> dmesg from the router: $ dmesg Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.11-RELEASE-p11 #0: Wed Sep 7 13:49:09 CEST 2005 [EMAIL PROTECTED]:/usr/src/sys/compile/M0N0WALL_GENERIC Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (434.32-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x665 Stepping = 5 Features=0x183f9ff real memory = 201326592 (196608K bytes) avail memory = 179142656 (174944K bytes) Preloaded elf kernel "kernel" at 0xc1006000. Preloaded mfs_root "/mfsroot" at 0xc100609c. Pentium Pro MTRR support enabled md0: Preloaded image 11534336 bytes at 0xc0504d9c md1: Malloc disk Using $PIR table, 8 entries at 0xc00fdef0 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xd000-0xd01f irq 11 at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered chip1: port 0x5000-0x500f at device 7.3 on pci0 pci0: (vendor=0x1274, dev=0x1371) at 8.0 irq 11 fxp0: port 0xd800-0xd83f mem 0xd040-0xd041,0xd046-0xd0460fff irq 10 at device 15.0 on pci0 fxp0: Ethernet address 00:02:b3:62:f6:06 inphy0: on miibus0 inphy0: 10baseT, 10ba
RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
>-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] Behalf Of Sasa Stupar >Sent: Sunday, December 18, 2005 2:21 AM >To: Ted Mittelstaedt; freebsd-questions@freebsd.org >Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd >Theme Song) > > > > >--On 18. december 2005 1:33 -0800 Ted Mittelstaedt ><[EMAIL PROTECTED]> >wrote: > >> >> >>> -Original Message- >>> From: Sasa Stupar [mailto:[EMAIL PROTECTED] >>> Sent: Friday, December 16, 2005 5:25 AM >>> To: Ted Mittelstaedt; [EMAIL PROTECTED]; Drew Tomlinson >>> Cc: freebsd-questions@freebsd.org >>> Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd >>> Theme Song) >>> >>> >>> >>> >>> --On 16. december 2005 3:36 -0800 Ted Mittelstaedt >>> <[EMAIL PROTECTED]> >>> wrote: >>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Sasa Stupar [mailto:[EMAIL PROTECTED] >>>>> Sent: Thursday, December 15, 2005 12:34 AM >>>>> To: Ted Mittelstaedt; [EMAIL PROTECTED]; Drew Tomlinson >>>>> Cc: freebsd-questions@freebsd.org >>>>> Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd >>>>> Theme Song) >>>>> >>>>>> >>>>>> 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). >>>>> >>>> >>>> what are the cpu speeds and operating systems of all devices >>>> in the packet path, what is the make and model of switchs in >>>> use, provide dmesg output of the bsd box, a network diagram >>>> of the setup, etc. etc. etc. >>>> >>>> The above test results are not replicatable and thus, worthless. >>>> Useful test results would allow a reader to build an exact >>>> duplicate of your setup, config it identically, and get identical >>>> results. >>>> >>>> Ted >>>> >>> >>> OK. The server (192.168.1.200) is FreeBSD 5.4 with Duron 900 >and 3C905C >> >> The 3com 3c905 is not a very good card under FreeBSD the driver was >> written >> without support from 3com and is shakey on a lot of hardware. I would >> say >> there's a big question that your server is actually saturating the >> ethernet. >> Probably that is why your only getting 90Mbt. >> >>> NIC; router is m0n0wall (FreeBSD 4.11) with three Intel >>> Pro/100S Nics and >>> Celeron 433; The user computer (192.168.10.249) is Celeron 2400 >>> with winxp >>> and integrated NIC Realtek 8139 series. Switch is CNET CNSH-1600. >>> >> >> Once again, the winxp+realtek 8139 is not a particularly >steller combo, >> I would question that this system could saturate the ethernet, either. >> >>> Diagram: <http://me.homelinux.net/network.pdf> >>> >>> dmesg from the router: >>> >>> $ dmesg >>> Copyright (c) 1992-2005 The FreeBSD Project. >>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, >1992, 1993
RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
--On 18. december 2005 1:33 -0800 Ted Mittelstaedt <[EMAIL PROTECTED]> wrote: -Original Message- From: Sasa Stupar [mailto:[EMAIL PROTECTED] Sent: Friday, December 16, 2005 5:25 AM To: Ted Mittelstaedt; [EMAIL PROTECTED]; Drew Tomlinson Cc: freebsd-questions@freebsd.org Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song) --On 16. december 2005 3:36 -0800 Ted Mittelstaedt <[EMAIL PROTECTED]> wrote: -Original Message- From: Sasa Stupar [mailto:[EMAIL PROTECTED] Sent: Thursday, December 15, 2005 12:34 AM To: Ted Mittelstaedt; [EMAIL PROTECTED]; Drew Tomlinson Cc: freebsd-questions@freebsd.org Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song) 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). what are the cpu speeds and operating systems of all devices in the packet path, what is the make and model of switchs in use, provide dmesg output of the bsd box, a network diagram of the setup, etc. etc. etc. The above test results are not replicatable and thus, worthless. Useful test results would allow a reader to build an exact duplicate of your setup, config it identically, and get identical results. Ted OK. The server (192.168.1.200) is FreeBSD 5.4 with Duron 900 and 3C905C The 3com 3c905 is not a very good card under FreeBSD the driver was written without support from 3com and is shakey on a lot of hardware. I would say there's a big question that your server is actually saturating the ethernet. Probably that is why your only getting 90Mbt. NIC; router is m0n0wall (FreeBSD 4.11) with three Intel Pro/100S Nics and Celeron 433; The user computer (192.168.10.249) is Celeron 2400 with winxp and integrated NIC Realtek 8139 series. Switch is CNET CNSH-1600. Once again, the winxp+realtek 8139 is not a particularly steller combo, I would question that this system could saturate the ethernet, either. Diagram: <http://me.homelinux.net/network.pdf> dmesg from the router: $ dmesg Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.11-RELEASE-p11 #0: Wed Sep 7 13:49:09 CEST 2005 [EMAIL PROTECTED]:/usr/src/sys/compile/M0N0WALL_GENERIC Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (434.32-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x665 Stepping = 5 Features=0x183f9ff real memory = 201326592 (196608K bytes) avail memory = 179142656 (174944K bytes) Preloaded elf kernel "kernel" at 0xc1006000. Preloaded mfs_root "/mfsroot" at 0xc100609c. Pentium Pro MTRR support enabled md0: Preloaded image 11534336 bytes at 0xc0504d9c md1: Malloc disk Using $PIR table, 8 entries at 0xc00fdef0 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xd000-0xd01f irq 11 at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered chip1: port 0x5000-0x500f at device 7.3 on pci0 pci0: (vendor=0x1274, dev=0x1371) at 8.0 irq 11 fxp0: port 0xd800-0xd83f mem 0xd040-0xd041,0xd046-0xd0460fff irq 10 at device 15.0 on pci0 fxp0: Ethernet address 00:02:b3:62:f6:06 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: port 0xdc00-0xdc3f mem 0xd042-0xd043,0xd0462000-0xd0462fff irq 12 at device 16.0 on pci0 fxp1: Ethernet address 00:02:b3:9c:2a:16 inphy1: on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp2: port 0xe000-0xe03f mem 0xd044-0xd045,0xd0461000-0xd0461fff irq 7 at device 19.0 on pc
RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
>-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] Behalf Of Danial Thom >Sent: Friday, December 16, 2005 7:36 AM >To: Sasa Stupar; freebsd-questions@freebsd.org >Subject: Re: Polling For 100 mbps Connections? (Was Re: Freebsd Theme >Song) > > > > >--- Sasa Stupar <[EMAIL PROTECTED]> >wrote: > >> >> >> --On 15. december 2005 6:33 -0800 Drew >> Tomlinson <[EMAIL PROTECTED]> >> wrote: >> >> > On 12/15/2005 12:33 AM Sasa Stupar wrote: >> > >> >> >> >> >> >> --On 14. december 2005 20:01 -0800 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 >> r
RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
>-Original Message- >From: Sasa Stupar [mailto:[EMAIL PROTECTED] >Sent: Friday, December 16, 2005 5:25 AM >To: Ted Mittelstaedt; [EMAIL PROTECTED]; Drew Tomlinson >Cc: freebsd-questions@freebsd.org >Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd >Theme Song) > > > > >--On 16. december 2005 3:36 -0800 Ted Mittelstaedt ><[EMAIL PROTECTED]> >wrote: > >> >> >>> -Original Message- >>> From: Sasa Stupar [mailto:[EMAIL PROTECTED] >>> Sent: Thursday, December 15, 2005 12:34 AM >>> To: Ted Mittelstaedt; [EMAIL PROTECTED]; Drew Tomlinson >>> Cc: freebsd-questions@freebsd.org >>> Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd >>> Theme Song) >>> >>>> >>>> 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). >>> >> >> what are the cpu speeds and operating systems of all devices >> in the packet path, what is the make and model of switchs in >> use, provide dmesg output of the bsd box, a network diagram >> of the setup, etc. etc. etc. >> >> The above test results are not replicatable and thus, worthless. >> Useful test results would allow a reader to build an exact >> duplicate of your setup, config it identically, and get identical >> results. >> >> Ted >> > >OK. The server (192.168.1.200) is FreeBSD 5.4 with Duron 900 and 3C905C The 3com 3c905 is not a very good card under FreeBSD the driver was written without support from 3com and is shakey on a lot of hardware. I would say there's a big question that your server is actually saturating the ethernet. Probably that is why your only getting 90Mbt. >NIC; router is m0n0wall (FreeBSD 4.11) with three Intel >Pro/100S Nics and >Celeron 433; The user computer (192.168.10.249) is Celeron 2400 >with winxp >and integrated NIC Realtek 8139 series. Switch is CNET CNSH-1600. > Once again, the winxp+realtek 8139 is not a particularly steller combo, I would question that this system could saturate the ethernet, either. >Diagram: <http://me.homelinux.net/network.pdf> > >dmesg from the router: > >$ dmesg >Copyright (c) 1992-2005 The FreeBSD Project. >Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >The Regents of the University of California. All rights reserved. >FreeBSD 4.11-RELEASE-p11 #0: Wed Sep 7 13:49:09 CEST 2005 >[EMAIL PROTECTED]:/usr/src/sys/compile/M0N0WALL_GENERIC >Timecounter "i8254" frequency 1193182 Hz >CPU: Pentium II/Pentium II Xeon/Celeron (434.32-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x665 Stepping = 5 > >Features=0x183f9ffGE,MCA,CMOV,PAT,PSE36,MMX,FXSR> >real memory = 201326592 (196608K bytes) >avail memory = 179142656 (174944K bytes) >Preloaded elf kernel "kernel" at 0xc1006000. >Preloaded mfs_root "/mfsroot" at 0xc100609c. >Pentium Pro MTRR support enabled >md0: Preloaded image 11534336 bytes at 0xc0504d9c >md1: Malloc disk >Using $PIR table, 8 entries at 0xc00fdef0 >npx0: on motherboard >npx0: INT 16 interface >pcib0: on motherboard >pci0: on pcib0 >pcib1: at device >1.0 on pci0 >pci1: on pcib1 >isab0: at device 7.0 on pci0 >isa0: on isab0 >atapci0: port 0xf000-0xf00f at >device 7.1 on >pci0 >ata0: at 0x1f0 irq 14 on atapci0 >ata1: at 0x170 irq 15 on atapci0 >uhci0: port >0xd000-0xd01f irq 11 >at device 7.2 on pci0 >
RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
>-Original Message- >From: Danial Thom [mailto:[EMAIL PROTECTED] >Sent: Thursday, December 15, 2005 11:42 AM >To: Ted Mittelstaedt >Cc: freebsd-questions@freebsd.org >Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme >Song) > > > > >--- 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. > Duh, but that wasn'
Re: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
--- Sasa Stupar <[EMAIL PROTECTED]> wrote: > > > --On 15. december 2005 6:33 -0800 Drew > Tomlinson <[EMAIL PROTECTED]> > wrote: > > > On 12/15/2005 12:33 AM Sasa Stupar wrote: > > > >> > >> > >> --On 14. december 2005 20:01 -0800 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, > >
RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
--On 16. december 2005 3:36 -0800 Ted Mittelstaedt <[EMAIL PROTECTED]> wrote: -Original Message- From: Sasa Stupar [mailto:[EMAIL PROTECTED] Sent: Thursday, December 15, 2005 12:34 AM To: Ted Mittelstaedt; [EMAIL PROTECTED]; Drew Tomlinson Cc: freebsd-questions@freebsd.org Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song) 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). what are the cpu speeds and operating systems of all devices in the packet path, what is the make and model of switchs in use, provide dmesg output of the bsd box, a network diagram of the setup, etc. etc. etc. The above test results are not replicatable and thus, worthless. Useful test results would allow a reader to build an exact duplicate of your setup, config it identically, and get identical results. Ted OK. The server (192.168.1.200) is FreeBSD 5.4 with Duron 900 and 3C905C NIC; router is m0n0wall (FreeBSD 4.11) with three Intel Pro/100S Nics and Celeron 433; The user computer (192.168.10.249) is Celeron 2400 with winxp and integrated NIC Realtek 8139 series. Switch is CNET CNSH-1600. Diagram: <http://me.homelinux.net/network.pdf> dmesg from the router: $ dmesg Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.11-RELEASE-p11 #0: Wed Sep 7 13:49:09 CEST 2005 [EMAIL PROTECTED]:/usr/src/sys/compile/M0N0WALL_GENERIC Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (434.32-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x665 Stepping = 5 Features=0x183f9ff real memory = 201326592 (196608K bytes) avail memory = 179142656 (174944K bytes) Preloaded elf kernel "kernel" at 0xc1006000. Preloaded mfs_root "/mfsroot" at 0xc100609c. Pentium Pro MTRR support enabled md0: Preloaded image 11534336 bytes at 0xc0504d9c md1: Malloc disk Using $PIR table, 8 entries at 0xc00fdef0 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xd000-0xd01f irq 11 at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered chip1: port 0x5000-0x500f at device 7.3 on pci0 pci0: (vendor=0x1274, dev=0x1371) at 8.0 irq 11 fxp0: port 0xd800-0xd83f mem 0xd040-0xd041,0xd046-0xd0460fff irq 10 at device 15.0 on pci0 fxp0: Ethernet address 00:02:b3:62:f6:06 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: port 0xdc00-0xdc3f mem 0xd042-0xd043,0xd0462000-0xd0462fff irq 12 at device 16.0 on pci0 fxp1: Ethernet address 00:02:b3:9c:2a:16 inphy1: on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp2: port 0xe000-0xe03f mem 0xd044-0xd045,0xd0461000-0xd0461fff irq 7 at device 19.0 on pci0 fxp2: Ethernet address 00:02:b3:8c:e4:f6 inphy2: on miibus2 inphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pmtimer0 on isa0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1: configured irq 3 not in bitmap of probed irqs 0 BRIDGE 020214 loaded IPsec: Initialized Security Association Processing. IP Filter: v3.4.35 initialized. Default = block all, Logging = enabled ad0: 3098MB [6296/16/63] at ata0-master PIO4 acd0: CDROM at ata1-master PIO4 Mounting root from ufs:/dev/md0c fxp1: Microcode loaded, int_delay: 1000 usec bundle_max: 6 fxp0: Microcode loa
RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
>-Original Message- >From: Sasa Stupar [mailto:[EMAIL PROTECTED] >Sent: Thursday, December 15, 2005 12:34 AM >To: Ted Mittelstaedt; [EMAIL PROTECTED]; Drew Tomlinson >Cc: freebsd-questions@freebsd.org >Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd >Theme Song) > >> >> 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). > what are the cpu speeds and operating systems of all devices in the packet path, what is the make and model of switchs in use, provide dmesg output of the bsd box, a network diagram of the setup, etc. etc. etc. The above test results are not replicatable and thus, worthless. Useful test results would allow a reader to build an exact duplicate of your setup, config it identically, and get identical results. Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
--On 15. december 2005 6:33 -0800 Drew Tomlinson <[EMAIL PROTECTED]> wrote: On 12/15/2005 12:33 AM Sasa Stupar wrote: --On 14. december 2005 20:01 -0800 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. 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 underst
RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
--- 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 &
Re: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
On 12/15/2005 12:33 AM Sasa Stupar wrote: --On 14. december 2005 20:01 -0800 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. 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 packet
RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
--On 14. december 2005 20:01 -0800 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. 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
RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
>-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. >> >> 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 eff
RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
I also use polling on my Intel Pro/100S and I get inscrease of almoast 100% in speed. OK, My machine is Celeron 433 with 256 MB RAM and it is used as router. With iperf between DMZ and LAN with polling enabled I reach speed of 90 Mbit and without polling I can get speed only about 58 Mbit. So for me polling is good and I'll keep on using it. -- Sasa Stupar ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
--- Ted Mittelstaedt <[EMAIL PROTECTED]> wrote: > > > >-Original Message- > >From: [EMAIL PROTECTED] > >[mailto:[EMAIL PROTECTED] > Behalf Of Danial Thom > >Sent: Tuesday, December 13, 2005 11:07 AM > >To: Drew Tomlinson > >Cc: freebsd-questions@freebsd.org > >Subject: Re: Polling For 100 mbps Connections? > (Was Re: Freebsd Theme > >Song) > > > > > > > > > >--- Drew Tomlinson <[EMAIL PROTECTED]> > >wrote: > > > >> Ted Mittelstaedt wrote, On 12/13/2005 12:44 > AM: > >> > >> > > >> > > >> >>-Original Message- > >> >>From: Drew Tomlinson > >> [mailto:[EMAIL PROTECTED] > >> >>Sent: Monday, December 12, 2005 12:30 PM > >> >>To: Ted Mittelstaedt > >> >>Cc: Michael Vince; [EMAIL PROTECTED]; > >> freebsd-questions@freebsd.org; > >> >>Kris Kennaway > >> >>Subject: Polling For 100 mbps Connections? > >> (Was Re: Freebsd Theme Song) > >> >> > >> >> > >> >>On 12/12/2005 8:13 AM Ted Mittelstaedt > wrote: > >> >> > >> >> > >> >> > >> >>>Michael, > >> >>> > >> >>> Fundamentally, here's the problem Danial > is > >> claiming exists: > >> >>> > >> >>>it takes a certain amount of time to get > the > >> packet clocked in > >> >>> > >> >>> > >> >>>from the network into the ethernet > receiver. > >> This is hardware > >> >> > >> >> > >> >>>dependent and cannot be changed. > >> >>> > >> >>>It takes a certain amount of time to get > the > >> packet out of > >> >>>the hardware in the ethernet card into > main > >> ram, this also > >> >>>hardware dependent and cannot be changed. > >> (unless the device > >> >>>driver is terribly inefficient, which we > >> will assume it's not) > >> >>> > >> >>>Once in main ram, the information in the > >> packet has to go through > >> >>>a number of code statements. The more > code > >> statements the > >> >>>longer the information in the packet is > >> sitting around in > >> >>>the FreeBSD system's memory. > >> >>> > >> >>>It then takes a certain amount of time to > >> get the information > >> >>>out of main memory into the other sending > >> ethernet nic's buffers, > >> >>> > >> >>>and it takes time to get it out of the > >> sending nic back to the > >> >>>wire. > >> >>> > >> >>>Danial is claiming the slowness is in the > >> main ram section of > >> >>>things, not in the ethernet driver code. > >> >>> > >> >>>polling makes the ethernet driver more > >> efficient at high data > >> >>>rates, but it does nothing for the speed > of > >> processing within > >> >>>the TCPIP stack itself. At low data > rates > >> polling is less > >> >>>efficient than the interrupt method. And > >> unless the nic driver > >> >>>is terribly inefficient to start with, > the > >> time it adds to the > >> >>>packet path in the system is minor > compared > >> to the time spent > >> >>>in the TCP/IP stack. > >> >>> > >> >>>Ted > >> >>> > >> >>> > >> >>> > >> >>> > >> >>Thanks for the explanation. So would > polling > >> be beneficial or > >> >>detrimental for a 100 mbps Ethernet card? > >> >> > >> >> > >> > > >> >Yes, if you were running 100Mbt's of > bandwidth > >> through it. > >> > > >> > > >> > >> I assume you mean "yes it's beneficial"? :) > > > >Thats just not true, or at least not globally. > >The right answer is: It depends on the > hardware. > >Polling should NEVER be used for hardware that > >has built-in hardware interrupt throttling > (such > >as fxp and em driver cards). p
RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
>-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] Behalf Of Danial Thom >Sent: Tuesday, December 13, 2005 11:07 AM >To: Drew Tomlinson >Cc: freebsd-questions@freebsd.org >Subject: Re: Polling For 100 mbps Connections? (Was Re: Freebsd Theme >Song) > > > > >--- Drew Tomlinson <[EMAIL PROTECTED]> >wrote: > >> Ted Mittelstaedt wrote, On 12/13/2005 12:44 AM: >> >> > >> > >> >>-Original Message- >> >>From: Drew Tomlinson >> [mailto:[EMAIL PROTECTED] >> >>Sent: Monday, December 12, 2005 12:30 PM >> >>To: Ted Mittelstaedt >> >>Cc: Michael Vince; [EMAIL PROTECTED]; >> freebsd-questions@freebsd.org; >> >>Kris Kennaway >> >>Subject: Polling For 100 mbps Connections? >> (Was Re: Freebsd Theme Song) >> >> >> >> >> >>On 12/12/2005 8:13 AM Ted Mittelstaedt wrote: >> >> >> >> >> >> >> >>>Michael, >> >>> >> >>> Fundamentally, here's the problem Danial is >> claiming exists: >> >>> >> >>>it takes a certain amount of time to get the >> packet clocked in >> >>> >> >>> >> >>>from the network into the ethernet receiver. >> This is hardware >> >> >> >> >> >>>dependent and cannot be changed. >> >>> >> >>>It takes a certain amount of time to get the >> packet out of >> >>>the hardware in the ethernet card into main >> ram, this also >> >>>hardware dependent and cannot be changed. >> (unless the device >> >>>driver is terribly inefficient, which we >> will assume it's not) >> >>> >> >>>Once in main ram, the information in the >> packet has to go through >> >>>a number of code statements. The more code >> statements the >> >>>longer the information in the packet is >> sitting around in >> >>>the FreeBSD system's memory. >> >>> >> >>>It then takes a certain amount of time to >> get the information >> >>>out of main memory into the other sending >> ethernet nic's buffers, >> >>> >> >>>and it takes time to get it out of the >> sending nic back to the >> >>>wire. >> >>> >> >>>Danial is claiming the slowness is in the >> main ram section of >> >>>things, not in the ethernet driver code. >> >>> >> >>>polling makes the ethernet driver more >> efficient at high data >> >>>rates, but it does nothing for the speed of >> processing within >> >>>the TCPIP stack itself. At low data rates >> polling is less >> >>>efficient than the interrupt method. And >> unless the nic driver >> >>>is terribly inefficient to start with, the >> time it adds to the >> >>>packet path in the system is minor compared >> to the time spent >> >>>in the TCP/IP stack. >> >>> >> >>>Ted >> >>> >> >>> >> >>> >> >>> >> >>Thanks for the explanation. So would polling >> be beneficial or >> >>detrimental for a 100 mbps Ethernet card? >> >> >> >> >> > >> >Yes, if you were running 100Mbt's of bandwidth >> through it. >> > >> > >> >> I assume you mean "yes it's beneficial"? :) > >Thats just not true, or at least not globally. >The right answer is: It depends on the hardware. >Polling should NEVER be used for hardware that >has built-in hardware interrupt throttling (such >as fxp and em driver cards). polling has a LOT of >overhead. Hardware hold offs give you the benefit >of controlled interrupt reduction without >adulterating your system with tons of extra clock >interrupts. This has been discussed over and >over, and still some of the people who are >supposed to know about this have no clue >whatsoever. > 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? 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
RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
>-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] Behalf Of Danial Thom >Sent: Tuesday, December 13, 2005 10:46 AM >To: Ted Mittelstaedt; Drew Tomlinson >Cc: Michael Vince; freebsd-questions@freebsd.org; Kris Kennaway >Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme >Song) > So >specifically WHAT it is doesn't change my claim >the FreeBSD 5.x and 6.x suck, at least relative >to what you started with. If you take something >and make it worse, and seem to have no ability to >figure out WHY, then you're incompetent. Its as >simple as that. > >I have posted a reasonable test and results, No you have not. You have posted a general test, you have not posted exactly what you did and with exactly what hardware, nor that hardware's settings. > and >there are countless complaints about performance. > The -questions mailing list is self-selecting, what that means is that you only will see complaints on it. That is it's purpose. What your basically doing is standing at the door of the women's bathroom at the mall, and trying to determine the ratio of men to women in the mall by looking at every person that comes out of that door. >I think the fact that every time someone >complains Robert Watson tells them to "wait for >6.0, or wait for 7.0" is a pretty good indication >that things aren't what the Teds and Krises >claim. > What am I claiming? Danial once again you are proving you are nothing more than a blowhard - you haven't really read anything that I have said. What I have claimed repeatedly is that until you post verifyable, and repeatable benchmarks, along with the test methodology used to arrive at them, that your statements have no credibility. In other words, you have made some interesting accusations, now please get on with some supporting evidence. Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
>-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] Behalf Of Drew Tomlinson >Sent: Tuesday, December 13, 2005 6:48 AM >To: Ted Mittelstaedt >Cc: Michael Vince; [EMAIL PROTECTED]; freebsd-questions@freebsd.org; >Kris Kennaway >Subject: Re: Polling For 100 mbps Connections? (Was Re: Freebsd Theme >Song) > > >Ted Mittelstaedt wrote, On 12/13/2005 12:44 AM: > >> >> >>>-Original Message- >>>From: Drew Tomlinson [mailto:[EMAIL PROTECTED] >>>Sent: Monday, December 12, 2005 12:30 PM >>>To: Ted Mittelstaedt >>>Cc: Michael Vince; [EMAIL PROTECTED]; >freebsd-questions@freebsd.org; >>>Kris Kennaway >>>Subject: Polling For 100 mbps Connections? (Was Re: Freebsd >Theme Song) >>> >>> >>>On 12/12/2005 8:13 AM Ted Mittelstaedt wrote: >>> >>> >>> >>>>Michael, >>>> >>>> Fundamentally, here's the problem Danial is claiming exists: >>>> >>>>it takes a certain amount of time to get the packet clocked in >>>> >>>> >>>>from the network into the ethernet receiver. This is hardware >>> >>> >>>>dependent and cannot be changed. >>>> >>>>It takes a certain amount of time to get the packet out of >>>>the hardware in the ethernet card into main ram, this also >>>>hardware dependent and cannot be changed. (unless the device >>>>driver is terribly inefficient, which we will assume it's not) >>>> >>>>Once in main ram, the information in the packet has to go through >>>>a number of code statements. The more code statements the >>>>longer the information in the packet is sitting around in >>>>the FreeBSD system's memory. >>>> >>>>It then takes a certain amount of time to get the information >>>>out of main memory into the other sending ethernet nic's buffers, >>>> >>>>and it takes time to get it out of the sending nic back to the >>>>wire. >>>> >>>>Danial is claiming the slowness is in the main ram section of >>>>things, not in the ethernet driver code. >>>> >>>>polling makes the ethernet driver more efficient at high data >>>>rates, but it does nothing for the speed of processing within >>>>the TCPIP stack itself. At low data rates polling is less >>>>efficient than the interrupt method. And unless the nic driver >>>>is terribly inefficient to start with, the time it adds to the >>>>packet path in the system is minor compared to the time spent >>>>in the TCP/IP stack. >>>> >>>>Ted >>>> >>>> >>>> >>>> >>>Thanks for the explanation. So would polling be beneficial or >>>detrimental for a 100 mbps Ethernet card? >>> >>> >> >>Yes, if you were running 100Mbt's of bandwidth through it. >> >> > >I assume you mean "yes it's beneficial"? :) > Yes. :-) >>>Not sure if 100 mbps is >>>considered "high" or "low" speed. I'm specifically interested in >>>NetGear cards using the dc driver or DLink cards using the rl driver. >>> >>> >>> >> >>The rl chipset isn't known as a very good chipset. YMMV >> >> > >Yeah, I've heard that a lot. It was an old card I had lying around and >it seems to work OK for me. I'm not using it for anything other that >connecting to a 802.11b wireless bridge. Very little traffic. > This post is passing through 2 of these cards on my home BSD router. Fortunately these days since so many mboards are coming with onboard ethernet, the used market is awash in nice PCI ethernet cards. >>Some of the Netgear cards use clone 21143 chipsets which are >>extremely inferior to the real thing. In particular if your >>Netgear card is using a PNIC chipset it is pretty bad with serious >>performance penalty. This is documented in Section 4 of the >dc manpage. >> >> > >This is disapointing. I was under the impression that NetGear cards >were pretty good. But now I looked closer at dmesg.boot and see I have >the PNIC chipset you mention. I'll read the dc man page to see what >penalties I'm suffering. > >>People seem to have good results with polling on the fxp cards. >> >> > >Ah, the built in interface on a HP e60 server I have. It's an old dog >used as a file s
Re: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
--- Drew Tomlinson <[EMAIL PROTECTED]> wrote: > Ted Mittelstaedt wrote, On 12/13/2005 12:44 AM: > > > > > > >>-Original Message- > >>From: Drew Tomlinson > [mailto:[EMAIL PROTECTED] > >>Sent: Monday, December 12, 2005 12:30 PM > >>To: Ted Mittelstaedt > >>Cc: Michael Vince; [EMAIL PROTECTED]; > freebsd-questions@freebsd.org; > >>Kris Kennaway > >>Subject: Polling For 100 mbps Connections? > (Was Re: Freebsd Theme Song) > >> > >> > >>On 12/12/2005 8:13 AM Ted Mittelstaedt wrote: > >> > >> > >> > >>>Michael, > >>> > >>> Fundamentally, here's the problem Danial is > claiming exists: > >>> > >>>it takes a certain amount of time to get the > packet clocked in > >>> > >>> > >>>from the network into the ethernet receiver. > This is hardware > >> > >> > >>>dependent and cannot be changed. > >>> > >>>It takes a certain amount of time to get the > packet out of > >>>the hardware in the ethernet card into main > ram, this also > >>>hardware dependent and cannot be changed. > (unless the device > >>>driver is terribly inefficient, which we > will assume it's not) > >>> > >>>Once in main ram, the information in the > packet has to go through > >>>a number of code statements. The more code > statements the > >>>longer the information in the packet is > sitting around in > >>>the FreeBSD system's memory. > >>> > >>>It then takes a certain amount of time to > get the information > >>>out of main memory into the other sending > ethernet nic's buffers, > >>> > >>>and it takes time to get it out of the > sending nic back to the > >>>wire. > >>> > >>>Danial is claiming the slowness is in the > main ram section of > >>>things, not in the ethernet driver code. > >>> > >>>polling makes the ethernet driver more > efficient at high data > >>>rates, but it does nothing for the speed of > processing within > >>>the TCPIP stack itself. At low data rates > polling is less > >>>efficient than the interrupt method. And > unless the nic driver > >>>is terribly inefficient to start with, the > time it adds to the > >>>packet path in the system is minor compared > to the time spent > >>>in the TCP/IP stack. > >>> > >>>Ted > >>> > >>> > >>> > >>> > >>Thanks for the explanation. So would polling > be beneficial or > >>detrimental for a 100 mbps Ethernet card? > >> > >> > > > >Yes, if you were running 100Mbt's of bandwidth > through it. > > > > > > I assume you mean "yes it's beneficial"? :) Thats just not true, or at least not globally. The right answer is: It depends on the hardware. Polling should NEVER be used for hardware that has built-in hardware interrupt throttling (such as fxp and em driver cards). polling has a LOT of overhead. Hardware hold offs give you the benefit of controlled interrupt reduction without adulterating your system with tons of extra clock interrupts. This has been discussed over and over, and still some of the people who are supposed to know about this have no clue whatsoever. polling is ONLY a POSSIBLE advantage is your hardware actually interrupts for every event. Good controllers do not. I don't know the specs of every card/chipset, but with intel cards you definitely do NOT want to use polling, as an example. Regardless of the hardware, if you see a substantial increase with performance its because the OS is broken and not because of the polling, particularly if you have a relatively low volume of traffic. The same number of cpu cycles are needed to process the packets whether you poll or not. As an example, changing the number of receive interrupts per second from 10,000 to 25000 on an em card (4.9 OS, which is known NOT to be broken) pushing 100Kpps yields about a 3% difference in cpu load (no noticable difference in performance). For an average load server doing less than 1K pps, on a modern processor the cpu load difference is not significant enough to make much noticable difference in performance. Of course anyone using a realtek or cheap controller on an expensive machine is just a plain fool; spend the extra relative pennies for a controller that actually works properly. I'm amazed at the number of idiots running MP machines with cheap ethernet controllers. Its like putting $25. tires on a porche. 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]"
RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
--- Ted Mittelstaedt <[EMAIL PROTECTED]> wrote: > > > >-Original Message- > >From: Danial Thom > [mailto:[EMAIL PROTECTED] > >Sent: Monday, December 12, 2005 1:35 PM > >To: Drew Tomlinson; Ted Mittelstaedt > >Cc: Michael Vince; [EMAIL PROTECTED]; > freebsd-questions@freebsd.org; > >Kris Kennaway > >Subject: Re: Polling For 100 mbps Connections? > (Was Re: Freebsd Theme > >Song) > > > > > > > > > >--- Drew Tomlinson <[EMAIL PROTECTED]> > >wrote: > > > >> On 12/12/2005 8:13 AM Ted Mittelstaedt > wrote: > >> > > > >Danial is claiming the slowness is in the > main > > >ram section of > > >things, not in the ethernet driver code. > > >I don't think I'm claiming that at all. > > Oh, really, do tell then: > > >The > >slowness is in the latency and inefficiencies > of > >the scheduler and whatever other kernel > "stuff" > >(locking, general overheads). > > Which runs in main ram... > > >The entire point of > >the tests are that the managing of the packets > is > >a constant, in that its the same hardware and > >mostly the same code. > > What I said... > > >Now I suppose its possible > >that the em driver could just be slower in 5.4 > >and 6.0, but the code is fundamentally the > same, > >so it should be a constant. So since the > >processing of the packets is a constant, then > if > >you can process less packets on the same > machine > >the overhead of the OS must be the culprit. > > And, where again does the OS do it's > processing... > > >It > >could be the code, > > Well, if it's not, then your explanation and > everything > you have said up to this point sure strongly > implies it. > > What's wrong Danial, now that you have actually > had to > think about it, now realizing you have some > holes in > your bitching? Scared that I'm about ready to > start > punching holes in your flimsy inferences? > Not really, because its still a FreeBSD release, so whether its the driver or the scheduler or the code generated by the compiler, it still substantially worse than FreeBSD 4.x. And MP is SLOWER than UP for many functions. So specifically WHAT it is doesn't change my claim the FreeBSD 5.x and 6.x suck, at least relative to what you started with. If you take something and make it worse, and seem to have no ability to figure out WHY, then you're incompetent. Its as simple as that. I have posted a reasonable test and results, and there are countless complaints about performance. I think the fact that every time someone complains Robert Watson tells them to "wait for 6.0, or wait for 7.0" is a pretty good indication that things aren't what the Teds and Krises claim. 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]"
Re: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
Ted Mittelstaedt wrote, On 12/13/2005 12:44 AM: -Original Message- From: Drew Tomlinson [mailto:[EMAIL PROTECTED] Sent: Monday, December 12, 2005 12:30 PM To: Ted Mittelstaedt Cc: Michael Vince; [EMAIL PROTECTED]; freebsd-questions@freebsd.org; Kris Kennaway Subject: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song) On 12/12/2005 8:13 AM Ted Mittelstaedt wrote: Michael, Fundamentally, here's the problem Danial is claiming exists: it takes a certain amount of time to get the packet clocked in from the network into the ethernet receiver. This is hardware dependent and cannot be changed. It takes a certain amount of time to get the packet out of the hardware in the ethernet card into main ram, this also hardware dependent and cannot be changed. (unless the device driver is terribly inefficient, which we will assume it's not) Once in main ram, the information in the packet has to go through a number of code statements. The more code statements the longer the information in the packet is sitting around in the FreeBSD system's memory. It then takes a certain amount of time to get the information out of main memory into the other sending ethernet nic's buffers, and it takes time to get it out of the sending nic back to the wire. Danial is claiming the slowness is in the main ram section of things, not in the ethernet driver code. polling makes the ethernet driver more efficient at high data rates, but it does nothing for the speed of processing within the TCPIP stack itself. At low data rates polling is less efficient than the interrupt method. And unless the nic driver is terribly inefficient to start with, the time it adds to the packet path in the system is minor compared to the time spent in the TCP/IP stack. Ted Thanks for the explanation. So would polling be beneficial or detrimental for a 100 mbps Ethernet card? Yes, if you were running 100Mbt's of bandwidth through it. I assume you mean "yes it's beneficial"? :) Not sure if 100 mbps is considered "high" or "low" speed. I'm specifically interested in NetGear cards using the dc driver or DLink cards using the rl driver. The rl chipset isn't known as a very good chipset. YMMV Yeah, I've heard that a lot. It was an old card I had lying around and it seems to work OK for me. I'm not using it for anything other that connecting to a 802.11b wireless bridge. Very little traffic. Some of the Netgear cards use clone 21143 chipsets which are extremely inferior to the real thing. In particular if your Netgear card is using a PNIC chipset it is pretty bad with serious performance penalty. This is documented in Section 4 of the dc manpage. This is disapointing. I was under the impression that NetGear cards were pretty good. But now I looked closer at dmesg.boot and see I have the PNIC chipset you mention. I'll read the dc man page to see what penalties I'm suffering. People seem to have good results with polling on the fxp cards. Ah, the built in interface on a HP e60 server I have. It's an old dog used as a file server. It has been nothing but reliable and is still chuggin' along just fine. I'll enable polling on it and see if there's any noticeable improvement in transfer rates. The machine that typically is used for large file transfers to and from the e60 is a Windows XP box that has a Nvidia Nforce 4 chipset and whatever intergrated ethernet port that comes with that chipset. Are there any known issues with this setup that would invalidate my test? Thanks again for the info. Drew Ted -- Visit The Alchemist's Warehouse Magic Tricks, DVDs, Videos, Books, & More! http://www.alchemistswarehouse.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
>-Original Message- >From: Danial Thom [mailto:[EMAIL PROTECTED] >Sent: Monday, December 12, 2005 1:35 PM >To: Drew Tomlinson; Ted Mittelstaedt >Cc: Michael Vince; [EMAIL PROTECTED]; freebsd-questions@freebsd.org; >Kris Kennaway >Subject: Re: Polling For 100 mbps Connections? (Was Re: Freebsd Theme >Song) > > > > >--- Drew Tomlinson <[EMAIL PROTECTED]> >wrote: > >> On 12/12/2005 8:13 AM Ted Mittelstaedt wrote: >> > >Danial is claiming the slowness is in the main > >ram section of > >things, not in the ethernet driver code. >I don't think I'm claiming that at all. Oh, really, do tell then: >The >slowness is in the latency and inefficiencies of >the scheduler and whatever other kernel "stuff" >(locking, general overheads). Which runs in main ram... >The entire point of >the tests are that the managing of the packets is >a constant, in that its the same hardware and >mostly the same code. What I said... >Now I suppose its possible >that the em driver could just be slower in 5.4 >and 6.0, but the code is fundamentally the same, >so it should be a constant. So since the >processing of the packets is a constant, then if >you can process less packets on the same machine >the overhead of the OS must be the culprit. And, where again does the OS do it's processing... >It >could be the code, Well, if it's not, then your explanation and everything you have said up to this point sure strongly implies it. What's wrong Danial, now that you have actually had to think about it, now realizing you have some holes in your bitching? Scared that I'm about ready to start punching holes in your flimsy inferences? Danial, you spewed some accusations about the core team making FreeBSD's network performance slower in the newer versions. As I said before, you haven't posted anything to back this up. I know you think your misunderstood but you fail to realize we all understand what your bitching about very well, and are waiting for you to put your money where your mouth is and start posting some repeatable tests. Until then, your just puffing air. And that goes for the rest of you claiming that the later versions of FreeBSD's network performance are better. You too are puffing air. Start showing some test results or go away. Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
>-Original Message- >From: Drew Tomlinson [mailto:[EMAIL PROTECTED] >Sent: Monday, December 12, 2005 12:30 PM >To: Ted Mittelstaedt >Cc: Michael Vince; [EMAIL PROTECTED]; freebsd-questions@freebsd.org; >Kris Kennaway >Subject: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song) > > >On 12/12/2005 8:13 AM Ted Mittelstaedt wrote: > >>Michael, >> >> Fundamentally, here's the problem Danial is claiming exists: >> >>it takes a certain amount of time to get the packet clocked in >>from the network into the ethernet receiver. This is hardware >>dependent and cannot be changed. >> >>It takes a certain amount of time to get the packet out of >>the hardware in the ethernet card into main ram, this also >>hardware dependent and cannot be changed. (unless the device >>driver is terribly inefficient, which we will assume it's not) >> >>Once in main ram, the information in the packet has to go through >>a number of code statements. The more code statements the >>longer the information in the packet is sitting around in >>the FreeBSD system's memory. >> >>It then takes a certain amount of time to get the information >>out of main memory into the other sending ethernet nic's buffers, >> >>and it takes time to get it out of the sending nic back to the >>wire. >> >>Danial is claiming the slowness is in the main ram section of >>things, not in the ethernet driver code. >> >>polling makes the ethernet driver more efficient at high data >>rates, but it does nothing for the speed of processing within >>the TCPIP stack itself. At low data rates polling is less >>efficient than the interrupt method. And unless the nic driver >>is terribly inefficient to start with, the time it adds to the >>packet path in the system is minor compared to the time spent >>in the TCP/IP stack. >> >>Ted >> >> > >Thanks for the explanation. So would polling be beneficial or >detrimental for a 100 mbps Ethernet card? Yes, if you were running 100Mbt's of bandwidth through it. >Not sure if 100 mbps is >considered "high" or "low" speed. I'm specifically interested in >NetGear cards using the dc driver or DLink cards using the rl driver. > The rl chipset isn't known as a very good chipset. YMMV Some of the Netgear cards use clone 21143 chipsets which are extremely inferior to the real thing. In particular if your Netgear card is using a PNIC chipset it is pretty bad with serious performance penalty. This is documented in Section 4 of the dc manpage. People seem to have good results with polling on the fxp cards. Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
--- Drew Tomlinson <[EMAIL PROTECTED]> wrote: > On 12/12/2005 8:13 AM Ted Mittelstaedt wrote: > > >Michael, > > > > Fundamentally, here's the problem Danial is > claiming exists: > > > >it takes a certain amount of time to get the > packet clocked in > >from the network into the ethernet receiver. > This is hardware > >dependent and cannot be changed. > > > >It takes a certain amount of time to get the > packet out of > >the hardware in the ethernet card into main > ram, this also > >hardware dependent and cannot be changed. > (unless the device > >driver is terribly inefficient, which we will > assume it's not) > > > >Once in main ram, the information in the > packet has to go through > >a number of code statements. The more code > statements the > >longer the information in the packet is > sitting around in > >the FreeBSD system's memory. > > > >It then takes a certain amount of time to get > the information > >out of main memory into the other sending > ethernet nic's buffers, > > > >and it takes time to get it out of the sending > nic back to the > >wire. > > > >Danial is claiming the slowness is in the main > ram section of > >things, not in the ethernet driver code. > > > >polling makes the ethernet driver more > efficient at high data > >rates, but it does nothing for the speed of > processing within > >the TCPIP stack itself. At low data rates > polling is less > >efficient than the interrupt method. And > unless the nic driver > >is terribly inefficient to start with, the > time it adds to the > >packet path in the system is minor compared to > the time spent > >in the TCP/IP stack. > > > >Ted > > > > > > Thanks for the explanation. So would polling > be beneficial or > detrimental for a 100 mbps Ethernet card? Not > sure if 100 mbps is > considered "high" or "low" speed. I'm > specifically interested in > NetGear cards using the dc driver or DLink > cards using the rl driver. I don't think I'm claiming that at all. The slowness is in the latency and inefficiencies of the scheduler and whatever other kernel "stuff" (locking, general overheads). The entire point of the tests are that the managing of the packets is a constant, in that its the same hardware and mostly the same code. Now I suppose its possible that the em driver could just be slower in 5.4 and 6.0, but the code is fundamentally the same, so it should be a constant. So since the processing of the packets is a constant, then if you can process less packets on the same machine the overhead of the OS must be the culprit. It could be the code, particularly if you've compiled with a different compiler, but there are only slight variations in code performance generally, unless some macro was changed that say, efficts 100s of thousands of I/O operations per second and adds a few cycles to each. Polling is only beneficial if your ethernet card actually interrupts for every event, which few likely do. Intel cards (fxp and em driver) have built-in hold offs so you get the supposed benefits of polling without all the overhead. fxp cards will never interrupt more then 6000 times per second, and em cards have a tunable with the default at 8000. 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]"
