cancel
Showing results for 
Search instead for 
Did you mean: 

pings to ntp.plus.net are unreliable, especially on pcl gateways

Community Veteran
Posts: 19,100
Thanks: 437
Fixes: 21
Registered: 31-08-2007

pings to ntp.plus.net are unreliable, especially on pcl gateways

This has cropped up as a result of looking initially at tracerts as part of looking at performance on pcl-ag01 which is currently connected to new traffic management, especially following on from reply #24 and my post here.
I'm not suggesting this has anything to do with the traffic management which is why I've started another thread.
I suspect this will apply to all pcl gateways as a result of the checks in the tracert thread, but in the past I've seen odd high values on many other gateways but not looked for a pattern Embarrassed  I suspect this is to do with load balancing for the ntp servers.
Here are some of the results from pcl-ag01  -
>ping ntp.plus.net -t
Pinging ntp.plus.net [212.159.6.10] with 32 bytes of data:
Reply from 212.159.6.10: bytes=32 time=39ms TTL=250
Reply from 212.159.6.10: bytes=32 time=53ms TTL=250
Reply from 212.159.6.10: bytes=32 time=142ms TTL=250
Reply from 212.159.6.10: bytes=32 time=53ms TTL=250
Reply from 212.159.6.10: bytes=32 time=38ms TTL=250
Reply from 212.159.6.10: bytes=32 time=52ms TTL=250
Reply from 212.159.6.10: bytes=32 time=93ms TTL=250
Reply from 212.159.6.10: bytes=32 time=39ms TTL=250
Reply from 212.159.6.10: bytes=32 time=33ms TTL=250
Reply from 212.159.6.10: bytes=32 time=40ms TTL=250
Reply from 212.159.6.10: bytes=32 time=82ms TTL=250
Reply from 212.159.6.10: bytes=32 time=40ms TTL=250
Reply from 212.159.6.10: bytes=32 time=32ms TTL=250
Reply from 212.159.6.10: bytes=32 time=41ms TTL=250
Reply from 212.159.6.10: bytes=32 time=81ms TTL=250
Reply from 212.159.6.10: bytes=32 time=40ms TTL=250
Reply from 212.159.6.10: bytes=32 time=33ms TTL=250
Reply from 212.159.6.10: bytes=32 time=39ms TTL=250
Reply from 212.159.6.10: bytes=32 time=81ms TTL=250
Reply from 212.159.6.10: bytes=32 time=40ms TTL=250
Reply from 212.159.6.10: bytes=32 time=33ms TTL=250
Reply from 212.159.6.10: bytes=32 time=40ms TTL=250
Reply from 212.159.6.10: bytes=32 time=83ms TTL=250
Reply from 212.159.6.10: bytes=32 time=42ms TTL=250
Reply from 212.159.6.10: bytes=32 time=34ms TTL=250
Reply from 212.159.6.10: bytes=32 time=42ms TTL=250
Reply from 212.159.6.10: bytes=32 time=82ms TTL=250
Reply from 212.159.6.10: bytes=32 time=41ms TTL=250
Reply from 212.159.6.10: bytes=32 time=34ms TTL=250
Reply from 212.159.6.10: bytes=32 time=41ms TTL=250
Reply from 212.159.6.10: bytes=32 time=86ms TTL=250
Reply from 212.159.6.10: bytes=32 time=42ms TTL=250
Reply from 212.159.6.10: bytes=32 time=34ms TTL=250
Reply from 212.159.6.10: bytes=32 time=42ms TTL=250
Reply from 212.159.6.10: bytes=32 time=85ms TTL=250
Reply from 212.159.6.10: bytes=32 time=43ms TTL=250
Reply from 212.159.6.10: bytes=32 time=35ms TTL=250
Reply from 212.159.6.10: bytes=32 time=44ms TTL=250
Reply from 212.159.6.10: bytes=32 time=85ms TTL=250
Reply from 212.159.6.10: bytes=32 time=43ms TTL=250
Reply from 212.159.6.10: bytes=32 time=35ms TTL=250
Reply from 212.159.6.10: bytes=32 time=44ms TTL=250
Reply from 212.159.6.10: bytes=32 time=88ms TTL=250
Reply from 212.159.6.10: bytes=32 time=44ms TTL=250
Reply from 212.159.6.10: bytes=32 time=36ms TTL=250
Reply from 212.159.6.10: bytes=32 time=43ms TTL=250
Reply from 212.159.6.10: bytes=32 time=85ms TTL=250
Reply from 212.159.6.10: bytes=32 time=43ms TTL=250
Reply from 212.159.6.10: bytes=32 time=36ms TTL=250
Reply from 212.159.6.10: bytes=32 time=45ms TTL=250
Reply from 212.159.6.10: bytes=32 time=88ms TTL=250
Reply from 212.159.6.10: bytes=32 time=46ms TTL=250
Reply from 212.159.6.10: bytes=32 time=33ms TTL=250
Reply from 212.159.6.10: bytes=32 time=38ms TTL=250
Reply from 212.159.6.10: bytes=32 time=74ms TTL=250
Reply from 212.159.6.10: bytes=32 time=37ms TTL=250
Reply from 212.159.6.10: bytes=32 time=32ms TTL=250
Reply from 212.159.6.10: bytes=32 time=36ms TTL=250
Reply from 212.159.6.10: bytes=32 time=75ms TTL=250
Reply from 212.159.6.10: bytes=32 time=37ms TTL=250
Reply from 212.159.6.10: bytes=32 time=33ms TTL=250
Ping statistics for 212.159.6.10:
    Packets: Sent = 61, Received = 61, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 32ms, Maximum = 142ms, Average = 51ms
