in reply to Re: IO::Socket::INET performance on Linux
in thread IO::Socket::INET performance on Linux

Hello BrowserUK,

Sorry for the delay in answering, but your comments sent me on a long journey. I used both 'recv' and 'sysread' without much change in the results. I then compiled a new version of Perl ( Perl-5.14.4 ) and had similar results.

But the problem may be in the test case I'm using, since when I do a single transfer I can max out the GigE interfaces, but when I test for random sizes it runs at the 10Mpbs rate. I may try it on an AIX system, just in case it's a quirk of the Debian Linux systems. ( It wouldn't be the first time that Debian is different ).

Thanks for the help!

Regards...Ed

"Well done is better than well said." - Benjamin Franklin

  • Comment on Re^2: IO::Socket::INET performance on Linux

Replies are listed 'Best First'.
Re^3: IO::Socket::INET performance on Linux
by BrowserUk (Patriarch) on Nov 18, 2014 at 21:07 UTC
    I do a single transfer I can max out the GigE interfaces, but when I test for random sizes it runs at the 10Mpbs rate

    Sorry. Could you explain a little more about the difference(s) between "a single transfer" and "random sizes"?

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

      BrowserUk,

        Sorry. Could you explain a little more about the difference(s) between "a single transfer" and "random sizes"?

      I implemented the client routine as a function that I can 'require' at execution. Obviously the server runs all the time, and the client sends a command to the server and waits for a reply. Normally this reply is processed and the client exits. This is a single transfer or transaction. This works and I get near wire speed between the client and server.

      Now, I have a test case that calls the client with different command sizes and tests that the server received the correct command by returned the exact data that was sent and comparing that they are the same. This runs until I stop the test case. This is where I get the 10Mbps. So it looks like the test case has a problem, but the funny thing is this doesn't happen when the client/server are on the same server. Note: I disabled the compare just in case, but it didn't change the 10Mbps.

      I may be hitting some limitation with the Debian socket implementation, so as long as the 'single transfer' is correct, I'm okay. I've added a CRC to verify the data in addition to the size of the transfer. If either are incorrect, I ask for a re-transfer.

      Best Regards...Ed

      "Well done is better than well said." - Benjamin Franklin

[reply]
        Now, I have a test case that calls the client with different command sizes and tests that the server received the correct command by returned the exact data that was sent and comparing that they are the same. This runs until I stop the test case. This is where I get the 10Mbps. So it looks like the test case has a problem, but the funny thing is this doesn't happen when the client/server are on the same server.

        Do you make a new connection each time you send a new command?

        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Seekers of Perl Wisdom