04-02-2010 03:40 AM
We've used the ping utility in-built into the Junos with the -Interval and -rapid options while trying to estimate the bandwidth capacity of the channel.
We noticed that some sort the intellectual algorithm of the speed adjustment appears when we were trying to use both parameters simultaneously (ping 172.16.20.38 count 10000 size 1400 interval 0.1 rapid).
Where we can look up for this algorithm description?
04-02-2010 11:50 AM
AFAIK, "rapid" is the almost the same as flood ping on FreeBSD
-f Flood ping. Outputs packets as fast as they come back or one hundred times per second, whichever is more. For every ECHO_REQUEST sent a period ``.'' is printed, while for every ECHO_REPLY received a backspace is printed. This provides a rapid display of how many packets are being dropped. Only the super-user may use this option.
Of course, flood ping printout and "superuser-only" privileges have been modified from original source.
04-06-2010 01:56 PM
Also see that fragmentation (pdu size above mtu size) may slow things down too (account for mac /ip header)
04-29-2010 03:45 AM
How does the generation velocity (pps or bps) change when rapid and interval are appointed sumiltaniously in junos ping? Would it be similar to the FreeBSD ping command ( -f & -i )?
As i understand ping -f in BSD ping command send 100 pps (1200kbit/s size 1500 Byte)
04-29-2010 04:43 AM - edited 04-29-2010 04:44 AM
I think the algorithm description is pretty clear:
Flood ping. Outputs packets as fast as they come back or one hundred times per second, whichever is more.
So on fast links , you can see >100 pps, the smaller the ping size, the greater is the achieved rate.
On slower links, it is dropping back to 100pps, and once 100pps is met, it stays there.
Also, there is low-prio traffic throttling on RE-PFE link, and pings are assigned to Q0/best-effort on that link in PFE->RE direction.
So if there is other control traffic going across RE-PFE link, the pings may slow down even more.
This may explain Your observations.