You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

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:

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.

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.

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.

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.

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.

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.

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.