Hey guys! This is my first time to post here in your forum!
I have a big problem.
My new purchase ASUS P4P800-VM machine has a very slow transfer file troughput.
Transferring a 372MB file from 1000 Mbps Full Duplex DELL PC through a gigabit switch, it consumed an average of 2:15minutes or a transfer rate of 2.75MBps!

I also tried this file transfer test with same setup and same environment but different Linux machines and I got satisfied results, 36sec or 10.3MBps!

My ASUS PC is connected to cat5 cable, with add-on 3Com PCI 3c905 100baseTx card, Linux Distro is RedHat 7.3 in all of our Linux box.
These are the messages of lspci:

00:00.0 Host bridge: Intel Corp.: Unknown device 2570 (rev 02)
00:02.0 VGA compatible controller: Intel Corp.: Unknown device 2572 (rev 02)
00:1d.0 USB Controller: Intel Corp.: Unknown device 24d2 (rev 02)
00:1d.1 USB Controller: Intel Corp.: Unknown device 24d4 (rev 02)
00:1d.2 USB Controller: Intel Corp.: Unknown device 24d7 (rev 02)
00:1d.3 USB Controller: Intel Corp.: Unknown device 24de (rev 02)
00:1d.7 USB Controller: Intel Corp.: Unknown device 24dd (rev 02)
00:1e.0 PCI bridge: Intel Corp. 82801BA/CA PCI Bridge (rev c2)
00:1f.0 ISA bridge: Intel Corp.: Unknown device 24d0 (rev 02)
00:1f.2 IDE interface: Intel Corp.: Unknown device 24d1 (rev 02)
00:1f.3 SMBus: Intel Corp.: Unknown device 24d3 (rev 02)
00:1f.5 Multimedia audio controller: Intel Corp.: Unknown device 24d5 (rev 02)
01:0b.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang]

I am very new in linux environment and I don't know what to do.

You should probably post what protocol you are using to transfer files (like FTP, NFS or HTTP)

HI dcostakos,
Thanks for your reply!
I was just used ordinary "cp" command in Linux.

I really don't know what other information you still need to figure out this poroblem.
So please feel free to ask me.

By the way, sorry for my late response.
I just have an internet access only in our office.
And I was on my vacation yesterday.

Hope to have good communication w/ you.

thanks again!

Since cp does not use the network at all, I'll assume that you are copying files from one machine to another using NFS.

if that is the case, I usually find that slow network transfer rates can be "fixed" by using the "tcp" mount option on the NFS client. This will only work if the NFS server supports it.

See this link to another post about slow NFS and using TCP and see if it works for you:

http://www.linuxquestions.org/questi...hreadid=211164

If you're using SAMBA or some other network protocol like SSHFS, please post that or I don't see how anyone can help you.

Hello dcostakos,

I tried yo use TCP mount option in fstab but the RedHat 7.3 Distro I used seems doesn't support this.
Below is the rcpinfo messages of my machines:

d1lux01(NFS client):
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 32768 status
100024 1 tcp 32768 status
100021 1 udp 32769 nlockmgr
100021 3 udp 32769 nlockmgr
100021 4 udp 32769 nlockmgr
100004 2 udp 652 ypserv
100004 1 udp 652 ypserv
100004 2 tcp 655 ypserv
100004 1 tcp 655 ypserv
100007 2 udp 672 ypbind
100007 1 udp 672 ypbind
100007 2 tcp 675 ypbind
100007 1 tcp 675 ypbind
391002 2 tcp 32769 sgi_fam
100009 1 udp 909 yppasswdd
100011 1 udp 609 rquotad
100011 2 udp 609 rquotad
100011 1 tcp 612 rquotad
100011 2 tcp 612 rquotad
100005 1 udp 32980 mountd
100005 1 tcp 33089 mountd
100005 2 udp 32980 mountd
100005 2 tcp 33089 mountd
100005 3 udp 32980 mountd
100005 3 tcp 33089 mountd
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs

tiyaga(NFS server):
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 32768 status
100024 1 tcp 32768 status
100021 1 udp 32769 nlockmgr
100021 3 udp 32769 nlockmgr
100021 4 udp 32769 nlockmgr
100004 2 udp 661 ypserv
100004 1 udp 661 ypserv
100004 2 tcp 664 ypserv
100004 1 tcp 664 ypserv
100007 2 udp 681 ypbind
100007 1 udp 681 ypbind
100007 2 tcp 684 ypbind
100007 1 tcp 684 ypbind
391002 2 tcp 32769 sgi_fam
100009 1 udp 882 yppasswdd
100011 1 udp 774 rquotad
100011 2 udp 774 rquotad
100011 1 tcp 777 rquotad
100011 2 tcp 777 rquotad
100005 1 udp 32803 mountd
100005 1 tcp 33204 mountd
100005 2 udp 32803 mountd
100005 2 tcp 33204 mountd
100005 3 udp 32803 mountd
100005 3 tcp 33204 mountd
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs


I also tried the suggested option in fstab [hard,rsize=8192,wsize=8192] and changing it to the following values but they are also doesn't worked.
1. rsize=1024,wsize=1024
2. rsize=3072,wsize=3072
3. rsize=6144,wsize=6144


Is there any other way how to figure out this problem? Please tell me.

Thanks!

Well, the first step is to confirm that transferring files via some TCP-based protocol is actually faster than NFS. I sould try "ftp-ing" or "scp-ing" the same file and comparing the FTP or SCP data transfer rate to NFS.

If FTP or SCP is significantly faster, then you _MAY_ be able to assume that UDP packets are getting fragmented causing slow NFS performance. At that point, the only 2 things you could do are compile a new kernel w/ TCP NFS support in the server or upgrade the server OS to something that suports TCP over NFS. Any number of newer distributions support this feature.

