Re: [ntp:questions] Start of new GPS 1024 week epoch
David Taylor wrote: On 23/08/2013 15:08, Martin Burnicki wrote: [] Indeed. I've just enabled the SHM refclock in the config.h file for Windows, tried to build it with VS2008, and found that it builds after I had fixed a tiny bug, a missing semicolon. However, I have also no idea if it works. David, if you want to give it a try you can simply unpack the current -dev version. Then: 1.) Open the solution (.sln file) in Visual Studio 2.) Open the file ports\winnt\include\config.h, search for CLOCK_SHM, and change the line #undef CLOCK_SHM to #define CLOCK_SHM 3.) Edit ntpd/refclock_shm.c and look around line 177. There is a line starting with msyslog(LOG_ERR, "SHM MapViewOfFile ... and at the end of this line a semicolon is missing. Just add it and the project should at least compile. As said above, don't know if it works, though, and don't know if there is another program which can feed the SHM driver under Windows. If this turns out to work I can submit the fix to the code base. Martin Martin, Thanks for that - the start of good news, I hope. I can confirm your findings - as-supplied, there is an error in ntpd/refclock_shm.c which prevent compilation, but that's easily fixed just as you described and I also now have an ntpd.exe which has compiled correctly. The fault should certainly have a bug-report submitted. OK, I can do that. This was only a tiny syntax error in the source code, but even if this is fixed we still don't know if the SHM driver really works as expected under Windows until somebody has tested it. Unfortunately, I don't have any programs which could write into shared memory, so perhaps we would need to find a simple driver (the NMEA seems an possible choice to me as many devices can drive that) and convert it to shared memory operation. I don't know if that makes much sense. I have a non-critical Windows XP box I could test on. Would the first step, though, be to see a FreeBSD or Linux driver converted and working in SHM mode, and then provide similar modifications to the Windows driver? Usually the SHM segment is fed by some other daemon/service, so if e.g gpsd could be built under Windows as service this could be used to do this. I don't know, though, if gpsd can also be used under Windows. Extracting some refclock driver code from ntpd, modify it so that it uses the SHM interface instead of ntpd's "native" refclock interface, and putting all this into an own Windows service would be quite some effort. Maybe it would make more sense to try to port gpsd or something similar to Windows, if this is not yet supported. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] manual change on clock time seems to inhibit ntp service.
David Woolley wrote: On 23/08/13 14:27, Martin Burnicki wrote: Windows machine, and watch how the reported offset (which is in milliseconds) decreases until it reaches and then stays at some minimum. There should be no minimum. It should end up varying randomly around zero. Agreed. But the numbers "randomly around zero" are usually much closer to zero under Linux, *BSD or other *IX systems than under Windows. So maybe "minimum interval around zero" might be a more precise wording. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] refid question
On 2013-08-23, Michael Dolan wrote: > I've exhausted my search for refid .FLY. and its meaning. > > Our stratum 2 client reported Stratum 1 172.17.172.74 appliance > (Symmetricon S200) initialized with .GPS. but after ~ 24 hours the > refid switched to .FLY. and the offset has been steadily increasing. > > Any guidance to what this means appreciated. It may be worth contracting the appliance manufacturer. -- Steve Kostecke NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] refid question
Michael Dolan wrote: > Long time reader first time writer… > > I've exhausted my search for refid .FLY. and its meaning. > > Our stratum 2 client reported Stratum 1 172.17.172.74 appliance (Symmetricon > S200) initialized with .GPS. but after ~ 24 hours the refid switched to .FLY. > and the offset has been steadily increasing. > > Any guidance to what this means appreciated. RTFM! If the reference becomes unavailable, the HW Clock uses the next highest available reference in the list. If no other references are available, the HW Clock provides holdover by "flywheeling" on its oscillator until a reference becomes available again. During this time, "REF" on the front panel TIME screen (press the TIME button) is "None", while the "NTP Stratum" remains "1". “REF” on the front panel NTP Status screen (press the STATUS button) changes to “FLY”. The following ref ids are used by the SyncServer: == GPS GPS satellite) IRIG IRIG B timecode PPS Ext. 1 PPS input E10M Ext. 10 MHz input FREE Internal Clock FLY Internal Clock after the Hardware Clock reference is lost == Apparently your first Symmetricon S200 has lost its reference. It needs attention. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Fwd: refid question
I should maybe add a little. The reason you are seeing an unstable offset will be that as the server has lost access to its GPS receiver, it is now serving time using just its now unlocked oscillator, which, if you can see the offset changing, is certainly quartz. If it was rb, it would be a while before you would notice any change. So you will have to ask the admins to check it out. Début du message réexpédié : > De : mike cook > Date : 24 août 2013 19:27:08 HAEC > À : Michael Dolan > Cc : questions@lists.ntp.org > Objet : Rép : [ntp:questions] refid question > > > I think it means FYLWHEEL. ie the device has lost its GPS signal. Bad > antenna?, Rollover hit??? > > Le 23 août 2013 à 17:48, Michael Dolan a écrit : > >> 172.17.172.74 > > ___ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] refid question
I think it means FYLWHEEL. ie the device has lost its GPS signal. Bad antenna?, Rollover hit??? Le 23 août 2013 à 17:48, Michael Dolan a écrit : > 172.17.172.74 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] refid question
Long time reader first time writer… I've exhausted my search for refid .FLY. and its meaning. Our stratum 2 client reported Stratum 1 172.17.172.74 appliance (Symmetricon S200) initialized with .GPS. but after ~ 24 hours the refid switched to .FLY. and the offset has been steadily increasing. Any guidance to what this means appreciated. ntpq -p remote refid st t when poll reach delay offsetdisp == LOCAL(1) LOCAL(1) 10 l 14 64 377 0.000.000 10.01 *172.17.172.72 .GPS.1 u3 64 377 0.50 -0.0250.05 172.17.172.73 0.0.0.0 16 -- 640 0.000.000 16000.0 x172.17.173.74 .FLY.1 u 59 64 37732.85 -56.0110.41 +172.17.173.75 .GPS.1 u 34 64 37732.750.0260.02 +172.17.174.76 .GPS.1 u 45 64 377 117.480.8410.34 +172.17.174.77 .GPS.1 u 45 64 377 117.260.8430.35 +172.17.174.78 .GPS.1 u 21 64 377 118.180.2210.21 Thanks! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Start of new GPS 1024 week epoch
On 23/08/2013 15:08, Martin Burnicki wrote: [] Indeed. I've just enabled the SHM refclock in the config.h file for Windows, tried to build it with VS2008, and found that it builds after I had fixed a tiny bug, a missing semicolon. However, I have also no idea if it works. David, if you want to give it a try you can simply unpack the current -dev version. Then: 1.) Open the solution (.sln file) in Visual Studio 2.) Open the file ports\winnt\include\config.h, search for CLOCK_SHM, and change the line #undef CLOCK_SHM to #define CLOCK_SHM 3.) Edit ntpd/refclock_shm.c and look around line 177. There is a line starting with msyslog(LOG_ERR, "SHM MapViewOfFile ... and at the end of this line a semicolon is missing. Just add it and the project should at least compile. As said above, don't know if it works, though, and don't know if there is another program which can feed the SHM driver under Windows. If this turns out to work I can submit the fix to the code base. Martin Martin, Thanks for that - the start of good news, I hope. I can confirm your findings - as-supplied, there is an error in ntpd/refclock_shm.c which prevent compilation, but that's easily fixed just as you described and I also now have an ntpd.exe which has compiled correctly. The fault should certainly have a bug-report submitted. Unfortunately, I don't have any programs which could write into shared memory, so perhaps we would need to find a simple driver (the NMEA seems an possible choice to me as many devices can drive that) and convert it to shared memory operation. I have a non-critical Windows XP box I could test on. Would the first step, though, be to see a FreeBSD or Linux driver converted and working in SHM mode, and then provide similar modifications to the Windows driver? Cheers, David -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Raspberry Pi error in PPM offset
On 2013-08-24, james.perou...@gmail.com wrote: > On Friday, August 23, 2013 12:09:03 PM UTC-5, unruh wrote: >> Your measurement procedure is HIGHLY suspect. > > Ok, perhaps. Could you suggest a better measurement procedure? You have not told us what yours was. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Raspberry Pi error in PPM offset
On 2013-08-24, james.perou...@gmail.com wrote: > On Friday, August 23, 2013 10:55:06 AM UTC-5, David Woolley wrote: >> Unless ntpd is failing to converge to an average offset of zero > > It's converging to an average time offset of zero, but an average frequency > offset of +2.5PPM. Fine. That means that your RPi crystal oscillator is 2.5PPM out from spec, or the calibration that the operating system did on the crystal to set the clock rate is 2.5PPM out. Either way ntpd corrects that error. If it is the calibration loop, then probably the next time you boot up it will be -4.7PPM out. etc. man adjtimex Especially the tick value and the frequency. You also still have not told us how you made your measurements. > >> (accounting for signs), the question is of marginal academic interest. > > So, are you saying that the PPM value returned by NTP is to be ignored, is > purely for information purposes, and is not to be interpreted as having any > real-world meaning? > > James ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Raspberry Pi error in PPM offset
On 24/08/13 14:46, james.perou...@gmail.com wrote: So, are you saying that the PPM value returned by NTP is to be ignored, is purely for information purposes, and is not to be interpreted as having any real-world meaning? It can be ignored, as long as it is fairly stable and not too close to +/- 500ppm. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Raspberry Pi error in PPM offset
On 8/24/2013 9:46 AM, james.perou...@gmail.com wrote: So, are you saying that the PPM value returned by NTP is to be ignored, is purely for information purposes, and is not to be interpreted as having any real-world meaning? istinfo/questions Yes and no. The value displayed is the adjustment to the frequency that NTP had to apply to maintain the time offset at zero. So your supposition that the actual system clock frequency is 2.5 ppm different than the clock frequency the kernel is using is correct, and indeed if you could accurately tell the kernel the correct frequency then you could get that number to zero. However, what is the point? Why do you care if the value ends up at zero? If you are using the kernel discipline (ntp_adjtime call) then the kernel has been told the more accurate number anyway and it is using it to update the clock. That is the whole point of making that calculation. Another problem is that the actual frequency usually isn't static. It changes with the temperature among other factors. So even if you got the kernel to use the correct value, it would still be off some of the time. Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Raspberry Pi error in PPM offset
On Friday, August 23, 2013 12:09:03 PM UTC-5, unruh wrote: > Your measurement procedure is HIGHLY suspect. Ok, perhaps. Could you suggest a better measurement procedure? BR, James ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Raspberry Pi error in PPM offset
On Friday, August 23, 2013 10:55:06 AM UTC-5, David Woolley wrote: > Unless ntpd is failing to converge to an average offset of zero It's converging to an average time offset of zero, but an average frequency offset of +2.5PPM. > (accounting for signs), the question is of marginal academic interest. So, are you saying that the PPM value returned by NTP is to be ignored, is purely for information purposes, and is not to be interpreted as having any real-world meaning? James ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] manual change on clock time seems to inhibit ntp service.
On 23/08/13 14:27, Martin Burnicki wrote: Windows machine, and watch how the reported offset (which is in milliseconds) decreases until it reaches and then stays at some minimum. There should be no minimum. It should end up varying randomly around zero. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
