Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Time Gets Lost in London
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Plusnet Community
- :
- Forum
- :
- Other forums
- :
- Tech Help - Software/Hardware etc
- :
- Time Gets Lost in London
Time Gets Lost in London
09-03-2015 9:41 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
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%
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 6
Re: Time Gets Lost in London
09-03-2015 10:28 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
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.
Re: Time Gets Lost in London
09-03-2015 10:41 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
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.
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.
Re: Time Gets Lost in London
09-03-2015 10:58 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
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.
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 (£14.40/month) Mobile: iD mobile (£4/month) |
Re: Time Gets Lost in London
10-03-2015 8:55 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
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!
Quote from: Jaggies I use ntp.plus.net as my primary time server, and uk.pool.ntp.org as my secondary.
The time server used (W7x64) was time.windows.com. So I changed it to the above and it's now much better.
Re: Time Gets Lost in London
11-03-2015 9:23 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
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.
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.
Re: Time Gets Lost in London
02-07-2015 3:01 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
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/)
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/)
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Plusnet Community
- :
- Forum
- :
- Other forums
- :
- Tech Help - Software/Hardware etc
- :
- Time Gets Lost in London