Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
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.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
The encryption that scp uses is also going to lower the transfer speeds. Maybe you could try with ftp? You could also try replacing ethernet cables/cards if you have extras to try to rule out a problem with them.
I can see two significant items in your hdparm output:
- lack of 32bit IO support
- the drive is only doing dma2 instead of 5/6
Do you have some other slow device on the primary port?
I'm under the impression that this is bad practice, and pretty sure that you can't 'fix' it with software.
here's output of mine for reference: (I have an identical drive on hdb too)
spitfire:~# hdparm /dev/hda
I think the big problem on that might actually be the chipset. The box is just a Pentium II. I seem to recall reading somewhere that 32 bit transfer mode could be dangerous. In fact, ALL my boxes have 16 bit transfer mode. I'll read up on that for now.
I believe the IDE chipset does not support anything higher than mode 2. Is there a way I can test higher modes with no risk to data? (The hdparm man page indicates that setting the wrong mode may be damaging to data)
If the auto setting in bios is giving you dma2 then that will probably have to do.
Might pay to have a look at bios though and double check that dma2 is the fastest mode.
I wouldn't recommend trying a fiddle with hdparm.
However, before you get completely side-tracked from your original question, have you tried a transfer from, say hda to hdb and tested the rate? Got anything on your secondary port? Try transfers from that as well.
Have you shown rates for non-scp transfers yet?
Have both the systems got enough ram? ... ie. perhaps swapping is affecting transfers.
If the ide chipset on your computer is limited to dma 2 then you could install an ultra ata 133 ide controller board. That is assuming that the drives aren't to old for the higher modes. A new controller card can be had for under 20 bucks.
Well, the /dev/hdb (/home) drive is brand spanking new as of about a week ago. It's ATA/133. I have to wonder how much it's worth though... I'll look into it.
I agree with fur.
scp can consume a significant amount of CPU overhead while it
tries to encrypt the data intended to be transferred.
Before you go ahead with spending money on a hardware investment,
I recommend that you experiment with ftp and rcp to see what kinds
of transfer rates you achieve.
1.7 MB/S is VERY slow. Even a hardrive in PIO mode could more than cope with that. This sounds to me like a duplex mismatch. You need to check for error son your switch ports and nic's if anything is reporting collisions then something is not Full duplex. Remember one end as Full and the other as auto DOES NOT WORK! You must have full/full, auto/auto, auto/half or half/half.
The 37% figure is from a study done that showed that if you have a lot of devices contending for ethernet there are so many collisions and retransmissions that only 30% of whats on the wire is real throughput, retransmissions are counted as overhead.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.