Re: [CentOS] Network Performance Update
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. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Network Performance Update
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. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] 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> ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Network Performance
> 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. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Network Performance
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 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Network Performance
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? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Network performance issue on CentOS 6 KVM
Hi All, I am using CentOS 6.4 on 4 servers, guests are also CentOS 6.4 Network is setup using virtio, and vhost, this works well but sometime I see connection issue from application to DB. I found that sometimes latency increases from 0.200 ms approx to 123ms or even more sometimes, this happens only for 1-2 packets but keep happening after sometime. CPU load remains under 1, CPU usages is around 20-30%. If I ping from host machine to host machine then there is consistent latency, this only happens when ping from a guest machine to either other guest machines or a host machine. Did anyone face similar issue? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
