[netperf-talk] TCP_RR not returning results

[Rick Jones]

> Interesting - looks like the code is posting a single-byte recv as 
> expected, getting a zero byte return, and ignoring it.  That keeps it in 
> the loop trying to complete a transaction.

And indeed that is the way the code in src/nettest_bsd.c send_tcp_rr() 
is written.  It does not expect the remote side to ever close the data 
connection first - the remote side is sitting there with an extra four 
seconds on its timer to "make sure" of that.

Of course if the remote netserver happened to die in the middle of the 
test, it means netperf would ignore the recv return of zero.

Also, if the remote netserver system's clock happened to end-up running 
faster than that on the netperf system it could have the four second pad 
be insufficient.  Are the two systems running NTP to sync time between 
themselves or via some NTP servers, or do they have free-running clocks?

It would be interesting to know if time is running faster on the 
netserver system.

TCP_STREAM and UDP_STREAM wouldn't have this problem.  At least I don't 
_think_ UDP_STREAM would, although it too has a pad timer on the 
netserver side, but there is no wait for data to be returned on the 
netperf side and I'm not sure what would happen on the send() calls if 
ICMP's started coming back because the remote port closed - if they were 
even coming back at all.

UDP_RR might be affected by a more rapid netserver clock but then almost 
anything can upset a UDP_RR test.

I suspect that the send_tcp_rr() code will need to have a check for a 
recv() return of zero added to it.  The question is - what to do when 
that check hits - fail the test or blythly continue to try to get 
something from recv_response()...  my initial reaction is to fail the 
test because I _think_ this may be the free-running clock business, but 
I'd be interested in the opinions of others on the list.

If indeed the netserver server's clock is running faster than the 
netperf server's clock, IIRC that would show-up in the elapsed_time 
being returned by netserver to netperf at the "end" of the TCP_STREAM 
test.  Adding -d -d to the netperf command line will cause it to emit a 
hex dump of the control messages which we can examine, or you can try 
applying this patch to your src/nettest_bsd.c file:

raj at tardy:~/netperf2_trunk$ svn diff src/nettest_bsd.c
Index: src/nettest_bsd.c
===================================================================
--- src/nettest_bsd.c   (revision 289)
+++ src/nettest_bsd.c   (working copy)
@@ -1961,8 +1961,10 @@

        recv_response();
        if (!netperf_response.content.serv_errno) {
-       if (debug)
-         fprintf(where,"remote results obtained\n");
+       if (debug)
+         fprintf(where,
+                 "remote reporting results for %.2f seconds\n",
+                 tcp_stream_result->elapsed_time);
        }
        else {
         Set_errno(netperf_response.content.serv_errno);

and just set the one -d (although two -d's would still be OK).

Since there is no PAD_TIME used in recv_tcp_stream(), if the netserver 
server's clock is running rather differently from the netperf server's 
clock, we should see it in that fprintf output.

happy benchmarking,

rick jones

> 
> rick
> _______________________________________________
> netperf-talk mailing list
> netperf-talk at netperf.org
> http://www.netperf.org/cgi-bin/mailman/listinfo/netperf-talk