slow transfers on 100mbit connection

i have two machines, "1" and "2":

1: windows98 + linux 2.2.15
nic: dec tulip 100mbit

2: win98 + linux 2.2.15
nic: 3com 905b 100mbit

the machines are connected with a crossover tp cable.

now, when i try transfering files with both machines in linux, the transfer rate drops to 2Kbytes/sec. with machine 1 in linux and 2 in win98, the transferrate is somewhat similar - 2k/sec. with 1 in win98 and 2 in win98 OR linux, the transfer rate easily goes up to 4 MB/sec!.. when both are in linux, it seems transfers go faster from 2 to 1 than from 1 to 2.

what might be causing this, and how do i fix it?


Who is Participating?
jlevieConnect With a Mentor Commented:
Yes 100Mbps should max out somewhere around 10Mb/sec, but only if the systems and the protocol used can make full use of the bandwidth. For file transfers, FTP will come the closest to being able to make full use of the bandwidth because of the way the protocol works. My guess would be that Linux<->Linux would yield the highest rates. How are doing the data transfers for the number you cited?

The seemingly odd behaviour that you observed when both were set to FDX is just a reflection of the fact the system with the Tulip card had problems dealing with FDX mode. When sending data it did okay, which frequently happens when the mode is wrong for the system/card. But when presented with an inbound data stream it choked.
The two NIC's are probably not correctly negotiating the correct speed and mode when connect via a cross-over cable. They probably would with a hub as it's live all the time. With a cross-over cable you can wind up in a catch-22 situation in that each side needs to see the other in the correct mode in order to properly set the speed and mode.

You ought to be able to force the cards to at least 100MBps HDX (and perhaps 100Mbps FDX) and get significantly better data rates. For the 905 this can be done with the 3Com configuration program. The tulip card may need to set each time the OS boots. In Linux this can be done with options in /etc/conf.modules. There's information on what the options are at
You probably want 3 for HDX or 5 for FDX.
diggzAuthor Commented:
Adjusted points from 300 to 400
Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

diggzAuthor Commented:
about using a hub.. i did that too, but the transfer-rate got so slow, it seemed like it stopped (while using the linux - linux and linux - windows setup)

therefore i tried the crossover cable.

i'll try configuring the cards properly, but it seems the tulip card is correctly set up, so i'll try fix the 3com first.

i'll post the results soon

Usually, but not always, the cards will correctly auto-negotiate with a hub. If it's not been locked to a specific speed/mode, I'd expect the 905 to properly configure itself. I've seen more problems with tulip based cards.

Of course another possibility is that one of the cards is simply bad, or possibly conflicting with some other device. Linux won't let you get away with an IRQ conflict, but I have seen windows sort of get away with it.
Check this out to see if it helps. Even though it is not a high delay link... This fixed retransmission problems on my home Win 98 machine networked with 3 linux and 1 NT machine...
Try to isolate the problem in the same way you did by trying the different OS combinations. Here are some things to check/try.

In Linux look at ifconfig. The typical setting for MTU on the ethernet card is 1500 and you should see low or 0 counts in the error stats.

Try a different program. Were you using ftp? Try samba.

Eliminate a disk by routing the received data to /dev/null

Try only going to localhost - ie. "ftp localhost" and try both routing the received data to disk and to /dev/null.

Check top to see if there are any cpu hogs while you are trying these tests (M$ has wintop which you can download - I think it's in the powertools or kernel toys)

Try a flood-ping (only root can flood-ping) with "ping -f -s 1400 the.other.machine.ip" to try pinging with 1400 byte packets at a minimum rate of 100/second. It displays a series of dots indicating packets sent but not returned yet. It will get a bit behind but does it take a few seconds to fill a line or do the dots just start rapidly filling the page? Ctrl-C stops the flood. Note: it's bad form to flood-ping on a live network and especially bad form to flood-ping your boss.

Recheck ifconfig after the flood.

As a last resort run tcpdump (again only as root) with "tcpdump -n -i eth0 > mydumpfile" and try your transfer. Stop tcpdump with Ctrl-C and read the output. It will take a while to grok the output but you may find out where the delay is happening.
diggzAuthor Commented:
hold on a sec
diggzAuthor Commented:
i should have posted this some time ago, but lynx doesnt like to submit.

i tried jlevie's tips, and it worked perfectly. I am now running both machines on 100mbit half duplex. full duplex only worked fine from machine 1 to 2, but stopped when transfering from 2 to 1.

when i modprobe the cards, i append module options, like full_duplex=0 and media_select=3 .. max transferrate is about 2-2.5 MB/sec.. why is this? i thought 100mbit networks should do maximum 10MB/sec.. my harddrives do about 5-6 mb/sec.. any ideas?

anyway, now the problem is solved, please post an answer, jlevie, and ill give you the points.. might be quite a bit more points than it was worth, but ..wellwell


diggzAuthor Commented:
case closed. thanks
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.