0

I'm trying to check what the maximum transfer speed is over ethernet. In my local network I want the communication between a Linux device and a Microsoft machine.

I tried using dd if=/dev/zero | ssh user@ip to the Microsoft machine but it doens't accept the dd command. I tried scp but is not able to send dev/zero. I read about the pv command but I don't want to install additional software on the Linux device.

Maybe it is possible to use a FTP client on the Microsoft machine and download the dev/zero to get an infinite stream of data, and while it is downloading run a script like this (https://gist.github.com/cjsewell/96463db7fec6faeab291) to check the transfer speed.

Any suggestions for a better way?

4
  • 2
    iperf3 is available both for Linux and Windows.
    – dirkt
    Dec 15, 2020 at 17:22
  • Your command dd if=/dev/zero | ssh user@ip would try to run a command on the remote system consisting of a stream of null bytes. (That isn't a command.) That's supposing your Microsoft machine has an ssh service, which most don't. What do you mean by "it doesn't accept the dd command"? Please provide details. You seem to be muddling /dev/zero with dev/zero (missing the leading /). Details are important. Dec 15, 2020 at 17:23
  • @roaima, I was hoping this would start an infinit stream of 0's to a file on the windows machine. dd if=/dev/zero | ssh [email protected] dd of=/C:/Users/Piet/text.txt [email protected]'s password: dd is not recognized as an internal or external command, operable program or batch file.' But even if this works, it is in SSH, which I don't want.
    – Dukel
    Dec 15, 2020 at 18:22
  • 1
    But that's not what you wrote in your question. Please correct your question to show the full command and the error message Dec 15, 2020 at 18:34

1 Answer 1

1

I'm trying to check what the maximum transfer speed is over ethernet. In my local network I want the communication between a Linux device and a Microsoft machine.

suggest you keep it simple, you don't need to do a stream an infinite zeros.

  • Install samba [server] on linux and open a shared folder such as /tmp.
  • On linux if it's a systemd type system, do a systemctl enable tmpfs.mount followed by a reboot. This will put the /tmp folder in ram and will prevent disk i/o from messing up the transfer numbers. This way it will all be in RAM and the slowest thing happening will be the transfer over ethernet whatever those hops may be.
  • create some .tar file sized around 10gb, do larger if you like to test transfer speed over a longer duration.
  • connect to your linux server from your windows machine making use of the samba setup, move the ~10gb file back and forth and observe the transfer speed in the popup on windows.

from linux to linux, make use of secure copy scp which is over SSH and you will notice some reduction because of the overhead of SSH. It neatly prints out the transfer speed for you when doing scp.

on a 1gbps wired network, such as 2 systems next to each other over a 6' cat6 cable, I see a solid 112 MB/sec transfer speed between windows and linux.

Over SSH with secure copy on a LAN having a few switches (not routers) it is often around 80 MB/sec; this is on rhel 7.

1gbps = 1000 mbit per sec, and is theoretical not accounting for ethernet overhead. 1000 / (8 bits per byte ) = 125 MB/sec maximum theoretical. Seeing ~112 MB/sec is 89.6%. I have never experienced larger than 113 mb/sec on a 1gbps wired network shown on that pop on the windows machine.

fwiw: just did a 7.6gb tar file over scp between two rhel 7.9 systems on a 1gbps wired network in work environment, so figure at least 2 [expensive] cisco routers present. Everything within the building. From a server having 512gb ram, secure copied to a pc having an ssd and 16gb ram. SCP finished in 1:11 and and said at the end 106.5 MB/s. So consider as a baseline a 106 mb/s vs 112 mb/s transfer speed... 84.8% vs 89.6% and the ballpark reduction in speed due to ssh overhead.

2

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .