Re: nping: bitrate bug

["Luis MartinGarcia." <luis.mgarc () gmail com>]

On 10/11/2012 05:09 AM, David Fifield wrote:
> On Mon, Oct 08, 2012 at 04:05:41PM +0600, Мамаев Антон Владимирович wrote:
> > Good day.
> >
> > I use nping for generate traffic with given rate. I need send
> > 12mbit/s traffic ipv6:
> >
> > nping -6 XXXX:XXXX::2 -e eth3.3352 --tcp -p 5032 -HN --data-len 1358
> > --rate 1104 -c 662739
> >
> > Send 662739 packet with payload 1358 byte and rate 1104 pps: 1358
> > byte * 8 bit * 1104 pps ~ 12mbit/s
> >
> > However, i see rate much more 12 mbit/s:
> >
> > avm@avm:~# nping -6 XXXX:XXXX::2 -e eth3.3352 --tcp -p 5032 -HN
> > --data-len 1358 --rate 1104 -c 662739
> >
> > Starting Nping 0.6.01 ( http://nmap.org/nping ) at 2012-10-08 15:43 YEKT
> > ^C
> > Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
> > Raw packets sent: 107805 (148.555MB) | Rcvd: 0 (0B) | Lost: 107805 (100.00%)
> > Tx time: 2.43267s | Tx bytes/s: 61066690.84 | Tx pkts/s: 44315.45
> > Rx time: 2.43267s | Rx bytes/s: 0.00 | Rx pkts/s: 0.00
> > Nping done: 1 IP address pinged in 2.43 seconds
> >
> > I see bitrate ~ 488 mbit/s!
> Thank you for making this report. I think the problem is that the --rate
> really only controls the inter-packet delay, and the dealy only has
> millisecond precision. This code in ArgParser.cc evaluates to a delay of 0:
>
>                 /* Compute delay from rate: delay= 1000ms/rate*/
>                 aux32 = 1000 / aux32;
>                 o.setDelay(aux32);
>
> I don't think there is an easy fix for this. Nmap has similar --min-rate
> and --max-rate options that use a more sophisticated scheduler that
> would obey a rate such as 1104. Nping could use something like it.
>
> Luis: I have some old notes from the Nmap implementation at
> http://www.bamsoftware.com/wiki/Nmap/FixedRate (section "Some sample
> stable rate-fixing code").
>
> David Fifield


Hi,

It is true that the inter-packet delay can only be expressed in
milliseconds. This is is a limitation caused by the usage of Nsock,
which does not allow scheduling events with a higher precision. However,
good news is that the current development version of Nping already
handles packet rates a lot better than it used to. Here's an example.

OLD  NPING:

luis@aberdeen ~/Desktop/repos/gitrepo/nmap $ sudo nping 1.2.3.4 --tcp
-HN --data-len 960 --rate 1000 -c 10000

Starting Nping 0.6.02 ( http://nmap.org/nping ) at 2012-10-11 08:41 CEST
 
Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 10000 (10.000MB) | Rcvd: 0 (0B) | Lost: 10000 (100.00%)
Tx time: 11.08710s | Tx bytes/s: 901949.36 | Tx pkts/s: 901.95
Rx time: 11.08741s | Rx bytes/s: 0.00 | Rx pkts/s: 0.0

LATEST DEV VERSION OF NPING:

luis@aberdeen ~/Desktop/repos/gitrepo/nmap-npingchanges/nping $ sudo
./nping 1.2.3.4 --tcp -HN --data-len 960 --rate 1000 -c 10000

Starting Nping 0.6.02 ( http://nmap.org/nping ) at 2012-10-11 08:43 CEST

Raw packets sent: 10000 (10.000MB) | Rcvd: 0 (0B) | Lost: 10000 (100.00%)
Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Tx time: 9.99874s | Tx bytes/s: 1000125.82 | Tx pkts/s: 1000.13
Rx time: 10.99976s | Rx bytes/s: 0.00 | Rx pkts/s: 0.00
Nping done: 1 IP address pinged in 11.15 seconds


Notice that in the 1000pps example, the current dev version gets the
rate just right (1000.13 packets per second). Of course, if the rate is
higher than 1000pps, then we run out of milliseconds in a second to
perform proper scheduling, so this does not work reliably for any rate>1000.

Another thing you have to consider is that the final statistics are
expressed in terms of the total number of bytes sent, not only the
payload bytes. In other words, if you are sending IPv6 packets, Nping
will count 60 bytes for the IPv6 header, 20 for the TCP header, and X
for the payload. So, take that into account or you'll never get the rate
right.

If you want to try the dev version, let me know and I'll point out how
to get it.

Best regards,

Luis Martin.




_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/