[time-nuts] Accurate timestamping on computers (previously: For mywhole life timezones have been weird)
kuzetsa at gmail.com
Sat Nov 3 05:49:50 EDT 2012
On 11/3/2012 9:18 AM, David J Taylor wrote:
> -----Original Message----- From: Sarah White
> Seeing as I'm in the process of installing a hardware refclock (trimble
> thunderbolt connected via serial port) for my NTP, it is highly
> problematic and potentially error-prone for microsoft's OS to touch the
> bios hardware clock AT ALL.
> I'm entertaining the notion of writing a kernel-mode hardware timestamp
> / PPSAPI driver to pull the signal off the 1 PPS port on the tbolt one
> way or another.
> I plan to do this on windows. This is something I want to attempt even
> though the NT kernel doesn't have the best reputation for realtime
> hardware / interrupt handling. Plan is to put in a non-zero amount of
> work, up to and including steps where I go through the driver signing
> run-around with microsoft to actually have it fully recognized by the OS
> without modification. (unless budget issues are a limiting factor)
> I don't know which version of Windows you are proposing to use, but I
> have NTP stratum-1 servers based on GPS devices with a PPS signal on the
> DCD line of the COM port, and Windows altering, or not altering, the
> hardware clock has /no effect/ at all. I'm using Dave Hart's
> serialPPS.sys device driver on Windows-2000 up to Windows-7/64
> (including telling Win-7/64 to ignore the signed 64-bit driver
> GPS hardware:
> Windows stratum-1 notes:
> I would note that for the best performance on a stratum-1 server you may
> want to try FreeBSD or even Linux on a Raspberry Pi.
> If Dave Hart's driver suits your needs, I'm sure he would be interested
> in getting it signed for Microsoft use (if he hasn't already done so).
Thanks so much David...
Really. Thanks. I feel alot better now.
Regardless of documented issues on:
(quote) The numerous past malfunctions of Microsoft operating systems
caused by keeping local time in the RTC and trying to cleverly perform
the RTC adjustment semi-automatically have been repeatedly the subject
of concerned public discussion: RISKS 16.54.1 RISKS 18.96.3 RISKS
19.11.16, RISKS 19.12.14 RISKS 19.43.13, RISKS 19.43.14, RISKS
22.34.3... (multiple links)
Not sure what timezone you're in...
... So I don't know which day your summer time ends this year. I'd love
to see the your loopstats file for as many of your windows boxes as
possible (with refclock, or without. Either is fine.) for the day of the
DST update this fall (and maybe any other loopstats data from when the
realtime clock got updated due to summer time / DST updates)
According to: http://www.satsignal.eu/mrtg/daily_ntp.html
(section: Hardware and OS configuration)
I'm assuming the relevant list is:
feenix, stamsund, bacchus, narvik, alta, molde, ystad, puffin, and any
other NT-5.x / NT 6.x based kernel (windows machines) I missed. Wow
that's a wonderfully diverse list :)
I actually thought about it a bit, and in hindsight I'm realizing that
internally, NTP uses a synthetic timebase anyway. Perhaps I was being
paranoid after all.
Thanks for the reply,
P.S. Your site has always had great documentation about NTP
configurations with a GPS-type reflock since I first saw it a couple
years ago. I've found it very useful.
More information about the time-nuts