cancel
Showing results for 
Search instead for 
Did you mean: 

Time Gets Lost in London

AuldCPU
Newbie
Posts: 3
Registered: 09-03-2015

Time Gets Lost in London

Oh dear, NTP time packets keep disappearing on their way through London.
Has anyone seen a pool of missing  NTP packets?
Unreliable? Well that does seem to be the case what-ever the time of day but at least there does seem to be a 24-hour cycle when looking at the recorded scores.
http://www.pool.ntp.org/scores/81.174.139.3
Any ideas from a couple of monitoring sessions shown below?
Monitoring UDP NTP traffic to 0.us.pool.ntp.org
from client 41.19.14.238
1425935266.91524
1425935268.0479
No answer from 0.us.pool.ntp.org Received 260, Lost 6, 2%
98.143.24.53
132.163.4.102
192.96.207.244
208.75.88.4
wait tracing...
Tracing route to 0.us.pool.ntp.org [132.163.4.102]
over a maximum of 7 hops:
  1  41.19.14.228
  2  lo0.11.central11.ptn-bng01.plus.net [195.166.128.229]
  3  irb.11.PTW-CR01.plus.net [84.93.249.17]
  4    *    te-3-4.car5.London1.Level3.net [217.163.45.181]
  5  ae-21-52.car1.Denver1.Level3.net [4.69.147.99]
  6    *        *    CENIC.car1.Denver1.Level3.net [4.53.13.34]
  7  xe-0-1-1.core-910.frgp.net [192.43.217.173]
Computing statistics for 175 seconds...
            Source to Here  This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  1    0ms    0/ 100 =  0%    0/ 100 =  0%  41.19.14.228
                                3/ 100 =  3%  |
  2  16ms    3/ 100 =  3%    0/ 100 =  0%  lo0.11.central11.ptn-bng01.plus.ne
t [195.166.128.229]
                                8/ 100 =  8%  |
  3  ---    100/ 100 =100%    89/ 100 = 89%  irb.11.PTW-CR01.plus.net [84.93.24
9.17]
                                0/ 100 =  0%  |
  4  41ms    11/ 100 = 11%    0/ 100 =  0%  te-3-4.car5.London1.Level3.net [21
7.163.45.181]
                              89/ 100 = 89%  |
  5  ---    100/ 100 =100%    0/ 100 =  0%  ae-21-52.car1.Denver1.Level3.net [
4.69.147.99]
                                0/ 100 =  0%  |
  6  ---    100/ 100 =100%    0/ 100 =  0%  CENIC.car1.Denver1.Level3.net [4.5
3.13.34]
                                0/ 100 =  0%  |
  7  ---    100/ 100 =100%    0/ 100 =  0%  xe-0-1-1.core-910.frgp.net [192.43
.217.173]
Trace complete.
1425935466.71916
1425935467.76747
1425935468.80083
1425935469.84918
1425935470.88011
Total Received 265, Total Lost 6, 2.26415094339623%
Monitoring UDP NTP traffic to 0.us.pool.ntp.org
from client 41.19.14.238
1425935266.83025
1425935267.97269
No answer from 0.us.pool.ntp.org Received 450, Lost 6, 1%
192.96.207.244
208.75.88.4
98.143.24.53
132.163.4.102
wait tracing...
Tracing route to 0.us.pool.ntp.org [132.163.4.102]
over a maximum of 7 hops:
  1  41.19.14.228
  2  lo0.11.central11.ptn-bng01.plus.net [195.166.128.229]
  3  irb.11.PTW-CR01.plus.net [84.93.249.17]
  4  te-3-4.car5.London1.Level3.net [217.163.45.181]
  5  ae-21-52.car1.Denver1.Level3.net [4.69.147.99]
  6  CENIC.car1.Denver1.Level3.net [4.53.13.34]
  7  xe-0-1-1.core-910.frgp.net [192.43.217.173]
