One of our summer interns has stayed on working part time on weekends during the school year. This schedule presents an opportunity for technical investigations and some needed performance testing. The last weekend assignment included data rate testing on one specific network pathway.
Checking out previous network testing was the first assignment. Some five year old, archived SPARC/Solaris and Intel/Solaris network tests included ftp runs like the following:
ftp> ftp> put "|dd if=/dev/zero bs=32768 count=8000" /dev/null 200 PORT command successful. 150 Binary data connection for /dev/null (IP Address). 8000+0 records in 8000+0 records out 226 Transfer complete. local: |dd if=/dev/zero bs=32768 count=8000 remote: /dev/null 262144000 bytes sent in 23 seconds (11081.79 Kbytes/s) ftp>
There were dozens of examples of such ftp tests with varying block sizes, bidirectional transfers, destination files on RAID storage, and a mix of some system loading programs run independently and during the network performance testing. Also archived were a full complement of network tests with what looks like the original ttcp and possibly newer versions.
These utilities looked like they would work on our CentOS 6 systems, but we did not find ttcp and the ftp tests failed. the piping from dd failed with a message indicating that: |dd was not a recognized file.
We no longer have available CentOS systems with versions of the OS before CentOS 6. Could there have been a change to ftp that will not allow a source file specified in this way or would this transfer method have never worked on Linux?
On 04/30/2018 10:43 AM, Chris Olson wrote:
ftp> ftp> put "|dd if=/dev/zero bs=32768 count=8000" /dev/null 200 PORT command successful. 150 Binary data connection for /dev/null (IP Address). 8000+0 records in 8000+0 records out 226 Transfer complete. local: |dd if=/dev/zero bs=32768 count=8000 remote: /dev/null 262144000 bytes sent in 23 seconds (11081.79 Kbytes/s) ftp>
Though I haven't tried this, my first guess would be your ftp server is running in some kind of a chroot environment. You would have to either disable this for the test or put whatever programs and libraries are needed inside the chroot environment. You might also try specifying the full path, i.e. /bin/dd.
Nataraj
There were dozens of examples of such ftp tests with varying block sizes, bidirectional transfers, destination files on RAID storage, and a mix of some system loading programs run independently and during the network performance testing. Also archived were a full complement of network tests with what looks like the original ttcp and possibly newer versions.
ttcp morphed into iperf.
These utilities looked like they would work on our CentOS 6 systems, but we did not find ttcp and the ftp tests failed. the piping from dd failed with a message indicating that: |dd was not a recognized file.
Try
ftp> put |"dd if=/dev/zero bs=32768 count=8000" /dev/null
We no longer have available CentOS systems with versions of the OS before CentOS 6. Could there have been a change to ftp that will not allow a source file specified in this way or would this transfer method have never worked on Linux?
It works, just the semantics are a bit different.
P.
-
Chris Olson -
Nataraj -
Pete Biggs