[ntp:questions] Local (own site) NTP servers.
david at ex.djwhome.demon.co.uk.invalid
Thu Jul 23 23:31:50 UTC 2009
> Wonder if this will get posed, or returned to me..
As far as I know, Google groups rejects synchronously. A direct NNTP
client certainly would.
> So... I'm about to try a couple of Windows "solutions"
> (opportunities) One the "Tardis" program, that would appear
Unless you are using an MS-DOS based Windows (ME was the last) I can see
no point whatsoever in using a shareware program with unknown internals
when the official version of NTP is available as open source! There is
no certainty about the internals of Tardis, but it is quite likely no
better than recent versions of w32time (when configured properly, rather
than out of the box) which has been supplied, bundled with NT based
versions of Windows, for many years. w32time doesn't support local
reference clocks, or PPS.
The prime designer of ntpd is a radio amateur.
> (& just why is it that about all 'nix documentation and help
> files, are written almost exclusively to obfuscate the needed
At least the information is there. Have you ever tried to navigate
MSDN: a maze of windy passages leading nowhere. In order to make
Windows appear easy, Microsoft make the scary stuff difficult or
impossible to find, even though it exists in copious amounts.
> Also the Meinberg NTP software (not looked at in detail yet)
> Both of them (independently while I play with them) will each
This is the same software as on FreeBSD, except that it doesn't work as
well, because of the limitations of Windows. All Meinberg did was
configure a Windows installer for it.
> live on a dedicated PC for now, but ultimately one or the
> other would need to co-exist on the same PC with the
> monitoring program (Faros) that needs the time stamps.
> Pointing it's NTP client routines at LocalHost? Low single
> figure mS jitter is OK, sub uS accuracy is just not needed.
Seriously stretches Windows. Actually using NTP to access the time on
the same machine removes the problem that the Windows clock cannot be
read that accurately, but you still have the problem that Windows
scheduling delays will introduce jitter of more than this in the
measurement of the external events that you are monitoring, and possibly
in the scheduling of the return to the application from the time server.
Normally people reckon in terms of low 10s of mss for Windows, although
there are claims of better performance, possibly on lightly loaded systems.
If you want really high precision timing of sound card input, you should
probably construct special hardware to inject the PPS signal into the
analogue input of the sound card.
> However, while involved in something else, this came to my
> Now, I realise the clock speed is not that quick by modern
> standards, but could that have enough "grunt" to work as a
> GPSDNTP server for a small low traffic LAN?..
> OK, I've managed (I think, as earlier) to get an older version
> of FreeBSD to run for this sort of thing (on a 500MHz P3
Seriously over-powered! You should be thinking something more like
> machine) But, just how cut down can it go, with just enough
> left to boot and do the NTP task, or is the Kernel BifferOS
The size of ntpd will be the main limit. With older versions of Linux,
and presumably FreeBSD, you can fit everything else onto one floppy.
Again, without ntpd, you would probably get away with 6MB of RAM. I'd
budget on more like 16MHz, unless you start building custom versions
against custom libc's.
> To get Faros (HF Beacon monitoring program, runs on Windows,
> only.) A GPSDNTP source, HF Receiver control app (my own
> code) and the resulting web based status page (or website
Be careful about the licencing for Windows; there are severe limits on
how many people can legally access a web server on a non-server edition
> Now, if Alex would integrate GPS timekeeping within Faros, all
> this would not be needed, but he has his own reasons it seems
> for not doing so. As a result, it needs a 24/7 'net
> connection, or access to some other NTP time source. My
> ISP's servers are somewhat less than reliable at times,
> likewise access to others due to unpredictable and huge WAN
> network latencies from time to time.
You are locked into the wrong platform, and you can't go the VM route,
as VM systems give very poor timing to the virtual machines.
Modern versions of ntpd require floating point, whereas 486SX doesn't
have it, so you will need software floating point. On the other hand,
it may well have plenty of excess processing speed to support that.
More information about the questions