isochronous compilation and its output issue when used with -R
A means to measure network responsiveness and throughput
Brought to you by:
rjmcmahon
Hello,
With iperf v2.1.4, the following two issues are observed that are related to isochronous:
(1) When compiling with isochronous support using "./configure --enable-isochronous", a warning message is thrown - "WARNING: unrecognized options: --enable-isochronous". What would be the resolution for that since it looks like isochronous still works without enabling the support?
(2) When testing UDP with isochronous and -R options, there seems an issue with the output on the client side, e.g., large interval, zeros for all the rest of columns. If just running isochronous without -R, it works as expected.
Ok I found it. It doesn't occur with --trip-times. Code fix is here. You'll have to compile from master to get it.
Can you provide the command line used for both sides? Also, the ifconfig or equivalent output. How are the clocks synchronized?
Here's my output
The server side command is pretty much the same except that a port number is specified. The client size command we used is below:
iperf -c 192.168.90.26 -i 1 -u -f k -B 192.168.15.4 -p 10104 -t 20 -e --isochronous=80:30M,0 -R
When we switched to use burst period and burst size, the same strange output was observed too:
iperf -c 192.168.90.26 -i 1 -u -f k -B 192.168.15.4 -p 10104 -t 10 -e --burst-period 10 --burst-size 240M -R
Can you verify this came from a master compile?
src/iperf -v
iperf version 2.1.n (4 October 2021) pthreads
Thanks. After compiling the latest master, isochronous seems working and the output shows the expected result.
There are two questions regarding the output:
(1) Latency reported by the client shows dashes for avg/min/max/stdev. Is it expected?
(2) As an example, when the following isochronous setting is used, large numbers of missed and slipped packets are reported on the server side. Are those numbers looking ok?
--isochronous=148437:76m,0
(Here we assume packet size is 64 bytes, traffic load is 76 Mbits/s, 148437 is the number of frames expected to send)
Last edit: Ray Wang 2021-10-04
The reason for the dashes is iperf found the one way delay (OWD) to be unrealistic. The clocks are not synchronized.
Item 2 is probably an assumption that the clocks are synchronized. Given a timestamp the server can compute the client frame id but that only works if the clocks are synced.
It's probably a good idea to file a bug & ticket for this, i.e. isochronous error counters should still work even w/o clock sync. I've been having all my clocks synced so I haven't tested as much on systems where they're not.
Thanks. Once I synced the clock between the client and the server, the latency is showing some numbers instead of dashes. However with the isoch setting, there is still a large number of packets shown under miss/slip which seems a bit weird. I will file a ticket for investigation.
Also, can you provide the ifconfig too. Can you try with bind to device option? Also, please use -e and provide the full output