Control-C
^C
In the above, you'll notice that every 3rd result in groups of 4 gives a longer ping time.
(At none busy times, I can get results with all the ping values being identical).
Repeating the test a short while later gave the following, where it was every 4th result in a group of 4 -
>ping ntp.plus.net -t
Pinging ntp.plus.net [212.159.6.10] with 32 bytes of data:
Reply from 212.159.6.10: bytes=32 time=33ms TTL=250
Reply from 212.159.6.10: bytes=32 time=33ms TTL=250
Reply from 212.159.6.10: bytes=32 time=33ms TTL=250
Reply from 212.159.6.10: bytes=32 time=38ms TTL=250
Reply from 212.159.6.10: bytes=32 time=34ms TTL=250
Reply from 212.159.6.10: bytes=32 time=33ms TTL=250
Reply from 212.159.6.10: bytes=32 time=33ms TTL=250
Reply from 212.159.6.10: bytes=32 time=38ms TTL=250
Reply from 212.159.6.10: bytes=32 time=34ms TTL=250
Reply from 212.159.6.10: bytes=32 time=33ms TTL=250
Reply from 212.159.6.10: bytes=32 time=33ms TTL=250
Reply from 212.159.6.10: bytes=32 time=40ms TTL=250
Reply from 212.159.6.10: bytes=32 time=33ms TTL=250
Reply from 212.159.6.10: bytes=32 time=33ms TTL=250
Reply from 212.159.6.10: bytes=32 time=33ms TTL=250
Reply from 212.159.6.10: bytes=32 time=38ms TTL=250
Reply from 212.159.6.10: bytes=32 time=33ms TTL=250
Reply from 212.159.6.10: bytes=32 time=32ms TTL=250
Reply from 212.159.6.10: bytes=32 time=33ms TTL=250
Reply from 212.159.6.10: bytes=32 time=38ms TTL=250
Reply from 212.159.6.10: bytes=32 time=34ms TTL=250
Reply from 212.159.6.10: bytes=32 time=33ms TTL=250
Reply from 212.159.6.10: bytes=32 time=33ms TTL=250
Reply from 212.159.6.10: bytes=32 time=38ms TTL=250
Reply from 212.159.6.10: bytes=32 time=33ms TTL=250
Reply from 212.159.6.10: bytes=32 time=34ms TTL=250
Reply from 212.159.6.10: bytes=32 time=33ms TTL=250
Reply from 212.159.6.10: bytes=32 time=39ms TTL=250
Reply from 212.159.6.10: bytes=32 time=33ms TTL=250
Reply from 212.159.6.10: bytes=32 time=33ms TTL=250
Reply from 212.159.6.10: bytes=32 time=34ms TTL=250
Reply from 212.159.6.10: bytes=32 time=39ms TTL=250
Reply from 212.159.6.10: bytes=32 time=32ms TTL=250
Reply from 212.159.6.10: bytes=32 time=32ms TTL=250
Reply from 212.159.6.10: bytes=32 time=32ms TTL=250
Reply from 212.159.6.10: bytes=32 time=41ms TTL=250
Reply from 212.159.6.10: bytes=32 time=33ms TTL=250
Reply from 212.159.6.10: bytes=32 time=33ms TTL=250
Reply from 212.159.6.10: bytes=32 time=33ms TTL=250
Reply from 212.159.6.10: bytes=32 time=41ms TTL=250
Reply from 212.159.6.10: bytes=32 time=32ms TTL=250
Ping statistics for 212.159.6.10:
    Packets: Sent = 41, Received = 41, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 32ms, Maximum = 41ms, Average = 34ms
