Re: [gentoo-user] Lots of network collisions - can I eliminate them?
Mark Knecht wrote: Note that there is no link for any of the 100Mb settings. This is verified looking at the switch itself as the link light turns off. Actually, I had never noticed that the 100 light was not turning on before today. so much for plug and play! (My bad...me stupido...) ;-) Hehehe. Until you push the network, you probably would never really notice. :) dragonfly ~ # mii-tool -r restarting autonegotiation... dragonfly ~ # mii-tool -v eth0: autonegotiation failed, link ok I must admit - this I find quite interesting. Somewhere along the line, the switch and the interface aren't talking to each other. OK, so something is having trouble with this negotiation stuff. I'll drag out some new cables after I send this and see what happens with that. I looked at the LinkSys switch docs again. There are no user settings that I see to get the switch to support 100Mb/S. It's supposed to be automatic. Your cables could be an issue. For 100MBps you really need Cat5, although Cat4 may be able to handle it (just not ideal). Cat5e is generally the best as (IIRC) it supports up to Gigabit ethernet. Again, thanks very much. mii-tool is very helpful. I'll also have to look at mii-diag to see if it can help with this problem. Depending on the two computer locations, you could try connecting the two computers together via a crossover cable and seeing how the autonegoition works. I think there are some switches which require all ports/nodes to be on the same speed/duplex settings as it can't handle the differences, although I find that unlikely with any modern switch (personally, I'm running two Netgear Switches - FS105, 5-port FS108, 8-port, and they can handle multiple node-types - all systems are on 100baseTx-FD whereas my VoIP phone is 10base-HD, and they all work without a problem). Try disconnecting one system and restarting the switch to see if one node is causing a problem. Also, if you can, try a crossover cable to see if it's the switch causing the problem and not the computers. -- Jonathan Wright ~ mail at djnauk.co.uk ~ www.djnauk.co.uk -- 2.6.12-gentoo-r6-djnauk-b2 AMD Athlon(tm) XP 2100+ up 23:59, 4 users, load average: 3.98, 4.22, 4.32 -- Earlier today, President Bush said gay marriage is immoral and that heterosexual marriage must be defended, that's what he said. You can tell Bush is serious because he said the new Axis of Evil is Cher, Bette Middler and Clay Aiken. ~ Conan O'Brien -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Lots of network collisions - can I eliminate them? - SOLVED
Mark Knecht wrote: The switch was stuck in some strange state. Power down and back up fixed it. Time to get a UPS for the media center... Opps. Just clicked send on the reply and I saw this! :) Ah well! hehehe. I'm using a UPS myself for my two servers the master switch and the wireless router: http://catalog.belkin.com/IWCatProductPage.process?Merchant_Id=Section_Id=202840pcount=Product_Id=201050Section.Section_Path=%2FRoot%2FPowerProtection%2FUPSUninterr%2E%2E%2EerSupply%2FUninterr%2E%2E%2EerSupply%2FBelkinSu%2E%2E%2EeriesUPS%2F I prefer that one as it has standard plugs, allowing you to connect extra items (such as the switch and wireless router) and keep the network running! :) Thanks for the invaluable help with mii-tool. Very, very helpful. NP. Glad to help :) -- Jonathan Wright ~ mail at djnauk.co.uk ~ www.djnauk.co.uk -- 2.6.12-gentoo-r6-djnauk-b2 AMD Athlon(tm) XP 2100+ up 23:59, 4 users, load average: 3.98, 4.22, 4.32 -- You can tell Bush is serious because he said the new Axis of Evil is Cher, Bette Middler and Clay Aiken. Earlier today, President Bush said gay marriage is immoral and that heterosexual marriage must be defended, that's what he said. ~ Conan O'Brien -- gentoo-user@gentoo.org mailing list
[gentoo-user] Lots of network collisions - can I eliminate them?
Hi all. Sorry in advance for the rash of emails today but the topics seem to be varying and hopefully folks will read only the ones they think they could help with. QUESTIONS: 1) What causes a 'collision' on a network interface? 2) How can I eliminate them? (Including hardware changes if required.) In looking at this MythTV problem it looks like it's possibly the networking/NFS side of the equation and not the PVR software side. I'm running a test using my local drive right now to see if that's true. In looking at the networking side i see a problem with collisions: dragonfly ~ # ifconfig eth0 Link encap:Ethernet HWaddr 00:40:CA:74:21:E9 inet addr:192.168.1.55 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4014229 errors:0 dropped:0 overruns:0 frame:0 TX packets:4014933 errors:0 dropped:0 overruns:0 carrier:0 collisions:1808957 txqueuelen:1000 RX bytes:17072649 (16.2 Mb) TX bytes:3375271889 (3218.9 Mb) Interrupt:20 Base address:0x9000 myth14 ~ # ifconfig eth0 Link encap:Ethernet HWaddr 00:11:D8:F4:CD:1D inet addr:192.168.1.14 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1732167 errors:0 dropped:0 overruns:0 frame:0 TX packets:1592861 errors:0 dropped:0 overruns:0 carrier:0 collisions:289582 txqueuelen:1000 RX bytes:1645387797 (1569.1 Mb) TX bytes:1558513991 (1486.3 Mb) Interrupt:18 Base address:0xec00 Myth14 is the NFS server. Dragonfly is the NFS client that mounts the drive. I do not see any collisions on other machines on my network. Ethernet hardware is built-in to both machines: dragonfly ~ # lspci | grep Ethernet :01:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) dragonfly ~ # myth14 ~ # lspci | grep Ethernet :02:08.0 Ethernet controller: 3Com Corporation 3Com 3C920B-EMB-WNM Integrated Fast Ethernet Controller (rev 40) myth14 ~ # The two machines are connected through a small LinkSys switch. model EZXS55W: http://www.linksys.com/servlet/Satellite?childpagename=US%2FLayoutpackedargs=c%3DL_Product_C2%26cid%3D1115416836711pagename=Linksys%2FCommon%2FVisitorWrapper The URL probably won't survive the email. If I run hdparm -tT on the NFS drive it is using DMA but it's slow, as it's always been: myth14 ~ # hdparm -tT /dev/hdc /dev/hdc: Timing cached reads: 1544 MB in 2.00 seconds = 771.73 MB/sec Timing buffered disk reads: 46 MB in 3.11 seconds = 14.77 MB/sec myth14 ~ # I'm going to investigate a new kernel on the NFS server side, althoguh I'm loth to do this since it means messing with LIRC, fglrx and lots of other touchy stuff. However, if there is a simple way to configure things so that collisions disappear or go down significantly that would be great. Again, thanks in advance and sorry for the number of emails. Cheers, Mark -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Lots of network collisions - can I eliminate them?
On Fri, 2005-09-23 at 11:12 -0700, Mark Knecht wrote: Hi all. Sorry in advance for the rash of emails today but the topics seem to be varying and hopefully folks will read only the ones they think they could help with. QUESTIONS: 1) What causes a 'collision' on a network interface? 2) How can I eliminate them? (Including hardware changes if required.) See the following thread from May of last year http://thread.gmane.org/gmane.linux.gentoo.user/80369 The bottom line is that your network interface is probably running in Half-Duplex mode and should be switched to Full-Duplex mode. If you have more questions after reading it, let me know. Regards, Paul -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Lots of network collisions - can I eliminate them?
Mark Knecht wrote: 1) What causes a 'collision' on a network interface? As Paul pointed out via his e-mail (via the previous thread), collisions are when two packets try and talk over an ethernet cable at the same time. In terms of a hub, it's very common, esp. when the hub becomes loaded as 2/4/8/32, etc. machines are all essentially using the same bit of cable (what with a hub being nothing more than a repeater). If an interface detects a collision, the transfer is stopped and a it waits a random amount of time before trying to send it again. This goes round and round until it's sent. For a switch on the other hand, its not so common, as there are only ever two machines on the cable - the switch and the computer. Although 31% collision rate on dragonfly does seam alot. Again, Paul is probably right, with half-duplex being the problem. In this case, the same 'cable' us used for both sending and receiving traffic. If one conflicts the other, you'll get a collision. With Full-duplex, sends and receives are independent and therefore you can't get collisions: jwright on jonathan [ ~ ] -- /sbin/ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:02:B3:87:89:03 inet addr:10.0.0.10 Bcast:10.0.0.255 Mask:255.255.255.0 UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3481762 errors:0 dropped:0 overruns:0 frame:0 TX packets:3664852 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1212745301 (1156.5 Mb) TX bytes:1002484102 (956.0 Mb) jwright on jonathan [ ~ ] -- ssh -t kenny /sbin/ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:50:8B:4C:9C:EA inet addr:10.0.0.2 Bcast:10.0.0.255 Mask:255.255.255.0 UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 RX packets:18415888 errors:0 dropped:0 overruns:0 frame:0 TX packets:17153032 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:2907452267 (2772.7 Mb) TX bytes:960767410 (916.2 Mb) Interrupt:11 Base address:0x2000 Memory:4210-42100038 Connection to kenny closed. jwright on jonathan [ ~ ] -- ssh -t kyle /sbin/ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:08:C7:7F:CF:A7 inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:34264896 errors:0 dropped:0 overruns:0 frame:0 TX packets:4375 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3580726012 (3414.8 MB) TX bytes:196135708 (187.0 MB) Interrupt:9 Base address:0x2000 Memory:4210-42100038 Connection to kyle closed. 2) How can I eliminate them? (Including hardware changes if required.) The two machines are connected through a small LinkSys switch. model EZXS55W: When I first read that I thought 'cheap built-in hub', so only 10MBps @ HD, however looking at it, 100MBps-FD shouldn't be a problem. A good tool to look at is mii-tool (emerge mii-diag): root on jonathan [ ~ ] -- mii-tool eth0: negotiated 100baseTx-FD flow-control, link ok root on jonathan [ ~ ] -- mii-tool -v eth0: negotiated 100baseTx-FD flow-control, link ok product info: Intel 82555 rev 4 basic mode: autonegotiation enabled basic status: autonegotiation complete, link ok capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control Then you can run: root on jonathan [ ~ ] -- mii-tool -F 100baseTx-FD Which should put the computer into 100MBps via Full Duplex. Give that a go - it should work. If there's a problem putting it into that (and you can run 'mii-tool -r' to re-negotiate), it may be the switch and/or the cable. -- Jonathan Wright ~ mail at djnauk.co.uk ~ www.djnauk.co.uk -- 2.6.12-gentoo-r6-djnauk-b2 AMD Athlon(tm) XP 2100+ up 11:04, 4 users, load average: 3.06, 5.30, 6.56 -- People sometimes think I'm gay because I once played a gay in a movie. It's funny. Audiences don't think you're a murderer if you play a murderer, but they do think you're gay if you play a gay. ~ Perry King -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Lots of network collisions - can I eliminate them?
On 9/23/05, Jonathan Wright [EMAIL PROTECTED] wrote: Mark Knecht wrote: 1) What causes a 'collision' on a network interface? As Paul pointed out via his e-mail (via the previous thread), collisions are when two packets try and talk over an ethernet cable at the same time. In terms of a hub, it's very common, esp. when the hub becomes loaded as 2/4/8/32, etc. machines are all essentially using the same bit of cable (what with a hub being nothing more than a repeater). If an interface detects a collision, the transfer is stopped and a it waits a random amount of time before trying to send it again. This goes round and round until it's sent. For a switch on the other hand, its not so common, as there are only ever two machines on the cable - the switch and the computer. Although 31% collision rate on dragonfly does seam alot. Again, Paul is probably right, with half-duplex being the problem. In this case, the same 'cable' us used for both sending and receiving traffic. If one conflicts the other, you'll get a collision. With Full-duplex, sends and receives are independent and therefore you can't get collisions: SNIP 2) How can I eliminate them? (Including hardware changes if required.) The two machines are connected through a small LinkSys switch. model EZXS55W: When I first read that I thought 'cheap built-in hub', so only 10MBps @ HD, however looking at it, 100MBps-FD shouldn't be a problem. I bought the switch base don it being able to do 100Mb FD. Thanks to your suggestion about mii-tool I'm not so sure right now that it's actually doing it... A good tool to look at is mii-tool (emerge mii-diag): YES!! VERY HELPFUL! Thanks! root on jonathan [ ~ ] -- mii-tool eth0: negotiated 100baseTx-FD flow-control, link ok Now, I'm thinking that this is setting the mii on my PC, correct? (Not on the switch.) Unfortunately it appears that Dragonfly cannot/will not do 100baseTx-FD or HD! dragonfly ~ # mii-tool eth0: 10 Mbit, full duplex, link ok dragonfly ~ # mii-tool -F 100baseTx-FD dragonfly ~ # mii-tool eth0: 100 Mbit, full duplex, no link dragonfly ~ # mii-tool -F 10baseT-FD dragonfly ~ # mii-tool eth0: 10 Mbit, full duplex, link ok dragonfly ~ # mii-tool -F 10baseT-HD dragonfly ~ # mii-tool eth0: 10 Mbit, half duplex, link ok dragonfly ~ # mii-tool -F 100baseTx-HD dragonfly ~ # mii-tool eth0: 100 Mbit, half duplex, no link dragonfly ~ # mii-tool -F 10baseT-FD dragonfly ~ # mii-tool eth0: 10 Mbit, full duplex, link ok dragonfly ~ # mii-tool -F 100baseTx-FD dragonfly ~ # mii-tool eth0: 100 Mbit, full duplex, no link dragonfly ~ # dragonfly ~ # lspci | grep Ethernet :01:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) dragonfly ~ # Note that there is no link for any of the 100Mb settings. This is verified looking at the switch itself as the link light turns off. Actually, I had never noticed that the 100 light was not turning on before today. so much for plug and play! (My bad...me stupido...) ;-) dragonfly ~ # mii-tool -v eth0: 100 Mbit, full duplex, no link product info: vendor 00:00:00, model 0 rev 0 basic mode: 100 Mbit, full duplex basic status: no link capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD dragonfly ~ # dragonfly ~ # mii-tool -F 10baseT-FD dragonfly ~ # mii-tool -v eth0: 10 Mbit, full duplex, link ok product info: vendor 00:00:00, model 0 rev 0 basic mode: 10 Mbit, full duplex basic status: link ok capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD dragonfly ~ # So far, up to this point, I can at least see the world using 100baseT-FD. That should be better than what I had before. (I think...) root on jonathan [ ~ ] -- mii-tool -v eth0: negotiated 100baseTx-FD flow-control, link ok product info: Intel 82555 rev 4 basic mode: autonegotiation enabled basic status: autonegotiation complete, link ok capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control Then you can run: root on jonathan [ ~ ] -- mii-tool -F 100baseTx-FD Which should put the computer into 100MBps via Full Duplex. Give that a go - it should work. If there's a problem putting it into that (and you can run 'mii-tool -r' to re-negotiate), it may be the switch and/or the cable. dragonfly ~ # mii-tool -r restarting autonegotiation... dragonfly ~ # mii-tool -v eth0: autonegotiation failed, link ok product info: vendor 00:00:00, model 0 rev 0 basic mode: autonegotiation enabled basic status: autonegotiation complete, link ok capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD
Re: [gentoo-user] Lots of network collisions - can I eliminate them? - SOLVED
On 9/23/05, Mark Knecht [EMAIL PROTECTED] wrote: dragonfly ~ # mii-tool -r restarting autonegotiation... dragonfly ~ # mii-tool -v eth0: autonegotiation failed, link ok product info: vendor 00:00:00, model 0 rev 0 basic mode: autonegotiation enabled basic status: autonegotiation complete, link ok capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD dragonfly ~ # OK, so something is having trouble with this negotiation stuff. I'll drag out some new cables after I send this and see what happens with that. I looked at the LinkSys switch docs again. There are no user settings that I see to get the switch to support 100Mb/S. It's supposed to be automatic. Again, thanks very much. mii-tool is very helpful. I'll also have to look at mii-diag to see if it can help with this problem. cheers, Mark OK, interesting results. 1) This system has worked for a couple of months. 2) There was a small rainstorm here (SF Bay Area) on Tuesday afternoon. This had a bot of lightning and, according to the paper, a few peopl ehere were without power for 15 minutes. 3) On Tuesday afternoon we started having problems. 4) Looking at the logs on the NFS server I could see that it ha rebooted. That machine runs without a UPS. 5) The switch is on that same plug with no UPS. 6) Over the last couple of days I've rebooted the NFS server and the Myth backend server, all to better results. 7) This evening I get the bright idea to reboot the switch. 8) The switch now auto-negotiates and runs at 100Mb-FD: dragonfly ~ # mii-tool eth0: negotiated 100baseTx-FD, link ok dragonfly ~ # mii-tool -v eth0: negotiated 100baseTx-FD, link ok product info: vendor 00:00:00, model 0 rev 0 basic mode: autonegotiation enabled basic status: autonegotiation complete, link ok capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control dragonfly ~ # The switch was stuck in some strange state. Power down and back up fixed it. Time to get a UPS for the media center... Thanks for the invaluable help with mii-tool. Very, very helpful. Cheers, Mark -- gentoo-user@gentoo.org mailing list
