Activity for Ray Wang
-
Ray Wang posted a comment on ticket #167
Any update on this ticket, Bob? -Ray
-
Yes, it does even after 20 secs.
-
Client launched with UDP and -R hangs if server not running
-
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.
-
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...
-
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...
-
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...
-
iperf v2.1.4 issue with burst-period and burst-size for UDP
-
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
-
isochronous compilation and its output issue when used with -R
-
I have the following two questions regarding the use of isochronous in v2.1.4: (1) As per some online doc, it seems for iperf2 to support isochronous, it needs to be configured with "./configure --enable-isochronous". Is it still true since the "configure" file does not have the entry of "enable_isochronous"? (2) Compiling the code even without the above flag, it looks like the isochronous option is still working, e.g., --isochronous=60:20M,0. However when it is used together with -R for testing...
-
According to the spec, the latency test (26.2) should be performed after the throughput test (26.1). If looking at the throughput test, interestingly the implementation of the algorithm is kind of similar to what you stated. The difference is that it checks packet loss or packet loss rate to determine if the DUT throughput is in the equilibrium state.
-
The DUT can be both the transmitter and the receiver. In real test environment, the DUT is actually connected to a device called traffic endpoint through Ethernet port. It is the traffic endpoint sending or receiving data behind the DUT. Use case 1 uses a single packet to measure the latency. Although the measurement is repeated for at least 20 times and reports the average value, it still seems a bit unconventional. Hope the Little's Law holds if more measurements can be done.
-
Thank you. Hope it will become available in the next or so release.
-
The following are 3 use cases which can be referred to RFC2544 spec. It is also the reason I would think writing per packet info to files on either client or server side for post processing is a way for implementation. 1. Run a traffic for at least 120 seconds. After 60 seconds, tag one frame with its timestamp recorded at the transmitter, recognize the tagged frame on the receiver and record the timestamp at which the frame is received. 2. Run a traffic at a rate of 110% of the maximum throughput...
-
Thanks. Agree with what you said. If it is doable, I am wondering if there is any plan to add this feature. I guess for the time being using Wireshark is probably the way to go.
-
Wireshark or tshark can do it. The question here is that is it doable using iperf2?
-
Can iperf2 output per packet info (sequence number and timestamp) to a file? Currently it reports id1, id2 and packetID if the "HAVE_PACKET_DEBUG" option is enabled but no timestamp. Is it possible to add it? Assuming the timestamp of each packet can be added, is there a way to enable or disable it say using a command line argument as in some cases per packet info might not be needed due to its large amount of data.
1
