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 what media is between them? I'm using Cisco CSR 1000v and remote end is the host server. So topology is simply following: csr1000v[Gi1] <-> [tap10]server Gi1 has 192.168.11.1/24 configured and tap10 has 192.168.11.2/24 configured. > What latency do you see by running simply 'ping x.y.j.k'? 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# Martin On Thu, Apr 4, 2019 at 3:22 PM Saku Ytti <[email protected]> wrote: > > 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 simply 'ping x.y.j.k'? > > On Thu, 4 Apr 2019 at 14:59, Martin T <[email protected]> wrote: > > > > 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 Sending ID: 38 > > > > *Apr 4 09:55:25.396: IPSLA-OPER_TRACE:OPER:300 Rev Seq: 1, Id: 38 > > STS: 2183208743 RTD: 35723058 STD: 35723058 RTS: 35725395 > > > > > > This 2183208743 decimal timestamp(10000010001000010001111100100111 in > > binary) is a non-standard > > value(https://tools.ietf.org/html/rfc792#page-17) as the most > > significant bit is set. 10001000010001111100100111 converts to > > 35725095 in decimal, i.e debug output above can be translated into: > > > > *Apr 4 09:55:25.396: IPSLA-OPER_TRACE:OPER:300 Rev Seq: 1, Id: 38 > > STS: 35725095 RTD: 35723058 STD: 35723058 RTS: 35725395 > > > > This means that ICMP "Timestamp Request" reached the destination > > -2037(35723058-35725095) milliseconds later. This makes sense because > > the system time in destination is set to be bit more than two seconds > > behind. Processing in destination took less than a > > millisecond(35723058-35723058). ICMP "Timestamp Reply" was sent at > > 35723058 and reached the router at 35725395, i.e time difference is > > 2337ms. 2037ms is the clock difference and 300ms added by server > > egress queue discipline. This 300ms difference can also be seen in > > debug messages timestamps, i.e "Apr 4 09:55:25.095" vs "Apr 4 > > 09:55:25.396". In short, the numbers make perfect sense. > > > > However, when I check the IP SLA statistics, then it shows that RTT > > was 1ms which is clearly wrong: > > > > IPSLAs Latest Operation Statistics > > > > IPSLA operation id: 300 > > Type of operation: icmp-jitter > > Latest RTT: 1 milliseconds > > Latest operation start time: 09:55:25 UTC Thu Apr 4 2019 > > Latest operation return code: OK > > RTT Values: > > Number Of RTT: 1 RTT Min/Avg/Max: 1/1/1 milliseconds > > Latency one-way time: > > Number of Latency one-way Samples: 0 > > Source to Destination Latency one way Min/Avg/Max: 0/0/0 > > milliseconds > > Destination to Source Latency one way Min/Avg/Max: 0/0/0 > > milliseconds > > Jitter Time: > > Number of SD Jitter Samples: 0 > > Number of DS Jitter Samples: 0 > > Source to Destination Jitter Min/Avg/Max: 0/0/0 milliseconds > > Destination to Source Jitter Min/Avg/Max: 0/0/0 milliseconds > > Over Threshold: > > Number Of RTT Over Threshold: 0 (0%) > > Packet Late Arrival: 0 > > Out Of Sequence: 0 > > Source to Destination: 0 Destination to Source 0 > > In both Directions: 0 > > Packet Skipped: 0 Packet Unprocessed: 0 > > Packet Loss: 0 > > Loss Periods Number: 0 > > Loss Period Length Min/Max: 0/0 > > Inter Loss Period Length Min/Max: 0/0 > > Number of successes: 1 > > Number of failures: 0 > > Operation time to live: Forever > > > > > > 1) Why does "sh ip sla statistics" report 1ms RTT? > > 2) Does "icmp-jitter" expect the timestamps to be STS < RTD < STD < > > RTS and if not, then no calculations are made? > > 3) How practical such measurements are as even a small, few > > millisecond time offset in remote host, can screw up the latency > > measurement results? > > > > > > thanks, > > Martin > > _______________________________________________ > > cisco-nsp mailing list [email protected] > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > > -- > ++ytti _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
