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

adamv0025 at netconsultings.com adamv0025 at netconsultings.com
Mon Apr 15 07:37:47 EDT 2019


> Martin T
> Sent: Monday, April 15, 2019 11:47 AM
> 
> 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
> 
I'm afraid this is not a valid test to prove the effect of relative process
priorities within the RE, doing this you're slowing down the clock on the
complete RE simulation as a whole (all simulated processes slowed down
equally).


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

Again this could be because these kinds of operations have lower process
priority than the process handling ping.

Maybe try setting up BGP session with a tool where you can simulate route
churn or even load high number of paths via that BGP session (subject to vMX
license limits) this would allow you to see if high RE CPU utilization
caused by RPD has any effect on the ping RTTs (the assumption here is that
RDP should have one of the highest priorities...)

adam




More information about the juniper-nsp mailing list