rapid ping

[RTComm]

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?

[aarseniev]

Hello,

AFAIK, "rapid" is the almost the same as flood ping on FreeBSD

http://www.freebsd.org/cgi/man.cgi?query=ping&apropos=0&sektion=8&manpath=FreeBSD+6.1-RELEASE&format...

-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.

HTH

Regards

Alex

[RTComm]

I think generation speed depend on link latency

I can see different speed on different channel 

with the same ping setting.

[WadePrice-jnpr]

Also see that fragmentation (pdu size above mtu size) may slow things down too (account for mac /ip header)

Wade

[RTComm]

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)

     -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.  This can be very hard on a net-
         work and should be used with caution.

[aarseniev]

Hello,

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.

HTH

Regards

Alex