Control-C
^C
Then there was this oddity with the TTL  for 212.159.13.50 -
>ping 212.159.13.50 -t
Pinging 212.159.13.50 with 32 bytes of data:
Reply from 212.159.13.50: bytes=32 time=34ms TTL=249
Reply from 212.159.13.50: bytes=32 time=32ms TTL=249
Reply from 212.159.13.50: bytes=32 time=33ms TTL=249
Reply from 212.159.13.50: bytes=32 time=33ms TTL=249
Reply from 212.159.13.50: bytes=32 time=33ms TTL=249
Reply from 212.159.13.50: bytes=32 time=33ms TTL=249
Reply from 212.159.13.50: bytes=32 time=33ms TTL=249
Reply from 212.159.13.50: bytes=32 time=33ms TTL=249
Reply from 212.159.13.50: bytes=32 time=33ms TTL=249
Reply from 212.159.13.50: bytes=32 time=34ms TTL=249
Reply from 212.159.13.50: bytes=32 time=34ms TTL=249
Reply from 212.159.13.50: bytes=32 time=33ms TTL=249
Reply from 212.159.13.50: bytes=32 time=33ms TTL=249
Reply from 212.159.13.50: bytes=32 time=33ms TTL=249
Reply from 212.159.13.50: bytes=32 time=33ms TTL=249
Reply from 212.159.13.50: bytes=32 time=34ms TTL=249
Reply from 212.159.13.50: bytes=32 time=33ms TTL=249
Reply from 212.159.13.50: bytes=32 time=33ms TTL=249
Reply from 212.159.13.50: bytes=32 time=33ms TTL=249
Reply from 212.159.13.50: bytes=32 time=33ms TTL=249
Reply from 212.159.13.50: bytes=32 time=33ms TTL=249
Reply from 212.159.13.50: bytes=32 time=33ms TTL=249
Reply from 212.159.13.50: bytes=32 time=33ms TTL=249
Reply from 212.159.13.50: bytes=32 time=33ms TTL=249
Reply from 212.159.13.50: bytes=32 time=33ms TTL=249
Ping statistics for 212.159.13.50:
    Packets: Sent = 25, Received = 25, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 32ms, Maximum = 34ms, Average = 33ms
Control-C
^C
I'll do some more tests at peak times, it will be interesting to see if others can get similar odd results, particularly on pcl gateways.
41 REPLIES
Community Veteran
Posts: 2,274
Thanks: 109
Fixes: 4
Registered: 18-02-2013

Re: pings to ntp.plus.net are unreliable, especially on pcl gateways

I was looking at this earlier on today, how biazzre. here are my tinkering notepad results.
Ping statistics for 212.159.13.50:
    Packets: Sent = 159, Received = 159, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 16ms, Maximum = 119ms, Average = 29ms
Ping statistics for 93.184.219.20:
    Packets: Sent = 131, Received = 131, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 17ms, Maximum = 20ms, Average = 17ms
Ping statistics for 212.159.6.10:
    Packets: Sent = 148, Received = 148, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 16ms, Maximum = 187ms, Average = 34ms
Ping statistics for 93.184.219.20:
    Packets: Sent = 132, Received = 132, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 16ms, Maximum = 19ms, Average = 17ms
Ping statistics for 195.166.128.193:
    Packets: Sent = 139, Received = 139, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 17ms, Maximum = 250ms, Average = 24ms
Ping statistics for 212.58.244.70:
    Packets: Sent = 140, Received = 140, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 16ms, Maximum = 30ms, Average = 16ms
Tracing route to 93.184.219.20 over a maximum of 30 hops
  0  Laptop-PC [192.168.0.40]
  1  192.168.0.254
  2  lo0-central10.ptn-ag04.plus.net [195.166.128.193]
  3  link7-central10.ptn-gw01.plus.net [84.93.248.236]
  4  xe-10-1-0.ptw-cr01.plus.net [212.159.1.44]
  5  195.66.224.62
  6  93.184.219.20
Computing statistics for 150 seconds...
            Source to Here  This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                          192.168.0.40
                                0/ 100 =  0%  |
  1    1ms    0/ 100 =  0%    0/ 100 =  0%  192.168.0.254
                                0/ 100 =  0%  |
  2  27ms    0/ 100 =  0%    0/ 100 =  0%  lo0-central10.ptn-ag04.plus.net[195.166.128.193]
                                0/ 100 =  0%  |
  3  17ms    0/ 100 =  0%    0/ 100 =  0%  link7-central10.ptn-gw01.plus.net[84.93.248.236]
                                0/ 100 =  0%  |
  4  18ms    0/ 100 =  0%    0/ 100 =  0%  xe-10-1-0.ptw-cr01.plus.net [212.159.1.44]
                                0/ 100 =  0%  |
  5  20ms    0/ 100 =  0%    0/ 100 =  0%  195.66.224.62
                                0/ 100 =  0%  |
  6  17ms    0/ 100 =  0%    0/ 100 =  0%  93.184.219.20
Trace complete.
Tracing route to ntp.plus.net [212.159.6.9]
over a maximum of 30 hops:
  0  Laptop-PC [192.168.0.40]
  1  192.168.0.254
  2  lo0-central10.ptn-ag04.plus.net [195.166.128.193]
  3  link1-central10.ptn-gw01.plus.net [84.93.248.224]
  4  xe-10-1-0.ptw-cr01.plus.net [212.159.1.44]
  5  te9-4.ptn-gw01.plus.net [195.166.129.33]
  6  vl55.ptn-lb02.plus.net [212.159.2.125]
  7  cdns01.plus.net [212.159.6.9]
