Packet counting mode

[GoogleCodeExporter]

Explaination of new feature

It would be helpful to be able to send a known number of packets at a known 
rate, so that the 
packets can be counted at the far end.  The idea is to be able to measure the 
ability of the 
network to handle bursty behavior without requiring that the network devices be 
able to count 
packets reliably (Juniper routers can, most others cannot).

This is similar to the burst mode enhancement request.

It might be desirable to  have a flag to prime the flow cache of the routers 
along the path (routers 
with a punt-first architecture typically rely on the TCP handshake to get the 
hardware forwarding 
primed, so a big burst out of the blue might experience loss that a 
non-synthetic TCP stream 
might not experience).  The counting mechanism would have to take these 
"priming packets" into 
consideration.

Original issue reported on code.google.com by geek...@gmail.com on 13 Apr 2010 at 5:03

[GoogleCodeExporter]

Original comment by bltier...@gmail.com on 7 Sep 2012 at 3:53

• Added labels: Priority-Medium

[GoogleCodeExporter]

Original comment by bltier...@es.net on 12 Mar 2013 at 10:45

• Added labels: Milestone-3.1a1

[GoogleCodeExporter]

In addition to this, there should be a way to send exactly N UDP packets as 
fast as possible, and then quit. 

Probably should restrict N to some reasonable number to avoid serious DDOS 
attacks from this.
Maybe 5000 to start with?

Original comment by bltier...@es.net on 8 Nov 2013 at 11:35

[GoogleCodeExporter]

To control this properly, one should really expose it in bwctld.limits 
in the same way that udp bandwidth and test duration are exposed in 
bwctld.limits.

However, I agree - a burst of N packets at interface wire speed is an 
excellent feature.

        --eli

Original comment by geek...@gmail.com on 9 Nov 2013 at 2:52

[GoogleCodeExporter]

Actually it looks like this is already there (and was in iperf2 also).

See the -n flag.

Original comment by bltier...@es.net on 10 Nov 2013 at 5:34

[GoogleCodeExporter]

I think -n is for number of bytes, not number of packets.

Original comment by jef.posk...@gmail.com on 10 Nov 2013 at 5:35

[GoogleCodeExporter]

Yes -n flag for bytes 

iperf_parse_arguments(struct iperf_test *test, int argc, char **argv)
{"bytes", required_argument, NULL, 'n'},

Original comment by susant.sahani on 23 Nov 2013 at 6:35

[GoogleCodeExporter]

This would be a third termination condition, the current two being -t for time 
and -n for bytes.

It would be UDP only, since we don't have a way of counting TCP packets.

With multiple streams, I figure we should terminate when the total packet count 
across all streams reaches the threshhold.  This would be consistent with the 
-n flag which terminates on the total byte count.

Not sure what letter to use for the flag.  -N/-p/-P are taken.  Maybe 
-C/--count?

The "as fast as possible" part is already available by specifying -b0, so no 
need to mix that in with this.  They are independent features.

Original comment by jef.posk...@gmail.com on 30 Nov 2013 at 4:13

[GoogleCodeExporter]

-C is now in use for setting congestion control, so we need to choose a new 
flag.  Hmm...  How about -k for pacKet Kount?

Original comment by jef.posk...@gmail.com on 19 Dec 2013 at 3:33

[GoogleCodeExporter]

Added.

Original comment by jef.posk...@gmail.com on 19 Dec 2013 at 6:32

• Changed state: Fixed