Computing statistics for 175 seconds...
            Source to Here  This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  1    0ms    0/ 100 =  0%    0/ 100 =  0%  41.19.14.228
                                4/ 100 =  4%  |
  2  16ms    4/ 100 =  4%    0/ 100 =  0%  lo0.11.central11.ptn-bng01.plus.ne
t [195.166.128.229]
                                9/ 100 =  9%  |
  3  ---    100/ 100 =100%    87/ 100 = 87%  irb.11.PTW-CR01.plus.net [84.93.24
9.17]
                                0/ 100 =  0%  |
  4  47ms    13/ 100 = 13%    0/ 100 =  0%  te-3-4.car5.London1.Level3.net [21
7.163.45.181]
                              87/ 100 = 87%  |
  5  ---    100/ 100 =100%    0/ 100 =  0%  ae-21-52.car1.Denver1.Level3.net [
4.69.147.99]
                                0/ 100 =  0%  |
  6  ---    100/ 100 =100%    0/ 100 =  0%  CENIC.car1.Denver1.Level3.net [4.5
3.13.34]
                                0/ 100 =  0%  |
  7  ---    100/ 100 =100%    0/ 100 =  0%  xe-0-1-1.core-910.frgp.net [192.43
.217.173]
Trace complete.
1425935465.84095
1425935466.96206
1425935468.20603
1425935469.23307
1425935470.28537
1425935471.32002
1425935472.34715
1425935473.37503
1425935474.40426
Total Received 459, Total Lost 6, 1.30718954248366%
6 REPLIES
Community Veteran
Posts: 1,617
Thanks: 22
Registered: 29-06-2010

Re: Time Gets Lost in London

Why are you getting your time from the US? I use ntp.plus.net as my primary time server, and uk.pool.ntp.org as my secondary.
AuldCPU
Newbie
Posts: 3
Registered: 09-03-2015

Re: Time Gets Lost in London

My time service is not obtained from the US pool but from my own Stratum 1 time server. My time service is available to the Europe/UK zones and as such is monitored and scored in LA.
As my NTP packets have to travel to the US, then in order to identify the cause of packet loss, my own analysis has to be across this same path but in reverse. Hence my script monitoring the NTP packets provided by the US pool of time servers.
Community Veteran
Posts: 26,718
Thanks: 931
Fixes: 10
Registered: 10-04-2007

Re: Time Gets Lost in London

I think I must be being totally thick because reading this I initially got the impression that you were trying to run an ntp server on your ADSL connection which only an idiot would try to do. Crazy
jelv (a.k.a Spoon Whittler)
   Why I have left Plusnet (warning: long post!)   
Broadband: Andrews & Arnold Home::1 (FTTC 80/20)
Line rental: Pulse 8 Home Line Rental (£13/month)
Mobile: iD mobile (£4/month)
Community Veteran
Posts: 6,735
Thanks: 12
Registered: 02-02-2008

Re: Time Gets Lost in London

Quote from: Jaggies
I use ntp.plus.net as my primary time server, and uk.pool.ntp.org as my secondary.
Hope it's not digressing too far, but this thread made me look at the time on my PC, which was a couple of minutes out!  Huh
The time server used (W7x64) was time.windows.com. So I changed it to the above and it's now much better.  Cool
grahamauld
Newbie
Posts: 2
Registered: 17-12-2014

Re: Time Gets Lost in London

Looks like this has been a common issue on PlusNet for a while.
http://community.plus.net/forum/index.php/topic,133374.msg1165667.html#msg1165667
Would be good to hear from someone at PlusNet who could follow this up.
AuldCPU
Newbie
Posts: 3
Registered: 09-03-2015

Re: Time Gets Lost in London

Interestingly, if you use IPv6 rather than IPv4 to access the US pool of time servers on the UDP NTP port, there is no packet loss and the service is reliable. The problem is only associated with the current PlusNet IPv4 service.
Hence, if you provide a time service and are seeing poor scores on the NTP Pool Project page, either use  ‘tcptraceroute’ to investigate the problem further or switch to IPv6 and re-register with the pool. (http://www.pool.ntp.org/en/)