[Bloat] RRUL for netperf (bad hack)

[Bloat] RRUL for netperf (bad hack)

[Eggert, Lars]

[-- Attachment #1.1: Type: text/plain, Size: 876 bytes --]

Hi,

the attached patch is a horrible, horrible, HORRIBLE hack to add some sort of RRUL testing into netperf. I needed something like this for some quick testing and thought maybe someone else can get some use out of it. (I was interested in the delay an application sees on top of a TCP stream, which is not something Toke's excellent netperf-wrapper tool can currently do, AFAIK.)

I've only really used this with stream tests, and it only produces sensible results with a specific request size such as "-r 16384" or something. And I've only used this on Linux.

Basically, this embeds a timeval into the test stream for each block, echoes it back to the sender, and then prints the application-level RTT seen. (It also prints a one-way delay, but that is only sensible to look at for clocks synchronized to an accuracy much better than the network delay.)

Lars


[-- Attachment #1.2: nettest_omni.c.patch --]
[-- Type: application/octet-stream, Size: 1945 bytes --]

Index: src/nettest_omni.c
===================================================================
--- src/nettest_omni.c	(revision 676)
+++ src/nettest_omni.c	(working copy)
@@ -46,6 +46,7 @@
 #if HAVE_SCHED_H
 # include <sched.h>
 #endif
+#include <poll.h>
 
 #include <fcntl.h>
 #ifndef WIN32
@@ -2990,6 +2991,10 @@
     fflush(where);
   }
 
+#ifdef RTT
+      gettimeofday(send_ring->buffer_ptr, 0);
+#endif
+
   if (destination) {
     if (have_pktinfo) {
       len = send_pktinfo(data_socket,
@@ -3030,6 +3035,25 @@
 #endif
     }
   }
+
+#ifdef RTT
+  struct pollfd fds = { .fd = data_socket, .events = POLLIN };
+  if (poll(&fds, 1, 0) > 0) {
+    struct timeval now;
+    struct timeval before;
+    if (recv(data_socket, &before, sizeof(struct timeval), MSG_WAITALL) == -1) {
+      if(errno != EINTR) {
+        perror("netperf: recv timeval");
+        exit(-1);
+      }
+    }
+    gettimeofday(&now, 0);
+    int rtt = delta_micro(&before, &now);
+    if (rtt > 0)
+      fprintf(stderr, "%d usec RTT\n", rtt);
+  }
+#endif
+
   if(len != bytes_to_send) {
     /* don't forget that some platforms may do a partial send upon
        receipt of the interrupt and not return an EINTR... */
@@ -5790,7 +5814,21 @@
 	}
 	bytes_received += ret;
 	local_receive_calls += temp_recvs;
+
+#ifdef RTT
+        int chunk = bytes_received % bytes_to_recv;
+        if (chunk && chunk < ret) {
+          struct timeval *before = &(recv_ring->buffer_ptr[ret - chunk]);
+          struct timeval now;
+          gettimeofday(&now, 0);
+          fprintf(stderr, "%d usec one-way delay \n", delta_micro(before, &now));
+          if(send(data_socket, before, sizeof(struct timeval), 0) == -1) {
+            perror("netperf: send timeval");
+            exit(-1);
       }
+        }
+#endif
+      }
       else if (ret == 0) {
 	/* is this the end of a test, just a zero-byte recv, or
 	   something else? that is an exceedingly good question and

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [Bloat] RRUL for netperf (bad hack)

[Bill Ver Steeg (versteb)]

Lars-

Iperf also has some one-way and two-way delay measurements (or at least the version I used last year did). It also put timestamps in the payload of the packets.

Bill Ver Steeg












-----Original Message-----
From: bloat-bounces@lists.bufferbloat.net [mailto:bloat-bounces@lists.bufferbloat.net] On Behalf Of Eggert, Lars
Sent: Friday, April 17, 2015 10:46 AM
To: bloat
Subject: [Bloat] RRUL for netperf (bad hack)

Hi,

the attached patch is a horrible, horrible, HORRIBLE hack to add some sort of RRUL testing into netperf. I needed something like this for some quick testing and thought maybe someone else can get some use out of it. (I was interested in the delay an application sees on top of a TCP stream, which is not something Toke's excellent netperf-wrapper tool can currently do, AFAIK.)

I've only really used this with stream tests, and it only produces sensible results with a specific request size such as "-r 16384" or something. And I've only used this on Linux.

Basically, this embeds a timeval into the test stream for each block, echoes it back to the sender, and then prints the application-level RTT seen. (It also prints a one-way delay, but that is only sensible to look at for clocks synchronized to an accuracy much better than the network delay.)

Lars

Re: [Bloat] RRUL for netperf (bad hack)

[Eggert, Lars]

[-- Attachment #1: Type: text/plain, Size: 365 bytes --]

Hi,

On 2015-4-17, at 18:18, Bill Ver Steeg (versteb) <versteb@cisco.com> wrote:
> 
> Iperf also has some one-way and two-way delay measurements (or at least the version I used last year did). It also put timestamps in the payload of the packets.

got a pointer to that version of iperf? I only see some latency-related stuff for UDP flows.

Thanks,
Lars

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [Bloat] RRUL for netperf (bad hack)

[Bill Ver Steeg (versteb)]

Lars-

Looking now - Thinking back, I probably hacked it in myself.  I do not see it on my road Linux laptop, so I will check on my servers when I am back in the office. 



Bill Ver Steeg



-----Original Message-----
From: Eggert, Lars [mailto:lars@netapp.com] 
Sent: Friday, April 17, 2015 12:38 PM
To: Bill Ver Steeg (versteb)
Cc: bloat
Subject: Re: RRUL for netperf (bad hack)

Hi,

On 2015-4-17, at 18:18, Bill Ver Steeg (versteb) <versteb@cisco.com> wrote:
> 
> Iperf also has some one-way and two-way delay measurements (or at least the version I used last year did). It also put timestamps in the payload of the packets.

got a pointer to that version of iperf? I only see some latency-related stuff for UDP flows.

Thanks,
Lars

Re: [Bloat] RRUL for netperf (bad hack)

[Dave Taht]

I am delighted to see this functionality in netperf, however hacky. We
could use to also do something tcp-like in udp, with timestamping like
this (perhaps using the SO_TIMESTAMPING api in linux for increased
accuracy on rx)...

Getting better tools, one patch at a time, one tool at a time, one
daemon at a time...

On Fri, Apr 17, 2015 at 10:04 AM, Bill Ver Steeg (versteb)
<versteb@cisco.com> wrote:
> Lars-
>
> Looking now - Thinking back, I probably hacked it in myself.  I do not see it on my road Linux laptop, so I will check on my servers when I am back in the office.
>
>
>
> Bill Ver Steeg
>
>
>
> -----Original Message-----
> From: Eggert, Lars [mailto:lars@netapp.com]
> Sent: Friday, April 17, 2015 12:38 PM
> To: Bill Ver Steeg (versteb)
> Cc: bloat
> Subject: Re: RRUL for netperf (bad hack)
>
> Hi,
>
> On 2015-4-17, at 18:18, Bill Ver Steeg (versteb) <versteb@cisco.com> wrote:
>>
>> Iperf also has some one-way and two-way delay measurements (or at least the version I used last year did). It also put timestamps in the payload of the packets.
>
> got a pointer to that version of iperf? I only see some latency-related stuff for UDP flows.
>
> Thanks,
> Lars
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67

Re: [Bloat] RRUL for netperf (bad hack)

[Toke Høiland-Jørgensen]

"Eggert, Lars" <lars@netapp.com> writes:

> (I was interested in the delay an application sees on top of a TCP
> stream, which is not something Toke's excellent netperf-wrapper tool
> can currently do, AFAIK.)

You're quite right. If a version of this makes it upstream in netperf,
I'm quite happy to add in a parser for it so it can be used with the
other tests in netperf-wrapper :)

-Toke