Re: [c-nsp] understanding the IP SLA "icmp-jitter" calculations

2019-04-04 Thread Saku Ytti
Nathan does raise interesting point. What if the RTT means just round time trip of X. Like it's not specifically 'RTD' so it is conceivable that's RTT Jitter. On Thu, 4 Apr 2019 at 21:07, Martin T wrote: > > Hi Nathan, > > > I could be wrong, but doesn't the output you provided above represent 1

Re: [c-nsp] understanding the IP SLA "icmp-jitter" calculations

2019-04-04 Thread Nathan Lannine
On Thu, Apr 4, 2019 at 2:07 PM Martin T wrote: > Hi Nathan, > > > I could be wrong, but doesn't the output you provided above represent 1 > ms of jitter? > > Yes, but the output of "sh ip sla statistics" in my first e-mail shows > that RTT(round-trip time) is 1ms. > You might call it a bug or a

Re: [c-nsp] understanding the IP SLA "icmp-jitter" calculations

2019-04-04 Thread Martin T
Hi Nathan, > I could be wrong, but doesn't the output you provided above represent 1 ms of > jitter? Yes, but the output of "sh ip sla statistics" in my first e-mail shows that RTT(round-trip time) is 1ms. Martin On Thu, Apr 4, 2019 at 8:47 PM Nathan Lannine wrote: >> >> csr1000v#ping 192.16

Re: [c-nsp] understanding the IP SLA "icmp-jitter" calculations

2019-04-04 Thread Nathan Lannine
> > csr1000v#ping 192.168.11.2 > Type escape sequence to abort. > Sending 5, 100-byte ICMP Echos to 192.168.11.2, timeout is 2 seconds: > ! > Success rate is 100 percent (5/5), round-trip min/avg/max = 300/300/301 ms > csr1000v# > Hello, Martin, I could be wrong, but doesn't the output you pr

Re: [c-nsp] understanding the IP SLA "icmp-jitter" calculations

2019-04-04 Thread Martin T
Hi Saku, > Unfortunately I can't offer much anything than IP SLA bug. Me too. Or the other theory I have is that maybe "icmp-jitter" feature has some kind of expectations/requirements regarding the values of STS, RTD, STD and RTS and if those are not met, then calculations are not made. Still, th

Re: [c-nsp] understanding the IP SLA "icmp-jitter" calculations

2019-04-04 Thread Saku Ytti
Thanks, ok that makes sense. Right off the bat 300ms just seemed implausible. So the tap10server is artificially delaying the packets 300ms, so there is absolutely no way CSR1k could have received it within 1ms. Unfortunately I can't offer much anything than IP SLA bug. For additional datapoint y

Re: [c-nsp] understanding the IP SLA "icmp-jitter" calculations

2019-04-04 Thread Martin T
Hi Saku, > You quote 'queueing discipline', how do you measure this, is the device fully > congested and you expect packets to sit in queue for 300ms? I'm simply using netem(http://manpages.ubuntu.com/manpages/bionic/man8/tc-netem.8.html) to introduce the delay. > How far are the devices and wh

Re: [c-nsp] understanding the IP SLA "icmp-jitter" calculations

2019-04-04 Thread Saku Ytti
Hey Martin, I'd like to understand why do you say 300ms makes sense. You quote 'queueing discipline', how do you measure this, is the device fully congested and you expect packets to sit in queue for 300ms? How far are the devices and what media is between them? What latency do you see by running

[c-nsp] understanding the IP SLA "icmp-jitter" calculations

2019-04-04 Thread Martin T
Hi, I configured an icmp-jitter type of IP SLA entry in Cisco CSR1000V router and enabled IP SLA debug. Following two sequential debug messages show the sending of the ICMP "Timestamp Request" and receiving of the ICMP "Timestamp Reply" message: *Apr 4 09:55:25.095: IPSLA-OPER_TRACE:OPER:300 Sen