Computing statistics for 175 seconds...
            Source to Here  This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                          192.168.0.40
                                0/ 100 =  0%  |
  1    1ms    0/ 100 =  0%    0/ 100 =  0%  192.168.0.254
                                0/ 100 =  0%  |
  2  40ms    0/ 100 =  0%    0/ 100 =  0%  lo0-central10.ptn-ag04.plus.net [195.166.128.193]
                                0/ 100 =  0%  |
  3  18ms    0/ 100 =  0%    0/ 100 =  0%  link1-central10.ptn-gw01.plus.net[84.93.248.224]
                                0/ 100 =  0%  |
  4  19ms    0/ 100 =  0%    0/ 100 =  0%  xe-10-1-0.ptw-cr01.plus.net [212.159.1.44]
                                0/ 100 =  0%  |
  5  17ms    0/ 100 =  0%    0/ 100 =  0%  te9-4.ptn-gw01.plus.net [195.166.129.33]
                                0/ 100 =  0%  |
  6  17ms    0/ 100 =  0%    0/ 100 =  0%  vl55.ptn-lb02.plus.net [212.159.2.125]
                                0/ 100 =  0%  |
  7  19ms    0/ 100 =  0%    0/ 100 =  0%  cdns01.plus.net [212.159.6.9]
Trace complete.
Pinging 195.166.128.193 with 32 bytes of data:
Reply from 195.166.128.193: bytes=32 time=18ms TTL=126
Reply from 195.166.128.193: bytes=32 time=20ms TTL=126
Reply from 195.166.128.193: bytes=32 time=18ms TTL=126
Reply from 195.166.128.193: bytes=32 time=17ms TTL=126
Reply from 195.166.128.193: bytes=32 time=33ms TTL=126
Reply from 195.166.128.193: bytes=32 time=37ms TTL=126
Reply from 195.166.128.193: bytes=32 time=192ms TTL=126
Reply from 195.166.128.193: bytes=32 time=36ms TTL=126
Reply from 195.166.128.193: bytes=32 time=40ms TTL=126
Reply from 195.166.128.193: bytes=32 time=22ms TTL=126
Reply from 195.166.128.193: bytes=32 time=90ms TTL=126
Reply from 195.166.128.193: bytes=32 time=23ms TTL=126
Reply from 195.166.128.193: bytes=32 time=51ms TTL=126
Reply from 195.166.128.193: bytes=32 time=18ms TTL=126
Reply from 195.166.128.193: bytes=32 time=19ms TTL=126
Reply from 195.166.128.193: bytes=32 time=139ms TTL=126
Reply from 195.166.128.193: bytes=32 time=18ms TTL=126
Reply from 195.166.128.193: bytes=32 time=68ms TTL=126
Reply from 195.166.128.193: bytes=32 time=162ms TTL=126
Reply from 195.166.128.193: bytes=32 time=19ms TTL=126
Reply from 195.166.128.193: bytes=32 time=48ms TTL=126
Reply from 195.166.128.193: bytes=32 time=28ms TTL=126
Reply from 195.166.128.193: bytes=32 time=38ms TTL=126
Reply from 195.166.128.193: bytes=32 time=41ms TTL=126
Reply from 195.166.128.193: bytes=32 time=31ms TTL=126
Reply from 195.166.128.193: bytes=32 time=20ms TTL=126
Reply from 195.166.128.193: bytes=32 time=20ms TTL=126
Reply from 195.166.128.193: bytes=32 time=60ms TTL=126
Reply from 195.166.128.193: bytes=32 time=79ms TTL=126
Reply from 195.166.128.193: bytes=32 time=18ms TTL=126
Reply from 195.166.128.193: bytes=32 time=28ms TTL=126
Reply from 195.166.128.193: bytes=32 time=17ms TTL=126
Reply from 195.166.128.193: bytes=32 time=17ms TTL=126
Reply from 195.166.128.193: bytes=32 time=17ms TTL=126
Reply from 195.166.128.193: bytes=32 time=23ms TTL=126
Reply from 195.166.128.193: bytes=32 time=224ms TTL=126
Reply from 195.166.128.193: bytes=32 time=18ms TTL=126
Reply from 195.166.128.193: bytes=32 time=869ms TTL=126
Reply from 195.166.128.193: bytes=32 time=281ms TTL=126
Reply from 195.166.128.193: bytes=32 time=96ms TTL=126
Reply from 195.166.128.193: bytes=32 time=17ms TTL=126
Reply from 195.166.128.193: bytes=32 time=18ms TTL=126
Reply from 195.166.128.193: bytes=32 time=35ms TTL=126
Reply from 195.166.128.193: bytes=32 time=17ms TTL=126
Reply from 195.166.128.193: bytes=32 time=29ms TTL=126
Reply from 195.166.128.193: bytes=32 time=22ms TTL=126
Reply from 195.166.128.193: bytes=32 time=26ms TTL=126
Reply from 195.166.128.193: bytes=32 time=17ms TTL=126
Reply from 195.166.128.193: bytes=32 time=23ms TTL=126
Reply from 195.166.128.193: bytes=32 time=22ms TTL=126
Reply from 195.166.128.193: bytes=32 time=18ms TTL=126
Reply from 195.166.128.193: bytes=32 time=88ms TTL=126
Reply from 195.166.128.193: bytes=32 time=22ms TTL=126
Reply from 195.166.128.193: bytes=32 time=21ms TTL=126
Reply from 195.166.128.193: bytes=32 time=279ms TTL=126
Reply from 195.166.128.193: bytes=32 time=30ms TTL=126
Reply from 195.166.128.193: bytes=32 time=18ms TTL=126
Reply from : bytes=32 time=18ms TTL=126
Ping statistics for 195.166.128.193:
    Packets: Sent = 58, Received = 58, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 17ms, Maximum = 869ms, Average = 64ms

