July 2001 - Ag-tech - mailman3.cels.anl.gov

Re: [AG-TECH] Linux networking problems
by Stuart Levy 25 Jul '01

25 Jul '01

>mii-diag output included the following: > > Speed fixed at 100 mbps, full-duplex. #that's my linux box/card > >Your link partner is generating 100baseTx link beat (no >autonegotiation). #that's the switch That (100baseTx rather than 100baseTx-FD) worried me too, but checking the mii-diag.c source, it's only distinguishing 100baseTx from 10baseTx in printing that message -- it'll never report ``100baseTx-FD'' in this message no matter what the hardware registers say. I don't know whether it's even possible to detect whether the far-end thinks it's in full vs half-duplex. Also, alas, I don't know what sort of errors you should expect to see from the Linux drivers if there is a duplex mismatch. It might be entertaining to force the Linux card into *half* duplex now and see whether throughput gets even worse!

1 0

Re: [AG-TECH] Linux networking problems
by Robert Olson 25 Jul '01

25 Jul '01

Have you tried using iperf (http://dast.nlanr.net/Projects/Iperf/) for the bandwidth measurement? --bob At 04:06 PM 7/25/2001 -0500, Kay Gunn wrote: > > I only know enough about this to be dangerous but are you sure the > > switch port is full duplex? > >Our network admin just verified that it is full-duplex. >This means either mii-diag gave me faulty information or I'm reading it >wrong. Of course, I did use the very same switch port successfully with >Redhat 7.1 forced to do 100MB full duplex, so if the port was set to >half-duplex, I should have seen problems there, too. >mii-diag output included the following: > > Speed fixed at 100 mbps, full-duplex. #that's my linux box/card > >Your link partner is generating 100baseTx link beat (no >autonegotiation). #that's the switch > >I'm assuming that's 100BT HD fixed, since card info possibilities >listed >100baseTx-FD and 100baseTx. > > > if it is 100BaseT. The reason I ask is that I think the full duplex end > > of a theoretical mismatch would never get a collision because it knows > > you cannot get collisions running at full duplex. But the hdx end would > > not > >That makes sense...but I would expect to see errors. I have never worked >with Linux before, but I have worked alot with Solaris and 100BT duplex >problems. In the past when I've seen a duplex mismatch on Solaris, I'd >see *ALOT* of errors (using netstat -i time slices). > >The network admin looked at the port statistics on the switch I'm >connecting to, and he is seeing alot of errors there (but no collisions) >for my grid nodes. 99% of the errors are RUNTS, with a few CRC. It >doesn't make sense to me that the switch is reporting the errors, but the >linux boxes aren't (they're just performing slowly). I'll install Redhat >7.1 back on one of machines that's generating the RUNTS to see if they go >away with the different OS. > >------ >Kay Gunn > > >

1 0

Re: [AG-TECH] Linux networking problems
by Kay Gunn 25 Jul '01

25 Jul '01

> I only know enough about this to be dangerous but are you sure the > switch port is full duplex? Our network admin just verified that it is full-duplex. This means either mii-diag gave me faulty information or I'm reading it wrong. Of course, I did use the very same switch port successfully with Redhat 7.1 forced to do 100MB full duplex, so if the port was set to half-duplex, I should have seen problems there, too. mii-diag output included the following: Speed fixed at 100 mbps, full-duplex. #that's my linux box/card Your link partner is generating 100baseTx link beat (no autonegotiation). #that's the switch I'm assuming that's 100BT HD fixed, since card info possibilities listed 100baseTx-FD and 100baseTx. > if it is 100BaseT. The reason I ask is that I think the full duplex end > of a theoretical mismatch would never get a collision because it knows > you cannot get collisions running at full duplex. But the hdx end would > not That makes sense...but I would expect to see errors. I have never worked with Linux before, but I have worked alot with Solaris and 100BT duplex problems. In the past when I've seen a duplex mismatch on Solaris, I'd see *ALOT* of errors (using netstat -i time slices). The network admin looked at the port statistics on the switch I'm connecting to, and he is seeing alot of errors there (but no collisions) for my grid nodes. 99% of the errors are RUNTS, with a few CRC. It doesn't make sense to me that the switch is reporting the errors, but the linux boxes aren't (they're just performing slowly). I'll install Redhat 7.1 back on one of machines that's generating the RUNTS to see if they go away with the different OS. ------ Kay Gunn

1 0

Re: [AG-TECH] Linux networking problems
by Kay Gunn 25 Jul '01

25 Jul '01

Thanks for the tip. I got this installed and running on my ag nodes. One thing I really like about this tool is that you can suppossedly use it to set as well as check your speed/duplex settings. And in case you're wondering..I really don't care about ftp speeds. I had noticed some network issues and was just looking for a way to benchmark the network performance. I'm using ncftp which gives a nice avg after it finishes downloading a file. Here is the output from my station with the etherexpress pro 100 card. I left this running while I was doing a large file transfer. The avg again for the transfer was 2.66MB/sec. [root@watrgrid3 /tmp]# ./mii-diag -v -w mii-diag.c:v2.02 5/21/2001 Donald Becker (becker(a)scyld.com) http://www.scyld.com/diag/index.html Using the default interface 'eth0'. Basic mode control register 0x2100: Auto-negotiation disabled, with Speed fixed at 100 mbps, full-duplex. You have link beat, and everything is working OK. This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation not complete. Your link partner is generating 100baseTx link beat (no autonegotiation). End of basic transceiver informaion. MII PHY #1 transceiver registers: 2100 780d 02a8 0154 05e1 0081 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0a03 0000 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000. Basic mode control register 0x2100: Auto-negotiation disabled! Speed fixed at 100 mbps, full-duplex. Basic mode status register 0x780d ... 780d. Link status: established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation not complete. Vendor ID is 00:aa:00:--:--:--, model 21 rev. 4. No specific information is known about this transceiver type. I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 0081: 100baseTx. Negotiation did not complete. Monitoring the MII transceiver status. 13:57:25.518 Baseline value of MII BMSR (basic mode status register) is 780d. > > You can compile the mii diag tools yourself under RH 6.2, > and it might well be rewarding. I just tried fetching from: > http://www.scyld.com/diag/ > > which has instructions, and links to the necessary pieces: > ftp://ftp.scyld.com/pub/diag/mii-diag.c > ftp://ftp.scyld.com/pub/diag/libmii.c > > After fetching these, just say > gcc -Wall -Wstrict-prototypes -O mii-diag.c -DLIBMII libmii.c -o mii-diag > (quoting from the last couple lines of mii-diag.c) and then > > mii-diag -v -w >

1 0

Re: [AG-TECH] stable VIC
by Marty Hoag 25 Jul '01

25 Jul '01

I've been using the VIC v2.8ucl-1.1.3 on W2k for some time now with a Hauppage Model 401 WinTV card. It seems to seldom crash. I usually leave it running days on end. I recently added SP2 to W2K this is running on but that didn't seem to make a difference and I think I'm just using stock drivers, etc. The speeds aren't great but then we have lots of wind and I've found that blowing branches and leaves seem to drop the frame rate. ;-) It is running the "Marty's Office" view in the "Window on NDSU" sdr session at 233.24.119.155/64546 . But that is not really meant for production AG use, just some experimentation (and a way to use an old camera! ;-). I've also used v2.8ucl-1.0 on an old NT machine for viewing and it is pretty stable. But I don't know a lot about the "internals"... Marty

1 0

Re: [AG-TECH] Linux networking problems
by Kay Gunn 25 Jul '01

25 Jul '01

Cisco Catlayst 3500XL I tried some tests with the box that I reinstalled 6.2 on that originally had 7.1 on it. It didn't matter whether I forced it to full duplex or not...the transfer rate was still the same. I'm using fixed IP address now, and not DHCP. The switch port I'm connected to is set to full duplex 100MB - no autonegotiate. On Wed, 25 Jul 2001, Robert Olson wrote: > Weird. What sort of switches do you have? > > --bob > > At 12:47 PM 7/25/2001 -0400, Christopher E. Geddings wrote: > >With several of the Dell machines we've had on site, some > >interaction between the hardware resources, the linux NIC driver > >and the switch resulted in the ethernet cards not being able to > >properly recieve DHCP assigned addresses. Forcing the cards full > >duplex fixed this problem, and has become habit for these > >machines. > ------ Kay Gunn

1 0

Re: [AG-TECH] Linux networking problems
by Robert Olson 25 Jul '01

25 Jul '01

Weird. What sort of switches do you have? --bob At 12:47 PM 7/25/2001 -0400, Christopher E. Geddings wrote: >With several of the Dell machines we've had on site, some >interaction between the hardware resources, the linux NIC driver >and the switch resulted in the ethernet cards not being able to >properly recieve DHCP assigned addresses. Forcing the cards full >duplex fixed this problem, and has become habit for these >machines.

1 0

Help with Dell 2550
by Mustafa Varank 25 Jul '01

25 Jul '01

Hello Guys, Does anyone has experience with dell 2550 servers? I am about the order them and I need to know is there any specific problem ? Thank you, Mustafa

1 0

Re: [AG-TECH] Linux networking problems
by Christopher E. Geddings 25 Jul '01

25 Jul '01

With several of the Dell machines we've had on site, some interaction between the hardware resources, the linux NIC driver and the switch resulted in the ethernet cards not being able to properly recieve DHCP assigned addresses. Forcing the cards full duplex fixed this problem, and has become habit for these machines. --Chris On Wed, Jul 25, 2001 at 11:03:17AM -0500, Robert Olson wrote: > I'm wondering why you have to force the cards to full-duplex? Did you try > without that? I've never had to poke at them that forcefully. >

1 0

Re: [AG-TECH] Linux networking problems
by Robert Olson 25 Jul '01

25 Jul '01

Wow, very cool find. I think this is worth making an RPM of and including in the distribution... --bob At 11:39 AM 7/25/2001 -0500, Stuart Levy wrote: >I've had this kind of problem too, where I seemed to need to >force the 3c59x/3c90x drivers to a specific duplex setting >to avoid catastrophic packet loss. It might have been the >switch's fault, but how can I tell? > >You can compile the mii diag tools yourself under RH 6.2, >and it might well be rewarding. I just tried fetching from: > http://www.scyld.com/diag/ > >which has instructions, and links to the necessary pieces: > ftp://ftp.scyld.com/pub/diag/mii-diag.c > ftp://ftp.scyld.com/pub/diag/libmii.c > >After fetching these, just say > gcc -Wall -Wstrict-prototypes -O mii-diag.c -DLIBMII libmii.c -o mii-diag >(quoting from the last couple lines of mii-diag.c) and then > > mii-diag -v -w > >will report the duplex, etc. status and -- better -- >watch for link state changes. I just saw a couple transitions >when trying a 10MB TCP transfer: > 11:26:43.869 MII BMSR now 1000: no link, NWay busy, No Jabber (41e1). > 11:26:43.879 MII BMSR now 782d: Good link, NWay done, No Jabber (41e1). >Unfortunately, I can't seem to replicate any problems right now -- >all the transfers I tried ran at about 11 MB/sec -- but maybe you can. > > Stuart Levy

1 0