CentOS - May 2018 - Network Performance Update

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.

On 05/06/2018 06:20 AM, Chris Olson wrote:
>
> Thanks for the follow up message regarding measurement
> of network performance.? we are checking into nc and
> how it might be used.
The man page for "nc" has specific examples of sending a file over
TCP.
> We have not found iperf on any
> of our systems, but we may try installing it with yum.
>
> You may be right about the ftp server trying to use
> ftruncate() on the destination file /dev/null, but
> I do not see a reason that it would do that. What
> needs to be truncated at the beginning of a transfer?
Explaining *why* the authors of the FTP server wrote it as they did is 
beyond what I can offer.? I can explain the mechanism, but not the 
rationale.