Also i like this new toy...
** Pinging continuously.  Press control-c to stop **
Probing 212.159.6.9:53/tcp - Port is open - time=36.467ms
Probing 212.159.6.9:53/tcp - Port is open - time=17.670ms
Probing 212.159.6.9:53/tcp - Port is open - time=18.232ms
Probing 212.159.6.9:53/tcp - Port is open - time=17.625ms
Probing 212.159.6.9:53/tcp - Port is open - time=18.345ms
Probing 212.159.6.9:53/tcp - Port is open - time=17.550ms
Probing 212.159.6.9:53/tcp - Port is open - time=17.775ms
Probing 212.159.6.9:53/tcp - Port is open - time=18.049ms
Probing 212.159.6.9:53/tcp - Port is open - time=17.641ms
Probing 212.159.6.9:53/tcp - Port is open - time=18.395ms
Probing 212.159.6.9:53/tcp - Port is open - time=20.315ms
Probing 212.159.6.9:53/tcp - Port is open - time=18.902ms
Probing 212.159.6.9:53/tcp - Port is open - time=18.236ms
Probing 212.159.6.9:53/tcp - Port is open - time=17.963ms
Probing 212.159.6.9:53/tcp - Port is open - time=17.641ms
Control-C
Ping statistics for 212.159.6.9:53
    15 probes sent.
    15 successful, 0 failed.
Approximate trip times in milli-seconds:
    Minimum = 17.550ms, Maximum = 36.467ms, Average = 19.387ms
Community Veteran
Posts: 5,056
Thanks: 422
Fixes: 16
Registered: 10-06-2010

Re: pings to ntp.plus.net are unreliable, especially on pcl gateways

There's nothing odd about the TTL being one less when there's one more hop in the route. We already noted pcl gateways route 212.159.13.50 into Telehouse North rather than staying in City Lifeline.
I'm now on pcl-ag02 after some overnight maintenance work. There wasn't any pattern in ping times.
--- 212.159.6.10 ping statistics ---
60 packets transmitted, 60 received, 0% packet loss, time 59371ms
rtt min/avg/max/mdev = 18.228/19.271/21.342/0.598 ms
Community Veteran
Posts: 19,100
Thanks: 437
Fixes: 21
Registered: 31-08-2007

Re: pings to ntp.plus.net are unreliable, especially on pcl gateways

If that was off-peak I'm not surprised
Quote from: Anotherone
..................(At none busy times, I can get results with all the ping values being identical)..................
I'll do some more tests at peak times, it will be interesting to see if others can get similar odd results, particularly on pcl gateways.

And I've never noticed a TTL of 249 before, but that may be a lack of observation, but I don't usually miss things like that.
Community Gaffer
Community Gaffer
Posts: 13,096
Thanks: 893
Fixes: 74
Registered: 04-04-2007

Re: pings to ntp.plus.net are unreliable, especially on pcl gateways

