Time Gets Lost in London

[#1]

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%

[#2]

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.

[#3]

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.

[#4]

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.

[#5]

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! 
The time server used (W7x64) was time.windows.com. So I changed it to the above and it's now much better. 

[#6]

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.

[#7]

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/)