[j-nsp] What exactly causes inconsistent RTT seen using ping utility in Junos?

[Martin T]

Hi Saku,

thanks for reply!

> > This is well know behavior and documented in several KB articles.
> > However, what exactly causes this?
>
> I think just CPU doing something else before given time to do the ICMP
> packets. Like busy running some RPD task.

I also thought that it has something to do with control-plane
process/thread scheduling at first. However, I would expect the RTT of
ping to become even more inconsistent when less CPU-time is available
for sending the ICMP "echo request" messages, but this is not the
case. For example, if I pin the vCPU of virtual control plane to
physical CPU core 0:

$ sudo virsh vcpuinfo vcp-vmx1
VCPU:           0
CPU:            0
State:          running
CPU time:       142291.0s
CPU Affinity:   y-------

$

..and at the same time run stress-ng on the core 0:

$ sudo taskset 0x00000001 stress-ng --cpu 1 --timeout 600s

..and "while :; do /usr/bin/nice -n -20 sha256 /var/tmp/2GB &
/usr/bin/nice -n -20 sha256 /var/tmp/2GB & /usr/bin/nice -n -20 sha256
/var/tmp/2GB; done" on the RE, then it has no affect to RTT. Physical
core CPU utilization was ~100% and RE CPU utilization seen with "show
chassis routing-engine" was >80%:

    1 min CPU utilization:
      User                      83 percent
      Background                 0 percent
      Kernel                    16 percent
      Interrupt                  1 percent
      Idle                       0 percent


In addition, the KB28157 says that "An ICMP ping shows intermittent
latency on a directly connected link with the default Junos Class of
Service (CoS) configuration" which gives an impression that there is a
non-default CoS configuration where there is steady latency.
This makes me think that the this occasional abnormal latency is not
caused by RE. However, I could be easily wrong.


> > Based on this information I changed the CoS configuration in two MX
> > series routers. First I tried with vMX(runs in performance mode) and
> > configured RE-sent ICMP "echo request" messages into forwarding-class
> > named "ef" and associated this class with low-latency queue:
>
> This won't do anything, this is only applicable for forwarding-plane
> traffic. For control-plane you want 'set class-of-service
> host-outbound-traffic forwarding-class ef'. However this won't do
> anything to give CPU scheduling priority on sending and receiving ICMP
> messages.

I classified control-plane ICMP traffic into "ef" forwarding-class
with multifield classifier on lo0. It has the same effect as
"host-outbound-traffic".


Martin