NTP server - problem
#1
I have a system blue going (station 2241) and I notice that the time-stamp of NTP server
function is consistently 4 - 5 mS ahead of my other reference servers.  

Listed below is a time query from my workstation:-

allenc@pippin ~ $ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+SHM(0)          .MSFa.           0 l   13   64  377    0.000    0.369   0.191
*SHM(1)          .DCF.            0 l   11   64  377    0.000    0.212   0.597
-blitzortung.cid .GPS.            1 u   61   64  377    0.721    4.834   0.136
+ xxxxxxxxxx .GPS.            1 u   40   64  377   33.641    0.141   0.101
+ xxxxxxxxxx  .MRS.            1 u   44   64  377   47.260   -0.848   0.657
+ xxxxxxxxxx  .GPS.            1 u  574 1024  377   33.485    0.484   0.204
- xxxxxxxxxx  xxxxxxxxxx     2 u   43   64  377   26.984   -0.006   0.435
- xxxxxxxxxx xxxxxxxxxx    2 u   47   64  377   27.614    0.175   0.236
- xxxxxxxxxx    xxxxxxxxxx   2 u   38   64  377   30.130    0.311   0.735
allenc@pippin ~ $
MOD EDIT:  REMOVED URL INFORMATION... please protect your security!
You can see that the time offset of every server except blitzortung is within + or - 1 mS. but  the
blitzortung offset is +4.8 mS

Obviously, you will want to keep the limited processing power of system blue available
for the primary purpose of monitoring lightning strikes,  but it would be nice if you
could get the NTP time-stamp a bit closer than 4 milliseconds.
Reply
#2
(2018-12-15, 22:46)Kingfisher Wrote: Obviously, you will want to keep the limited processing power of system blue available
for the primary purpose of monitoring lightning strikes,  but it would be nice if you
could get the NTP time-stamp a bit closer than 4 milliseconds.

Here is the 'information' window on your settings page.
"Enable NTP time server. The server uses the GPS time and 1PPS as time source. It is not as accurate as other hardware dedicated to NTP, but far enough for home usage (around ~1ms). Enabled CPU sleep mode and higher load on the controller can result in much lower accuracy."

In other words, "it is what it is" ... Big Grin 

Cheers!
Mike


Stations: 689, 791, 1439, 3020
Reply
#3
(2018-12-15, 22:46)I have a stratum 0/1 server in my LAN, based on PPS also, and i use the Blitz as a secondary server.The almost "fixed" error of the Blitz station is 770 +/ - 40 μSec (0.77 mSec).This is probably the time it takes the micro-controller to catch up all the jobs and to reach the NTP calculations.The Ethernet subsystem is also "not of the latest technology", 10 MBps with long delays (1.123 mSec as you can see).In your case, maybe you have enabled more tasks in the controller.. Wrote:
    remote           refid      st t when poll reach   delay   offset  jitter
====================================================
x10.49.226.60    .GPS.            1 u   16   16  377    1.123    0.764   1.601
LOCAL(0)        LOCAL(0)        10 l   27   64  377    0.000    0.000   0.002
*SHM(1)          .PPS.            0 l    4   16  377    0.000    0.003   0.006
Reply
#4
The NTP server is a "nice to have" feature. It doesn't make sense to put too much energy into its improvement. Besides, recording and processing lightning signals has always highest priority and will have more or less impact on the NTP results.
Stations: 538, 1534, 1712, 2034, 2219
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)