On Mon, 28 Jul 2003 19:34:56 -0700 Rob Blomquist <[EMAIL PROTECTED]> wrote:
> > > This sounds exactly as you describe... collisions! They are due to a > > number of reasons; but some things to check: > > > > 1. Bypass the hub with a direct (rolled) cable. If this works (check > > collisions in ifconfig), then replace your hub with a switch which > > doesn't suffer from the following... Note: some "hubs" are really > > switches... A real hub is a cheap buffered repeater -- the buffer is > > rather small (acts like an "elastic buffer"); it "snaps" when a > > sending NIC's crystal is out of specs -- the snap results in the hub > > sending a "jam" (collision) back to the sending NIC. Bypassing the > > hub eliminates the hub's elastic buffer. I'm surprised you're able to > > send that much data if this is the problem though... > > Well the hub I use a LinkSys NH-105 connects all the machines on the > network, our DSL router, my Linux box, our File server, and my wife's > laptop. One of mine is a LinkSys EFAH05W, sold as a "hub" (as opposed to the one sold as a "switch"); but it is really a switch. I wanted a real *hub* for net. monitoring purposes; but that's another story. > I have not recently checked my wife's laptop, but the only time that I > see these collisions is between my box and the file server. And yes, I > did get 650Mb to pass after rebooting the server. Are they on both ends, or just between the LinkSys and one of the machines? > > 2. Near end collisions: are your cables direct, or running through > > hookups around the house? Poor connections and not enough twists in > > the pairs or poor cable at the sending end can result in near-end > > collisions due to crosstalk from sending signal back into sender's > > receiver circuitry-- hearing itself. > We just moved, and right now all connections with the hub to machines > are less than 10 feet. So I don't think there is a problem there, but > maybe the hub to FS cable is bad, it has gotten a bit of strain, as I > forget it is only 3 feet long. Near-end collisions have been know to occur on short cables and be resolved with longer cables; but I don't have a specific example as that experience was circa 1991. On the other hand, if near-end coll. are not the problem, and the coll. are only seen on one box, I might be tempted to swap the NICs to see if the problem changes. That said, this is ethernet, and collisions are normal to some extent. I was once doing some tests on a server/router pair and found that there were 30% collisions on a direct 10baseT/CAT5 link -- turned out to be the pseudo-random backoff algorithm in both machines was causing the problems. Both were trying to be aggressive in getting their data on the wire resulting in tons of early colisions. This is something that can't be fixed easily -- low-level driver changes needed -- no idea if that is in the Linux drivers, or in the NIC's logic (probably the latter)... > > > 3. If your NIC is an Intel eepro10, consider trying something else... > > I had this very problem when transferring large files... > > interestingly, the apparently random failures were at exactly the same > > point on any specific file. > > No I run a mixture of 3Com 3C509 and D-Link RTL 8139 using the 8139too > driver. When transfering a particular file, any chance the length of the transfer is always the same...? A long shot; but if so, it would be a problem the kernel folk should hear about... in that case, let me know and I'll dig out my notes... > I will check the cables and the hub as you say, and replace as needed, > upgrading the hub if needed. May be moot... but good luck. > Rob
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
