| Defects & Anomalies - 3rd Party |
|
|
|
|
|
|
|
|
|
- Following are either;
a) unknown by iperf authors - ie. do not exist on iperf's web site
b) known by iperf authors but warrant specific mention - eg. referenced
within code or user guide |
|
| - Refer 3rd party documentation for additional known
defects/anomalies |
|
|
|
|
|
|
|
- Submission to authors;
a) Iperf/Jperf - via web form;
http://dast.nlanr.net/contactform.html (not submitted on symbian defect
database, as they are not defects related to Symbian produced SW) |
- Environment (unless specified otherwise);
a) 3.4GHz Windows Server 2003
b) iperf 2.0.2 (03 May 2005)
c) unspecified version of jperf downloaded as part of the kperf package
(presumably v1.0)
d) all testing was using udp (not tcp)
e) quiet network with no other traffic/noise
f) 1Gb/s ethernet cards on both PCs over a 100Mb/s connected by a
(reliable - as proven over many years of use) switch |
|
|
|
|
|
|
|
|
|
| No. |
Author |
Priority |
Submit Date |
Component |
Estimate (days) |
Description |
Approved |
| 1 |
|
low |
31-01-07 |
Iperf/Jperf |
|
BUG. iperf udp server 'num connections' (-P) - setting to
anything except 1 results in the server not sending the finish reply
message to the client. Setting to 1 works, but
it is painful to use since the server must be manually run every time. |
|
| 2 |
|
low |
31-01-07 |
Iperf/Jperf |
|
BUG. At the end of test completion, reports 1 fewer data
segment (aka iperf frame) than what was received/sent. This
becomes very visible when cmparing the datagram count against 3rd party
tools such as ethereal/wireshark which report the correct number of
frames. |
|
| 3 |
|
low |
31-01-07 |
Iperf/Jperf |
|
ANOMALY. When using Iperf udp server, on approximately
every 5th session when using udp at rates > 30Mb/s on a 100Mb/s
link, the first disconnect request message sent from the client is
ignored. This is despite the fact it was valid
and definitely sent (as verified by 3rd party ethereal monitoring). |
|
| 4 |
|
low |
31-01-07 |
Iperf/Jperf |
|
BUG. At speeds >20Mb/s, the algorithim for modulating
upload udp bit rate does not function very well. It
is typically 1-2Mb/s too slow. |
|
| 5 |
|
low |
31-01-07 |
Iperf/Jperf |
|
BUG. Iperf UDP server, after completing a session and
correctly disconnecting. A subsequent
connection attempt from a client using the same local port number is
ignored. If the client specifies a different
local port number (eg. randomly generates a src port number) then iperf
works as expected. |
|
| 6 |
|
low |
31-01-07 |
Iperf/Jperf |
|
BUG. If the Iperf server receives it's frist datagram with
a sequence number > 0, it wrongly reports at the end of test that it
has received the datagrams it never received. Eg.
start sending traffic from udp client, then start the server, upon
completion the server reports that it received all of the traffic...
which it didn't! |
|
| 7 |
|
low |
31-01-07 |
Iperf/Jperf |
|
ANOMALY/BUG. Reported jitter in the finish reply message
appears to be the jitter reported over the last second, but i would of
thought a more useful value would the average jitter over the entire
session? |
|
| 8 |
|
low |
31-01-07 |
Iperf/Jperf |
|
ANOMALY. The default setting of UDP buffer size (client
& server modes) of 8kB is far too low. On
my 3.4GHz Windows Server 2003 box, using the default value results in
sporadic datagram loss for bit rates > 20Mb/s. I
know it's configurable (which is very good), but perhaps the default
should be increased to a more reasonable value (eg. 1MB) to avoid false
negatives and the inevitible user questions of 'why am i dropping
packets'? |
|
| 9 |
|
low |
31-01-07 |
Iperf/Jperf |
|
BUG. I haven't been able to reliably reproduce this
defect, but it appears that approximately 1 in 20 small (eg. <20kB)
and fast (eg. >30Mb/s) does not respond to the first finish request. However, subsequent finish request (ie. retry) does
get responded too. This is unfortunate, as the
timeout associated with the retry negatively influences the metrics. |
|
| 10 |
|
low |
31-01-07 |
Iperf/Jperf |
|
BUG. iperf udp client '-n X' option to specify the number
of bytes to transmit does not work. It does not
stop sending after the specified number of bytes are sent.
eg. iperf -c 192.168.30.201 -u -P 1 -i 1 -p 5001 -w 10M -B 192.168.30.1
-l 1472 -f m -b 10M -n 5M -L 5001 -T 1 |
|
| 11 |
|
low |
31-01-07 |
Iperf/Jperf |
|
BUG. Approximately every 3rd session at relatively high
throughput (>30Mb/s) the sequence number of the finish request sent
by the client is NOT <= -(last seq. number + 1). Instead,
frequently the sequence number is = -(last seq. number), and sometimes
even > (-last seq. number). Presumably, this
is is some sort of nasty race condition? |
|
| 12 |
|
low |
02-01-07 |
Iperf/Jperf |
|
ANOMALY/BUG. Iperf reports datagrams as "sent" as soon as
the datagram enters the underlying tcp/ip stack. However,
for UDP there does not necessarily equate to the datagram being sent.
A simple example to illustrate the point is the scenario where a link
layer that requries address resolution (eg. 802.3). If
the remote IP address doesn't exist then the ARP broadcast message will
not be responded, thus making it impossible to send any Iperf datagrams. However Iperf still reports that it has sent the
datagrams when it clearly has not (easily checked with
wireshark/ethereal). |
|