My thanks to all that responded to my posting about measuring network performance. Helpful suggestions are always very much appreciated. The type of testing that we were attempting does not appear to be a major topic of interest on the list but the additional information below may be helpful to some users.
Initial reports of an issue with |dd not being recognized was questioned so several more tests were conducted. Testing the transfer to /dev/null was repeated several times with identical results as indicated immediately below. How this message about dd was interpreted as it not being recognized is not clear.
What is clear is the Broken pipe indication which we then went on to investigate. All indications are that the destination of the pipe was not accepting the sourced data. With this in mind we conducted several successful transfers as indicated below. It appears that /dev/null is not a legitimate place to send data from an ftp transfer. This was the case even when the original source was a file and not a dd command.
One of the suggestions in response to our original posting indicated that "|dd might be changed to |"dd. This was also tried as indicated below. Both forms of the put command that send the data to an actual file (zeros) work and were repeated several times. Using the form |"dd consistently runs slower than using the original put command format: "|dd
Bottom Line: Mystery partially solved. What is left is why the /dev/null destination for the data does not work. Just about every other commands we tried routing data to /dev/null work from any user space.
Attempting Transfer Of dd Created Output To /dev/null ------------------------------------------------------------- ftp> ftp> put "|dd if=/dev/zero bs=32768 count=8000" /dev/null local: |dd if=/dev/zero bs=32768 count=8000 remote: /dev/null 227 Entering Passive Mode (192,168,1,101,27,154) 500 OOPS: ftruncate dd: writing `standard output': Broken pipe 1+0 records in 0+0 records out 0 bytes (0 B) copied, 9.3018e-05 s, 0.0 kB/s ftp>
Successful Transfers Of dd Created Output To A File Named zeros --------------------------------------------------------------- ftp> ftp> put "|dd if=/dev/zero bs=32768 count=8000" zeros local: |dd if=/dev/zero bs=32768 count=8000 remote: zeros 227 Entering Passive Mode (192,168,1,103,164,178) 150 Ok to send data. 8000+0 records in 8000+0 records out 262144000 bytes (262 MB) copied, 26.4611 s, 9.9 MB/s 226 Transfer complete. 262144000 bytes sent in 27 seconds (9.7e+03 Kbytes/s) ftp>
ftp> ftp> put |"dd if=/dev/zero bs=32768 count=8000" zeros local: |dd if=/dev/zero bs=32768 count=8000 remote: zeros 227 Entering Passive Mode (192,168,1,103,39,252) 150 Ok to send data. 8000+0 records in 8000+0 records out 262144000 bytes (262 MB) copied, 30.7971 s, 8.5 MB/s 226 Transfer complete. 262144000 bytes sent in 31 seconds (8.3e+03 Kbytes/s) ftp>
On 05/04/2018 07:56 AM, Chris Olson wrote:
Bottom Line: Mystery partially solved. What is left is why the /dev/null destination for the data does not work.
...
Attempting Transfer Of dd Created Output To /dev/null
ftp> ftp> put "|dd if=/dev/zero bs=32768 count=8000" /dev/null local: |dd if=/dev/zero bs=32768 count=8000 remote: /dev/null 227 Entering Passive Mode (192,168,1,101,27,154) 500 OOPS: ftruncate dd: writing `standard output': Broken pipe
It looks like the FTP server is attempting to use ftruncate() on the destination file, and that call fails when the destination file is /dev/null. The server then closes the connection, and dd reports that it cannot write to its stdout fd, and the error reported is EPIPE.
You might not get that error with a different ftp server, and there are no shortage of options there. However, you're probably just as well off with something that has less overhead. You can use "nc" (netcat) for this task, or iperf as was suggested earlier.
-
Chris Olson -
Gordon Messmer