Re: 3Com driver problems (fixed)
On Sun, 16 Dec 2001 [EMAIL PROTECTED] wrote: > ping is not a very good test...one of the reasons that most people cant find > problems generally. plus you want to use smaller packets to get the pps up. > The ave size packet is under 400 bytes on the net and it better simulates > real life. Once you saturate the wire the lockup occurs rather > quicklyyou have to get to the point where the overflows are happening > faster than the machine can process the interupts. Blah blah blah blah blah. I know ping isn't a great network diagnostic tool, but it allowed me to see the problem easily. You're welcome to run further tests with your flooder of choice to confirm my findings. The problem with stats interrupts causing slowdown was indeed due to a bug in our driver, and not some hardware bug. I have fixed the bug and committed the fix to -current; the fix will be MFC'd in a day or two, before the 4.5 codefreeze begins. In the meantime, you can grab the diff out of cvsweb if you're interested. And yes, it was pretty bad. The reason I didn't notice it too much is because stats interrupts were disabled under -current as a temporary fix; that change never got ported back to 4.x. Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: 3Com driver problems
On Fri, 14 Dec 2001 [EMAIL PROTECTED] wrote: > We dont sell ethernet drivers, and Im not trying to "hide". Why does linux > have specific code to disable the stats under load if Im making this up? Why > can you lock up a FreeBSD 4.4 system with a 3com card at 20Kpps due to > counter overflow interrupts in about 3 seconds? Well, I'm unable to lock up my -current box with a 3c905-tx (non-B or C). However, I can see the delay (apparently) caused by the stat collection routine, which was previously mentioned in the message http://docs.freebsd.org/cgi/getmsg.cgi?fetch=12982+0+archive/2001/freebsd-net/20010114.freebsd-net Interestingly enough, the delay seems to grow as I run the test longer and longer. (My test is ping -s 1400 -i .001 boxwithxlnic.) The delay seems to be able to grow to as much as 12 ms, though it's typically less, around 5 ms or so. If I switch back to the dc interface, I see no delayed packets. I see the hack you refer to in the 3c59x.c driver; I also notice that 3com's official driver (3c90x.c) doesn't contain such a workaround. They must be doing something subtly different which avoids the problem. I have a few ideas, I'll try them out next week and see what I can come up with. Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 3Com driver problems
[EMAIL PROTECTED] writes: > In a message dated 12/15/2001 1:07:28 PM Eastern Standard Time, "."@babalo.ru > writes: > > > At 06:41 PM 12/14/2001, you wrote: > > >[EMAIL PROTECTED] writes: > > > > Try to front end your machine with a switch...the 5 cards is most > > > likely your > > > > problem. With each device you increase your bus contention (ie worsen > > the > > > > worst case bus master scenario)...either that or get a 4 port card > that > > is > > > > more efficient than 5 individual cards. > > >I have some opposite expierence. > > >This is my biggest router: > > >0gw~(1)>uname -a > > >FreeBSD gw.pike 4.4-STABLE FreeBSD 4.4-STABLE #0: Wed Sep 19 06:29:38 MSD > > >2001 [EMAIL PROTECTED]:/tmp/babolo/usr/src/sys/gw i386 > > >0gw~(2)>ifconfig -a > > >dc0: flags=8843 mtu 1500 > > >dc1: flags=8802 mtu 1500 > > >dc2: flags=8843 mtu 1500 > > >dc3: flags=8843 mtu 1500 > > >xl0: flags=8843 mtu 1500 > > >xl1: flags=8843 mtu 1500 > > >xl2: flags=8843 mtu 1500 > > >6 used 100 M ethernet interfaces among others. > > >dc0..dc3 is one card. > > >xl0 cards are workaround for the fact that processor > > sty > > > >spent MUCH more time in interrupt state with dc driver > > >than with xl driver with the same load. > > >Yes, I try find xl x 4 card but no success > > Interrupt state and bus contention are 2 different problems...the problem > with referencing the dc driver is that there are lots of different cards with > different results. btw, the if_dc driver is one of the drivers optimized for > the alpha (note the m_devget calls)..and can use a bit of tuning. my > experience with dlink quad cards and xl is that they are similar in > performance if you account for the fact that the quad cards are going through > a pci bridge chip...and the reduction in bus contention versus using 4 cards. Mine 4 port card was bought as D-link... What is "a bit of tuning"? Yes, I played with shared and non-shared interrupts to assign non-shared to most loaded ports > One issue is that you (and alot of others) dont understand the physical I come to FreeBSD after I was a hardware developper. Hardware constraints are the things I understand well. I do not connect all high load interfaces to one router and this example has 3 relatively high load interfaces. > limits of your machine. putting 6 or more 100Mb/s ethernets on one 32bit bus > is simply asking for problems. You are dealing with a bus that BURSTs to a > bit more than a Gb and probably no more sustained throughput capability than > 500Mb/s (with 2 cards you'll get some errors at 400Mb/s and down from there > as you add cards)...so how do you expect to handle worst case DMA > requirements of 600-800Mb/s in half duplex or twice that if you run 100Mb/s > full duplex? Its just not physically possible. I have no problem with this router now. There is a home network, so no one want to pay more if quality is sufficient. The worst interface has about 1:1 loss - it's OK. Average packet rate for last 67 days is 860 pkt/sec only, burst rate is about 5 times more for 2 min intervals. Yes, I have no direct data about real (short) bursts, but total packet loss is sufficiently low. The real restriction is IP rule complexity. -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 3Com driver problems
On Sun, Dec 16, 2001 at 03:56:02AM +0300, "."@babolo.ru wrote: >> different results. btw, the if_dc driver is one of the drivers optimized for >> the alpha (note the m_devget calls)..and can use a bit of tuning. my this has been fixed recently in both stable and current. luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 3Com driver problems
In a message dated 12/15/2001 1:07:28 PM Eastern Standard Time, "."@babalo.ru writes: > At 06:41 PM 12/14/2001, you wrote: > >[EMAIL PROTECTED] writes: > > > Try to front end your machine with a switch...the 5 cards is most > > likely your > > > problem. With each device you increase your bus contention (ie worsen > the > > > worst case bus master scenario)...either that or get a 4 port card that > is > > > more efficient than 5 individual cards. > >I have some opposite expierence. > >This is my biggest router: > >0gw~(1)>uname -a > >FreeBSD gw.pike 4.4-STABLE FreeBSD 4.4-STABLE #0: Wed Sep 19 06:29:38 MSD > >2001 [EMAIL PROTECTED]:/tmp/babolo/usr/src/sys/gw i386 > >0gw~(2)>ifconfig -a > >dc0: flags=8843 mtu 1500 > >dc1: flags=8802 mtu 1500 > >dc2: flags=8843 mtu 1500 > >dc3: flags=8843 mtu 1500 > >xl0: flags=8843 mtu 1500 > >xl1: flags=8843 mtu 1500 > >xl2: flags=8843 mtu 1500 > >6 used 100 M ethernet interfaces among others. > >dc0..dc3 is one card. > >xl0 cards are workaround for the fact that processor > sty > >spent MUCH more time in interrupt state with dc driver > >than with xl driver with the same load. > >Yes, I try find xl x 4 card but no success Interrupt state and bus contention are 2 different problems...the problem with referencing the dc driver is that there are lots of different cards with different results. btw, the if_dc driver is one of the drivers optimized for the alpha (note the m_devget calls)..and can use a bit of tuning. my experience with dlink quad cards and xl is that they are similar in performance if you account for the fact that the quad cards are going through a pci bridge chip...and the reduction in bus contention versus using 4 cards. One issue is that you (and alot of others) dont understand the physical limits of your machine. putting 6 or more 100Mb/s ethernets on one 32bit bus is simply asking for problems. You are dealing with a bus that BURSTs to a bit more than a Gb and probably no more sustained throughput capability than 500Mb/s (with 2 cards you'll get some errors at 400Mb/s and down from there as you add cards)...so how do you expect to handle worst case DMA requirements of 600-800Mb/s in half duplex or twice that if you run 100Mb/s full duplex? Its just not physically possible. DB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 3Com driver problems
FYI, this is another [EMAIL PROTECTED] clone. [EMAIL PROTECTED] wrote: > >> with 3Com905B devices. > >> And a quick search did not reveal any major problems with the 3com cards. > > > > A "quick search" of what? Get some perspective. The "hackers" are only > > interested in cards that they use, and they all use intel for high end > stuff. > > Bill paul is too busy writing drivers for some new gigabit card to worry > > about old stuff. (note that most of his drivers are optimised for the Alpha > > and not i386...like what pct of people are using Alpha?) And there is > > apparantly no interest in fixing anything or finding out whats wrong > because > > some guy at freebsd with a 2 inch weener keeps knocking me off the > > list...they dont like criticism. I've already fixed it, so all im trying to > > do is save you a lot of time doing work thats already been done. > > >Actually, the cards are very much optimized for the i386. See the lack of > >using bus_dma for example, which is required for these cards to work on > things > >ike sparc64. Grow up and realize that not all the world is an i386. Ports > >like sparc64, powerpc, ia64, and x86-64 are being added and they are not > >exactly like the i386. I've used 3com cards (xl(4)) without any problems. > > >They are rather nice cards and Bill Paul prefers those to Intel cards since > >Intel is so nazi with its docco. :) > > >To Guret: > > >Please don't listen to Dennis. He is feeding you lies so that you will go > buy? > >his "better" ethernet drivers. He is very obnoxious and thus has been banne d > >from the lists several times. This is just another one of his silly aliases . > > We dont sell ethernet drivers, and Im not trying to "hide". Why does linux > have specific code to disable the stats under load if Im making this up? Why > can you lock up a FreeBSD 4.4 system with a 3com card at 20Kpps due to > counter overflow interrupts in about 3 seconds? > > Its too bad that pointing out bugs is deemed as being obnoxious. Maybe its > why they were complaining that linux outperforms Freebsd last week? > > Guret, I apologize for trying to help. Im sure these fellows at freebsd.org > will work painstakingly to help you find your problem. But since they are in > denial about there being anything wrong with it, you most likely are sunk. > > Try to front end your machine with a switch...the 5 cards is most likely your > problem. With each device you increase your bus contention (ie worsen the > worst case bus master scenario)...either that or get a 4 port card that is > more efficient than 5 individual cards. > > DB > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > > Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 3Com driver problems
[EMAIL PROTECTED] writes: > Try to front end your machine with a switch...the 5 cards is most likely your > problem. With each device you increase your bus contention (ie worsen the > worst case bus master scenario)...either that or get a 4 port card that is > more efficient than 5 individual cards. I have some opposite expierence. This is my biggest router: 0gw~(1)>uname -a FreeBSD gw.pike 4.4-STABLE FreeBSD 4.4-STABLE #0: Wed Sep 19 06:29:38 MSD 2001 [EMAIL PROTECTED]:/tmp/babolo/usr/src/sys/gw i386 0gw~(2)>ifconfig -a dc0: flags=8843 mtu 1500 dc1: flags=8802 mtu 1500 dc2: flags=8843 mtu 1500 dc3: flags=8843 mtu 1500 xl0: flags=8843 mtu 1500 xl1: flags=8843 mtu 1500 xl2: flags=8843 mtu 1500 6 used 100 M ethernet interfaces among others. dc0..dc3 is one card. xl0 cards are workaround for the fact that processor spent MUCH more time in interrupt state with dc driver than with xl driver with the same load. Yes, I try find xl x 4 card but no success -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: 3Com driver problems
>> with 3Com905B devices. >> And a quick search did not reveal any major problems with the 3com cards. > > A "quick search" of what? Get some perspective. The "hackers" are only > interested in cards that they use, and they all use intel for high end stuff. > Bill paul is too busy writing drivers for some new gigabit card to worry > about old stuff. (note that most of his drivers are optimised for the Alpha > and not i386...like what pct of people are using Alpha?) And there is > apparantly no interest in fixing anything or finding out whats wrong because > some guy at freebsd with a 2 inch weener keeps knocking me off the > list...they dont like criticism. I've already fixed it, so all im trying to > do is save you a lot of time doing work thats already been done. >Actually, the cards are very much optimized for the i386. See the lack of >using bus_dma for example, which is required for these cards to work on things >ike sparc64. Grow up and realize that not all the world is an i386. Ports >like sparc64, powerpc, ia64, and x86-64 are being added and they are not >exactly like the i386. I've used 3com cards (xl(4)) without any problems. >They are rather nice cards and Bill Paul prefers those to Intel cards since >Intel is so nazi with its docco. :) >To Guret: >Please don't listen to Dennis. He is feeding you lies so that you will go buy? >his "better" ethernet drivers. He is very obnoxious and thus has been banned >from the lists several times. This is just another one of his silly aliases. We dont sell ethernet drivers, and Im not trying to "hide". Why does linux have specific code to disable the stats under load if Im making this up? Why can you lock up a FreeBSD 4.4 system with a 3com card at 20Kpps due to counter overflow interrupts in about 3 seconds? Its too bad that pointing out bugs is deemed as being obnoxious. Maybe its why they were complaining that linux outperforms Freebsd last week? Guret, I apologize for trying to help. Im sure these fellows at freebsd.org will work painstakingly to help you find your problem. But since they are in denial about there being anything wrong with it, you most likely are sunk. Try to front end your machine with a switch...the 5 cards is most likely your problem. With each device you increase your bus contention (ie worsen the worst case bus master scenario)...either that or get a 4 port card that is more efficient than 5 individual cards. DB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