What's all the sudden fascination with pinging/tracing stuff? Cheesy
I honestly don't think there's anything of concern here. In cases you're talking milliseconds. Some of the routers on our network will de-prioritise ICMP requests when they've something better to do anyway and any number of things happening  on your local machine machine could cause variations. We've also established that some routes across our core network are slightly longer than others, although certainly not to the extend where it should cause problems.
FWIW (which isn't much), I'm on pcl-ag01 and this is from my machine at home:
C:\Users\Bob>ping ntp.plus.net -t
Pinging ntp.plus.net [212.159.6.9] with 32 bytes of data:
Reply from 212.159.6.9: bytes=32 time=16ms TTL=250
Reply from 212.159.6.9: bytes=32 time=16ms TTL=250
Reply from 212.159.6.9: bytes=32 time=17ms TTL=250
Reply from 212.159.6.9: bytes=32 time=16ms TTL=250
Reply from 212.159.6.9: bytes=32 time=16ms TTL=250
Reply from 212.159.6.9: bytes=32 time=16ms TTL=250
Reply from 212.159.6.9: bytes=32 time=17ms TTL=250
Reply from 212.159.6.9: bytes=32 time=16ms TTL=250
Reply from 212.159.6.9: bytes=32 time=16ms TTL=250
Reply from 212.159.6.9: bytes=32 time=17ms TTL=250
Reply from 212.159.6.9: bytes=32 time=17ms TTL=250
Reply from 212.159.6.9: bytes=32 time=17ms TTL=250
Reply from 212.159.6.9: bytes=32 time=16ms TTL=250
Reply from 212.159.6.9: bytes=32 time=16ms TTL=250
Reply from 212.159.6.9: bytes=32 time=15ms TTL=250
Reply from 212.159.6.9: bytes=32 time=17ms TTL=250
Reply from 212.159.6.9: bytes=32 time=17ms TTL=250
Reply from 212.159.6.9: bytes=32 time=17ms TTL=250
Reply from 212.159.6.9: bytes=32 time=17ms TTL=250
Reply from 212.159.6.9: bytes=32 time=16ms TTL=250
Reply from 212.159.6.9: bytes=32 time=16ms TTL=250
Reply from 212.159.6.9: bytes=32 time=17ms TTL=250
Reply from 212.159.6.9: bytes=32 time=16ms TTL=250
Reply from 212.159.6.9: bytes=32 time=18ms TTL=250
Reply from 212.159.6.9: bytes=32 time=16ms TTL=250
Reply from 212.159.6.9: bytes=32 time=17ms TTL=250
Reply from 212.159.6.9: bytes=32 time=17ms TTL=250
Reply from 212.159.6.9: bytes=32 time=17ms TTL=250
Reply from 212.159.6.9: bytes=32 time=16ms TTL=250
Reply from 212.159.6.9: bytes=32 time=21ms TTL=250
Reply from 212.159.6.9: bytes=32 time=19ms TTL=250
Reply from 212.159.6.9: bytes=32 time=17ms TTL=250
Reply from 212.159.6.9: bytes=32 time=16ms TTL=250
Ping statistics for 212.159.6.9:
    Packets: Sent = 33, Received = 33, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 15ms, Maximum = 21ms, Average = 16ms
Control-C
^C

Bob Pullen
Plusnet Products Team
If I've been helpful then please give thanks ⤵

Community Veteran
Posts: 19,100
Thanks: 437
Fixes: 21
Registered: 31-08-2007

Re: pings to ntp.plus.net are unreliable, especially on pcl gateways

At risk of repeating myself, bolded for clarity
Quote from: Anotherone
If that was off-peak I'm not surprised
Quote from: Anotherone
..................(At none busy times, I can get results with all the ping values being identical)..................
I'll do some more tests at peak times, it will be interesting to see if others can get similar odd results, particularly on pcl gateways.

And I've never noticed a TTL of 249 before, but that may be a lack of observation, but I don't usually miss things like that.

Quote from: Bob
What's all the sudden fascination with pinging/tracing stuff? Cheesy

This all started with DNS issues and response times. Those of us that are looking, are trying to provide some relevant data and discover why those issues arise.
Quote from: Bob
I honestly don't think there's anything of concern here. In cases you're talking milliseconds.

Gamers might not agree, but without wishing to appear flippant, packets get dropped in fractions of milliseconds.
Quote from: Bob
Some of the routers on our network will de-prioritise ICMP requests when they've something better to do

Precisely. So although ping (on a windows machine) may not be the best tool it is indicative of when its very busy or congested
Quote from: Bob
anyway and any number of things happening  on your local machine machine could cause variations.

If you count System Idle Process 98%, but I''ll certainly repeat some more tests on a faster machine later with processes stripped to a minimum.
Quote from: Bob
We've also established that some routes across our core network are slightly longer than others, although certainly not to the extend where it should cause problems.

We all hope that  Wink
Community Veteran
Posts: 2,274
Thanks: 109
Fixes: 4
Registered: 18-02-2013

Re: pings to ntp.plus.net are unreliable, especially on pcl gateways

I agree with everything everybody ses. And i like this new toy even more....
C:\Users\Laptop\Downloads>tcping -j -t www.bbc.co.uk 80
** Pinging continuously.  Press control-c to stop **
Probing 212.58.246.92:80/tcp - Port is open - time=23.029ms
Probing 212.58.246.92:80/tcp - Port is open - time=18.690ms jitter=-4.340
Probing 212.58.246.92:80/tcp - Port is open - time=18.267ms jitter=-2.593
Probing 212.58.246.92:80/tcp - Port is open - time=18.718ms jitter=-1.277
Probing 212.58.246.92:80/tcp - Port is open - time=19.115ms jitter=-0.561
Probing 212.58.246.92:80/tcp - Port is open - time=22.145ms jitter=2.582
Probing 212.58.246.92:80/tcp - Port is open - time=18.733ms jitter=-1.260
Probing 212.58.246.92:80/tcp - Port is open - time=18.961ms jitter=-0.852
Probing 212.58.246.92:80/tcp - Port is open - time=18.792ms jitter=-0.915
Probing 212.58.246.92:80/tcp - Port is open - time=22.974ms jitter=3.369
Probing 212.58.246.92:80/tcp - Port is open - time=23.450ms jitter=3.507
Probing 212.58.246.92:80/tcp - Port is open - time=24.194ms jitter=3.932
Probing 212.58.246.92:80/tcp - Port is open - time=25.016ms jitter=4.427
Probing 212.58.246.92:80/tcp - Port is open - time=23.900ms jitter=2.971
Probing 212.58.246.92:80/tcp - Port is open - time=23.625ms jitter=2.483
Probing 212.58.246.92:80/tcp - Port is open - time=23.690ms jitter=2.383
Probing 212.58.246.92:80/tcp - Port is open - time=19.018ms jitter=-2.438
Probing 212.58.246.92:80/tcp - Port is open - time=18.786ms jitter=-2.527
Probing 212.58.246.92:80/tcp - Port is open - time=18.834ms jitter=-2.338
Probing 212.58.246.92:80/tcp - Port is open - time=18.639ms jitter=-2.410
Probing 212.58.246.92:80/tcp - Port is open - time=18.874ms jitter=-2.054
Control-C
Ping statistics for 212.58.246.92:80
    21 probes sent.
    21 successful, 0 failed.
Approximate trip times in milli-seconds:
    Minimum = 18.267ms, Maximum = 25.016ms, Average = 20.831ms
Grin
Community Gaffer
Community Gaffer
Posts: 5,081
Thanks: 389
Fixes: 5
Registered: 04-04-2007

Re: pings to ntp.plus.net are unreliable, especially on pcl gateways

Quote from: Anotherone

Quote from: Bob
Some of the routers on our network will de-prioritise ICMP requests when they've something better to do

Precisely. So although ping (on a windows machine) may not be the best tool it is indicative of when its very busy or congested

Not quite.   The switching is done in hardware, responding to an ICMP request is looked at by the processor.  So ordinary traffic would route through unaffected, where as your ICMP request will be delayed because the processor is updating the router tables or something.
I'm always interested in seeing patterns that we can explain though Cheesy
Kelly Dorset
Broadband Service Manager
Community Veteran
Posts: 19,100
Thanks: 437
Fixes: 21
Registered: 31-08-2007

Re: pings to ntp.plus.net are unreliable, especially on pcl gateways

What about patterns that you can't Huh   [coat]
[/coat] So can explain why the ping every 3rd out of 4 in my first post on this thread, is longer? [coat]
Community Gaffer
Community Gaffer
Posts: 5,081
Thanks: 389
Fixes: 5
Registered: 04-04-2007

Re: pings to ntp.plus.net are unreliable, especially on pcl gateways

we can explain for you, I mean Wink
That ping patten?  No idea at all yet!
Kelly Dorset
Broadband Service Manager
Community Gaffer
Community Gaffer
Posts: 13,096
Thanks: 893
Fixes: 74
Registered: 04-04-2007

Re: pings to ntp.plus.net are unreliable, especially on pcl gateways

I guess the point I'm making is the fact that you haven't really flagged any visible problems that coincide with what you're seeing in your ICMP traces/pings etc.
We know what's caused most of the recent DNS hiccups and those problems have since been fixed.
It's also worth considering that some of the devices on our network will get busy at times.
Unless these high pings are being reported en masse (and actually causing people problems) then there's not really a great deal we can do from this side Undecided
It also makes it difficult to explain your 3/4 ping observation.
I suppose you could narrow it down further by pinging something closer to you like your router and see if there's any noticeable 3/4 pattern there? Same applies for @30FTTC06 who I'm guessing is using a wireless connection anyway based on the name of the computer?

Bob Pullen
Plusnet Products Team
If I've been helpful then please give thanks ⤵

Community Veteran
Posts: 6,313
Thanks: 86
Fixes: 3
Registered: 08-01-2008

Re: pings to ntp.plus.net are unreliable, especially on pcl gateways

The third of 4 or fourth of 4 pattern simply means something is happening (at that particular time) every four seconds (assuming a normal Windows ping repeat of one every second), whether it's repeated on the first, second, third or fourth of every four pings simply depends on when in the four second cycle the ping was initiated.
Now you're just looking for something somewhere that is working/happening, occasionally, on a four second cycle.
Call me 'w23'
At any given moment in the universe many things happen. Coincidence is a matter of how close these events are in space, time and relationship.
Opinions expressed in forum posts are those of the poster, others may have different views.
Community Veteran
Posts: 2,274
Thanks: 109
Fixes: 4
Registered: 18-02-2013

Re: pings to ntp.plus.net are unreliable, especially on pcl gateways

@Bob Look at the ping traces i did and you will see that those above the line are fine, those below the line are not, which just happen to belong to plusnet. Yes i was using my wifi. if it would make you happy i'll re-run all those tests over ethernet. In all honesty i posted in haste without fully reading Anotherone's post, i also realize that your gateways would give those results more than likely due to configuration of your equipment not to give priority to icmp ping requests... it's all pretty basic stuff! I don't see the need to question my equipment or knowledge either but hey-ho if you must have a cheap shot.

Non-authoritative answer:
Name:    gp1.adn.v2cdn.net
Address:  93.184.219.20
Aliases:  www.speedtest.net
         adn.A963.edgecastcdn.net

Ping statistics for 93.184.219.20:
   Packets: Sent = 131, Received = 131, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
   Minimum = 17ms, Maximum = 20ms, Average = 17ms
Ping statistics for 93.184.219.20:
   Packets: Sent = 132, Received = 132, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
   Minimum = 16ms, Maximum = 19ms, Average = 17ms
Non-authoritative answer:
Name:    bbc.co.uk
Addresses:  212.58.251.195
         212.58.253.67
Ping statistics for 212.58.244.70:
   Packets: Sent = 140, Received = 140, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
   Minimum = 16ms, Maximum = 30ms, Average = 16ms
=================================================================
Ping statistics for 212.159.13.50:
   Packets: Sent = 159, Received = 159, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
   Minimum = 16ms, Maximum = 119ms, Average = 29ms
Ping statistics for 212.159.6.10:
   Packets: Sent = 148, Received = 148, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
   Minimum = 16ms, Maximum = 187ms, Average = 34ms
Ping statistics for 195.166.128.193TongueTN-AG04
   Packets: Sent = 139, Received = 139, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
   Minimum = 17ms, Maximum = 250ms, Average = 24ms
Community Veteran
Posts: 5,056
Thanks: 422
Fixes: 16
Registered: 10-06-2010

Re: pings to ntp.plus.net are unreliable, especially on pcl gateways

I'm still finding ping times are almost unbelievably reliable.
--- 212.159.6.10 ping statistics ---
44 packets transmitted, 44 received, 0% packet loss, time 43062ms
rtt min/avg/max/mdev = 18.695/19.713/20.759/0.440 ms
--- 212.159.6.9 ping statistics ---
56 packets transmitted, 56 received, 0% packet loss, time 55069ms
rtt min/avg/max/mdev = 18.934/19.967/24.083/0.725 ms
Steek
Grafter
Posts: 103
Registered: 17-03-2012

Re: pings to ntp.plus.net are unreliable, especially on pcl gateways


Tracing route to bbc.co.uk [212.58.251.195]
over a maximum of 30 hops:
  1    <1 ms    <1 ms    <1 ms  router.asus.com [192.168.1.1]
  2    34 ms    40 ms    32 ms  lo0-central10.pcl-ag03.plus.net [195.166.128.184
]
  3    27 ms    30 ms    28 ms  link12-central10.pcl-gw02.plus.net [84.93.249.86
]
  4    53 ms    27 ms    27 ms  xe-1-2-0.pcl-cr02.plus.net [212.159.1.6]
  5    59 ms    28 ms    27 ms  ae2.pcl-cr01.plus.net [195.166.129.6]
  6    27 ms    30 ms    27 ms  ae1.ptw-cr01.plus.net [195.166.129.0]
  7    27 ms    27 ms    66 ms  kingston-gw.thdo.bbc.co.uk [212.58.239.6]
  8    *        *        *    Request timed out.
  9    *        *        *    Request timed out.
10    29 ms    27 ms    27 ms  ae0.er01.telhc.bbc.co.uk [132.185.254.109]
11    28 ms    28 ms    28 ms  132.185.255.140
12    31 ms    28 ms    28 ms  www-vip.telhc.bbc.co.uk [212.58.251.195]
Trace complete.
C:\Users\Steek>tracert ntp.plus.net
Tracing route to ntp.plus.net [212.159.6.9]
over a maximum of 30 hops:
  1    <1 ms    <1 ms    <1 ms  router.asus.com [192.168.1.1]
  2    28 ms    28 ms    28 ms  lo0-central10.pcl-ag03.plus.net [195.166.128.184
]
  3    27 ms    27 ms    27 ms  link3-central10.pcl-gw01.plus.net [84.93.249.68]
  4    29 ms    35 ms    75 ms  xe-1-2-0.pcl-cr01.plus.net [212.159.1.4]
  5    27 ms    27 ms    27 ms  po2.pcl-gw01.plus.net [195.166.129.41]
  6    28 ms    28 ms    29 ms  vl63.pcl-lb02.plus.net [212.159.2.253]
  7    27 ms    28 ms    28 ms  cdns01.plus.net [212.159.6.9]
Any idea why I am getting the odd 75, 66 ms?