Menu ▾ ▴

#303 Connection + bounceback option

1.0
accepted
None
2024-03-15
2024-03-14
No

Hi again,
I realised that I need a test like the TCP_CRR test in Netperf. In Netperf, TCP_RR (Request/Response) in Netperf is pretty much equal to bounceback in iperf2. On the other hand, TCP_CRR (Connection/Request/Response) disconnect and reconnect between each request/response cycle, so effectively each TCP request is a different TCP connection. I don't know if Netperf implements it reusing the same socket or using a new socket each time, I suspect the former for performance reasons. The TCP source port number increase by one for each request, if that can give a clue...
I wonder how much pain it would be to implement that in iperf2. I suspect it would break a number of assumptions :-(
Thanks in advance !
Jean

Discussion

  • Robert McMahon

    Robert McMahon - 2024-03-14

    Sure this can be done. Is the goal to meausre the connect() 3WHS, req/resp and the close all together or do they need to be separated out?

     
    • Jean Tourrilhes

      Jean Tourrilhes - 2024-03-15

      all together or do they need to be separated out

      Currently, in Netperf, they are measured all together, and that's fine with me. Netperf only reports the number of requests per seconds, and the report looks exactly the same as for the RR test (bounceback). Examples below...
      By keeping it simple, you could reuse the reports of bounceback.

      measure the connect() 3WHS, req/resp and the close

      You can see that as a measure of TCP handshake and TCP closure. But you can also see that as a measure of the network path. For example, if you are using fq_codel, every new active TCP connection force the instantiation of a new sub-queue (flow). And of course, as the number of sub-queues grow, you get into issue of classifier overhead and garbage collection. You would have similar effects if there is a load balancer on the path.

      $ netperf -H 127.0.0.1 -t TCP_CRR -- -r 1024,50
      MIGRATED TCP Connect/Request/Response TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 127.0.0.1 () port 0 AF_INET : demo
      Local /Remote
      Socket Size Request Resp. Elapsed Trans.
      Send Recv Size Size Time Rate
      bytes Bytes bytes bytes secs. per sec

      16384 131072 1024 50 10.00 13664.46
      16384 131072
      $ netperf -H 127.0.0.1 -t TCP_RR -- -r 1024,50
      MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 127.0.0.1 () port 0 AF_INET : demo : first burst 0
      Local /Remote
      Socket Size Request Resp. Elapsed Trans.
      Send Recv Size Size Time Rate
      bytes Bytes bytes bytes secs. per sec

      16384 131072 1024 50 10.00 54724.25
      16384 131072

      As you can see, the CRR test is 4 time slower than the RR test...
      Regards,
      Jean

       
  • Robert McMahon

    Robert McMahon - 2024-03-14
    • status: open --> accepted
    • assigned_to: Robert McMahon
     

Log in to post a comment.