I also tried to use FTP in the file trasnfer of the same file but it is still not worked for me. The transfer rate is still 2.8MBps.
Additional info is that, I have other machines connected with same network but it has satisfied transfer rate performance.
The only difference is their hardware, they have same OS and Kernel.

If there any other way, please let me know.
Thank you.

2.8 MB/s is over 22Mb/s. Given that you have only a 100Mb/s connection and you have all the TCP overhead, I'd say you're not doing all that bad. Even though you have a Gigabit switch and your Dell has a Gigabit adapter, you've only got a 100Mb link on your machine.

UDP connections will ALWAYS be faster than TCP, contrary to what the previous poster says. UDP is connectionless... it's just a stream of data; whereas, TCP is connection orriented. There is handshake and verification data that is sent back and forth that isn't needed with UDP.

SCP, SFTP, etc will be even slower. These connections are TCP sent through an SSL pipe. This adds the encryption overhead to the TCP stream. SLOW, SLOWER, SLOWEST.

The fastest way of getting the data from here to there would be tftp; however, good luck getting tftpd to accept files without creating the files locally first... but that's another issue.

Your speed isn't bad. If I were you, I'd look at getting a Gigabit card for your Asus box. It seems a waste to have the gigabit backbone and not be using it.

Cheers,

MrKnisely

Hi charon79m,

Thanks for your reply.
Lets say 2.8MB/s is really good enough, but I have other linux box which is connected to same network, also have 100 Mb/s LAN card got 10MB/s transfer rate. How does it happened? The only difference is their some hardware specification. I want my Asus box to have the same transfer rate performance.

I tried tftp but I also got same slow performance.

Without changing our existing 100Mb/s LAN card to Gigabit card, is there any other way how to solve this problem? Pleas tell me.

Thank you very much.

Check for errors/colissions/drops/overruns and such.

There could be an issue with your card. You could try another cable.

Have you tested recently with that other system. It's possible that your computer you are writing to is slower now.

You could run top on each to check utilization during the transfer as well.

Just some thoughts.

Here is the output of tcpdump while I was transferring the data from D1LUX01 to TIYAGA local directory:

08:15:58.167458 TIYAGA.nfs > D1LUX01.1285984286: reply ok 136 (DF)
08:15:58.167536 D1LUX01 > TIYAGA: (frag 29807:920@7400)
08:15:58.167545 D1LUX01 > TIYAGA: (frag 29807:1480@5920+)
08:15:58.167551 D1LUX01 > TIYAGA: (frag 29807:1480@4440+)
08:15:58.167559 D1LUX01 > TIYAGA: (frag 29807:1480@2960+)
08:15:58.167565 D1LUX01 > TIYAGA: (frag 29807:1480@1480+)
08:15:58.167572 D1LUX01.1319538718 > TIYAGA.nfs: 1472 write [|nfs] (frag 29807:1480@0+)
08:15:58.221181 TIYAGA.nfs > D1LUX01.1302761502: reply ok 136 write [|nfs] (DF)
08:15:58.221260 D1LUX01 > TIYAGA: (frag 29808:920@7400)
08:15:58.221269 D1LUX01 > TIYAGA: (frag 29808:1480@5920+)
08:15:58.221275 D1LUX01 > TIYAGA: (frag 29808:1480@4440+)
08:15:58.221281 D1LUX01 > TIYAGA: (frag 29808:1480@2960+)
08:15:58.221287 D1LUX01 > TIYAGA: (frag 29808:1480@1480+)
08:15:58.221294 D1LUX01.1336315934 > TIYAGA.nfs: 1472 write [|nfs] (frag 29808:1480@0+)
08:15:58.274907 TIYAGA.nfs > D1LUX01.1319538718: reply ok 136 write [|nfs] (DF)
08:15:58.275040 D1LUX01 > TIYAGA: (frag 29809:920@7400)
08:15:58.275052 D1LUX01 > TIYAGA: (frag 29809:1480@5920+)
08:15:58.275062 D1LUX01 > TIYAGA: (frag 29809:1480@4440+)
08:15:58.275071 D1LUX01 > TIYAGA: (frag 29809:1480@2960+)
08:15:58.275081 D1LUX01 > TIYAGA: (frag 29809:1480@1480+)
08:15:58.275090 D1LUX01.1353093150 > TIYAGA.nfs: 1472 write [|nfs] (frag 29809:1480@0+)

But these messsages don't appear when I transferred the same data from TIYAGA local drive to D1Lux01.
Furthermore, the transfer rate from TIYAGA to D1LUX01 is considerable faster.
If this message shows the real problem, could you please tell me how to fix this?
Also I know that our cable is theoretically not good in Gigabit but I don't think it is the main problem, and its CPU is always almost close to 100% idle time.

Thanks again!

how long is your cable by the way?? long cables are known to be very slow. i think this is to do with timeout being not long enough (eg. say your timeout is 20ms) but because of your cable it takes twice as long to get there (eg.40ms) this will cause it to drop some of the packets so it has to get resent this takes time.

The idea is sound, until you think of electrical signals as propogating at nearly the speed of light (300Mm/s). To increase the time it takes for a signal to travel down a wire by 20ms, it would have to be:

300Mm/s * .020s = 6Mm

or in easier to read terms, 6000 km in length. Now - don't get all mad at me for blowing up your example robokiller -- I have a better solution:

A better explanation would be that longer cables have more impedance, and thus more signal loss. More signal loss = more dropped packets = slower connections.

Sorry that this won't help you with your network speed issue... but I don't want you replacing cables for no reason! Cat 6, 5, & 5e cables can be up to 100m long and still have excellent throughput.