Hi All,
I've been working on a 2.0.10 release of iperf and hope this will be the
last iperf 2 release for quite awhile. In addition to bug fixes found both
internally and externally, the following are the goals.
o) Iperf 2.0.10 and iperf 2.0.5 interoperability
o) Peer version detection per a new client option (-X)
o) Support for 64 bit sequence numbers in UDP packet to support longer
duration tests
o) Two new UDP server counters (see below)
o) Support for a --reverse allowing testing through NAT firewalls
o) Fixes to summing with combined -P and -d
o) Continued support of UDP end/end latency
// Legacy 2.0.5 counters
//
// The server Total and Lost fields are derived from the packet ID
// (or sequence number) found in the payloads. This is an important
// distinction because the server is reporting from the client's tx
perspective
// more than it's recv() count perspective. The new 2.0.10 counters
// will help give a more complete view.
//
// Note: This can be different than the Client's packet count because
// packets in flight won't have updated the expected sequence number
// though the final closing UDP packet should resynch them
stats->info.udps.pkts.count.value = (stats->info.udps.srvpkts.packetid.current
- stats->info.udps.srvpkts.packetid.previous);
// Lost counter derived from sequence number gaps and adjusted by out of
order receives
stats->info.udps.srvpkts.lost.value = (stats->info.udps.srvpkts.lost.current
- stats->info.udps.srvpkts.lost.previous);
// The out of order counter. This is any packet that's sequence number is
less than expected
// so a train of in-sequence packets can be considered out of order if the
expected sequence number
// is larger than all them in the trai.
stats->info.udps.srvpkts.outoforder.value =
(stats->info.udps.srvpkts.outoforder.current
- stats->info.udps.srvpkts.outoforder.previous);
// New counters for 2.0.10 follow
//
// Here the RX count is derived from the socket recv() count where there
should be one per each packet received,
// i.e. a UDP socket recv() will preserve the socket write() boundary.
//
// Note: If IP fragments a UDP socket's write (TX) the RX stack should
restore the packet prior to UDP recv()
// so these counters are really UDP socekt level write() and recv() counts
and not underlying IP packet counts
// (nor L2,e.g. 802.11, packet counts.) Most use a write length of less
than the IP MTU so IP fragmenting
// isn't in play.
//
stats->info.udps.srvpkts.rx.value = (stats->info.udps.srvpkts.rx.current -
stats->info.udps.srvpkts.rx.previous);
// This counter indicates the number of sequence ID jumps that occurred. A
jump is where the received sequence number
// is greater than the expected by one or more . It's named here as gaps.
(Note: One could do more statistics
// on gaps but let's start with counting them)
stats->info.udps.srvpkts.gaps.value = (stats->info.udps.srvpkts.gaps.current
- stats->info.udps.srvpkts.gaps.previous);
/* * Enhanced UDP server counters * * Lost/Total/Gaps (%rx) Rx/OOO * *
Lost/Total/Gaps are derived from the pkt sequence ID (aka client)
perspective * though lost is adjusted as packets received out-of-order are
* assumed to be "found" (and not duplicates.) Many users only get stats
from * the client side (the server final report is sent to the client for *
client side consumption) so these triplet is the view from that perspective
* * Rx/OOO are packet received derived from the server view * a duplicate
will likely trigger an out-of-order * * Some scenarios (from server view) *
A: actual seq no * E: Expected seq no * L: Lost counter * G: Gap counter *
O: out-of-order counter * R: RX counter * T: Total value * * indicates
interval report output * * case: All packets per interval are out of order
whete 2.0.5 reports 0/0! * actual should be 600 received out of order: *
2.0.5: 0/0 (0%) * 2.0.10: 0/0/0 (0%) 600/600 * * case: lost and duplicates
(accounting can't be perfect here) * * A: 96 100 100 98 98 98 98 101 * * E:
96 97 101 101 101 101 101 102 * L: 0 4 3 2 1 0 -1 -2/0 * S: 0 1 1 1 1 1 1 1
* 0: 0 0 1 2 3 4 5 6 * R: 1 2 3 4 5 6 7 8 * T: 6 (101 - 96) * * case:
duplicates (negative lost reported as zero) * duplicate is R - T when L is
zero, if L non-zero * duplicates can't be accounted * * A: 96 96 96 97 * *
E: 97 97 97 98 * L: 0 -1 -2 -2 0 * G: 0 0 0 0 0 * 0: 0 1 2 2 2 * R: 1 2 3 4
4 * T: 0 0 0 1 2 */
if (packet->packetID != (stats->udps.srvpkts.packetid + 1)) {
if (packet->packetID < (stats->udps.srvpkts.packetid + 1)) {
stats->udps.srvpkts.outoforder++;
stats->udps.srvpkts.lost--;
} else {
stats->udps.srvpkts.gaps++;
stats->udps.srvpkts.lost += packet->packetID -
(stats->udps.srvpkts.packetid + 1);
}
}
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users
