Meinberg NTP monitor, silly question
G8KBV
A silly question if I may, and yes I've been poking arround the Meinberg
website and forum for hours, and can't find the answer. Likewise the
(non existant) help within the program, though I'm *sure* I've seen text
on this somewhere, but can't find it at the moment.
Re the status column in the 'NTP Status' tab.
I think a * means that this server is being used as the reference.
+ signals a posible candidate for use as a reference.
- = will not be used (for whatever reason)
But what does 'o' mean?
I have now successfully (I think) got the local NTP server program
ticking along in sympathy with a GPS receiver with PPS, but though the
address 127.127.20.2 shows with a '*' (and is coloured green)
The 'Server' PPS(2) shows with the 'o' status, and though green in
colour, I cannot find out what that status flag means.
Where have I forgotten to look? As I can find little meeningful help on
what the various parts of Meinberg's monitor program actualy mean, in
sufficient (and not OTT) detail for the faded befuddled grey cell.
The "Application Log" shows:-
Using user-mode PPS timestamp for GPS_NMEA(2) Not that I think it'll
make any significant difference, but I thought I'd set all this up so
that the PPS thing would run in Kernel mode, but obviously not.
What I've got is this in the NTP status tab page...
State Remote Refid Stratum Type When Poll
Reach Delay Offset Jitter
* 127.127.20.2 GPS 0 Local clock 9 16 377
0.000 0.089 0.006
o PPS(2) PPS 0 Local clock 8 16 377
0.000 0.124 0.004
+ 83.170.75.28 130.88.200.6 3 Unicast server 1439 1024
376 22.333 2.644 1.013
- 82.219.4.31 195.66.241.3 2 Unicast server 302 1024
377 27.919 4.023 0.960
+ 213.130.44.252 192.93.2.20 2 Unicast server 271
1024 377 20.736 1.023 1.408
Yes, the mailer wrapped it all, but hope someone can understand it and
say if it's good/bad or ???
Preliminary results are a *HUGE* improvement over using Wan based
servers, but the system is still settling, and the GPS RX is still
indoors! (high up and seemingly happy, but not as good a sky view as
it'll be when eventualy sited outside.)
Best Regards.
Dave Baxter.
Dave Hart
> But what does 'o' mean?
It means the PPS peer, and when present effective trumps any * seen.
> The "Application Log" shows:-
> Using user-mode PPS timestamp for GPS_NMEA(2) Not that I think it'll
> make any significant difference, but I thought I'd set all this up so
> that the PPS thing would run in Kernel mode, but obviously not.
So 127.127.20.2 (NMEA) is using the user-mode hack to get DCD
timestamps, which is only effective when you restrict the GPS to one
sentence per second. However, 127.127.22.2 (atom/PPS) is using real
kernel-mode PPSAPI timestamps. In this configuration, NMEA is
"numbering the seconds" with its sloppier timestamps, and once its
offset is under .4s, the PPS refclock takes over with its interrupt-
time timestamps.
> State Remote Refid Stratum Type When Poll
> Reach Delay Offset Jitter
> * 127.127.20.2 GPS 0 Local clock 9 16 377
> 0.000 0.089 0.006
> o PPS(2) PPS 0 Local clock 8 16 377
> 0.000 0.124 0.004
The jitter figures are nice and low for Windows. I would hope the
offset to PPS(2) would eventually be trimmed to 25us or less, and even
with temperature swings you might hope to keep within 150-200us at
worst.
Cheers,
Dave Hart
David J Taylor
[]
> Re the status column in the 'NTP Status' tab.
> But what does 'o' mean?
"o" - appears to mean - "synced to the "atom" (PPS) driver", which is
filtering the clock from the "*" source.
[]
> The "Application Log" shows:-
> Using user-mode PPS timestamp for GPS_NMEA(2) Not that I think it'll
> make any significant difference, but I thought I'd set all this up so
> that the PPS thing would run in Kernel mode, but obviously not.
Requirements:
- serialpps.sys installed and in use, perhaps Computer Management, Device
Manager might show what the driver is for that COM port?
- serialpps-ppsapi-provider.dll installed
- environment variable PPSAPI_DLLS set to point to the full path of the
DLL, in the system environment variables, not the per-user variables. For
example:
PPSAPI_DLLS=c:\serialpps\serialpps-ppsapi-provider.dll
As you say, it doesn't seem to improve the offset jitter a lot, but I know
that having gone to the bother of installing it, it would be nice to see
it working!
> What I've got is this in the NTP status tab page...
>
> State Remote Refid Stratum Type When Poll
> Reach Delay Offset Jitter
>
> * 127.127.20.2 GPS 0 Local clock 9 16 377
> 0.000 0.089 0.006
>
> o PPS(2) PPS 0 Local clock 8 16 377
> 0.000 0.124 0.004
[]
> Yes, the mailer wrapped it all, but hope someone can understand it and
> say if it's good/bad or ???
About what I see on my own Windows/GPS/PPS/atom system, so I would say its
working correctly.
> Preliminary results are a *HUGE* improvement over using Wan based
> servers, but the system is still settling, and the GPS RX is still
> indoors! (high up and seemingly happy, but not as good a sky view as
> it'll be when eventualy sited outside.)
>
> Best Regards.
>
> Dave Baxter.
Here, the GPS 18x LVC working on the top-floor of a building is about as
good as a GPX 18 LVC on the roof, at least for timekeeping.
73,
David
Harlan Stenn
information you are looking for?
--
Harlan Stenn <st...@ntp.org>
http://ntpforum.isc.org - be a member!
David Woolley
> A silly question if I may, and yes I've been poking arround the Meinberg
> website and forum for hours, and can't find the answer. Likewise the
> (non existant) help within the program, though I'm *sure* I've seen text
> on this somewhere, but can't find it at the moment.
These are standard ntpq status codes. I assume the authors assumed that
you would be familiar with ntpq, as you need it for any active debugging
of the configuration.
>
> Re the status column in the 'NTP Status' tab.
>
> I think a * means that this server is being used as the reference.
> + signals a posible candidate for use as a reference.
+ means that it is being used to set the time, but isn't the one peer
used to define stratum, root delay, etc. in downstream packets.
David J Taylor
news:ywn9skb6...@ntp1.isc.org...
> Does http://support.ntp.org/Support/TroubleshootingNTP#Section_9.4. have
> the
> information you are looking for?
That's an excellent start, Harlan, but it leaves me with a little
confusion....
* the source you are synchronized to (syspeer)
o the PPS source if your ntpd (ppspeer, only if you have a PPS capable
system and refclock)
There may be an implication here that you only have PPS if you see the "o"
tally code. Now on both a FreeBSD system, and my Windows systems, I get
PPS through the GPS/NMEA driver directly, /without/ the "o" tally code
showing at all. On the Windows systems, I only get the "o" tally code
when I add an updated serial port driver, which allows kernel-mode rather
than user-mode timestamping of the serial port transitions. When that
driver, and a type 22 ref-clock, are in use, I do get the "o", and I do
see a lower jitter.
So my point is that tally-code "*" can, depending on the clock source of
course, also mean that you have a PPS source.
It's a little confusing, I think. Would you agree?
Cheers,
David
G8KBV
@h40g2000prf.googlegroups.com>, dave...@gmail.com says...
>
> On Dec 20, 00:32ï¿œUTC, G8KBV wrote:
> > But what does 'o' mean?
>
> It means the PPS peer, and when present effective trumps any * seen.
>
> > The "Application Log" shows:-
> > make any significant difference, but I thought I'd set all this up so
> > that the PPS thing would run in Kernel mode, but obviously not.
>
> So 127.127.20.2 (NMEA) is using the user-mode hack to get DCD
> timestamps, which is only effective when you restrict the GPS to one
> sentence per second. However, 127.127.22.2 (atom/PPS) is using real
> kernel-mode PPSAPI timestamps. In this configuration, NMEA is
> "numbering the seconds" with its sloppier timestamps, and once its
> offset is under .4s, the PPS refclock takes over with its interrupt-
> time timestamps.
>
> > ￜ ￜ ￜ ￜ Reach ￜ Delay ￜ Offset ￜJitter
> > * ￜ ￜ ￜ 127.127.20.2 ￜ ￜGPS ￜ ￜ ￜ ￜ ￜ ￜ 0 ￜ ￜ ￜ Local clock ￜ ￜ 9 ￜ ￜ ￜ 16 ￜ ￜ ￜ377
> > ￜ ￜ ￜ ￜ 0.000 ￜ 0.089 ￜ 0.006 ￜ
> > o ￜ ￜ ￜ PPS(2) ￜ ￜ ￜ ￜ ￜPPS ￜ ￜ ￜ ￜ ￜ ￜ 0 ￜ ￜ ￜ Local clock ￜ ￜ 8 ￜ ￜ ￜ 16 ￜ ￜ ￜ377
> > ￜ ￜ ￜ ￜ 0.000 ￜ 0.124 ￜ 0.004
>
> The jitter figures are nice and low for Windows. I would hope the
> offset to PPS(2) would eventually be trimmed to 25us or less, and even
> with temperature swings you might hope to keep within 150-200us at
> worst.
>
> Cheers,
> Dave Hart
Thanks Dave.
AFIK I have all the right things pointing in the right places, but...
The PPS jitter this morning is still some 0.004mS, but the offset is
down to 0.077mS From what you say, not too shabby.
The system running it does seem temperature sensitive, not helped by
being in an unheated room, often with a window cracked open to get the
heat out! My problem here is keeping the room cool most times!
The same PC is also running the GB3RAL 5Mhz beacon monitor program, as
it's one machine that has a working soundcard that is not used for
anything else. It's a P4 1GHz machine, with 512Meg of RAM, running
Win2k SP4 + all updates.
I have not (yet) ticked the box to optimise the system for background
events. I want to let this "settle" for a few days, then I'll try that
and see what the difference (if any) is.
My need is for something *MUCH* better than the servers I can get to via
the somewhat variable (latency) ADSL connection I have. So far, though
probably not to "Time Nuts" standards, it is a *HUGE* improvement over
what I had.
Seasons Greatings etc and so forth.
Dave Baxter.
G8KBV
tay...@blueyonder.delete-this-bit.and-this-part.co.uk.invalid says...
Thanks Dave.
So it appears to be working. Nice.
Device Mangler just reports the standard MS driver for that port, also
not reflecting the actual currently in use baud rate settings either, so
nothing new there. (I've never yet seen that tool actualy reflect what
the actual conditions are, on 2k or XP!)
SerialPPS and the ppsapi-provider DLL are installed and pointed to in
the appropriate way, that I can tell, and the machine has been rebooted
several time since then, with no errors. I will poke about and check
again though, as there has been one Windows Update since then.
The Garmin GPS16LVC is set for one sentence (GPRMC) only, and is powered
like yours, from a neighboring USB port.
If the SerialPPS driver was not installed, accessable and working, would
not the Meinberg NTP status panel show an error?
I'll let things run like this for a while, before messing some more.
But for now, for Faros use, it's a *HUGE* improvement on the NTP access
I was getting via my ISP (Demon) so, so far, so good.
I'm going to start to write all this up soon, for others who also run
Faros, and have timing issues. I was always told the best way to learn
something, is to have to teach others about it. How true!
Seasons Greetings etc.
Dave Baxter.
G8KBV
>
> Does http://support.ntp.org/Support/TroubleshootingNTP#Section_9.4. have the
> information you are looking for?
Yes it does Harlan.
Site/page bookmarked!
Dave Baxter.
G8KBV
da...@ex.djwhome.demon.invalid says...
Re: "I assume the authors assumed that you would be familiar with ntpq"
:-)
As I have learnt and been reminded of *Many* times. Never make
assumptions in regards to others abilities!
Best Regards.
Dave Baxter.
Gene
> Hi All..
>
> A silly question if I may, and yes I've been poking arround the Meinberg
> website and forum for hours, and can't find the answer. Likewise the
> (non existant) help within the program, though I'm *sure* I've seen text
> on this somewhere, but can't find it at the moment.
>
> Re the status column in the 'NTP Status' tab.
>
> I think a * means that this server is being used as the reference.
> + signals a posible candidate for use as a reference.
> - = will not be used (for whatever reason)
>
> But what does 'o' mean?
>
> I have now successfully (I think) got the local NTP server program
> ticking along in sympathy with a GPS receiver with PPS, but though the
> address 127.127.20.2 shows with a '*' (and is coloured green)
> The 'Server' PPS(2) shows with the 'o' status, and though green in
> colour, I cannot find out what that status flag means.
>
right hand corner.
Regards,
Gene Miller
G8KBV
@g26g2000yqe.googlegroups.com>, euge...@sbcglobal.net says...
>
> On Dec 19, 6:32ï¿œpm, G8KBV <g8...@nospam-uko2.co.uk> wrote:
> > Hi All..
> >
> > A silly question if I may, and yes I've been poking arround the Meinberg
> > (non existant) help within the program, though I'm *sure* I've seen text
> > on this somewhere, but can't find it at the moment.
> >
> > Re the status column in the 'NTP Status' tab.
> >
> > I think a * means that this server is being used as the reference.
> > + signals a posible candidate for use as a reference.
> > - = will not be used (for whatever reason)
> >
> > But what does 'o' mean?
> >
> > I have now successfully (I think) got the local NTP server program
> > ticking along in sympathy with a GPS receiver with PPS, but though the
> > address 127.127.20.2 shows with a '*' (and is coloured green)
> > The 'Server' PPS(2) shows with the 'o' status, and though green in
> > colour, I cannot find out what that status flag means.
> >
> In the "NTP Status" tab, click on the "Legend" button in the lower
> right hand corner.
>
> Regards,
> Gene Miller
Spot On Sir!
Silly me, my eyes must have been painted on! In fact, I hadn't realised
that button was there at all, bottom right is sort of "out of the way".
Thanks for the pointer, wrist duly slapped!
Dave B.
David J Taylor
> not reflecting the actual currently in use baud rate settings either, so
> nothing new there. (I've never yet seen that tool actualy reflect what
> the actual conditions are, on 2k or XP!)
Then the device driver isn't installed correctly. On my Windows-7 system,
in Device Manager selecting the COM port, Driver tab, Driver details
button, I see three entries:
<directory>serenum.sys
<directory>serial.sys
<directory>serialpps.sys
where the first two have a certificate icon against them, and the third
not, and the details display if you click the third are obviously
different.
> SerialPPS and the ppsapi-provider DLL are installed and pointed to in
> the appropriate way, that I can tell, and the machine has been rebooted
> several time since then, with no errors. I will poke about and check
> again though, as there has been one Windows Update since then.
I haven't found Windows update destroying the updated serial drivers.
> If the SerialPPS driver was not installed, accessable and working, would
> not the Meinberg NTP status panel show an error?
The event log on the startup of NTP might show something, and the program
continues in a "degraded" mode (i.e. with the user-mode timestamps).
> I'll let things run like this for a while, before messing some more.
> But for now, for Faros use, it's a *HUGE* improvement on the NTP access
> I was getting via my ISP (Demon) so, so far, so good.
>
> I'm going to start to write all this up soon, for others who also run
> Faros, and have timing issues. I was always told the best way to learn
> something, is to have to teach others about it. How true!
>
> Seasons Greetings etc.
>
> Dave Baxter.
What I see on PC Feenix (Windows XP) is this, trimmed:
12/12/2009,07:49:09,NTP,Information,None,3,N/A,FEENIX,Using user-mode PPS
timestamp for GPS_NMEA(1)
12/12/2009,07:49:07,NTP,Information,None,3,N/A,FEENIX,GPS_NMEA(1) serial
/dev/gps1 open at 4800 bps
12/12/2009,07:49:07,NTP,Information,None,3,N/A,FEENIX,proto: precision =
1.900 usec
12/12/2009,07:49:04,NTP,Information,None,3,N/A,FEENIX,HZ 64.000 using 43
msec timer 23.256 Hz 64 deep
12/12/2009,07:49:04,NTP,Information,None,3,N/A,FEENIX,"Windows clock
precision 15.625 msec, min. slew 6.400 ppm/s "
12/12/2009,07:49:04,NTP,Information,None,3,N/A,FEENIX,Clock interrupt
period 15.625 msec
12/12/2009,07:49:04,NTP,Information,None,3,N/A,FEENIX,Performance counter
frequency 3.580 MHz
12/12/2009,07:49:04,NTP,Information,None,3,N/A,FEENIX,"MM timer
resolution: 1..1000000 msec, set to 1 msec "
12/12/2009,07:49:04,NTP,Information,None,3,N/A,FEENIX,Raised to realtime
priority class
12/12/2009,07:49:04,NTP,Information,None,3,N/A,FEENIX,ntpd 4.2.6-o Dec 09
11:48:30.27 (UTC-00:00) 2009 (1)
.. and what I see at the start of the ntpq -p display is:
oPPS(1) .PPS.
*GPS_NMEA(1) .GPS.
So I am now confused, in that NTP has said it is using the user-mode and
not the kernel-mode timestamps, and yet I have "o" tally entry. Let me
check device manager on that PC..... Yes, just like the Windows-7
system, the serialpps.sys is listed in the port drivers for COM1. Looking
at the jitter it looks more like kernel-mode than user-mode.
Dave Hart - any chance that 4.2.6 doesn't report using kernel-mode any
more?
73,
David
G8KBV
tay...@blueyonder.delete-this-bit.and-this-part.co.uk.invalid says...
Your confused!...
How are you getting to those driver display details?
In Win2k, I'm going in via the control panel, system, then device
manager.
In there, expand the "Ports (COM and LPT)" selection, select Com2 (the
one with the GPS) right click, Properties, Driver, Driver details.
Nothing about serialpps, or 4800bd for that matter in the port settings
tab either..
In the Driver File Details dialog, it just shows:-
C:\WINNT\System32\DRIVERS\serenum.sys
C:\WINNT\System32\DRIVERS\serial.sys
But as earlier, I've *Never* seen those dialogs reflect the actual port
settings that are in use at the time you look, up to and including XP.
I don't have 7, and the one Vista PC I have I leave well alone!
I don't doubt I might have not done something right, but at the moment
I'm at a loss to decide what that might be?
Hmm... Poking arround... The only thing I can see, is the file is
called "serialpps.sys" and the registry entry has "Serialpps.sys".
Could that be the issue? (upper/lower case 'S' ?)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Serial
ImagePath REG_SZ system32\drivers\Serialpps.sys
The pps-api dll is in it's own folder:-
C:\serialpps\serialpps-ppsapi-provider.dll
Also, the system environment variable PPSAPI_DLLS (Is that right?)
points to that path & file. But, I notice that I got the drive letter
in the environment variable as c not C.
Idea's ??
Regards.
Dave B.
David J Taylor
>
> How are you getting to those driver display details?
>
> In Win2k, I'm going in via the control panel, system, then device
> manager.
>
> In there, expand the "Ports (COM and LPT)" selection, select Com2 (the
> one with the GPS) right click, Properties, Driver, Driver details.
> Nothing about serialpps, or 4800bd for that matter in the port settings
> tab either..
The 4800 baud was from NTP's Applications Event log entry.
> In the Driver File Details dialog, it just shows:-
> C:\WINNT\System32\DRIVERS\serenum.sys
> C:\WINNT\System32\DRIVERS\serial.sys
Then you haven't full installed the serialpps.sys driver. There should be
a registry entry:
HKLM\SYSTEM\CurrentControlSet\Services\Serial
ImagePath => system32\drivers\serialpps.sys
HKLM is short for HKEY_LOCAL_MACHINE
and obviously C:\WINNT\System32\DRIVERS\ should contain the file
serialpps.sys
[]
> I don't doubt I might have not done something right, but at the moment
> I'm at a loss to decide what that might be?
>
> Hmm... Poking arround... The only thing I can see, is the file is
> called "serialpps.sys" and the registry entry has "Serialpps.sys".
> Could that be the issue? (upper/lower case 'S' ?)
Sounds unlikely to me, but worth making them match to be certain.
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Serial
> ImagePath REG_SZ system32\drivers\Serialpps.sys
On XP I have the path as type REG_EXPAND_SZ, but I don't think that
matters if you don't have nay strings which need to be expanded.
> The pps-api dll is in it's own folder:-
> C:\serialpps\serialpps-ppsapi-provider.dll
>
> Also, the system environment variable PPSAPI_DLLS (Is that right?)
> points to that path & file. But, I notice that I got the drive letter
> in the environment variable as c not C.
>
> Idea's ??
>
> Regards.
>
> Dave B.
I don't think that C: versus c: will matter, but I would certainly see if
you can resolve the driver loading issue first. A reboot is required to
change that driver, as I expect you know. One other thought - there is a
32-bit version of that driver and two 64-bit ones in the Zip file. Just
asking - you did install the right one? The 32-bit DLL is 69,120 bytes,
and the 32-bit serialpps.sys 82,432 bytes.
73,
David
Harlan Stenn
Yes, the content could easily be improved. And it's a wiki.
David J Taylor
> David,
>
> Yes, the content could easily be improved. And it's a wiki.
I would have a go at that, but as I am uncertain about things myself, it
won't be until after those more knowledgeable folk have explained further.
Cheers,
David
G8KBV
tay...@blueyonder.delete-this-bit.and-this-part.co.uk.invalid says...
Thanks David.
I'll have a dig about, probably something silly i've done, as always.
Best Regards.
Dave Baxter.
G8KBV
tay...@blueyonder.delete-this-bit.and-this-part.co.uk.invalid says...
>
> > ImagePath REG_SZ system32\drivers\Serialpps.sys
>
> On XP I have the path as type REG_EXPAND_SZ, but I don't think that
> matters if you don't have nay strings which need to be expanded.
Hi again...
OK, I've got everything as it should be, but...
I see in the companion registry entry, for the 'serenum' key, that the
ImagePath type is indeed REG_EXPAND_SZ, where as in the 'serial' key,
the ImagePath is just REG_SZ.
I've tried all sorts in there, resulting in either no working com ports
at all, or just the standard MS driver being loaded. I cannot find a
way to change the value type from REG_SZ to REG_EXPAND_SZ.
I checked the file sizes, and they all correspond you your 32 bit file
sizes just fine.
I remember Dave Hart saying something about this a long time back to
someone else, and the need to enter a long string of hex digits for the
ImagePath registry entry. But I can't find that information any more.
For now, it's still defaulting to usermode timestamps. Any other
idea's?
Regards.
Dave Baxter.
G8KBV
uko2.co.uk says...
>
> In article <B6vXm.17261$Ym4....@text.news.virginmedia.com>, david-
> tay...@blueyonder.delete-this-bit.and-this-part.co.uk.invalid says...
> >
> > > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Serial
> > > ImagePath REG_SZ system32\drivers\Serialpps.sys
> >
> > On XP I have the path as type REG_EXPAND_SZ, but I don't think that
> > matters if you don't have nay strings which need to be expanded.
>
> Hi again...
>
I just checked on another Win2k machine, and the serial key type is
indeed REG_EXPAND_SZ
I'm currently trawling MS's KB looking for inspiration.
Regards.
Dave Baxter.
David J Taylor
>
> OK, I've got everything as it should be, but...
>
> I see in the companion registry entry, for the 'serenum' key, that the
> ImagePath type is indeed REG_EXPAND_SZ, where as in the 'serial' key,
> the ImagePath is just REG_SZ.
>
> I've tried all sorts in there, resulting in either no working com ports
> at all, or just the standard MS driver being loaded. I cannot find a
> way to change the value type from REG_SZ to REG_EXPAND_SZ.
>
> I checked the file sizes, and they all correspond you your 32 bit file
> sizes just fine.
>
> I remember Dave Hart saying something about this a long time back to
> someone else, and the need to enter a long string of hex digits for the
> ImagePath registry entry. But I can't find that information any more.
>
> For now, it's still defaulting to usermode timestamps. Any other
> idea's?
>
> Regards.
> Dave Baxter.
Well, I just checked on my actual XP system (I had checked on a different
XP system before), and the string is a plain REG_SZ, not the Expand
variety.
HKLM\SYSTEM\CurrentCotrolSet\Services\Serial\
ImagePath REG_SZ => system32\drivers\serialpps.sys
Dave Hart's install and uninstall .BAT files just use REG_SZ, so I don't
think that's the issue.
Here's an exported REG_EXPAND_SZ string - enter into a file serial.reg
and double-click:
________________________________________
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Serial]
"ImagePath"=hex(2):73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,44,00,52,\
00,49,00,56,00,45,00,52,00,53,00,5c,00,73,00,65,00,72,00,69,00,61,00,6c,00,\
70,00,70,00,73,00,2e,00,73,00,79,00,73,00,00,00
________________________________________
but I don't think it will alter anything.
Perhaps you need to open the protection on serialpps.sys?
As the serialpps.sys is an unsigned driver, I wonder whether there is an
option in XP not to accept unsigned drivers? Anything in the event log
when XP boots - before you log in? I don't think it helps a lot, but
there's this page:
http://articles.techrepublic.com.com/5100-10878_11-5875443.html
73,
David
G8KBV
tay...@blueyonder.delete-this-bit.and-this-part.co.uk.invalid says...
> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Serial]
> "ImagePath"=hex(2):73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,44,00,52,\
> 00,49,00,56,00,45,00,52,00,53,00,5c,00,73,00,65,00,72,00,69,00,61,00,6c,00,\
> 70,00,70,00,73,00,2e,00,73,00,79,00,73,00,00,00
>
Oh well...
That didn't change anything either, other than the registry setting type
is now 'REG_EXPAND_SZ' like yours, the com port properties still show
the original MS serial.sys file as the driver, and NTPD is still
resolutely using usermode PPS timestamps as a result.
(Yes, I did reboot the thing.)
The next step could be to swap the contents of the original serial.sys
and serialpps.sys files, if it insists on loading the former, I'll try
force feeding it again, but the last time I tried that (in error) I got
into a black screen/reboot loop... So, I need to get the physical
situation here again such that I can swap hard drives about to restore
the file if that comes back.
Does anyone know of other reasons why a Win2000 system will not accept
and act on these changes? I'm using COM2 for the GPS, nothing is using
COM1 (at the mo') & there are no other COM (virtual or otherwise) ports
on this box (a Compaq Deskpro EN small form factor desktop.)
The faded grey cell is somewhat frazzled again, so all that can wait a
while, as Faros *Needs* this thing right now, as even as it is, it is
just sooooo much better than the WAN service at this time, currently
variable and anything up to 300ms or more latency to the "nearest" NTP
servers out there!
I think I need to lie down in a dark room for a while.
73.
Dave Baxter.
G8KBV
tay...@blueyonder.delete-this-bit.and-this-part.co.uk.invalid says...
>
>
> XP system before), and the string is a plain REG_SZ, not the Expand
> variety.
>
> HKLM\SYSTEM\CurrentCotrolSet\Services\Serial\
>
> ImagePath REG_SZ => system32\drivers\serialpps.sys
>
> Dave Hart's install and uninstall .BAT files just use REG_SZ, so I don't
> think that's the issue.
>
> Here's an exported REG_EXPAND_SZ string - enter into a file serial.reg
> and double-click:
>
> ________________________________________
> Windows Registry Editor Version 5.00
>
> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Serial]
> "ImagePath"=hex(2):73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,44,00,52,\
> 00,49,00,56,00,45,00,52,00,53,00,5c,00,73,00,65,00,72,00,69,00,61,00,6c,00,\
> 70,00,70,00,73,00,2e,00,73,00,79,00,73,00,00,00
> ________________________________________
>
> but I don't think it will alter anything.
> Perhaps you need to open the protection on serialpps.sys?
> As the serialpps.sys is an unsigned driver, I wonder whether there is
> an option in XP not to accept unsigned drivers? Anything in the event
> log when XP boots - before you log in? I don't think it helps a lot,
> but there's this page:
> http://articles.techrepublic.com.com/5100-10878_11-5875443.html
Thanks for the reg file, I'll try it.
I'm running on Win2000 Pro, not XP btw. (though they are similar behind
the shiny bits.) I don't think there is any driver signing issues in
2k, but I could be wrong. Anyone else know?
Cheers David.
Dave Baxter.
David J Taylor
news:MPG.2599839da...@news.demon.co.uk...
[]
> Thanks for the reg file, I'll try it.
Noted on your results.
> I'm running on Win2000 Pro, not XP btw. (though they are similar behind
> the shiny bits.) I don't think there is any driver signing issues in
> 2k, but I could be wrong. Anyone else know?
>
> Cheers David.
>
> Dave Baxter.
Ah, I had forgotten you had Windows 2000. Let me see what the settings
are I have there....
Yes, the Atom driver shows as working ("o" tally code).
The environment variable is set:
PPSAPI_DLLS=E:\Program Files\NTP\PPS\serialpps-ppsapi-provider.dll
The ImagePath registry entry /is/ REG_EXPAND_SZ, and set to:
System32\DRIVERS\serialpps.sys
The two files there are:
19/06/2003 12:05 62,736 serial.sys
01/03/2009 22:07 82,432 serialpps.sys
COM1 shows as having two drivers: serenum.sys and serial.sys
COM2 shows as having two drivers: serenum.sys and serial.sys
So the new driver /doesn't/ show - just like your system. Looking at the
event log for the most recent start, it shows "User-mode timestamps".
So are we in exactly the same state? Use-mode timestamps, but the Atom
PPS driver still showing as locked with the "o" tally code?
Looking at the Application Event log, there is no entry for "kernel", and
that's since 15-May-2009. So it seems that Windows 2000 doesn't support
the Kernel-mode driver, or that different steps are required to replace
the driver on that OS. I wonder whether Dave Hart has tried this - I know
he didn't have Windows 2000 at one point.
73,
David
Dave Hart
> That didn't change anything either, other than the registry setting type
> is now 'REG_EXPAND_SZ' like yours, the com port properties still show
> the original MS serial.sys file as the driver, and NTPD is still
> resolutely using usermode PPS timestamps as a result.
serialpps.sys is not a freestanding driver, and does not have its own
installer or GUI properties DLL. Instead, it is a very lightly
modified serial.sys which is "installed" via a cheap trick of pointing
the serial.sys ImagePath registry entry at serialpps.sys instead of
serial.sys. What you see is normal.
Further, despite the fact that this thread started out with you asking
what the 'o' meant in the ntpq peers billboard, which indicates
working PPSAPI (and hence working serialpps.sys), you've been
mistakenly assuming that because you see a message about user-mode
PPS, that means serialpps.sys is not working. As long as one of your
refclocks has 'o' in the billboard, you know it is successfully
talking to serialpps.sys via PPSAPI. The fact that the NMEA refclock
is using user-mode PPS timestamps does not imply the PPS/atom driver
is not. In fact, the atom driver will only work at all on systems
with functional PPSAPI. The "user-mode PPS" message _does_ mean you
could get a respectable result without using PPS(2)/atom/PPSAPI/
serialpps.sys.
Cheers,
Dave Hart
David J Taylor
news:b0496413-c034-4be1...@y32g2000prd.googlegroups.com...
[]
> Further, despite the fact that this thread started out with you asking
> what the 'o' meant in the ntpq peers billboard, which indicates
> working PPSAPI (and hence working serialpps.sys), you've been
> mistakenly assuming that because you see a message about user-mode
> PPS, that means serialpps.sys is not working. As long as one of your
> refclocks has 'o' in the billboard, you know it is successfully
> talking to serialpps.sys via PPSAPI. The fact that the NMEA refclock
> is using user-mode PPS timestamps does not imply the PPS/atom driver
> is not. In fact, the atom driver will only work at all on systems
> with functional PPSAPI. The "user-mode PPS" message _does_ mean you
> could get a respectable result without using PPS(2)/atom/PPSAPI/
> serialpps.sys.
>
> Cheers,
> Dave Hart
Dave,
That's most helpful. So just to be sure: if the "o" appears as the
tally-code, the system /must/ be using kernel mode timestamps. Yes?
Could the use of kernel-mode be logged, as having the "user-mode" message
causes confusion. Or is it not that simple now the components are
separate?
Cheers,
David
Dave Hart
> > is using user-mode PPS timestamps does not imply the PPS/atom driver
> > is not.
I should have said the fact that a message about user-mode PPS is
logged does not imply PPSAPI is not available or even being used. You
could see the user-mode PPS message (which is only seen with the
Windows ntpd, for those who are baffled by this user-mode PPS
discussion) during startup of NMEA configured to use PPSAPI directly
(which implies not configuring PPS/atom as a separate source). The
user-mode PPS message is coming from the common reference clock serial
support code, and occurs if a PPS signal is detected on the DCD line
of a serial port being read by a refclock. In that case, the
timestamp of each PPS event is saved and replaces the normal end-of-
line timestamp of the following line of serial input read by the clock
driver, which is the reason you must configure only one sentence (line
of serial input) per second for the user-mode PPS hack to work as
intended.
On Dec 21, 16:16 UTC, "David J Taylor" wrote:
> That's most helpful. So just to be sure: if the "o" appears as the
> tally-code, the system /must/ be using kernel mode timestamps. Yes?
Yes.
> Could the use of kernel-mode be logged, as having the "user-mode" message
> causes confusion. Or is it not that simple now the components are
> separate?
Yes, there is an issue with the messages coming from entirely separate
components. Moreover, as I have just said, the presence of user-mode
PPS timestamps (replacing end-of-line timestamps on serial input) does
not imply the lack of PPSAPI timestamps on the same port. If I
configure the NMEA driver to use PPSAPI directly, user-mode PPS
timestamps remain active and functional from the perspective of the
refclock serial support in ntpd on Windows. The fact that higher-
level code in the driver only uses those timestamps briefly during
startup before switching to PPSAPI-provided timestamps is invisible to
the code that logs the "using user-mode PPS" message.
Similarly, the PPSAPI client code used by NMEA and atom has no way of
knowing if the same port is also being used for serial timecode input,
and if so, if the end of line timestamps have been tinkered.
Finally, the PPSAPI client code in ntpd tends to follow the model of
being quiet unless something goes wrong, so it's the absence of error
messages with a PPSAPI-enabled driver (whether atom or another with
PPSAPI integrated and enabled) that "logs" the success.
Cheers,
Dave Hart
G8KBV
tay...@blueyonder.delete-this-bit.and-this-part.co.uk.invalid says...
Phew!...
So it looks like it is working at it's best anyway, excelent.
I can (as a small time programmer with Delphi) appreciate the complexity
of all this, in particular in regards to what messages, status values,
flags etc are presented to the user.
I'll leave it as it is then for now at least, as I've just been called
upon to go provide transport and driver (my other toy and me) to relieve
others who are keeping a vilage alive since they lost water, gas and
electricity, so I'd better get my kit sorted out for an early dark
start, for some 12 hours plus volunteer work. Eu working time
directives do not apply! <G>
Oh yes, just checked, we're down to 5uS offset, and 8uS jitter, somewhat
better than 'net based synchronisation! ;-)
Thanks All.
Dave Baxter.
Brent Gordon
> Hi All..
>
> A silly question if I may, and yes I've been poking arround the Meinberg
> on this somewhere, but can't find it at the moment.
>
> Re the status column in the 'NTP Status' tab.
>
> I think a * means that this server is being used as the reference.
> + signals a posible candidate for use as a reference.
> - = will not be used (for whatever reason)
>
> But what does 'o' mean?
>
corner. It will explain the status column and give you a link to more
details.
Brent
David J Taylor
[]
> Phew!...
>
> So it looks like it is working at it's best anyway, excelent.
Yes, it's good news!
> I can (as a small time programmer with Delphi) appreciate the complexity
> of all this, in particular in regards to what messages, status values,
> flags etc are presented to the user.
Now knowing that "o" means kernel-mode, I am much happier. I had better
document that on my Web page about user-mode versus kernel-mode so I
remember next time! Done:
http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html#kernel-check
Comments and corrections welcome.
> I'll leave it as it is then for now at least, as I've just been called
> upon to go provide transport and driver (my other toy and me) to relieve
> others who are keeping a vilage alive since they lost water, gas and
> electricity, so I'd better get my kit sorted out for an early dark
> start, for some 12 hours plus volunteer work. Eu working time
> directives do not apply! <G>
>
> Oh yes, just checked, we're down to 5uS offset, and 8uS jitter, somewhat
> better than 'net based synchronisation! ;-)
>
> Thanks All.
>
> Dave Baxter.
Batteries charged, I hope! For some of my kit I have gone to the Sanyo
eneloops, as they lose their charge much more slowly. Global warming -
with this cold weather? <G>
You will find that for the best performance, the NTP PC needs to be left
running, as initial settling is not quick.
73,
David
David J Taylor
[]
> Yes, there is an issue with the messages coming from entirely separate
> components. Moreover, as I have just said, the presence of user-mode
> PPS timestamps (replacing end-of-line timestamps on serial input) does
> not imply the lack of PPSAPI timestamps on the same port. If I
> configure the NMEA driver to use PPSAPI directly, user-mode PPS
> timestamps remain active and functional from the perspective of the
> refclock serial support in ntpd on Windows. The fact that higher-
> level code in the driver only uses those timestamps briefly during
> startup before switching to PPSAPI-provided timestamps is invisible to
> the code that logs the "using user-mode PPS" message.
>
> Similarly, the PPSAPI client code used by NMEA and atom has no way of
> knowing if the same port is also being used for serial timecode input,
> and if so, if the end of line timestamps have been tinkered.
>
> Finally, the PPSAPI client code in ntpd tends to follow the model of
> being quiet unless something goes wrong, so it's the absence of error
> messages with a PPSAPI-enabled driver (whether atom or another with
> PPSAPI integrated and enabled) that "logs" the success.
>
> Cheers,
> Dave Hart
Dave,
Thanks for that - the good news is that the "o" tally-code is sufficient.
I've documented that here:
http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html#kernel-check
I've also made a very brief and rather imperfect summary of the clear and
most interesting points you made above. Thanks to taking the time to
spell that out in detail. I may add that to the Web pages as well, if I
may.
Cheers,
David
Richard B. Gilbert
"Not quick" is an extreme understatement! It takes about 30 minutes to
get a "reasonable approximation". It can take ten to twelve hours to
stabilize with the best possible approximation of the time. Once there
it's good for as long as you can keep the power on and the temperature
reasonably stable.
David J Taylor
news:ZJydnVuvufm1Wa3W...@giganews.com...
[]
>> You will find that for the best performance, the NTP PC needs to be
>> left running, as initial settling is not quick.
>>
>
> "Not quick" is an extreme understatement! It takes about 30 minutes to
> get a "reasonable approximation". It can take ten to twelve hours to
> stabilize with the best possible approximation of the time. Once there
> it's good for as long as you can keep the power on and the temperature
> reasonably stable.
Richard,
On one LAN-synced system it took bout 90 minutes to get to within its
normal offset range, and about the same on a Windows-XP system with a GPS
reference clock. On the Windows-7 system, with a GPS ref-clock, it took
about 5 hours.
I do wish there were some way of speeding this up - a variable loop
bandwidth or something like that.
Cheers,
David
Richard B. Gilbert
Lots of luck. My understanding is that it can't be done without loss of
accuracy and/or stability.
I keep my system running 24x7 except when we have a power outrage
lasting longer than the run time of the UPS.
If your power is insufficiently reliable, consider a UPS and a gasoline
(or natural gas) powered generator. If it's important enough to spend
money on, you can make it almost bullet proof!
unruh
> David J Taylor wrote:
>> "G8KBV" <g8...@nospam-uko2.co.uk> wrote in message
>> news:MPG.2599f4f8b...@news.demon.co.uk...
>> []
>>
>> running, as initial settling is not quick.
>>
>
> "Not quick" is an extreme understatement! It takes about 30 minutes to
> get a "reasonable approximation". It can take ten to twelve hours to
> stabilize with the best possible approximation of the time. Once there
> it's good for as long as you can keep the power on and the temperature
> reasonably stable.
Yes, the time scale is about 1 hour half life (it takes about 1 hour to
halve the error). David Mills gets really
annoyed if someone points out how slow ntp is at converging. It is
definitely a feature, not a bug. That you or I could, with the first
three offset measurements, make a far better approximation to the true
time and rate than ntp does, is irrelevant.
unruh
>> "Richard B. Gilbert" <> wrote in message
>> news:ZJydnVuvufm1Wa3W...@giganews.com...
>> []
>>>> You will find that for the best performance, the NTP PC needs to be
>>>> left running, as initial settling is not quick.
>>>>
>>>
>>> "Not quick" is an extreme understatement! It takes about 30 minutes
>>> to get a "reasonable approximation". It can take ten to twelve hours
>>> to stabilize with the best possible approximation of the time. Once
>>> there it's good for as long as you can keep the power on and the
>>> temperature reasonably stable.
>>
>> Richard,
>>
>> On one LAN-synced system it took bout 90 minutes to get to within its
>> normal offset range, and about the same on a Windows-XP system with a
>> GPS reference clock. On the Windows-7 system, with a GPS ref-clock, it
>> took about 5 hours.
>>
>> I do wish there were some way of speeding this up - a variable loop
>> bandwidth or something like that.
>>
>
> Lots of luck. My understanding is that it can't be done without loss of
> accuracy and/or stability.
Nonsense. chrony does it, without loss of accuracy (chrony is about 3
times as accurate as ntp is) or stability. It will correct a few hundred
second initial error in far less time than ntp takes for a .01 sec error,
and without stepping.
Richard B. Gilbert
Well, you could always try to create an NTPD that would converge more
quickly without introducing some other nastiness. Somehow I think this
would be a massive project and is quite likely impossible. If Dave
Mills thinks it won't work he's probably right.
Keeping an NTPD server up and synched is not all that difficult. A UPS
will keep you alive for three to fifteen minutes if power fails. The
longer the UPS run time, the more it costs. Any longer than fifteen
minutes and you will need a generator fueled by either gasoline or
natural gas. You will either need a human being to start it and set it
for the right speed or a device that will do this automagically.
Richard B. Gilbert
Then why don't you use chrony and stop bugging us? If it can replace
NTPD under most common scenarios for normal and emergency operation and
do a better job, I'm sure that it will eventually replace NTPD. Does
anyone see that happening yet?
John Hasler
> Lots of luck. My understanding is that it can't be done without loss of
> accuracy and/or stability.
Bill Unruh writes:
> Nonsense. chrony does it, without loss of accuracy (chrony is about 3
> times as accurate as ntp is) or stability.
Unfortunately, that stability has only been demonstrated, not proven.
Know anybody who needs a thesis subject?
--
John Hasler
jha...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA
David J Taylor
> unruh wrote:
[]
>> Nonsense. chrony does it, without loss of accuracy (chrony is about 3
>> times as accurate as ntp is) or stability. It will correct a few
>> hundred
>> second initial error in far less time than ntp takes for a .01 sec
>> error,
>> and without stepping.
>
> Then why don't you use chrony and stop bugging us? If it can replace
> NTPD under most common scenarios for normal and emergency operation and
> do a better job, I'm sure that it will eventually replace NTPD. Does
> anyone see that happening yet?
I would be quite happy to try chrony were it not for the fact that it
doesn't work with Windows and it doesn't support reference clocks.
I would be even happier if there were a version of NTP available which, as
an option, had a fast convergence algorithm for its initial operation, and
switched to the existing NTP algorithm once initial stability had been
achieved.
Cheers,
David
Richard B. Gilbert
You have the ability to set at least one of the two key variables: the
time. The frequency can be set from a file when ntpd starts. If you
know both the time and frequency for conditions then obtaining you have
all you need. If you cold started the computer you are SOL!
I think that ntpd was designed for continuous or very nearly continuous
operation. If you boot up after dinner, read your mail, and shut down
again you might as well get a "radio controlled" wrist watch and forget
about NTP. If you want time from NTP plan on running NTPD 24x7x365.
Try to control the temperature in the room to a constant value. If you
can maintain a steady 68 degrees F 24x365 you should be able to keep
time within a very small fraction of a second.
Anyone who thinks he can boot up, get the correct time to within
microseconds and shut down again is living in a dream world!
Windows is a poor choice of O/S for the job. Try Linux or Solaris.
Either will run on the X86 architecture.
unruh
> unruh wrote:
>> On 2009-12-22, Richard B. Gilbert <rgilb...@comcast.net> wrote:
>>> David J Taylor wrote:
>>>> "G8KBV" <g8...@nospam-uko2.co.uk> wrote in message
>>>> news:MPG.2599f4f8b...@news.demon.co.uk...
>>>> []
>>>>
>>>> You will find that for the best performance, the NTP PC needs to be left
>>>> running, as initial settling is not quick.
>>>>
>>> "Not quick" is an extreme understatement! It takes about 30 minutes to
>>> get a "reasonable approximation". It can take ten to twelve hours to
>>> stabilize with the best possible approximation of the time. Once there
>>> it's good for as long as you can keep the power on and the temperature
>>> reasonably stable.
>>
>> Yes, the time scale is about 1 hour half life (it takes about 1 hour to
>> halve the error). David Mills gets really
>> annoyed if someone points out how slow ntp is at converging. It is
>> definitely a feature, not a bug. That you or I could, with the first
>> three offset measurements, make a far better approximation to the true
>> time and rate than ntp does, is irrelevant.
>
> Well, you could always try to create an NTPD that would converge more
> quickly without introducing some other nastiness. Somehow I think this
> would be a massive project and is quite likely impossible. If Dave
> Mills thinks it won't work he's probably right.
As I said, it has already been done. It is called chrony. And it works--
about three times better accuracy than ntpd in the tests I ran, and far
far faster convergence. It impliments an almost complete ntpd 3.0
standard,(without broadcast option, but as of 1.24-pre1 with refclock
support). It does not work on Windows machines.
David decided on a simply Markovian feedback loop with one single
"memory"-- the current rate. It is simple, easy to analyse ( although
with the additional bells and whistles like the clock filter, the huff
and puff filter, stepping, etc, it is far more difficult to analyse),
and has been tested extensively. That does not mean it is the best
way of using the data, and certainly as far as rate of convergence
is concerned it is far from the best.
>
> Keeping an NTPD server up and synched is not all that difficult. A UPS
> will keep you alive for three to fifteen minutes if power fails. The
> longer the UPS run time, the more it costs. Any longer than fifteen
> minutes and you will need a generator fueled by either gasoline or
> natural gas. You will either need a human being to start it and set it
> for the right speed or a device that will do this automagically.
Lets see, Pay a few $100 for a UPS (and many more for a generator) ,
run the machine 24/7 with the associated energy costs, or load a free
program. Hmm.
Richard B. Gilbert
And chrony will start up and give time to the microsecond and not drift
as it warms up? There must be SOME reason why we are not all running
chrony!
unruh
I do use chrony. Until recently I used ntp for refclock support. I am
not bugging you, just pointing out that the claims made here are
nonesense, by conterexample. I had hoped that ntpd would impliment the
chrony clock discipline algorithm, but it is clear that will not happen.
But this is a newgroup to discuss ntp, not the reference implimentation
of ntpd, and chrony is a program that impliments ntp.
Richard B. Gilbert
Most computers that need accurate time live in a data center somewhere
and shut down maybe as often as once every six months! I've had a few
machines that ran continuously for a year or more! It's not impossible;
it just requires a lot of luck OR heavy expenditures for a UPS, a backup
generator, N+1 redundant air conditioners, etc, etc. Some enterprises
require this sort of uptime and are prepared to pay the bills.
unruh
> Richard B. Gilbert writes:
>> Lots of luck. My understanding is that it can't be done without loss of
>> accuracy and/or stability.
>
> Bill Unruh writes:
>> Nonsense. chrony does it, without loss of accuracy (chrony is about 3
>> times as accurate as ntp is) or stability.
>
> Unfortunately, that stability has only been demonstrated, not proven.
> Know anybody who needs a thesis subject?
It has also not been proven for ntpd with its stepping algorithm, its
clockfilters ( including huffandpuff), its peer selection algorithm,
etc. I cannot see how they could introduce instabilities, but
non-linearities are notorious for doing surprizing things.
The simple feedback loop certainly has been proven stable (
assuming the parameters are appropriately chosen, which ntpd does).
Chrony also impliments a feedback loop but with far more "memory" ( the
algorithm remembers 5-60 of the past data points, in addition to the
rate which ntpd remembers), which is
easily provable to be stable under the linear assumptions (ie if the
number of points remembered stays constant). It is this extra memory
which allows chrony to respond far more rapidly to changes than does
ntp, while remaining stable. But the
"breathing" of chrony ( adjustment of the number of points used in the
linear regression) is again a non-linear feature which is much harder to
prove to be unconditionally stable. My interest in chrony began because
I saw features which suggested oscillation in the chrony rate, which
,while not unstable, suggested some sort of amplification of certain
frequencies. I have not been able to track them down to anything in
chrony, but do not have a proof that they are, or are not, an artifact
of the algorithm.
Yes, a thesis project would be interesting.
David Lord
Yes, I've used chronyd along with ntpd for a while. I've moved
desktops and notebooks to chronyd.
What chronyd seems not to provide is peering ability with ntpd
(or it may be I've never been able to get it working), and up
to recently lacked any refclock support.
For ntpd I've had problems with long periods to come into sync,
temperature, system load or network disturbance causing
instability. With older systems it was possible to reduce these
effects by fiddling system clock frequency to within 10ppm or
so, but with most recent software some systems where previously
I had ntpd tamed are now back to being unstable due to self
calibration putting them 50ppm or more out, but not consistent
between reboots, (that isn't due to ntpd, just that it
exacerbates the problems and I suspect this will also affect
chronyd).
David
unruh
You tell me why you are not using chrony. Lazyness? Inertia? Running
Windows? Lack of knowledge?
Chrony will start up, and if the computer's rtc is not out by too much,
or if you tell it in the config file to step on initial startup, and
within a few minutes have the computer clock to within usec ( if it is running
from GPS) or better than a msec if from the network. It depends on how
often you told it to get the time from the remote clock.
And as it warms up, it will compensate for the changing drift. Have a
look at the graphs in www.theory.physics.ubc.ca/chrony/chrony.html. Note
that I recently restarted many of the chrony programs to install a new
version-- screwed up the config files , and then corrected them. Compare
to the behaviour of string, which runs ntp from a GPS system and how
long it took to settle down about 6 days ago.
unruh
> unruh wrote:
>> On 2009-12-22, Richard B. Gilbert <rgilb...@comcast.net> wrote:
>>> unruh wrote:
>>>> On 2009-12-22, Richard B. Gilbert <rgilb...@comcast.net> wrote:
>>>>> David J Taylor wrote:
>>>>>> "G8KBV" <g8...@nospam-uko2.co.uk> wrote in message
>>>>>> news:MPG.2599f4f8b...@news.demon.co.uk...
>>
>>> Keeping an NTPD server up and synched is not all that difficult. A UPS
>>> will keep you alive for three to fifteen minutes if power fails. The
>>> longer the UPS run time, the more it costs. Any longer than fifteen
>>> minutes and you will need a generator fueled by either gasoline or
>>> natural gas. You will either need a human being to start it and set it
>>> for the right speed or a device that will do this automagically.
>>
>> Lets see, Pay a few $100 for a UPS (and many more for a generator) ,
>> run the machine 24/7 with the associated energy costs, or load a free
>> program. Hmm.
>>
>
> Most computers that need accurate time live in a data center somewhere
> and shut down maybe as often as once every six months! I've had a few
> machines that ran continuously for a year or more! It's not impossible;
> it just requires a lot of luck OR heavy expenditures for a UPS, a backup
> generator, N+1 redundant air conditioners, etc, etc. Some enterprises
> require this sort of uptime and are prepared to pay the bills.
Most computers running ntp do not fall under that description.
And now adays, with the emphasis on conservation, that applies to fewer
and fewer computers.
David J Taylor
news:xrOdnUgQK7Mhs6zW...@giganews.com...
[]
> Anyone who thinks he can boot up, get the correct time to within
> microseconds and shut down again is living in a dream world!
>
> Windows is a poor choice of O/S for the job. Try Linux or Solaris.
> Either will run on the X86 architecture.
But Linux and Solaris will not run all the programs and device drivers I
need to run! The OS is a given and is not going to change. The
engineering challenge is: given a particular OS, do the best timekeeping
job you can.
Where did I say I needed microseconds? In fact settling to within one
millisecond would be fine for /my/ applications.
I am already down to the level of seeing exactly what Bill was saying
could be done better with chrony than with NTP - the settling time to a
given accuracy, so I think that addressing the algorithm rather than the
choice of hardware is the most important issue here.
How about a dual-algorithm NTP?
Cheers,
David
unruh
> Richard B. Gilbert wrote:
>> unruh wrote:
>>> On 2009-12-22, Richard B. Gilbert <rgilb...@comcast.net> wrote:
>>>> David J Taylor wrote:
>>>>> "Richard B. Gilbert" <> wrote in message
>>>>> news:ZJydnVuvufm1Wa3W...@giganews.com...
>
> desktops and notebooks to chronyd.
>
> What chronyd seems not to provide is peering ability with ntpd
> (or it may be I've never been able to get it working), and up
> to recently lacked any refclock support.
Not sure what "peering" ability means. It can certainly use ntpd as a
server source. It now has refclock support (shm, socket) and you can
set up ntpd so that it feeds its refclock output to chrony via the
socket ( and via the hacked ntpd that M Lichvar has created which uses
ntpd purely to get the refclock times and feed it to chrony-- so you
have all of the refclock support that ntpd has.)
These are in 1.24-pre1 from chrony.tuxfamily.org
>
> For ntpd I've had problems with long periods to come into sync,
> temperature, system load or network disturbance causing
> instability. With older systems it was possible to reduce these
> effects by fiddling system clock frequency to within 10ppm or
> so, but with most recent software some systems where previously
> I had ntpd tamed are now back to being unstable due to self
> calibration putting them 50ppm or more out, but not consistent
> between reboots, (that isn't due to ntpd, just that it
> exacerbates the problems and I suspect this will also affect
> chronyd).
Yes, a real problem with Linux these days. Chrony takes about 15 min to
adjust to the new rate, rather than the 10 hours it takes ntpd.
>
> David
David Woolley
>
> I do wish there were some way of speeding this up - a variable loop
> bandwidth or something like that.
>
It already does have one, and has had one since at least version 3.
David Lord
> On 2009-12-22, David Lord <sn...@lordynet.org> wrote:
>> Richard B. Gilbert wrote:
>>> unruh wrote:
>>>> On 2009-12-22, Richard B. Gilbert <rgilb...@comcast.net> wrote:
>>>>> David J Taylor wrote:
>>>>>> "Richard B. Gilbert" <> wrote in message
>>>>>> news:ZJydnVuvufm1Wa3W...@giganews.com...
>> Yes, I've used chronyd along with ntpd for a while. I've moved
>> desktops and notebooks to chronyd.
>>
>> What chronyd seems not to provide is peering ability with ntpd
>> (or it may be I've never been able to get it working), and up
>> to recently lacked any refclock support.
>
> Not sure what "peering" ability means. It can certainly use ntpd as a
> server source. It now has refclock support (shm, socket) and you can
> set up ntpd so that it feeds its refclock output to chrony via the
> socket ( and via the hacked ntpd that M Lichvar has created which uses
> ntpd purely to get the refclock times and feed it to chrony-- so you
> have all of the refclock support that ntpd has.)
If I have two systems with chrony specifying other as peer
in chrony.conf, along with other servers lines, it all works
ok and also systems running ntpd can use the systems running
chrony as servers without problem.
When I've tried with a system running chrony and system
running ntpd with both set as peer for the other, the ntpd
system doesn't appear to see the system running chrony
whilst the chrony system just seems to use the ntpd system
as server. I can't really say I'm suprised at that but if
not just a quirk of my setup it's a significant limitation.
> These are in 1.24-pre1 from chrony.tuxfamily.org
I might give that a try. I'd like to run a radioclock signal
or at least pps to each desktop but don't yet have suitable
hardware for that. Currently MSF (UK 60kHz time signal) is
giving loop summary:
296+/-2123, rms 492, freq -50.5+/- 0.095, var 0.039
That's with 0.5-5V input at serial port and I'm expecting
some improvement with full rs232 levels.
>
>> For ntpd I've had problems with long periods to come into sync,
>> temperature, system load or network disturbance causing
>> instability. With older systems it was possible to reduce these
>> effects by fiddling system clock frequency to within 10ppm or
>> so, but with most recent software some systems where previously
>> I had ntpd tamed are now back to being unstable due to self
>> calibration putting them 50ppm or more out, but not consistent
>> between reboots, (that isn't due to ntpd, just that it
>> exacerbates the problems and I suspect this will also affect
>> chronyd).
>
> Yes, a real problem with Linux these days. Chrony takes about 15 min to
> adjust to the new rate, rather than the 10 hours it takes ntpd.
Sometimes it seems like never, or for longer than I'm willing
to wait. I've had this quite recently with frequency being set
in ever increasing amounts in opposite directions up to over
500ppm when driftfile initially had what should have been a
reasonable starting value, then after a restart it still hit
+/-50ppm but then converged over a day to within 1ppm of
starting value.
David
unruh
> "Richard B. Gilbert" <rgilb...@comcast.net> wrote in message
> news:xrOdnUgQK7Mhs6zW...@giganews.com...
> []
>> Anyone who thinks he can boot up, get the correct time to within
>> microseconds and shut down again is living in a dream world!
>>
>> Windows is a poor choice of O/S for the job. Try Linux or Solaris.
>> Either will run on the X86 architecture.
>
> But Linux and Solaris will not run all the programs and device drivers I
> need to run! The OS is a given and is not going to change. The
> engineering challenge is: given a particular OS, do the best timekeeping
> job you can.
That is fine. Just as there are crucial programs which do not run on
Linux, there are crucial programs which do not run on windows.
>
> Where did I say I needed microseconds? In fact settling to within one
> millisecond would be fine for /my/ applications.
ntp will eventually settle to within a millisecond.
You can help by running it with the -g option, and apparently without a
ntp.drift file (It a) steps to within 1/8 of a sec, and tries to
raplidly determine the drift.)
>
> I am already down to the level of seeing exactly what Bill was saying
> could be done better with chrony than with NTP - the settling time to a
> given accuracy, so I think that addressing the algorithm rather than the
> choice of hardware is the most important issue here.
>
> How about a dual-algorithm NTP?
It is a massive coding job. chorny is not exactly a two line program.
And David Mills, who controls the algorithm of ntpd, does not have any
interest in implimenting any other algorithm, at least at this time.
Probably more userful would be porting chrony to windows. That is also a
big job. The biggest problem is to impliment the kernel microsecond or
nanosecond time control that the Linux/BSd kernels have, and then the
equivalent of the adjtimex routines to interface with those timing
routines.
Windows uses only the time interrupt ( originally 18 times a sec, now up
to 1000 times a sec) and does not divide the kernel time finer than
that. Linux/BSD divide the time into usec or nsec using things like
hpet, the cpu instruction counter,... to give the fine resolution. After
that one needs to impliment the select call with its fineness etc. Ie,
one has to try to make the Windows kernel act like a linux kernel.
Once those things are set, the porting is probably not too bad. Note
that the Meinberg implimentation of ntpd on windows had similar
problems as far as I can see.
>
> Cheers,
> David
>
unruh
One problem ntp has its clock filter algorithm. It throws away 80% of
the incoming data. (It accepts a new reading only if that new reading
has a smaller delay than any of the last 8 readings. This effectively
means that the time between measurements is 8 times the poll interval.
Ie, if you have a poll interval of 6 (64 sec) the effective poll
interval for ntpd is 8 min. And at poll interval 10, the effective
interval is about 2 hr. the system certainly cannot respond to anything
more rapidly than that, and must do so more slowly in order to remain
stable. This is true even if the delay has a very small variance.
Secondly because the only memory is contained in the rate, the system
has no way of actually estimating the rate of the clock with respect to
the remote clock. Ie, if the offset is positive, the rate is increased a
bit, if negative, it is decreased a bit, and that's it. But there is far
more information than that in the collection of offsets. With three
offsets, one can both estimate the drift, and the uncertainlty in that
drift. It is like walking down the street, staring only at i one square
inch of the the sidewalk
under your feet, and correcting when you see the curb in that 1 square
inch, and the grass, as opposed to looking ahead and behind you.
Note that the time scales ( 1hr for halving the error) I mentioned is
for a poll interval of 4 (16 sec) .
David J Taylor
news:hgrj64$d1l$1...@news.eternal-september.org...
Thanks, David.
So why doesn't it work better. i.e. converge much more quickly? Can you
tune the algorithm so that the first few minutes are aimed at rapid time
setting?
Cheers,
David
David J Taylor
"unruh" <un...@wormhole.physics.ubc.ca> wrote in message
news:slrnhj3at2...@wormhole.physics.ubc.ca...
[]
> ntp will eventually settle to within a millisecond.
> You can help by running it with the -g option, and apparently without a
> ntp.drift file (It a) steps to within 1/8 of a sec, and tries to
> raplidly determine the drift.)
I checked and I do have the -g option set. I have not seen faster
settling without a drift file, although I have seen the behaviour which
others have reported of a very occasional ever-increasing drift which can
only be cured by restarting without a drift file.
>> How about a dual-algorithm NTP?
>
> It is a massive coding job. chorny is not exactly a two line program.
> And David Mills, who controls the algorithm of ntpd, does not have any
> interest in implimenting any other algorithm, at least at this time.
The code is available - so why not demonstrate that the algorithm can be
improved in a private version?
> Probably more userful would be porting chrony to windows. That is also a
> big job. The biggest problem is to impliment the kernel microsecond or
> nanosecond time control that the Linux/BSd kernels have, and then the
> equivalent of the adjtimex routines to interface with those timing
> routines.
> Windows uses only the time interrupt ( originally 18 times a sec, now up
> to 1000 times a sec) and does not divide the kernel time finer than
> that. Linux/BSD divide the time into usec or nsec using things like
> hpet, the cpu instruction counter,... to give the fine resolution. After
> that one needs to impliment the select call with its fineness etc. Ie,
> one has to try to make the Windows kernel act like a linux kernel.
>
> Once those things are set, the porting is probably not too bad. Note
> that the Meinberg implimentation of ntpd on windows had similar
> problems as far as I can see.
As you hint, a lot of this work has already been done for Windows, both
for the slow clock (before Windows Vista) and for the faster-clock (Vista
and Windows-7). One could perhaps ask for permission to borrow that
code. Even better, Dave Hart's DLL now allows the PPS driver to get more
accurate kernel mode timestamps, once we are talking about porting
ref-clock drivers as well, but that's quite a long way down the line.
It would seem to me to be far less effort simply to provide an enhanced
fast-convergence option to the existing NTP code, test that privately, and
propose it as an option users can take or not, according to their own
needs. That code already accepts many ref-clocks, and is already ported
to multiple operating systems.
Cheers,
David
Dave Hart
> As you hint, a lot of this work has already been done for Windows, both
> for the slow clock (before Windows Vista) and for the faster-clock (Vista
> and Windows-7). One could perhaps ask for permission to borrow that
> code.
While that might be nice, my reading of the NTP copyright indicates
there is no need. You are free to use the reference implementation
without additional permission, and with almost no restrictions. See
COPYRIGHT in the tarballs, or
http://www.eecis.udel.edu/~mills/ntp/html/copyright.html
Some source files have different copyright notices. My understanding
is all the programs installed are using similar BSD-style licenses
which at most impose a requirement to reproduce the copyright notice
and restrict the use of the copyright holder(s)'s names without
permission.
I am not lawyer and this is not legal advice. I am however
interested in reducing the number of different copyright notices in
the reference implementation. I'm grateful to Max Kühn and Claas
Hilbrecht for removing their copyright notices from sntp and
refclock_neoclock4x, respectively, relying on the overall distribution
copyright. The fewer copyright claims and licenses involved, the
easier it is for third parties to use the code in projects sensitive
to license issues. Wasting less time and money on lawyers is a bonus.
Cheers,
Dave Hart
Richard B. Gilbert
So, have YOU written a program that works better? If so, why aren't you
using it instead of carping about the behavior of NTPD?
Have you even modified NTPD to make it work better? Tested your version
under a variety of conditions to demonstrate that it works better in all
reasonably probable circumstances?
I didn't think so!
unruh
>
> "unruh" <un...@wormhole.physics.ubc.ca> wrote in message
> news:slrnhj3at2...@wormhole.physics.ubc.ca...
> []
>> ntp will eventually settle to within a millisecond.
>> You can help by running it with the -g option, and apparently without a
>> ntp.drift file (It a) steps to within 1/8 of a sec, and tries to
>> raplidly determine the drift.)
>
> I checked and I do have the -g option set. I have not seen faster
> settling without a drift file, although I have seen the behaviour which
> others have reported of a very occasional ever-increasing drift which can
> only be cured by restarting without a drift file.
Sorry out of ideas then.
>
>
>>> How about a dual-algorithm NTP?
>>
>> It is a massive coding job. chorny is not exactly a two line program.
>> And David Mills, who controls the algorithm of ntpd, does not have any
>> interest in implimenting any other algorithm, at least at this time.
>
> The code is available - so why not demonstrate that the algorithm can be
> improved in a private version?
??? The code is NOT available on ntpd. It would require a large coding
job to impliment the chrony algorithm into ntpd and if you knew that
your one year worth of work would never ever make it into ntpd, why
would you do it? To properly integrate it you have to know ntpd
intimately, know chrony ( or at least the algorithm) intmately, and do
the coding job.
Note that I have run tests with chrony vs ntpd showing that on my test
system, chrony out performed ntpd significantly. The response was "If yo
ulike chrony so much use it, and don't bother us". The response from
David was that he was not interested until chrony had been tested in as
wide a set of circumstances as ntpd had been.
>
>> Probably more userful would be porting chrony to windows. That is also a
>> big job. The biggest problem is to impliment the kernel microsecond or
>> nanosecond time control that the Linux/BSd kernels have, and then the
>> equivalent of the adjtimex routines to interface with those timing
>> routines.
>> Windows uses only the time interrupt ( originally 18 times a sec, now up
>> to 1000 times a sec) and does not divide the kernel time finer than
>> that. Linux/BSD divide the time into usec or nsec using things like
>> hpet, the cpu instruction counter,... to give the fine resolution. After
>> that one needs to impliment the select call with its fineness etc. Ie,
>> one has to try to make the Windows kernel act like a linux kernel.
>>
>> Once those things are set, the porting is probably not too bad. Note
>> that the Meinberg implimentation of ntpd on windows had similar
>> problems as far as I can see.
>
> As you hint, a lot of this work has already been done for Windows, both
> for the slow clock (before Windows Vista) and for the faster-clock (Vista
> and Windows-7). One could perhaps ask for permission to borrow that
> code. Even better, Dave Hart's DLL now allows the PPS driver to get more
The code is open license
"Permission to use, copy, modify, and distribute this software and *
* its documentation for any purpose with or without fee is hereby *
* granted"
It is a bit of a mess because there are several authors claimed, and the
legal position of their code is unclear from the documentation ( did
they transfer copyright? Did they license their code to ntpd with an
open license, were they employees of Mills so he automatically had the
copyright of their work, etc) but the chances of your being sued (
copyright is simply a license to sue) are pretty remote I think.
I have no interest whatsoever in Windows, nor, I suspect, do most of the people involved with
chrony development. It is hard then to put in the time to do it.
> accurate kernel mode timestamps, once we are talking about porting
> ref-clock drivers as well, but that's quite a long way down the line.
chrony has refclock drivers, and ntpd can be altered (and has been) to deliver all of
its refclock drivers to chrony. So refclock is not a problem. The
problem is getting basic chrony to run on windows.
>
> It would seem to me to be far less effort simply to provide an enhanced
> fast-convergence option to the existing NTP code, test that privately, and
> propose it as an option users can take or not, according to their own
> needs. That code already accepts many ref-clocks, and is already ported
> to multiple operating systems.
The basic ntp algorithm is the problem. It is not simply that one has to
kludge on an additions "startup" algorithm. ntpd does much worse than
chrony even in long time running because of its poor response to change
( like temperature changes). The algorithm ( some combination of the
clock filter algorithm and the basic Markovian feedback loop) is simply
an extremely slowly responding algorithm all the time. It is most
obvious on startup but is there always. For people to hang a kludge onto
ntpd at startup, because that is what bothers you most, is not a job
most would want to do. You are of course free to do it yourself, but
like most of us, you do not have the depth of knowledge of ntpd, or
windows, or do not have the coding skills needed.
Once upon a time, Richard Curnow, the author of chrony, had an interest
in porting it to Windows. Unfortunately other aspects of life caught up
with him (children, jobs,...) and his interest now is very small.
unruh
> On Dec 23, 9:16?UTC, David J Taylor wrote:
>> As you hint, a lot of this work has already been done for Windows, both
>> for the slow clock (before Windows Vista) and for the faster-clock (Vista
>> code.
>
> While that might be nice, my reading of the NTP copyright indicates
> there is no need. You are free to use the reference implementation
> without additional permission, and with almost no restrictions. See
> COPYRIGHT in the tarballs, or
>
> http://www.eecis.udel.edu/~mills/ntp/html/copyright.html
>
> Some source files have different copyright notices. My understanding
> is all the programs installed are using similar BSD-style licenses
> which at most impose a requirement to reproduce the copyright notice
> and restrict the use of the copyright holder(s)'s names without
> permission.
>
> I am not lawyer and this is not legal advice. I am however
> interested in reducing the number of different copyright notices in
> Hilbrecht for removing their copyright notices from sntp and
> refclock_neoclock4x, respectively, relying on the overall distribution
> copyright. The fewer copyright claims and licenses involved, the
> easier it is for third parties to use the code in projects sensitive
> to license issues. Wasting less time and money on lawyers is a bonus.
The problem is that removing their copyright notice helps not at all,
and in fact makes the situation more complex. copyright is automatic.
They hold the copyright when they make the program. Without an explicit
license, noone has the right to use the program, in the sense that the authors
then have the right to sue for infringement. Now, I suspect they have no
intention of suing anyone, and for private individuals that is enough.
for large companies however, where the suit could reap large dollars,
the companies are not happy to simply rely on the good will of the
writer. So they should either explicitly transfer the copyright to David
Mills, or publish an explicit license. The problem with the current ntpd
"license" is that it is a combination of a copyright claim, and a
license. Thus the writers cannot simply state that they are using the
general license, since it also makes a copyright claim. (It also
confusingly refers to the U Delaware when the copyright holder is D
Mills).
The license would be better if it clearly stated that each of the
authors (listed in that document COPYRIGHT) releases their work under
the license, and that in addition to the specific claims on parts of the
ntp code he wrote, David Mills claimed copyright in the code as a whole
as a derived work, or something like that. Again this is just for
clarity, since the chances of any of the authors suing is I suspect
vanishingly small.
Again I am not a lawyer, so if a real copyright lawyer contradicts me,
listen to them, not me, or, if it matters to you, consult one of them.
>
> Cheers,
> Dave Hart
unruh
It is nice to have my claims to promptly and clearly substantiated.
No I have not write a program that works better. Richard Curnow did
about 12 years ago. And I do use it. This newsgroup is for discussion of
ntp, the protocol, not ntpd, the reference implimentation. And chrony,
the program Curnow wrote, is an implimentation of ntpd.
>
> Have you even modified NTPD to make it work better? Tested your version
> under a variety of conditions to demonstrate that it works better in all
> reasonably probable circumstances?
The key bits of ntpd which are the filter and algorithm are claimed, in
no uncertain terms, by David Mills, and he refuses to countenance any
changes to them.
I have tested chrony against ntp is a number of circumstances and shown
that it works better than ntpd. The results were posted to this news
group, where you can look at them at your leisure. they are not
exhaustive, and more work needs to be done. Some are also posted at
www.theory.physics.ubc.ca/chrony/chrony.html. However they are suggestive
( Much much faster convergence, smaller deviation from the "true time"
by factors of 2-3). Lichvar has also done some informal tests with
chrony and a gps refclock and has claimed much much better behaviour of
chrony (smaller standard deviation) over ntp.
Are there situations where chrony works worse? I
would be interested to hear of them.
E-Mail Sent to this address will be added to the BlackLists
> David J Taylor wrote:
>>> It is a massive coding job. chorny is not exactly a two
>>> line program. And David Mills, who controls the
>>> algorithm of ntpd, does not have any interest in
>>> implimenting any other algorithm, at least at this time.
>>
>> The code is available - so why not demonstrate that the
>> algorithm can be improved in a private version?
>
> ??? The code is NOT available on ntpd. It would require
> a large coding job to impliment the chrony algorithm
> into ntpd and if you knew that your one year worth of
> work would never ever make it into ntpd, why would you
> do it? To properly integrate it you have to know ntpd
> intimately, know chrony ( or at least the algorithm)
> intmately, and do the coding job.
So, you expect some one else to do programming for you?
If you, the person pushing this solution, are not interested
in making the effort to do the programming, the likelihood
of anyone else doing it for you is slim or none.
If you aren't interested in making the effort, why do you
(apparently uselessly) keep flogging your "ultimate solution"?
--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.
Dave Hart
> On 2009-12-23, Dave Hart <daveh...@gmail.com> wrote:
> > I am however
> > interested in reducing the number of different copyright notices in
> > the reference implementation. I'm grateful to Max K?hn and Claas
> > Hilbrecht for removing their copyright notices from sntp and
> > refclock_neoclock4x, respectively, relying on the overall distribution
>
> The problem is that removing their copyright notice helps not at all,
> and in fact makes the situation more complex. copyright is automatic.
I too believe copyright is automatic in most jurisdictions today. I
do not agree that reducing the number of diverse copyright claims and
accompanying BSD-ish licenses in the NTP reference implementation
"makes the situation more complex" -- quite the opposite.
Any arbiter of dispute is bound to look at the totality of the
evidence and not rely solely on automatic copyright as the end of the
story. When I contribute code to the reference implementation, I do
not make any explicit assignment of my interests, but I also do not
make any attempt to exercise a copyright holder's prerogative to set
license terms. Given that the reference implementation has a top-
level COPYRIGHT file and the documentation links to the same text in
html/copyright.html, I think it is clear I expect my contributions to
be distributed and licensed the same as the rest of the package. If
Dr. Mills or ntp.org were to ask me to sign a copyright assignment or
release as a condition of contributing, I would not hesitate. I would
prefer in the interest of the best software to avoid requiring
contributors to deal with paperwork, but it's not my call.
Similarly, while no one should rely on my opinions as legal advice,
When Max and Claas took affirmative steps to strip their copyright
claims and BSD-like licenses out of their contributed source, those
steps seem to me evidence of intent their contributions be covered by
the distribution-wide COPYRIGHT. I have a hard time seeing how those
steps "make the situation more complex", as there are now two fewer
licenses for lawyers to get paid by the hour to dissect, and two fewer
places for packagers to find copyright notices potentially requiring
duplication into documentation. So for now, I continue to be
interested in eliminating as many copyright claims and licenses from
the distribution as can be arranged with claimaints, with the ultimate
goal of having only the Mills/udel.edu copyright.
Cheers,
Dave Hart
G8KBV
@comcast.net says...
> >
> >> Keeping an NTPD server up and synched is not all that difficult. A UPS
> >> will keep you alive for three to fifteen minutes if power fails. The
> >> longer the UPS run time, the more it costs. Any longer than fifteen
> >> minutes and you will need a generator fueled by either gasoline or
> >> natural gas. You will either need a human being to start it and set it
My needs for this, is to run a HF (Shortwave) radio beacon monitor, for
propagation studdies and path conditon monitoring, the resulting data is
also presented to others on a web based status page.
The Faros PC ('Faros' is the software that does the job) and the NTP PC
(currently two seperate machines) do run 24/7, from a UPS that has been
proven to keep them (and associated radio hardware) running for over an
hour if the lights go out.
If I'm hear if that happens, I can indeed get a genny out of the garage,
and run it all from that if I realy realy needed to, or even a long lead
from my Landy on the driveway and the 12V to 240V inverter in that..
As to Chrony, for better or worse, everything here runs on Windows,
purely because after many years using it, I sort of know my way round
it. Sadly I do not have the time or inclenation to learn Linux (or
FreeBSD) to the same degree, for what I want to do.
I am not starting a 'Nix/Winders war, or a NTP/Crony one for that matter
either.
I have found what I need, to my satisfaction for now, with much help
from others hear, for which I'm truly grateful. They know who they are,
thanks again.
Cheers.
Dave Baxter.
unruh
> unruh wrote:
>> David J Taylor wrote:
> ---------|---------|---------|---------|---------|---------|
>>>> It is a massive coding job. chorny is not exactly a two
>>>> line program. And David Mills, who controls the
>>>> algorithm of ntpd, does not have any interest in
>>>> implimenting any other algorithm, at least at this time.
>>>
>>> The code is available - so why not demonstrate that the
>>> algorithm can be improved in a private version?
>>
>> ??? The code is NOT available on ntpd. It would require
>> a large coding job to impliment the chrony algorithm
>> into ntpd and if you knew that your one year worth of
>> work would never ever make it into ntpd, why would you
>> do it? To properly integrate it you have to know ntpd
>> intimately, know chrony ( or at least the algorithm)
>> intmately, and do the coding job.
>
> So, you expect some one else to do programming for you?
Yup. I am not competent at coding, nor do I have the time to learn ntpd
sufficiently well, and since the controller of ntpd, D Mills, has no
interest whatsoever in any alterations of the code base of the algorithm
that ntpd uses, I also have no motivation. As people have said, I can
use chrony. And now that chrony supports refclocks, the only motivation
I had is gone as well. I have spent a fair amount of time testing and
comparing chrony and ntpd-- that has been my contribution. What has
yours been?
>
> If you, the person pushing this solution, are not interested
> in making the effort to do the programming, the likelihood
> of anyone else doing it for you is slim or none.
If, after I have demonstrated that the algorithm used by chrony is both
much faster, and is much more accurate than that in ntpd, noone in the
ntpd community cares, I am afraid I do not either. Clearly it would be
best if the reference implimentation used the best possible algorithm.
Since it does not and since an implimentation of the better one exists,
I guess I will have to do the Linux vs Windows thing, and "take the road
less trodden".
>
> If you aren't interested in making the effort, why do you
> (apparently uselessly) keep flogging your "ultimate solution"?
In the hope that there are some people ( obviously not including you) in
the time keeping community which this is the newsgroup of, who might be
interested. And in the hope that enough will be interested that the
development will continue. And because as a scientist, I am interested
in understanding why the one algorithm is apparently better than the
other.
>
unruh
>> > interested in reducing the number of different copyright notices in
>> > Hilbrecht for removing their copyright notices from sntp and
>> > refclock_neoclock4x, respectively, relying on the overall distribution
>> > copyright. [...]
>>
>> The problem is that removing their copyright notice helps not at all,
>> and in fact makes the situation more complex. copyright is automatic.
>
> I too believe copyright is automatic in most jurisdictions today. I
> do not agree that reducing the number of diverse copyright claims and
> accompanying BSD-ish licenses in the NTP reference implementation
> "makes the situation more complex" -- quite the opposite.
>
> Any arbiter of dispute is bound to look at the totality of the
> evidence and not rely solely on automatic copyright as the end of the
> story. When I contribute code to the reference implementation, I do
> not make any explicit assignment of my interests, but I also do not
> make any attempt to exercise a copyright holder's prerogative to set
Unfortunately one of the prerogatives is to grant no license whatsoever,
meaning noone can copy. That is a perfectly valid option for a copyright
holder and must be the default option that the courts must apply-- that
the author granted no license because he intended to grant no license.
That is of course confused by the fact that the holder contributed the
work to another work which IS released under a specific very open
license. The problem is that in a dispute like this, the court in
general has to go with the more conservative option, and the author
might tell the court that was his intention because desperately and
irrationally dislikes, say Microsoft.
> license terms. Given that the reference implementation has a top-
> level COPYRIGHT file and the documentation links to the same text in
> html/copyright.html, I think it is clear I expect my contributions to
But the reference implimentation is clearly a work derivate of the
various parts, and the copyright in the derivative work does not
supercede the copyright in the part. The court could make what for you
is the obvious decision, that in the absense of an explicit statement,
the author implicitly decided to grant the same licence as the work as a
whole. The author could however, because he hates microsoft, come to
court and claim, that that was never his intention. This would leave
Microsoft up shit creek.
Now, the probability of any of this coming to court is small, but for a
large publically targeted company, they have to worry about such
possible ambushes. It is thus far cleaner for them if the license
granted by all of the authors of the contributed works are clear.
> be distributed and licensed the same as the rest of the package. If
No, unless you state it, it is not clear.
> Dr. Mills or ntp.org were to ask me to sign a copyright assignment or
> release as a condition of contributing, I would not hesitate. I would
> prefer in the interest of the best software to avoid requiring
> contributors to deal with paperwork, but it's not my call.
Agreed. But paperwork is not required. A statement that an unconditional
license is granted to Mills to relicense in any way he wished, or to
transfer copyright to him, would suffice-- in the text of the
contributions, or whatever. At present the COPYRIGHT notice claims
copyright for Mills, and then states that he is not the author of
various parts of the work, and states nothing about the copyright status
of those parts. It is a confusion. Is he claiming copyright over those
parts despite not being the author? Is he claiming the right to license
those parts despite not owning the copyright?
>
> Similarly, while no one should rely on my opinions as legal advice,
> When Max and Claas took affirmative steps to strip their copyright
> claims and BSD-like licenses out of their contributed source, those
> steps seem to me evidence of intent their contributions be covered by
> the distribution-wide COPYRIGHT. I have a hard time seeing how those
But their action actually accomplished the opposite. It removed anyone's
right to copy their source.
"Copyright in this work has been given to David Mills" would accomplish
what they want. Or "This work is licensed to David Mills to do with as
he wishes, incliding relicensing to others", or many other ways of
letting the world know what their intention is. Silence is not an very
good expression of intention. If you are married you know that taking
your wife's silence as an expression of consent is a pretty dangerous
thing to do.
> steps "make the situation more complex", as there are now two fewer
> licenses for lawyers to get paid by the hour to dissect, and two fewer
> places for packagers to find copyright notices potentially requiring
> duplication into documentation. So for now, I continue to be
> interested in eliminating as many copyright claims and licenses from
> the distribution as can be arranged with claimaints, with the ultimate
> goal of having only the Mills/udel.edu copyright.
Then transfer your copyright to him.
>
> Cheers,
> Dave Hart
David J Taylor
[]
> ??? The code is NOT available on ntpd. It would require a large coding
> job to impliment the chrony algorithm into ntpd and if you knew that
> your one year worth of work would never ever make it into ntpd, why
> would you do it? To properly integrate it you have to know ntpd
> intimately, know chrony ( or at least the algorithm) intmately, and do
> the coding job.
I was able to download, and even to compile, the code for NTP, so it /is/
available. I was only suggesting replacing one small part to prove a
point.
[]
> I have no interest whatsoever in Windows, nor, I suspect, do most of
> the people involved with
> chrony development. It is hard then to put in the time to do it.
So the majority of the world's computer users will have no interest in
chrony.
[]
> The basic ntp algorithm is the problem. It is not simply that one has to
> kludge on an additions "startup" algorithm. ntpd does much worse than
> chrony even in long time running because of its poor response to change
> ( like temperature changes). The algorithm ( some combination of the
> clock filter algorithm and the basic Markovian feedback loop) is simply
> an extremely slowly responding algorithm all the time. It is most
> obvious on startup but is there always. For people to hang a kludge onto
> ntpd at startup, because that is what bothers you most, is not a job
> most would want to do. You are of course free to do it yourself, but
> like most of us, you do not have the depth of knowledge of ntpd, or
> windows, or do not have the coding skills needed.
You assume far too much! You have no idea of what coding skills or
knowledge of OSes I may or may not have. You have no idea about what
bothers me most about NTP. That anyone chooses not to spend their time
working directly with NTP may simply reflect the priorities they have.
> Once upon a time, Richard Curnow, the author of chrony, had an interest
> in porting it to Windows. Unfortunately other aspects of life caught up
> with him (children, jobs,...) and his interest now is very small.
Is this not an open sauce project? <G>
David
unruh
> "unruh" <un...@wormhole.physics.ubc.ca> wrote in message
> news:slrnhj4u3f...@wormhole.physics.ubc.ca...
> []
>> ??? The code is NOT available on ntpd. It would require a large coding
>> job to impliment the chrony algorithm into ntpd and if you knew that
>> your one year worth of work would never ever make it into ntpd, why
>> would you do it? To properly integrate it you have to know ntpd
>> intimately, know chrony ( or at least the algorithm) intmately, and do
>> the coding job.
>
> I was able to download, and even to compile, the code for NTP, so it /is/
> available. I was only suggesting replacing one small part to prove a
> point.
Sorry my referents confused you. It is the code for chrony on ntp that
is not available (does not exist). And it is not "replacing one small
part".
>
>
> []
>> I have no interest whatsoever in Windows, nor, I suspect, do most of
>> the people involved with
>> chrony development. It is hard then to put in the time to do it.
>
> So the majority of the world's computer users will have no interest in
> chrony.
That may be true. Unfortunately the majority of the worlds computers
already have no interest in accurate time keeping because of the
architecture of the operating system. On the other hand, just as with
ntpd which was originally written for Unix type systems, someone might
decide that an ntp program which is two to three times more accurate
than ntpd, and has a much faster startup time might be useful on Windows
and be willing to invest the time and effort in the port.
Just as with you, many people do not know about chrony to get interested
in supporting it.
...
>
>> Once upon a time, Richard Curnow, the author of chrony, had an interest
>> in porting it to Windows. Unfortunately other aspects of life caught up
>> with him (children, jobs,...) and his interest now is very small.
>
> Is this not an open sauce project? <G>
Yes, and it has been taken over now by others, who have added refclock
support, IPV6 support, bug fixes in the past month or so. But noone has
stepped forward who is interested in adding windows support yet.
Are you volunteering?
>
> David
>
David J Taylor
[]
> Sorry my referents confused you. It is the code for chrony on ntp that
> is not available (does not exist). And it is not "replacing one small
> part".
Why not take a different approach, then? Start with chrony to make the
system rapidly stable, and then turn control over to NTP. Is something
like that possible?
[]
>> Is this not an open sauce project? <G>
>
> Yes, and it has been taken over now by others, who have added refclock
> support, IPV6 support, bug fixes in the past month or so. But noone has
> stepped forward who is interested in adding windows support yet.
> Are you volunteering?
Were it in Delphi, I would consider helping, but I don't "do" C/C++, which
I find a most obscure and unhelpful language, and arcane "make"
environments. I can and do use C DLLs written for Windows from Delphi,
though.
Cheers,
David
unruh
> news:slrnhj7b8s...@wormhole.physics.ubc.ca...
> []
>> Sorry my referents confused you. It is the code for chrony on ntp that
>> is not available (does not exist). And it is not "replacing one small
>> part".
>
> Why not take a different approach, then? Start with chrony to make the
> system rapidly stable, and then turn control over to NTP. Is something
> like that possible?
Why not just stick with chrony. But I thought we were discussing Windows
systems, on which chrony does not run. And if someone has rewritten
chrony to run on windows, there is no point in handing over to ntp. As I
said chrony is about 2 times better ( lower standard deviation) than
ntp. Why would you want to hand over control to a worse program?
>
David J Taylor
[]
>> Why not take a different approach, then? Start with chrony to make the
>> system rapidly stable, and then turn control over to NTP. Is something
>> like that possible?
>
> Why not just stick with chrony. But I thought we were discussing Windows
> systems, on which chrony does not run. And if someone has rewritten
> chrony to run on windows, there is no point in handing over to ntp. As I
> said chrony is about 2 times better ( lower standard deviation) than
> ntp. Why would you want to hand over control to a worse program?
I had wondered whether that might be an acceptable solution for some folk.
My original question was not OS-specific. As you say, until chrony is
available for a wider range of operating systems and supports GPS/PPS
reference clocks it is but of academic interest. As NTP already provides
that infrastructure, enhancing the initial convergence rather than having
to re-invent the whole wheel seems a better approach to me.
Happy Christmas all all our readers!
David
unruh
>
> "unruh" <un...@wormhole.physics.ubc.ca> wrote in message
> news:slrnhj7qd9...@wormhole.physics.ubc.ca...
> []
>>> Why not take a different approach, then? Start with chrony to make the
>>> system rapidly stable, and then turn control over to NTP. Is something
>>> like that possible?
>>
>> Why not just stick with chrony. But I thought we were discussing Windows
>> systems, on which chrony does not run. And if someone has rewritten
>> chrony to run on windows, there is no point in handing over to ntp. As I
>> said chrony is about 2 times better ( lower standard deviation) than
>> ntp. Why would you want to hand over control to a worse program?
>
> I had wondered whether that might be an acceptable solution for some folk.
> My original question was not OS-specific. As you say, until chrony is
> available for a wider range of operating systems and supports GPS/PPS
> reference clocks it is but of academic interest. As NTP already provides
It does (now) support GPS/PPS refclocks.
David Lord
When I first made use of chrony it was to keep time with
only occasional access to internet. There was no NetBSD
specific package at the time but enough guidance was
available to get it built and working. Ntpd was in
default base OS and I'd tried and failed to get that
working with dialup and maintain reasonable time between
connections. Chrony already came with configuration
examples just for this and apart from initial problems
getting it to build it worked very well for several years
on dialup then another few years on broadband. Two
fileservers running ntpd were happy to use the firewalls
as sources. So I'd not put it down as only of academic
interest.
I agree that from my non programmer point of view it
would seem that making changes to ntpd to import those
features from chrony would be easier than making changes
to chrony but I suspect lack of interest in that
direction or in developing a windows version of chrony.
David
unruh
>
> "unruh" <un...@wormhole.physics.ubc.ca> wrote in message
> news:slrnhj3at2...@wormhole.physics.ubc.ca...
> []
>> ntp will eventually settle to within a millisecond.
>> You can help by running it with the -g option, and apparently without a
>> ntp.drift file (It a) steps to within 1/8 of a sec, and tries to
>> raplidly determine the drift.)
>
> I checked and I do have the -g option set. I have not seen faster
> settling without a drift file, although I have seen the behaviour which
> others have reported of a very occasional ever-increasing drift which can
> only be cured by restarting without a drift file.
Sorry out of ideas then.
>
>
>>> How about a dual-algorithm NTP?
>>
>> It is a massive coding job. chorny is not exactly a two line program.
>> And David Mills, who controls the algorithm of ntpd, does not have any
>> interest in implimenting any other algorithm, at least at this time.
>
> The code is available - so why not demonstrate that the algorithm can be
> improved in a private version?
??? The code is NOT available on ntpd. It would require a large coding
job to impliment the chrony algorithm into ntpd and if you knew that
your one year worth of work would never ever make it into ntpd, why
would you do it? To properly integrate it you have to know ntpd
intimately, know chrony ( or at least the algorithm) intmately, and do
the coding job.
Note that I have run tests with chrony vs ntpd showing that on my test
system, chrony out performed ntpd significantly. The response was "If yo
ulike chrony so much use it, and don't bother us". The response from
David was that he was not interested until chrony had been tested in as
wide a set of circumstances as ntpd had been.
>
>> Probably more userful would be porting chrony to windows. That is also a
>> big job. The biggest problem is to impliment the kernel microsecond or
>> nanosecond time control that the Linux/BSd kernels have, and then the
>> equivalent of the adjtimex routines to interface with those timing
>> routines.
>> Windows uses only the time interrupt ( originally 18 times a sec, now up
>> to 1000 times a sec) and does not divide the kernel time finer than
>> that. Linux/BSD divide the time into usec or nsec using things like
>> hpet, the cpu instruction counter,... to give the fine resolution. After
>> that one needs to impliment the select call with its fineness etc. Ie,
>> one has to try to make the Windows kernel act like a linux kernel.
>>
>> Once those things are set, the porting is probably not too bad. Note
>> that the Meinberg implimentation of ntpd on windows had similar
>> problems as far as I can see.
>
> As you hint, a lot of this work has already been done for Windows, both
> for the slow clock (before Windows Vista) and for the faster-clock (Vista
> and Windows-7). One could perhaps ask for permission to borrow that
> code. Even better, Dave Hart's DLL now allows the PPS driver to get more
The code is open license
"Permission to use, copy, modify, and distribute this software and *
* its documentation for any purpose with or without fee is hereby *
* granted"
It is a bit of a mess because there are several authors claimed, and the
legal position of their code is unclear from the documentation ( did
they transfer copyright? Did they license their code to ntpd with an
open license, were they employees of Mills so he automatically had the
copyright of their work, etc) but the chances of your being sued (
copyright is simply a license to sue) are pretty remote I think.
I have no interest whatsoever in Windows, nor, I suspect, do most of the people involved with
chrony development. It is hard then to put in the time to do it.
> accurate kernel mode timestamps, once we are talking about porting
> ref-clock drivers as well, but that's quite a long way down the line.
chrony has refclock drivers, and ntpd can be altered (and has been) to deliver all of
its refclock drivers to chrony. So refclock is not a problem. The
problem is getting basic chrony to run on windows.
>
> It would seem to me to be far less effort simply to provide an enhanced
> fast-convergence option to the existing NTP code, test that privately, and
> propose it as an option users can take or not, according to their own
> needs. That code already accepts many ref-clocks, and is already ported
> to multiple operating systems.
The basic ntp algorithm is the problem. It is not simply that one has to
kludge on an additions "startup" algorithm. ntpd does much worse than
chrony even in long time running because of its poor response to change
( like temperature changes). The algorithm ( some combination of the
clock filter algorithm and the basic Markovian feedback loop) is simply
an extremely slowly responding algorithm all the time. It is most
obvious on startup but is there always. For people to hang a kludge onto
ntpd at startup, because that is what bothers you most, is not a job
most would want to do. You are of course free to do it yourself, but
like most of us, you do not have the depth of knowledge of ntpd, or
windows, or do not have the coding skills needed.
David Lord
Just tried again with chrony on desktop set as peer for each
of three servers and this time there appeared to be no
problem until last system started has just gone back to INIT
for the chrony peer. As it happens that is server I tried
this with previously, ntpd 4.2.0r vs ntpd 4.2.4p2-o on other
servers.
>> These are in 1.24-pre1 from chrony.tuxfamily.org
Compiled and installed on NetBSD 5.0.1 but on startup had
a coredump so I'm back to 1.23 until I have some spare
time to look into it.
David
unruh
> David Lord wrote:
>>> These are in 1.24-pre1 from chrony.tuxfamily.org
>
> Compiled and installed on NetBSD 5.0.1 but on startup had
> a coredump so I'm back to 1.23 until I have some spare
> time to look into it.
OK, definitely want to hear about that before 1.24 is released.
Danny Mayer
> The problem with the current ntpd
> "license" is that it is a combination of a copyright claim, and a
> license. Thus the writers cannot simply state that they are using the
> general license, since it also makes a copyright claim. (It also
> confusingly refers to the U Delaware when the copyright holder is D
> Mills).
Dave Mills transferred the license and copyright and ownership to
University of Delaware some time ago. The notice reflects that transfer.
Danny
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
unruh
> unruh wrote:
>> The problem with the current ntpd
>> "license" is that it is a combination of a copyright claim, and a
>> license. Thus the writers cannot simply state that they are using the
>> general license, since it also makes a copyright claim. (It also
>> confusingly refers to the U Delaware when the copyright holder is D
>> Mills).
>
> Dave Mills transferred the license and copyright and ownership to
> University of Delaware some time ago. The notice reflects that transfer.
The notice in 4.2.4p4, which is the version I have, says that David Mills owns the
copyright.
Copyright (c) David L. Mills 1992-2007
Looking at the Developement branch, the copyright notice now says that U
Delaware owns the copyright, as you say, and lists a series of authors of the work.
This document is still confusing since it is still a combination of
copyright claim and license. Another author cannot use it, since he owns
the copyright to his own work, not the U Delaware, unless he transfers
his copyright to the U Delaware. Such a transfer cannot be implicit, and
it certainly cannot be claimed that this license and copyright ownership
applies simply because the
authors removed all copyright and license text from their contribution.
While the chances of those authors making a copyright claim against a
big user are slim, a big company has to protect itself (the "big
pockets" theory of US law suits make them easy targets).
I guess if one of the authors did sue the big company, it could turn
around and sue U Delaware for falsely stating it owned the copyright and
claiming it had the right to issue a license.
>
> Danny
>