Very slow network...

Sat Mar 4 14:12:30 2000

when I ping the other machine,  I get some error messages like

64 bytes from 10.1.1.2: icmp_seq=84 ttl=255 time=0.7 ms
wrong data byte #36 should be 0x24 but was 0x14
        14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 14 25 26 27 28 29 2a 2b
2c 2d 2e 2f 30 31 32 33
        24 35 36 37 0 0 0 0 0 0 0 0 0 0 0 0
64 bytes from 10.1.1.2: icmp_seq=86 ttl=255 time=0.7 ms
64 bytes from 10.1.1.2: icmp_seq=87 ttl=255 time=0.7 ms
64 bytes from 10.1.1.2: icmp_seq=88 ttl=255 time=0.7 ms
64 bytes from 10.1.1.2: icmp_seq=89 ttl=255 time=0.7 ms

I wanted to change the connection type to 10BaseT from 100BaseT.  I tried setting
the options in
conf.modules, but still the hub indicates that both computers are connected at
100Mbs.

when I run  tulip-diag I get

tulip-diag.c:v1.19 10/2/99 Donald Becker (becker@cesdis.gsfc.nasa.gov)
Index #1: Found a Lite-On 82c168 PNIC adapter at 0x1400.
 * A potential Tulip chip has been found, but it appears to be active.
 * Either shutdown the network, or use the '-f' flag to see all values.
 Port selection is MII, half-duplex.
 Transmit started, Receive started, half-duplex.
  The Rx process state is 'Waiting for packets'.
  The Tx process state is 'Idle'.
  The transmit threshold is 72.

Randy Sandberg wrote:

> on 3/4/00 8:35 AM, Siva Alagarsamy at siva@sivasys.com wrote:
>
> > I was testing the network with Windows98 on both the computer.
> > One is a old 100Mhz Acer Aspire (Cyrix 6x86) and the other is a 500Mhz PIII
> > Dell
> > Dimension. I was tranfering
> > a 30Mb file from the Dell to Acer.
> > I changed the connection type to 10BaseT and I could transfer a 33Mb file in
> > 20
> > seconds...
> > At 100Mbs, I couldn't complete the transfer at all. After a minute, I had
> > transfered only 100K... This happened
> > both in Linux and Windows.... I guess, the Acer computer is slow to handle
> > that
> > speed and I need to force 10Mbs on both for efficient transfer.
> >
> > Siva
> >
>
> Hello Siva,
>
> Note: Please keep this letter going to the mailing list as well. I'm no
> expert at this stuff, but there are experts in this group. Therefore, the
> more people looking at your problem the better.
>
> And now for something completely different...
>
> Houston, we have a problem. I would try to isolate the problem if I were
> you. You might want to try the following:
>
> 1. Stick to Linux (i.e., the good OS) and the latest tulip.c driver (i.e.,
> Being most relevant to this mailing list). Although, being that the problem
> exists in both Windoz as well as Linux it does seem to point some kind of
> hardware bug.
>
> 2. Eliminate your hub. Buy or make a cross over cable.
>
> 3. Make sure both Linux boxes, using the same version of Linux as well as
> tulip.c code, are connected at the same rate and mode (e.g., 100Mb/s at
> Full-Duplex). You can usually find this out buy doing a:
>
> "dmesg | less" without the quotes and look towards the bottom of the log.
>
> Note: Make sure you're using the latest as well as the most correct tulip.c
> code/driver for your Network Interface Cards.
>
> 4. After a reboot of both systems transfer your 33MB sized file. By the way,
> how are you transferring the data? FTP? Moreover, are you transferring the
> data via binary (fast) or ASCII (slow)?
>
> Transfer rates as slow as you are talking about as well as the eventual
> timeout(s) spell out some major problem here. Are you sure both cards are
> good? My best guess thus far is either some kind of user error... It happens
> to the best of us (e.g., wrong driver or wrong driver settings). Or,
> possibly a bad NIC... One of the the 100Mb part(s) anyway.
>
> I hope this helps,
>
> Randy
>
> P.S., Just a sanity check here, what brand name/model number NICs are you
> using again? Also, cause I'm lazy, which DEC chipset(s) are they using
> (e.g., DEC 12143-x).
>
> P.P.S., Sanity check number two. IS YOUR HUB capable of doing both 10 and
> 100Mb? Are both Linux boxes connecting at either 10Mb/s Half-Duplex or
> 100Mb/s Half-Duplex? The keyword here being Half-Duplex. Hubs don't do
> Full-Duplex ;-)
>
> --
> Randy Sandberg
> Test Engineer
> Server Reliability Lab (DeathStarNet)
> Apple Computer, Inc.
> phone: (408) 974.5749
> email: <sandberg@apple.com>
> www: <http://deathstarnet.apple.com> - Apple Internal Website
>
> -------------------------------------------------------------------
> To unsubscribe send a message body containing "unsubscribe"
> to linux-tulip-bug-request@beowulf.org

--
http://www.sivasys.com/siva

-------------------------------------------------------------------
To unsubscribe send a message body containing "unsubscribe"
to linux-tulip-bug-request@beowulf.org