help with setting up NTP on windows with a USB GPS
jack
I am trying to setup NTP on Windows XP with a USB GPS at "COM1". I can
verify that the GPS is outputing $GPRMC strings at 1Hz with some other
strings occasionally (eg at startup).
I installed the Meinberg NTP server and then overwrote ntpd.exe with
Dave Hart's executable. I disabled all internet servers and add the
following line:
# NMEA GPS driver
server 127.127.20.1 mode 1 prefer
NTP can see COM1 but it always reports an error. Below is the log from
the system event logger. The most important line is:
NTP Error None 1 N/A JACKXPS configuration of 127.127.20.1 failed
---------------------------------------------------------------------------------------------------------------------------------------
11/26/2009 11:31:43 AM NTP Information None 3 N/A JACKXPS synchronized
to LOCAL(0), stratum 10
11/26/2009 11:30:11 AM NTP Information None 3 N/A JACKXPS interp_time
thd 3ec mean -7.3285 spread 14.6574 msec
11/26/2009 11:30:11 AM NTP Information None 3 N/A JACKXPS interp_time
thd 58c mean -7.3304 spread 14.6573 msec
11/26/2009 11:28:30 AM NTP Error None 1 N/A JACKXPS configuration of
127.127.20.1 failed
11/26/2009 11:28:30 AM NTP Information None 3 N/A JACKXPS frequency
initialized 0.000 PPM from C:\Program Files\NTP\etc\ntp.drift
11/26/2009 11:28:30 AM NTP Information None 3 N/A JACKXPS Listening on
interface #2 IP Interface 2, 192.168.1.121#123 Enabled
11/26/2009 11:28:30 AM NTP Information None 3 N/A JACKXPS Listening on
interface #1 Loopback Interface 1, 127.0.0.1#123 Enabled
11/26/2009 11:28:30 AM NTP Information None 3 N/A JACKXPS Listening on
interface #0 wildcard, 0.0.0.0#123 Disabled
11/26/2009 11:28:30 AM NTP Information None 3 N/A JACKXPS precision =
0.500 usec
11/26/2009 11:28:28 AM NTP Information None 3 N/A JACKXPS HZ 64.000
using 43 msec timer 23.256 Hz 64 deep
11/26/2009 11:28:28 AM NTP Information None 3 N/A JACKXPS Wiring to
processor 2 (0 means all) affinity mask 2
11/26/2009 11:28:28 AM NTP Information None 3 N/A JACKXPS substituting
RDTSC for QueryPerformanceCounter() with 2400.040 MHz frequency
11/26/2009 11:28:28 AM NTP Information None 3 N/A JACKXPS System time
precision 15.625 msec, min. slew 6.400 ppm/s
11/26/2009 11:28:28 AM NTP Information None 3 N/A JACKXPS Clock
interrupt period 15.625 msec
11/26/2009 11:28:28 AM NTP Information None 3 N/A JACKXPS Performance
counter frequency 2400.040 MHz
11/26/2009 11:28:28 AM NTP Information None 3 N/A JACKXPS MM timer
resolution: 1..1000000 msec, set to 1 msec
11/26/2009 11:28:28 AM NTP Information None 3 N/A JACKXPS Raised to
realtime priority class
11/26/2009 11:28:28 AM NTP Information None 3 N/A JACKXPS ntpd
4.2.4p6@DLH-QPC-o Mar 15 21:30:20.47 (UTC) 2009 (239)
Please help. I've tried to read all documents available. The GPS I
have is from ublox and it can output 1PPS signal, which I instend to
use later with an RS232 port.
Thanks in advance.
jack
David J Taylor
"jack" <j.jac...@gmail.com> wrote in message
news:54ad71bf-d76a-47c1...@m38g2000yqd.googlegroups.com...
> Hi all,
>
> I am trying to setup NTP on Windows XP with a USB GPS at "COM1". I can
> verify that the GPS is outputing $GPRMC strings at 1Hz with some other
> strings occasionally (eg at startup).
>
> I installed the Meinberg NTP server and then overwrote ntpd.exe with
> Dave Hart's executable. I disabled all internet servers and add the
> following line:
> 11/26/2009 11:28:28 AM NTP Information None 3 N/A JACKXPS ntpd
> 4.2.4p6@DLH-QPC-o Mar 15 21:30:20.47 (UTC) 2009 (239)
> jack
Jack, are you sure 4.2.4 includes the serial support you need? I've been
using 4.2.5.
Cheers,
David
jack
I read instructions on your web site especially the section on USB GPS
receivers. Version 4.2.4 dated March 15 2009 is the latest on Dave
Hart's website. Why do you get 4.2.5 from?
jack
On Nov 26, 12:20 pm, "David J Taylor" <david-tay...@blueyonder.not-
this-bit.nor-this-part.co.uk.invalid> wrote:
> "jack" <j.jack.w...@gmail.com> wrote in message
jack
I switched to a machine with an RS232 port and also found version
4.2.5. NTP now opens port COM1 with no problem. However, status shows
that it doesn't seem to be reading from GPS since all values (jitter,
offset etc) are 0. Any suggestions?
Jack
David J Taylor
news:c9339bbd-a773-44dc...@31g2000vbf.googlegroups.com...
> David,
>
> I read instructions on your web site especially the section on USB GPS
> receivers. Version 4.2.4 dated March 15 2009 is the latest on Dave
> Hart's website. Why do you get 4.2.5 from?
>
> jack
Jack,
Sorry for any confustion. On this page:
http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html#usb
it says: "Tested with Dave Hart's: ntpd 4.2.5p161...". There are a
variety of 4.2.5 development versions here. I would normally go for the
most recent.
http://www.davehart.net/ntp/win/x86/
http://www.davehart.net/ntp/win/x86/ntp-4.2.5p246-RC-win-x86-bin.zip
My thanks to Dave for making these Windows versions available for testing.
Cheers,
David
David J Taylor
news:7a8980f8-5cbc-4100...@e27g2000yqd.googlegroups.com...
> David,
>
> I switched to a machine with an RS232 port and also found version
> 4.2.5. NTP now opens port COM1 with no problem. However, status shows
> that it doesn't seem to be reading from GPS since all values (jitter,
> offset etc) are 0. Any suggestions?
>
> Jack
I've only tested with a PPS line connected to the DCD port. Do you have
that? Is the reach value showing 0 as well? I can't recall now what baud
rate you need - 4800 by default, perhaps?
Cheers,
David
jack
I only have the following in the configure file:
server 127.127.20.1 minpoll 4 prefer
I found the following entry in the log file:
Using user-mode PPS timestamp
Does it mean NTP reads the GPS strings and sees the 1PPS signal?
All the values are still 0 including reach. At one point for about 10
minutes, I saw some values after rebooting the machine but they
disappeared quickly.
Thanks.
jack
ps: I am using the latest NTP from Dave Hart's website. I also
installed serialpps.sys.
On Nov 26, 2:52 pm, "David J Taylor" <david-tay...@blueyonder.not-this-
jack
11/26/2009 16:26:34 NTP None 3 n/a DUALCORE
Using user-mode PPS timestamp for GPS_NMEA(1)
11/26/2009 16:26:32 NTP None 3 n/a DUALCORE
GPS_NMEA(1) serial /dev/gps1 open at 4800 bps
11/26/2009 16:26:32 NTP None 3 n/a DUALCORE
Listen normally on 2 IPv4 2 192.168.1.105 UDP 123
11/26/2009 16:26:32 NTP None 3 n/a DUALCORE
Listen normally on 1 v4loop 1 127.0.0.1 UDP 123
11/26/2009 16:26:32 NTP None 3 n/a DUALCORE
Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
11/26/2009 16:26:32 NTP None 3 n/a DUALCORE
proto: precision = 0.400 usec
11/26/2009 16:26:30 NTP None 3 n/a DUALCORE
HZ 64.000 using 43 msec timer 23.256 Hz 64 deep
Windows clock precision 15.625 msec, min. slew 6.400 ppm/s
11/26/2009 16:26:30 NTP None 3 n/a DUALCORE
Clock interrupt period 15.625 msec
Performance counter frequency 2999.700 MHz
11/26/2009 16:26:30 NTP None 3 n/a DUALCORE
MM timer resolution: 1..1000000 msec, set to 1 msec
Raised to realtime priority class
ntpd 4.2.5p246-RC-o Nov 17 16:02:21.54 (UTC-00:00) 2009
(1)
Meinberg Monitor was stuck at "Please wait".
jack
David Woolley
>
> I am trying to setup NTP on Windows XP with a USB GPS at "COM1". I can
You are making life difficult. Without PPS, GPS has poor accuracy, and
potentially high jitter. USB adds a lot of extra jitter. Windows is
not the best platform for time keeping.
>
> I installed the Meinberg NTP server and then overwrote ntpd.exe with
Meinberg don't do an NTP server, they do a Windows installer for the
reference version of ntpd.
David Woolley
> Using user-mode PPS timestamp
>
> Does it mean NTP reads the GPS strings and sees the 1PPS signal?
It probably means you have configured PPS on Windows, as Windows doesn't
have kernel mode support for ntpd. I doubt that it implies that
anything is working.
>
>
Dave Hart
> I found the following entry in the log file:
> Using user-mode PPS timestamp
> Does it mean NTP reads the GPS strings and sees the 1PPS signal?
Pretty much, yes. That message occurs only upon reading a CR when a
DCD transition has been observed and its timestamp is used instead of
the end-of-line CR/LF timestamp. That "user-mode" PPS hack only works
if the GPS is configured to emit only one sentence per second, and it
allow you to get most of the benefit of PPS without requiring
serialpps.sys.
Since the topic mentions a USB GPS, unless the GPS is documented to
deliver PPS via its emulated serial's DCD, you may be seeing
meaningless DCD transitions rather than PPS.
You have serialpps.sys, so you might consider enabling PPSAPI use by
the NMEA refclock driver using
fudge 127.127.20.1 flag1 1
Good luck figuring out the problem that's keeping it unreachable.
Cheers,
Dave Hart
David J Taylor
news:hen3cv$nit$1...@news.eternal-september.org...
So in these days of energy economy would your solution be to install
another PC running a different OS (with all the associated extra learning)
just so that accuracy could be improved from scores of microseconds to
microseconds? Does jack need the greater accuracy? Using USB doesn't
mean you need to give up PPS - some serial-to-USB converters carry the DCD
line. Even with USB, even with Windows, fractions of milliseconds are
achieved as I show on my Web page.
Whilst I see what you mean, pedantically, Meinberg's installation of
ntpd.exe works just like any other NTP server, by the way.
Cheers,
David
David J Taylor
news:9db25657-9837-4ebe...@j35g2000vbl.googlegroups.com...
> David,
>
> I only have the following in the configure file:
>
> server 127.127.20.1 minpoll 4 prefer
>
> I found the following entry in the log file:
>
> Using user-mode PPS timestamp
>
> Does it mean NTP reads the GPS strings and sees the 1PPS signal?
>
> All the values are still 0 including reach. At one point for about 10
> minutes, I saw some values after rebooting the machine but they
> disappeared quickly.
>
> Thanks.
>
> jack
>
> ps: I am using the latest NTP from Dave Hart's website. I also
> installed serialpps.sys.
Jack,
As Dave Hart has answered you are talking to the expert in this area!
I had assumed in my first response that you had a GPS receiver with a
serial output connected to a serial-USB convertor, but I see now that this
may not be the case. How well the PPS output is emulated in the
USB-serial port software you will need to check. You need somehow to
"connect" the PPS output from the GPS to the virtual DCD line of the
emulated COM1 port. Not quite sure how you do that. What GPS and
software are you using
Cheers,
David
Martin Burnicki
> jack wrote:
[...]
>> I installed the Meinberg NTP server and then overwrote ntpd.exe with
>
> Meinberg don't do an NTP server, they do a Windows installer for the
> reference version of ntpd.
They do also NTP servers, see:
http://www.meinberg.de/english/products/#network_sync
Take care, I'm biased ;-))
Martin
--
Martin Burnicki
Meinberg Funkuhren
Bad Pyrmont
Germany
jack
You assumed right. I did start with a USB emulated port. The GPS I
bought is from U-Blox and it has both USB and serial output. The
serial output has the 1PPS signal (with an LED indicator). I thought I
would start with the USB output since it's rather hard to find a
computer with a serial port. Also I would like to see the accuracy by
using the USB port only. I later switched to a machine with a serial
port and started using the serial output of the U-Blox GPS device and
1PPS. My objective is to use two of these devices to sync two separate
computers to within ms so they can share time-sensitive data (time
stamped).
I left the device running overnight and I noticed it computed an
offset at one time. It's currently not updating (everything is zero
now). I will read carefully what Dave Hart said and follow his advice.
Thanks to everyone for your help.
Jack
On Nov 27, 1:51 am, "David J Taylor" <david-tay...@blueyonder.not-this-
jack
After reading Dave Hart's message, I realized that I didn't configure
the GPS device to only emit $GPRMC messages. After doing this, the NTP
software starts to function. So that's big progress for me.
Right now, I am using:
server 127.127.20.1 minpoll 4 prefer
server 127.127.22.1 minpoll 4
NTPStatus shows that it's syncing to PPS(1) although the offset and
jitter are still quite big (-3ms and 0.2ms respectively).
I tried the following combination but the offset actually increased.
server 127.127.20.1 minpoll 4 prefer
fudge 127.127.20.1 flag1 1
Right now I am trying to figure out how to switch to kernel mode. I
have
1) serialpps.sys
2) the correspond DLL
3) the environment variable that points to the DLL
I am unclear as to what should be done to switch to kernel mode.
Thanks to all for the help.
Jack
David Lord
>
> You assumed right. I did start with a USB emulated port. The GPS I
> bought is from U-Blox and it has both USB and serial output. The
> serial output has the 1PPS signal (with an LED indicator). I thought I
> would start with the USB output since it's rather hard to find a
> computer with a serial port. Also I would like to see the accuracy by
> using the USB port only. I later switched to a machine with a serial
> port and started using the serial output of the U-Blox GPS device and
> 1PPS. My objective is to use two of these devices to sync two separate
> computers to within ms so they can share time-sensitive data (time
> stamped).
>
> I left the device running overnight and I noticed it computed an
> offset at one time. It's currently not updating (everything is zero
> now). I will read carefully what Dave Hart said and follow his advice.
>
> Thanks to everyone for your help.
>
Mostly here with convenient location for the gps, with Garmin
gps18x-lvc I had a few failed updates where reach dropped from
377 (avg offset about 2us), whilst with GS-BR-304 there isn't
anywhere near as good reception and there were many periods
where reach was back to 0 (avg offset about 10ms).
Have you connected with hyperterm or similar to check the serial
gps output?
Possibly you aren't picking up enough sats to get a fix. In that
case you need to site the gps in a better location for reception,
and/or give the gps your exact geographic coordinates.
David
jack
offset is 0.02ms with jitter at 0.002ms. My other GPS with only USB
out has an offset of 5ms and jitter of 2.5ms.
Jack
David J Taylor
> offset is 0.02ms with jitter at 0.002ms. My other GPS with only USB
> out has an offset of 5ms and jitter of 2.5ms.
>
> Jack
Good news, Jack. For comparison, my own tests with a serial to USB
converter (Sitecom) which did include the DCD line (we think) I saw a
minimum averaged jitter of about 45 microseconds, whereas with a LAN
connection it had been 110-140 microseconds. A direct serial port
connection (yes, you /ca/n still get computers with them, but it's
becoming more difficult) showed minimum averaged jitter in the order of
2 - 3 microseconds (with Windows XP).
The kernel-mode PPS driver allowed a minimum averaged jitter of just over
3 microseconds to be reduced to a much steadier just over 2 microseconds,
but had almost no effect on the offset or frequency variation.
With Windows-7 and a direct serial GPS/PPS connection, the offset is far
less, but the minimum averaged jitter is around 25 microseconds (PC
Stamsund).
It looks like that you need a direct serial connection if you want the PCs
to be synced to within the millisecond. Perhaps much better to have
completely separate time stamp to which both PCs refer.
Cheers,
David
jack
Would you mind looking up the model number of the Sitecom serial to
USB converter that has the DCD line? I am very interested in a
solution like that.
Jack
On Nov 27, 2:11 pm, "David J Taylor" <david-tay...@blueyonder.not-this-
Unruh
>"David Woolley" <da...@ex.djwhome.demon.invalid> wrote in message
>news:hen3cv$nit$1...@news.eternal-september.org...
>> jack wrote:
>>>
>>> I am trying to setup NTP on Windows XP with a USB GPS at "COM1". I can
>>
>> You are making life difficult. Without PPS, GPS has poor accuracy, and
>> potentially high jitter. USB adds a lot of extra jitter. Windows is
>> not the best platform for time keeping.
>>
>>>
>>> I installed the Meinberg NTP server and then overwrote ntpd.exe with
>>
>> Meinberg don't do an NTP server, they do a Windows installer for the
>> reference version of ntpd.
>So in these days of energy economy would your solution be to install
So throw away all your computers. Then all of these problems disappear.
>another PC running a different OS (with all the associated extra learning)
>just so that accuracy could be improved from scores of microseconds to
I think you mean 10s of msec to 1s of microseconds. If you do not need
it, certainly using a separate computer would be overkill. If you need
it, then presumably you have to factor in the costs and figure out how
much you need it.
I would certainly NOT use USB for accuracy. I would certainly not use
Windows for accuracy.
On a windows system, using the net (Ie external servers ) might well be
just as good or better than a usb gps.
David J Taylor
news:484bcf3e-dde5-4978...@l35g2000vba.googlegroups.com...
> David,
>
> Would you mind looking up the model number of the Sitecom serial to
> USB converter that has the DCD line? I am very interested in a
> solution like that.
>
> Jack
Jack, the convertor I had was Sitecom DK01 USB dock from 2002. It's no
longer available new.
Cheers,
David
David J Taylor
"Unruh" <unruh...@physics.ubc.ca> wrote in message
news:e5_Pm.33822$cd7....@newsfe04.iad...
[]
> I think you mean 10s of msec to 1s of microseconds. If you do not need
> it, certainly using a separate computer would be overkill. If you need
> it, then presumably you have to factor in the costs and figure out how
> much you need it.
> I would certainly NOT use USB for accuracy. I would certainly not use
> Windows for accuracy.
> On a windows system, using the net (Ie external servers ) might well be
> just as good or better than a usb gps.
No, on Windows I measure reported offsets well under a fraction of a
millisecond for both Windows 2000 and Windows XP stratum-1 GPS/PPS
reference clocks, not tens of milliseconds you think it is. On my
LAN-synced clients I measure under two milliseconds offset. On my
GPS/PPS/USB tests I measured better than LAN-synced offsets.
My results are based on actual measurements. Where do your figures come
from?
David
RedGrittyBrick
Internal serial cards seem like an inexpensive way to add a serial port
for a GPS connection - do people use them for NTP?
e.g.
StarTech.com 1 port Native PCI Express RS232 Serial Adapter Card with
16550 UART - Serial adapter - PCI Express x1 - RS-232
Manufacturer Part : PEX1S552
Dell Part : A2309415
--
RGB
David J Taylor
> for a GPS connection - do people use them for NTP?
>
> e.g.
>
> StarTech.com 1 port Native PCI Express RS232 Serial Adapter Card with
> 16550 UART - Serial adapter - PCI Express x1 - RS-232
> Manufacturer Part : PEX1S552
> Dell Part : A2309415
Something like that sounds ideal, and somewhere like Dabs (UK) has a
variety of similar types:
Not as cheap as they once were, though.
Cheers,
David
jack
Thank you, David. You're very helpful!
I ran both my setups over the weekend. The GPS with 1PPS has the worst
offset of 200us and the GPS without jumped up to 80ms, clearly due to
loss of satellite signals. I am happy with the performance of the GPS
with 1PPS out.
RGB: I have a similar PCI-serial card in my computer. I will try my
GPS with this board and let you know the results.
Jack
jack
I tried the serial port on my B&B serial board and the 1PPS signal is
not detected. I don't how how serialpps.sys sees the signal and am
thinking the DCD signal is not sent over the PCI bus.
jack
David J Taylor
news:7cc021d3-4ca9-47b3...@h10g2000vbm.googlegroups.com...
[]
> Thank you, David. You're very helpful!
>
> I ran both my setups over the weekend. The GPS with 1PPS has the worst
> offset of 200us and the GPS without jumped up to 80ms, clearly due to
> loss of satellite signals. I am happy with the performance of the GPS
> with 1PPS out.
>
> RGB: I have a similar PCI-serial card in my computer. I will try my
> GPS with this board and let you know the results.
>
> Jack
The 80ms could have been due to all sorts of things, particularly with
Windows Vista or Windows-7 with certain peripherals, but with the Windows
XP you are running it should be reasonably free from odd effects.
Certainly, without PPS a pure serial GPS may be no better than using a LAN
server. My own XP/GPS/PPS system is usually well within 250us, as you can
see here:
http://www.satsignal.eu/mrtg/feenix_ntp_2.html
That's with a GPS on the roof of the house with a view of about half the
sky.
Cheers,
David
jack
NTP wouldn't start automatically. The system event log shows that NTP
service was started repeatedly (I configured it so it restarts after
initial failure) but it shuts down itself (message: NTP service is
stopping with no message wrt why). It would stop if I start it
manually. However, it will run if I open the serial port with
Hyperterminal and the close it without doing anything else). I am
very puzzled.
jack
David J Taylor
news:b15dd4f8-2611-4e3f...@f20g2000vbl.googlegroups.com...
> RGB:
>
> I tried the serial port on my B&B serial board and the 1PPS signal is
> not detected. I don't how how serialpps.sys sees the signal and am
> thinking the DCD signal is not sent over the PCI bus.
>
> jack
Jack,
Dave Hart is obviously the man who knows most about this, but my
understanding is that the DCD transition should create a hardware
interrupt, which then creates a software interrupt, which serialpp.sys
handles and notes the time of the transition, which the DLL/ntpd.exe can
later retrieve. Even without the special serialpps.sys and DLL, ntpd.exe
can note the time of the transition, only just not as accurately. We're
talking microsecond-level differences here.
I suspect that you may find an option to enable or disable DCD. You seem
to have other COM-port issues from your next post.
Cheers,
David
Dave Hart
> I tried the serial port on my B&B serial board and the 1PPS signal is
> not detected. I don't how how serialpps.sys sees the signal and am
> thinking the DCD signal is not sent over the PCI bus.
serialpps.sys is a very lightly modified serial.sys. DCD transitions
trigger an interrupt and the driver looks at the "modem status
register" bits from the UART to determine whether DCD is asserted or
not.
I doubt there's a custom driver involved, so serialpps.sys hijacking
serial.sys's role should be handling it. I suppose it's possible the
card doesn't wire the DCD pin through to the UART but I hope that's
unlikely.
Cheers,
Dave Hart
Dave Hart
> NTP wouldn't start automatically. The system event log shows that NTP
> service was started repeatedly (I configured it so it restarts after
> initial failure) but it shuts down itself (message: NTP service is
> stopping with no message wrt why). It would stop if I start it
> manually. However, it will run if I open the serial port with
> Hyperterminal and the close it without doing anything else). I am
> very puzzled.
If you download the debug ntpd.exe binary for the same version and
invoke it from a command prompt with trace logging cranked up, there's
a good chance the problem will be evident in the last lines of output:
ntpd -g -c \my\ntp.conf -M -D5
Cheers,
Dave Hart
jack
examining the status by ntpstatus, I can see that the GPS park works
but the PPS source was not updated (with jitter and offset all zero).
If I restart ntpd, everything works. Any idea? I will try to run the
debug version now.
State Remote Refid Stratum Type When Poll Reach Delay Offset Jitter
* 127.127.20.1 GPS 0 Local clock 4 16 377 0.000 -0.208 0.064
PPS(1) PPS 0 Local clock 11 64 0 0.000 0.000 0.000
In ntpd.conf, I have
server 127.127.20.1 minpoll 4 prefer
server 127.127.22.1 minpoll 4
GPS is attached to COM1.
jack
David Woolley
>
> I tried the serial port on my B&B serial board and the 1PPS signal is
> not detected. I don't how how serialpps.sys sees the signal and am
> thinking the DCD signal is not sent over the PCI bus.
It won't be sent, on any serial interface, but it will be readable.
All backplane single serial interfaces are going to use the standard PC
UART programming model.
Dave Baxter
tay...@blueyonder.not-this-bit.nor-this-part.co.uk.invalid says...
>
> "jack" <> wrote in message
> news:c9339bbd-a773-44dc...@31g2000vbf.googlegroups.com...
> > David,
> >
> > I read instructions on your web site especially the section on USB GPS
> > receivers. Version 4.2.4 dated March 15 2009 is the latest on Dave
> > Hart's website. Why do you get 4.2.5 from?
> >
> > jack
>
> Jack,
>
> Sorry for any confustion. On this page:
>
> http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html#usb
>
> it says: "Tested with Dave Hart's: ntpd 4.2.5p161...". There are a
> variety of 4.2.5 development versions here. I would normally go for the
> most recent.
>
> http://www.davehart.net/ntp/win/x86/
>
> http://www.davehart.net/ntp/win/x86/ntp-4.2.5p246-RC-win-x86-bin.zip
>
> My thanks to Dave for making these Windows versions available for testing.
>
> Cheers,
> David
Hi.
I'm also trying to get this working, haveing failed miserably with the
FreeBSD system (it would never seem to respond to the GPS, and as I
don't know squat about 'BSD, decided to revert to Winders...)
Anyway, I have a working install of the Meinberg NTPD Windows port on
Win2k, and it is sync'ing OK to online servers, but they are the trouble
I'm trying to get round, due to variable and huge BT/ISP induced
latency, screwing arround with NTP during the weekday, that I use with
"Faros" a HF Radio propagation beacon monitor.
Long story short, I'm trying to put together a Stratum 1 time server for
my LAN only, maybe even on the same physical PC as Faros.
I had (killed it now) a version of the patched serial.sys for PPS
support, but it BSOD'd the machine at boot time (black screen) needing a
physical removal of the hard drive, and temporary fitment into another
PC to put the original file back.
At present, I can't find a ready-to-use binary of that file. Dave
Hart's site befuddles me, all I can see there is a *Huge* collection of
files, what file do I need and where from, exactly please.?
I have a Garmin GPS16LVC with PPS output. (Two of them, both work fine
AFAICS, with VisualGPS and a 'scope looking at the PPS signal, that
needed buffering to RS232 levels.)
Comments, hints?
Regards
Dave Baxter.
unruh
>
> David J Taylor wrote:
>> "jack" <> wrote in message
>> news:484bcf3e-dde5-4978...@l35g2000vba.googlegroups.com...
>>> David,
>>>
>>> Would you mind looking up the model number of the Sitecom serial to
>>> USB converter that has the DCD line? I am very interested in a
>>> solution like that.
>>>
>>> Jack
>>
>> Jack, the convertor I had was Sitecom DK01 USB dock from 2002. It's no
>> longer available new.
>
> Internal serial cards seem like an inexpensive way to add a serial port
> for a GPS connection - do people use them for NTP?
That is fine if your system is a desktop which can take internal cards
But laptops for example do not.
Richard B. Gilbert
> On 2009-11-30, RedGrittyBrick <RedGrit...@spamweary.invalid> wrote:
>> David J Taylor wrote:
>>> "jack" <> wrote in message
>>> news:484bcf3e-dde5-4978...@l35g2000vba.googlegroups.com...
>>>> David,
>>>>
>>>> Would you mind looking up the model number of the Sitecom serial to
>>>> USB converter that has the DCD line? I am very interested in a
>>>> solution like that.
>>>>
>>>> Jack
>>> Jack, the convertor I had was Sitecom DK01 USB dock from 2002. It's no
>>> longer available new.
>> Internal serial cards seem like an inexpensive way to add a serial port
>> for a GPS connection - do people use them for NTP?
>
> That is fine if your system is a desktop which can take internal cards
> But laptops for example do not.
>
Some laptops can take plug-in cards that offer Ethernet or RS-232C:
U.S. Robotics/Dell Model XJ4338 is a 33.6 baud modem.
Dell Ethernet Card 10BASE-T/100Base-2
D-Link DFE-670TXD 10/100 Base-T
I've not used them myself; my laptop came equipped with Ethernet and
RS232-C. If I ever buy another laptop, I will be sure that it has both
Ethernet and RS232-C interfaces.
David J Taylor
"Dave Baxter" <g8...@uko2.co.uk> wrote in message
news:MPG.257e52281...@news.demon.co.uk...
[]
> Hi.
>
> I'm also trying to get this working, haveing failed miserably with the
> FreeBSD system (it would never seem to respond to the GPS, and as I
> don't know squat about 'BSD, decided to revert to Winders...)
On reason for me writing my Web page was that I felt a similar level of
ignorance about FreeBSD, so I hoped it would help. However, I believe
some of the port names and perhaps other things have changed in later
versions of FreeBSD, so if what I wrote doesn't help, then neither can I.
Windows is getting sub-millisecond for me.
> Anyway, I have a working install of the Meinberg NTPD Windows port on
> Win2k, and it is sync'ing OK to online servers, but they are the trouble
> I'm trying to get round, due to variable and huge BT/ISP induced
> latency, screwing arround with NTP during the weekday, that I use with
> "Faros" a HF Radio propagation beacon monitor.
>
> Long story short, I'm trying to put together a Stratum 1 time server for
> my LAN only, maybe even on the same physical PC as Faros.
>
> I had (killed it now) a version of the patched serial.sys for PPS
> support, but it BSOD'd the machine at boot time (black screen) needing a
> physical removal of the hard drive, and temporary fitment into another
> PC to put the original file back.
>
> At present, I can't find a ready-to-use binary of that file. Dave
> Hart's site befuddles me, all I can see there is a *Huge* collection of
> files, what file do I need and where from, exactly please.?
>
> I have a Garmin GPS16LVC with PPS output. (Two of them, both work fine
> AFAICS, with VisualGPS and a 'scope looking at the PPS signal, that
> needed buffering to RS232 levels.)
>
> Comments, hints?
>
> Regards
> Dave Baxter.
Dave,
You don't need the serialpps.sys except for the ultimate in performance.
Having said that, it's working here on Windows 2000, Windows XP, and
Windows-7, and I would be rather surprised if it didn't work on Windows
Vista as well. Dave Hart would probably appreciate more details of the
BSOD failure.
Having installed the most recent Meinberg NTP (Copenhagen), copy the files
from this archive:
http://www.davehart.net/ntp/win/x86/
http://www.davehart.net/ntp/win/x86/ntp-4.2.5p246-RC-win-x86-bin.zip
on top of the Meinberg-installed files. Dave is very helpful in providing
the recent development builds of NTP, and in case some error is
introduced, he leaves working versions. The version I suggested is one I
am using so I know it's OK. In each release there is a normal build, a
build with extra debugging information, and the file containing the
symbols for each build in case you want to debug the programs by stepping
through a line at a time - "normal" users would not need to do this.
On my own system, I found that the PPS line worked directly to RS232
without any buffering, indeed I have a GPS 18 LVC feeding two RS232 ports
in parallel. My newer GPS 18x LVC feeds just one RS232 port directly.
Cheers,
David
Dave Hart
> I had (killed it now) a version of the patched serial.sys for PPS
> support, but it BSOD'd the machine at boot time (black screen) needing a
> physical removal of the hard drive, and temporary fitment into another
> PC to put the original file back.
I'm sorry to hear that. I note that to me, BSOD/bluescreen means
something distinct from hanging with a black/blank screen. The former
implies a "bugcheck", akin to a kernel panic.
I managed to develop the two revisions of serialpps.sys without
experiencing any bluescreens. In fact, it was about as painless as I
could have hoped for, but then I haven't actually tried any of the 64-
bit builds. Given the tiny changes between serial.sys and
serialpps.sys, and the fact that the code to implement the new "ioctl"
interface is cloned from several other examples in serial.sys,
combined with experience from a number of other users, I will be
surprised if there turns out to be a bug unique to serialpps.sys
involved here.
> At present, I can't find a ready-to-use binary of that file. Dave
> Hart's site befuddles me, all I can see there is a *Huge* collection of
> files, what file do I need and where from, exactly please.?
To have full PPSAPI capability with ntpd on Windows you need
serialpps.sys, serialpps-ppsapi-provider.dll, and a recent-enough
ntpd.exe. You need a serial port which can be driven by the stock
serial.sys (which includes a huge variety including some simple
multiport designs). serialpps.sys must be "installed" (if you can
call it that, the file must be in place and pointed to by the
serial.sys image path registry entry). serialpps-ppsapi-provider.dll
must be accessible and pointed to by environment variable PPSAPI_DLLS
visible to ntpd.exe (typically set systemwide), such as
C:\>set
...
PPSAPI_DLLS=c:\serialpps\serialpps-ppsapi-provider.dll
...
You can find both serialpps.sys and serialpps-ppsapi-provider.dll in:
http://davehart.net/ntp/refclock/serialpps-20090606.zip
There are more releases of serialpps .zip files in that directory than
there are different versions of serialpps.sys within. The most recent
changes, adding serialpps-ppsapi-provider.dll, simply shuffled code
previously hard-wired into ntpd.exe off into a per-provider DLL, but
did not change the ioctl interface or serialpps.sys.
If you are able to bluescreen a system due to serialpps.sys and
believe it wouldn't have occurred with serial.sys, I am interested in
getting access to the associated memory dump to extract more details
about the failure using kanalyze, or in the output of same.
Cheers,
Dave Hart
Dave Baxter
tay...@blueyonder.not-this-bit.nor-this-part.co.uk.invalid says...
Hi David...
I'll put the BSOD details in another post, beneath David Harts post, to
keep the tree branches sane...
You did help me out a while back, by pointing me at the exact same
distribution of F'BSD as you used, I managed (at the third attempt) to
get it to install on a suiable PC (P3/766MHz, 512M Ram) and it in it's
original guise seemed happy. At least, all the things I tried sort of
worked as documented.
It took me two more attempts to get the kernel recompiled with PPS
support enabled (needing another full re-install in the process, though
I now know where the "backup" kernel file is if I do that again!)
My single biggest problem, and no disrespect to you or anyone else here,
is that (and I've done exactly the same with stuff I work with for other
lesser people) is one is "too close" to it all in many ways to get a
truly idiot proof (for that's what us newbies need :) ) install working
safely. (If at all in some instances!)
I think I now know what I did wrong with the serialpps.sys in Windows,
you'll probably laugh when you read it in my reply to the other Dave
(maybe we should all use the name Bruce instead?)
The version on the Meinberg windows port of NTPD I've used so far is:-
ntpd 4.24p7@copenhagen-o May 22 2009 If that helps (as shown in the
NTP monitor program)
I realy would preffer a stable version, rather than any bleading edge
versions, as the rest of the system can be left to it's own devices for
weeks if needed with no issues.
I think I need at least single figure mS stability and resolution, not
absolute uS accuracy, but better is sort of better I guess, I'll bow to
superior knowledge on that though.
There are at least two other Faros users (just thought of someone else)
so that's 4 that I know of, who would also like a fully self contained
system for this purpose (Faros) as they are not well connected to the
'net, with resulting NTP issues as a reuslt.
Have to say, my main problem with this, is that there are so many
versions of this and that, plus knowledge I'm still learning is needed
to make it fly.
Best Regards. Now to answer Dave Harts post.
Dave Baxter.
Dave Baxter
@g4g2000pri.googlegroups.com>, dave...@gmail.com says...
>
> On Nov 30 22:06ï¿œUTC, Dave Baxter wrote:
> > I had (killed it now) a version of the patched serial.sys for PPS
> > support, but it BSOD'd the machine at boot time (black screen) needing a
> > physical removal of the hard drive, and temporary fitment into another
> > PC to put the original file back.
>
> I'm sorry to hear that. I note that to me, BSOD/bluescreen means
> something distinct from hanging with a black/blank screen. The former
> implies a "bugcheck", akin to a kernel panic.
>
> I managed to develop the two revisions of serialpps.sys without
> experiencing any bluescreens. In fact, it was about as painless as I
> could have hoped for, but then I haven't actually tried any of the 64-
> bit builds. Given the tiny changes between serial.sys and
> serialpps.sys, and the fact that the code to implement the new "ioctl"
> interface is cloned from several other examples in serial.sys,
> combined with experience from a number of other users, I will be
> surprised if there turns out to be a bug unique to serialpps.sys
> involved here.
>
> > Hart's site befuddles me, all I can see there is a *Huge* collection of
> > files, what file do I need and where from, exactly please.?
>
> To have full PPSAPI capability with ntpd on Windows you need
> serialpps.sys, serialpps-ppsapi-provider.dll, and a recent-enough
> ntpd.exe. You need a serial port which can be driven by the stock
> serial.sys (which includes a huge variety including some simple
> multiport designs). serialpps.sys must be "installed" (if you can
> call it that, the file must be in place and pointed to by the
> serial.sys image path registry entry). serialpps-ppsapi-provider.dll
> must be accessible and pointed to by environment variable PPSAPI_DLLS
> visible to ntpd.exe (typically set systemwide), such as
>
> C:\>set
> ...
> PPSAPI_DLLS=c:\serialpps\serialpps-ppsapi-provider.dll
> ...
>
> You can find both serialpps.sys and serialpps-ppsapi-provider.dll in:
>
> http://davehart.net/ntp/refclock/serialpps-20090606.zip
>
> There are more releases of serialpps .zip files in that directory than
> there are different versions of serialpps.sys within. The most recent
> changes, adding serialpps-ppsapi-provider.dll, simply shuffled code
> previously hard-wired into ntpd.exe off into a per-provider DLL, but
> did not change the ioctl interface or serialpps.sys.
>
Hi David...
Well, my mistake, I had obviously missed a critical stage in the
serialpps deployment, as I just copied it over the original serial.sys
(as that name) not doing the registry thing!
The problem that caused, was a looping boot, BLACK screen, boot, black
screen etc etc, as soon as the GUI part of Windows tried to start.
This is (was) on Windows 2000 Pro, on a compaq small form deskpro
machine, with two "real" com ports, neither were connected to anything
at that time.. Absolutely zero chance of getting any memory dump, but
from your comments about registry settings etc "I got it wrong Dad!"
As earlier, I honnestly don't know why I missed that part of the setup.
Is there a blow by blow (with screenshots?) description as to how to put
all this together anywhere? David Taylor's site gets close, but I
suffer "informaion overload" after a while. (The Grey cell version of
a buffer overun I think!)
As my ultimate aim, would be to get this working on the same physical
system that run's Faros (trying to keep the electric bill in check!)
What colateral effects will the serialpps.sys driver have on the other
com port, as that will be used for controling the radio (data lines
only.) Also, what effect would it have on, or be affected by, the CPU
loading of the needed DSP routines that kick off once every few seconds.
Currently Faros lives on a P3/666MHz PC, pushing the CPU to about 30% at
times. I've been playing with a P3/1GHz machine for NTP. I could move
everything over to that, but I'd like to keep that box for some other
DSP intesive communications apps, unrelated to the propagation monitor.
Comments, suggestions welcome.
Regards. You can all stop laughing now!
Dave Baxter.
David J Taylor
news:MPG.257f313b...@news.demon.co.uk...
[]
> Is there a blow by blow (with screenshots?) description as to how to put
> all this together anywhere? David Taylor's site gets close, but I
> suffer "informaion overload" after a while. (The Grey cell version of
> a buffer overun I think!)
> Comments, suggestions welcome.
>
> Regards. You can all stop laughing now!
>
> Dave Baxter.
Dave,
I would not worry about adding the special serialpps.sys, at least not
initially. Why? If you take a look at the offset graph here:
http://www.satsignal.eu/ntp/2009-05-17-Feenix_offset.png
I would challenge you to see which "half" of it was with the kernel-mode
serialpps.sys and which was with the standard driver. Yes, it's more
obvious if you look at the jitter graph here:
http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html#PPSAPI_DLLS
but even then the averaged jitter only changes from just over three to
just over two microseconds - to me negligible in comparison with the ~150
microseconds of offset. Temperature appears to be the main enemy I'm
facing.
Just concentrate on getting the basic GPS/PPS working.
73,
David - GM8ARV
David J Taylor
[]
> Hi David...
>
> I'll put the BSOD details in another post, beneath David Harts post, to
> keep the tree branches sane...
>
> You did help me out a while back, by pointing me at the exact same
> distribution of F'BSD as you used, I managed (at the third attempt) to
> get it to install on a suiable PC (P3/766MHz, 512M Ram) and it in it's
> original guise seemed happy. At least, all the things I tried sort of
> worked as documented.
Ah, I remember now....
> It took me two more attempts to get the kernel recompiled with PPS
> support enabled (needing another full re-install in the process, though
> I now know where the "backup" kernel file is if I do that again!)
I was luckier.
> My single biggest problem, and no disrespect to you or anyone else here,
> is that (and I've done exactly the same with stuff I work with for other
> lesser people) is one is "too close" to it all in many ways to get a
> truly idiot proof (for that's what us newbies need :) ) install working
> safely. (If at all in some instances!)
I agree, and that's why I have a user-group for my own software and
encourage people to try beta versions. Having different people explain
things in different ways can often be helpful when you have a mental block
about something. I've tried to simplify things at the top of my Web page:
http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html
by adding a "for the impatient" paragraph - i.e. for those who don't or
can't RTFM! I'd welcome any input to try and improve that page for
"novices".
> I think I now know what I did wrong with the serialpps.sys in Windows,
> you'll probably laugh when you read it in my reply to the other Dave
> (maybe we should all use the name Bruce instead?)
You can save playing with that for another day, though,
> The version on the Meinberg windows port of NTPD I've used so far is:-
> ntpd 4.24p7@copenhagen-o May 22 2009 If that helps (as shown in the
> NTP monitor program)
>
> I realy would preffer a stable version, rather than any bleading edge
> versions, as the rest of the system can be left to it's own devices for
> weeks if needed with no issues.
I agree, but the "stable" branch doesn't yet include the PPS support, so
we're stuck with the "development" branch. Quite honestly, I would treat
most of the development branch as being of "production" quality. I had
one problem when it wouldn't work with Windows 2000 (now resolved, I
think, I'm using ntpd 4.2.5p231 on PC Bacchus), and one more subtle
problem where something didn't work as well after a reboot of a Windows-7
system. That's also now resolved.
> I think I need at least single figure mS stability and resolution, not
> absolute uS accuracy, but better is sort of better I guess, I'll bow to
> superior knowledge on that though.
>
> There are at least two other Faros users (just thought of someone else)
> so that's 4 that I know of, who would also like a fully self contained
> system for this purpose (Faros) as they are not well connected to the
> 'net, with resulting NTP issues as a reuslt.
>
> Have to say, my main problem with this, is that there are so many
> versions of this and that, plus knowledge I'm still learning is needed
> to make it fly.
>
> Best Regards. Now to answer Dave Harts post.
>
> Dave Baxter.
Keep asking the questions, even if they seem elementary - and I will try
to both provide answers and record them on my Web site for others. One
issue which you haven't addressed (as far as I know) is how the Faros
program uses an accurate time. I take it that the author of the program
gets the time from Windows - he does know that time is typically only
updated once every ten milliseconds, I guess? NTP doesn't have an API
which can tell you the time more accurately than that, which is a pity
because that would be very handy....
73,
David
Dave Hart
> What colateral effects will the serialpps.sys driver have on the other
> com port, as that will be used for controling the radio (data lines
> only.) Also, what effect would it have on, or be affected by, the CPU
> loading of the needed DSP routines that kick off once every few seconds.
The effect compared to using serial.sys is quite similar.
serialpps.sys adds a new "ioctl" which software other than ntpd won't
know about or use. Until the first time that ioctl is called by a
given process, serial.sys behaves identically. After the first call
to that ioctl, the interrupt handler for "modem status" line changes
(including DCD) squirrels away a system timestamp and cycle counter
value at each DCD clear->asserted transition, retrievable via the same
ioctl.
serialpps.sys timekeeping performance compared to the "user-mode PPS"
hack is relatively marginal under optimal circumstances, as David
Taylor has demonstrated. The more loaded the box, the more likely
serialpps.sys's interrupt-time timestamping of DCD will be
substantially more accurate than ntpd doing the same thing from user
mode.
Cheers,
Dave Hart
jack
I would like to add that, from my own experiences, the GPS has to be
configured to output $GPRMC sentences only. Otherwise the PPS part of
NTP doesn't work.
I have a related question: given that my system clock is synced to an
external GPS within ms, how do I read time that gives me the same
accuracy? When I tried to read time at 60Hz, I found that the times
returned are not periodic, sometimes even the same.
Jack
On Dec 1, 9:28 am, "David J Taylor" <david-tay...@blueyonder.not-this-
David J Taylor
news:72491452-f89d-454b...@j19g2000yqk.googlegroups.com...
> David,
>
> I would like to add that, from my own experiences, the GPS has to be
> configured to output $GPRMC sentences only. Otherwise the PPS part of
> NTP doesn't work.
Good point - added.
> I have a related question: given that my system clock is synced to an
> external GPS within ms, how do I read time that gives me the same
> accuracy? When I tried to read time at 60Hz, I found that the times
> returned are not periodic, sometimes even the same.
>
> Jack
That was my point about using Windows! By default, the clock only returns
new values at either 16ms or 10ms intervals - depending on the OS version.
You can enable the Multimedia timers which increase the clock frequency,
but I can't remember off-hand whether that increases the read-out
precision in /all/ versions of Windows, or just Vista and Windows-7. Use
the timeBeginPeriod and timeEndPeriod functions, but be aware that
switching these functions on and off can result in timekeeping transients,
so with NTP and pre-Vista systems it's best to use NTP to keep the MM
timer enabled.
http://msdn.microsoft.com/en-us/library/dd757624%28VS.85%29.aspx
http://msdn.microsoft.com/en-us/library/dd743611%28VS.85%29.aspx
This source looks interesting for XP, but old:
http://www.lochan.org/2005/keith-cl/useful/win32time.html
On my XP system, with the MM timer enabled, I see a resolution for a
timeGetTime call of just under a millisecond. I wrote a small program
here:
http://www.satsignal.eu/software/net.htm#PCClockTiming
Cheers,
David
jack
I looked at timeGetTime() and I found it only gives out relative time
(since Windows was started). Is it possible to query NTP server to get
an accurate starting time?
jack
On Dec 1, 1:15 pm, "David J Taylor" <david-tay...@blueyonder.not-this-
Dave Hart
> I have a related question: given that my system clock is synced to an
> external GPS within ms, how do I read time that gives me the same
> accuracy? When I tried to read time at 60Hz, I found that the times
> returned are not periodic, sometimes even the same.
Depending on the version of Windows, hardware, and the interface used
(GetSystemTime[AsFileTime] vs timeGetTime/GetTickCount) the best
resolution you can get for the clock is 0.5ms, the worst about
15.625ms. To do better you need to query ntpd using the NTP protocol
-- gin up a mode 3 (client) packet and send it to UDP 127.0.0.1 or ::1
port 123 and grab the time from the resulting mode 4 response. You
can look at the sntp source code (not yet ported to Windows) for a
guide.
Cheers,
Dave Hart
jack
Dave,
Thanks for the query suggestion. That is what I plan to do. I am now
looking at ntpq code. I plan to query ntpd periodically and use the
high performance counter to keep time in between. If the query time is
negligible, I should get very accurate time. However, I have no way of
calibrating the query time.
Jack
unruh
> On Dec 1, 5:11?pm, Dave Hart <daveh...@gmail.com> wrote:
>> On Dec 1 16:58?UTC, jack wrote:
>>
>> > I have a related question: given that my system clock is synced to an
>> > external GPS within ms, how do I read time that gives me the same
>> > accuracy? When I tried to read time at 60Hz, I found that the times
>> > returned are not periodic, sometimes even the same.
>>
>> Depending on the version of Windows, hardware, and the interface used
>> (GetSystemTime[AsFileTime] vs timeGetTime/GetTickCount) the best
>> resolution you can get for the clock is 0.5ms, the worst about
>> -- gin up a mode 3 (client) packet and send it to UDP 127.0.0.1 or ::1
>> can look at the sntp source code (not yet ported to Windows) for a
>> guide.
>>
>> Cheers,
>> Dave Hart
>
> Dave,
>
> Thanks for the query suggestion. That is what I plan to do. I am now
> looking at ntpq code. I plan to query ntpd periodically and use the
> high performance counter to keep time in between. If the query time is
> negligible, I should get very accurate time. However, I have no way of
> calibrating the query time.
ntp does that for you. It sends out the query with the local time. It
receives back the time that the system received the query and replied to
the query, and finally times when it gets the packet back. of course
with your situation it is really a bit irrelevant, since the problem is
that you then need to use that time in whatever program you want to use.
(ie, it is true that ntp does not and cannot figure out how much time
there is between your receiving the time and your using the time. )
>
> Jack
>
David J Taylor
>
> I looked at timeGetTime() and I found it only gives out relative time
> (since Windows was started). Is it possible to query NTP server to get
> an accurate starting time?
>
> jack
As Dave Hart says, you would need to do a network transfer to get the time
from NTP - that's a bit of a pain when it's running locally. A pity that
Dave's new DLL couldn't include a very simple get current time call! Hint
Dave! Call: GetNTPTime - returns a 64-bit value. However, a network
query should take less than a millisecond on the local PC, so you could
then use the timeGetTime function. The ambiguity is around 49 days, so it
shouldn't be an issue. The other much more accurate way /may/ be to use
QueryPerformanceCounter - a 64 bit counter running at either a few MHz or
even at CPU-speed. Yes, it would need calibrating, and you may also have
to deal with CPUs where the speed changes (also an issue for NTP), and
there may also be an ambiguity issue.
If you go the SNTP route, the packet you need is easy to construct, and
it's on page 7 here:
http://www.ietf.org/rfc/rfc2030.txt
It's what my Delphi SNTP monitor program uses, and has about a dozen
fields to complete.
http://www.satsignal.eu/software/net.htm#NTPmonitor
73,
David
jack
I got this going and everything is working well. However, comparing
NTP time to an IRIG board time with a GPS antenna, I see a difference
of 100ms. Not sure where this came from.
Jack
On Dec 2, 2:29 am, "David J Taylor" <david-tay...@blueyonder.not-this-
David J Taylor
>
> I got this going and everything is working well. However, comparing
> NTP time to an IRIG board time with a GPS antenna, I see a difference
> of 100ms. Not sure where this came from.
>
> Jack
Good question! What is the pulse-length of your GPS PPS, and to which
edge is NTP syncing? There's a setting in NTP you can tweak. I think
that mine is probably right as I see only a few milliseconds of offset
compared to Internet servers. I have the DCD line directly connected to
the output from the GPS 18 LVC with no inverter in the path.
Cheers,
David
Dave Baxter
tay...@blueyonder.not-this-bit.nor-this-part.co.uk.invalid says...
>
> Keep asking the questions, even if they seem elementary - and I will
> try to both provide answers and record them on my Web site for others.
> One issue which you haven't addressed (as far as I know) is how the
> Faros program uses an accurate time. I take it that the author of the
> program gets the time from Windows - he does know that time is
> typically only updated once every ten milliseconds, I guess?
> NTP doesn't have an API which can tell you the time more accurately
> than that, which is a pity because that would be very handy....
>
> 73,
> David
Hi..
Back after getting diverted by my central heating system going on the
blink...
Re Faros. Good question, well presented, unknown (exactly) at this
time!
It does run it's own internal software clock, that I do know having
asked Alex (VE3NEA) questions about it in the past. That in turn is
synched to a reference by NTP (not SNTP) it does not (AFIK) use
"Windows" time in any way.
(Sadly, he's totally uninterested in making it able to use a local GPS
receiver with PPS, or a radio time code RX.)
It's own internal timekeeping routines use a Kalman Filter (Think that's
what it's called) to determine "true" time from a number of NTP sources.
It is also quite "chatty" I expect compared to a true NTP client, as it
will poll the NTP server (or selected collection of servers in rotation)
about every 10 seconds! Another reason I think a local server would be
best :-)
Generally it keeps good time, to within a mS or so, as it can reliably
tell if a received signal comes the short or long way round the globe,
even from New Zealand! (A close call that one though.)
However, it (for whatever reason) is not good at handling variable
network latency, especially if the flight times to/from the server are
different, as seems to be the case at odd times of day at present.
With the Meinberg NTP server in the path now, doing the synchronization
to the outside world's NTP boxes (for now) things are a little better.
At least, it takes longer for the variable latency problem to screw
things up, but it also takes longer to recover too. Extra "filtering"
in the overall path I guess. (Software algorithms etc in the Meinberg
software.)
Anyway. After reading all the info here, I now think I know how to do
it correctly, setting up the Meinberg program, and overlaying Dave Harts
binaries on it, also doing the registry thing pointing at the PPS
supporting serial driver, so when I get enough of the right sort of time
next time, I'll try again.
One thing I picked up on, is the parameters in the NTP config file,
regarding poll times. The units of measure are not mS, but 2^n mS, I
think?
By the time I get my head round all this, we'll have probably lost HF to
PLT anyway.
Regards to All.
Dave Baxter.
David J Taylor
"Dave Baxter" <sp...@goes.nowhere.com> wrote in message
news:MPG.2581b3818...@news.btopenworld.com...
[]
Dave, quite a few points there!
Polling external NTP servers every ten seconds is /very/ unfriendly, and
some servers are likely to return the kiss-of-death to such a client, and
may also deliberately return you an incorrect time value. Using a short
poll against your own server on your own LAN is a different matter, of
course.
It sounds as if the best arrangement would be to have one PC as a
stratum-1 NTP server (and it could be Windows- or FreeBSD-based), and get
your Faros PC syncing to it. Having that server on your LAN should
greatly reduce the variable network latency. You shouldn't need any extra
filtering with a LAN poll time of 32 seconds (maxpoll 5).
I don't know Faros, but perhaps you could manage on a single PC by
selecting the NTP server for Faros as 127.0.0.1 - the localhost - and
having that same PC as a stratum-1 server from the GPS/PPS arrangement we
have discussed. This would provide a GPS or radio-clock time source, but
with some additional control and filtering.
Poll times in the ntpq -p display are in seconds, as are the "when" times.
You should see the "when" increasing by one per second until it reaches
(or just exceeds) the "poll" value.
73,
David
Dave Baxter
2g2000prl.googlegroups.com>, dave...@gmail.com says...
>
> On Dec 1, 13:58ï¿œUTC, Dave Baxter wrote:
> > What colateral effects will the serialpps.sys driver have on the other
> > com port, as that will be used for controling the radio (data lines
> > loading of the needed DSP routines that kick off once every few seconds.
>
> The effect compared to using serial.sys is quite similar.
> serialpps.sys adds a new "ioctl" which software other than ntpd won't
> know about or use. Until the first time that ioctl is called by a
> given process, serial.sys behaves identically. After the first call
> to that ioctl, the interrupt handler for "modem status" line changes
> (including DCD) squirrels away a system timestamp and cycle counter
> value at each DCD clear->asserted transition, retrievable via the same
> ioctl.
>
> serialpps.sys timekeeping performance compared to the "user-mode PPS"
> hack is relatively marginal under optimal circumstances, as David
> Taylor has demonstrated. The more loaded the box, the more likely
> serialpps.sys's interrupt-time timestamping of DCD will be
> substantially more accurate than ntpd doing the same thing from user
> mode.
>
> Cheers,
> Dave Hart
Hi Dave..
I tried last night to "install" your serialPPS driver, onto the Win2k
machine I have temporaraly made available to try all this.
Sadly, all I get are errors like...
"'reg' is not recognized as an internal or external command,
operable program or batch file."
So, I guess it's a delicate manual install for Windows then? XP has the
'reg' command, but 2000 does not.
Appologies if you've answered this in the past, but I can never seem to
go back in time, with these news reader systems, and Google Groups wont
let me in at the moment.
Dave Baxter.
Dave Baxter
david-...@blueyonder.not-this-bit.nor-this-part.co.uk.invalid says...
--- snip ---
Dave, quite a few points there!
Polling external NTP servers every ten seconds is /very/ unfriendly, and
some servers are likely to return the kiss-of-death to such a client,
and may also deliberately return you an incorrect time value. Using a
short poll against your own server on your own LAN is a different
matter, of course.
It sounds as if the best arrangement would be to have one PC as a
stratum-1 NTP server (and it could be Windows- or FreeBSD-based), and
get your Faros PC syncing to it. Having that server on your LAN should
greatly reduce the variable network latency. You shouldn't need any
extra filtering with a LAN poll time of 32 seconds (maxpoll 5).
I don't know Faros, but perhaps you could manage on a single PC by
selecting the NTP server for Faros as 127.0.0.1 - the localhost - and
having that same PC as a stratum-1 server from the GPS/PPS arrangement
we have discussed. This would provide a GPS or radio-clock time source,
but with some additional control and filtering.
Poll times in the ntpq -p display are in seconds, as are the "when"
times. You should see the "when" increasing by one per second until it
reaches (or just exceeds) the "poll" value.
73,
David
--- end snip ---
Hi...
First, thanks for the direct email, I'll look at things in detail again
this evening/over the weekend.
No Kiss of Death packets that I know of (not sure if Faros would know
what they are?) There are many many Faros users world wide by the way,
I do try and spread the poll's around a collection of servers, or maybe
that is why I'm getting extended latency problems from my ISP.. Their
protestations? I have called them about this (several times, at ￜ1.50
a minute!) "curry flavored muppets" is the best I can say about their so
called tec' support these days! They don't even know what NTP is, as
it's not on their user support script I guess.
Your sumizing above, is exactly what I'd like to do, idealy all on one
physical box if posible. But as elsewhere, I'm not haveing much success
stitching it all together on a box of its own at present. The latest
being that the 'Reg' command, usd by Dave Hart's serialpps install batch
file, does not exist on Win2k! (XP and later only I think.) Oh well.
I'm suffereing a stinking head cold too at present (or pig flu, who
knows, the medics dont!) So my attention span is somewhat shorter than
usual, due to lack of sleep.
Regards to all, and thanks for being tolerant.
Dave Baxter.
Dave Baxter
sp...@goes.nowhere.com says...
I've just found that reg.exe can be used on 2000, many people seem to
just have coppied it from XP to 2k. Will try that later. It is said
it's on the 2k install CD too, just you have to go find it yourself.
I just tried it here, and it seems to work OK, at least the query
function did.
Dave B.
Dave Hart
> I tried last night to "install" your serialPPS driver, onto the Win2k
> machine I have temporaraly made available to try all this.
>
> Sadly, all I get are errors like...
>
> "'reg' is not recognized as an internal or external command,
> operable program or batch file."
>
> So, I guess it's a delicate manual install for Windows then? XP has the
> 'reg' command, but 2000 does not.
I'm sorry to hear that. I couldn't find it as a resource kit download
for Windows 2000 either. However, there should be a serialpps.reg
file in the .zip you downloaded containing:
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
That is a long way of saying ImagePath=system32\drivers\serialpps.sys
and should accomplish the same thing as the reg command in the
installation batch file. Double-click on the .reg file and allow it
to be applied, reboot, and with any luck you'll be in business.
Cheers,
Dave Hart
Dave Baxter
2911fa...@b25g2000prb.googlegroups.com>, dave...@gmail.com says...
>
> On Dec 4, 9:57ï¿œUTC, Dave Baxter wrote:
> > I tried last night to "install" your serialPPS driver, onto the Win2k
> > machine I have temporaraly made available to try all this.
> >
> > Sadly, all I get are errors like...
> >
> > "'reg' is not recognized as an internal or external command,
> > operable program or batch file."
> >
> > 'reg' command, but 2000 does not.
>
> I'm sorry to hear that. I couldn't find it as a resource kit download
> for Windows 2000 either. However, there should be a serialpps.reg
> file in the .zip you downloaded containing:
>
> 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
>
> That is a long way of saying ImagePath=system32\drivers\serialpps.sys
> and should accomplish the same thing as the reg command in the
> installation batch file. Double-click on the .reg file and allow it
> to be applied, reboot, and with any luck you'll be in business.
>
> Cheers,
> Dave Hart
Hi again...
When I get home, I'll look at all this again. As elswhere, I've found
the XP "reg.exe" program seems to run on 2k anyway, so another way to do
the job.
Hopefully better news in a day or three. (Phones tend to ring, plans
change etc)
Cheers.
Dave Baxter.
David J Taylor
[]
> Hi...
>
> First, thanks for the direct email, I'll look at things in detail again
> this evening/over the weekend.
> Your sumizing above, is exactly what I'd like to do, idealy all on one
> physical box if posible. But as elsewhere, I'm not haveing much success
> stitching it all together on a box of its own at present. The latest
> being that the 'Reg' command, usd by Dave Hart's serialpps install batch
> file, does not exist on Win2k! (XP and later only I think.) Oh well.
> Regards to all, and thanks for being tolerant.
>
> Dave Baxter.
Dave,
As I mentioned in the private e-mail, I suggest you don't bother with the
PPS DLL stuff until after everything else is working, because when I
tested it although you could see a noticeable improvement in the jitter
level as reported by NTP, the offsets seemed to be very similar with and
without the kernel-mode stuff. See:
http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html#PPSAPI_DLLS
I accept that if the system was more heavily loaded the results might be
different, though.
Hope the head cold soon clears!
73,
David
David Lord
Not windows but on NetBSD with a good radioclock MSF signal via
serial port I was a little better with pps, but when moved to
location where signal isn't so good, with pps is a lot worse than
without. Currently I'm trying mindist 0.003 without pps and that
seems to be a slight improvement, but temperature changes, or
lack of, might be involved. When MSF Tx is down on 10th, or next
network outage, I'll swap back to using pps and hope the mindist
change will result in keeping to pps rather than periodic swap
between pps and radioclock source (from logs it looks as if 3ms
is way more than enough whilst 1ms was just on edge).
DL
unruh
> In article <YQPRm.11377$Ym4....@text.news.virginmedia.com>,
> david-...@blueyonder.not-this-bit.nor-this-part.co.uk.invalid says...
>
> Your sumizing above, is exactly what I'd like to do, idealy all on one
> physical box if posible. But as elsewhere, I'm not haveing much success
> stitching it all together on a box of its own at present. The latest
> being that the 'Reg' command, usd by Dave Hart's serialpps install batch
> file, does not exist on Win2k! (XP and later only I think.) Oh well.
Please, do not use a Windows box as your main server. get a cheap ( your
local flea market should have one for $50) computer, install linux or
freebsd, purely for running ntp on it, and use it as your server.
Richard B. Gilbert
Elderly computers can frequently be found at curbside. Often, there is
nothing wrong with them, they are just old and/or slow. NTP does not
require a lot of computing power!! If these old wrecks will boot some
form of Windows or Linux they are well suited to not very demanding jobs
like running NTPD.
David J Taylor
news:slrnhhilur...@wormhole.physics.ubc.ca...
[]
> Please, do not use a Windows box as your main server. get a cheap ( your
> local flea market should have one for $50) computer, install linux or
> freebsd, purely for running ntp on it, and use it as your server.
Bill,
The requirement is to provide time within a millisecond or so for a
program running on a Windows PC. It makes much more sense to have that
same PC work as its own NTP server using a GPS/PPS source, purely from a
performance point of view.
Providing an extra PC with a network connection, would result in poorer
performance for the task in hand, together with all the overheads of
learning a different OS and the time that would take, plus all the energy
costs of running that extra PC!
Yes, you can get better absolute performance from a FreeBSD box, but in
this case that performance is not needed, could not be communicated to the
application which needs the time, and would provide a quite unnecessary
overhead. Linux/FreeBSD provides a /worse/ solution in this case.
I tire of the anti-Windows mantra which sometimes appears in this group,
particularly when it occurs with no consideration for the task in hand. A
good solution will not be over-engineered nor require two PCs where one
would do.
David
Richard B. Gilbert
Well, the anti-Windows mantra is a hangover from ten or twelve years
ago! Ten or twelve years ago, Windows earned that hangover. It's much
better these days. I haven't installed Vista yet but W/2K and W/XP were
good solid systems. W/2K had a good many vulnerabilities to Viri and
worms but if you kept up-to-date with your Windows patches it was OK.
I've been running W/XP for several years now and it runs like a watch!
jack
I totally agree with you. My main application runs on Windows for
various reasons (cheap hardware for one) and had been using PCI IRIG
board to keep time. I was not merely looking for a solution to keep
time. I was looking for a millisecond solution that my application can
access on a Windows box.
PS: I experimented with falling/rising edge of the 1PPS and now the
difference between NTP and my IRIG board is a few milliseconds.
Jack
David J Taylor
news:edbf7025-8578-48f5...@c34g2000yqn.googlegroups.com...
> David,
>
> I totally agree with you. My main application runs on Windows for
> various reasons (cheap hardware for one) and had been using PCI IRIG
> board to keep time. I was not merely looking for a solution to keep
> time. I was looking for a millisecond solution that my application can
> access on a Windows box.
>
> PS: I experimented with falling/rising edge of the 1PPS and now the
> difference between NTP and my IRIG board is a few milliseconds.
>
> Jack
Glad you resolved the leading/trailing edge issue, Jack. Now we need a
way to tune out those remaining few microseconds accurately!
It sounds as if your application - like some of mine - would benefit if
NTP were able to provide a new function where you could call it on your
local PC to get the time, rather than having to use a call via a network
packet, with all those overheads. The function would be really simple,
taking no arguments:
ntpGetTime
and returning a 64-bit timestamp value (as per
http://www.ietf.org/rfc/rfc2030.txt).
Would some kind soul like Dave Hart care to provide a small DLL which
could do this - perhaps even as part of his serial kernel-mode PPS support
DLL?
Perhaps there is some fundamental point I'm missing which makes this
difficult, though?
Cheers,
David
Rob
> I've not used them myself; my laptop came equipped with Ethernet and
> RS232-C. If I ever buy another laptop, I will be sure that it has both
> Ethernet and RS232-C interfaces.
Then I would not postpone buying that new laptop for too long...
Evandro Menezes
wrote:
>
> unruh wrote:
>
> > Please, do not use a Windows box as your main server. get a cheap ( your
> > local flea market should have one for $50) computer, install linux or
> > freebsd, purely for running ntp on it, and use it as your server.
>
> Elderly computers can frequently be found at curbside. Often, there is
> nothing wrong with them, they are just old and/or slow. NTP does not
> require a lot of computing power!! If these old wrecks will boot some
> form of Windows or Linux they are well suited to not very demanding jobs
> like running NTPD.
No engineer or analyst or consultant worth its salt would suggest a
banged up PC to perform any role in a project.
Such suggestion may be fine for one's own garage project, but not
anywhere else.
Dave Hart
> It sounds as if your application - like some of mine - would benefit if
> NTP were able to provide a new function where you could call it on your
> local PC to get the time, rather than having to use a call via a network
> packet, with all those overheads. The function would be really simple,
> taking no arguments:
>
> ntpGetTime
>
>
> Would some kind soul like Dave Hart care to provide a small DLL which
> could do this - perhaps even as part of his serial kernel-mode PPS support
> DLL?
>
> Perhaps there is some fundamental point I'm missing which makes this
> difficult, though?
I am guessing you're actually in a better position than me to provide
a DLL exposing a function to get the time from ntpd. There is no way
other than a NTP packet to request a timestamp from ntpd.
Additionally, if ntpd is busy, it may take some time for ntpd to send
its response. You'll get a very good idea of the time when you
receive the response, but not necessarily of the time you requested
the time. Since waiting on ntpd is involved, such a function could be
provided with a nonblocking option where the caller is given a socket
to select for readability while awaiting the response, and calls back
after its readable to retrieve the time.
Cheers,
Dave Hart
unruh
> On Dec 4, 2:10?pm, "Richard B. Gilbert" <rgilber...@comcast.net>
> wrote:
>>
>> unruh wrote:
>>
>> > Please, do not use a Windows box as your main server. get a cheap ( your
>> > local flea market should have one for $50) computer, install linux or
>> > freebsd, purely for running ntp on it, and use it as your server.
>>
>> nothing wrong with them, they are just old and/or slow. ?NTP does not
>> require a lot of computing power!! ?If these old wrecks will boot some
>> form of Windows or Linux they are well suited to not very demanding jobs
>> like running NTPD.
>
> No engineer or analyst or consultant worth its salt would suggest a
> banged up PC to perform any role in a project.
Especially if he were getting a kickback on the purchase.
The point is that any old desktop PC has pleanty of power to act as a
time server. Nothing special is needed. Now some people think that the
onlyway they can get "reliability " is to buy a new machine. good on
them. I hope they have the budget to match. Others make do. It is a well
established engineering tradition, with at least 1000 years backing it
up.
John Hasler
> No engineer or analyst or consultant worth its salt would suggest a
> banged up PC to perform any role in a project.
Bill Unruh writes:
> Especially if he were getting a kickback on the purchase
If I tell a client that he should install a used machine and it fails he
will blame me. If I tell him to buy a new one and it fails he will
blame the vendor (or more likely, if I recommend a used machine he will
buy a new one anyway and then never hire me again since he "knows" that
no one competent would ever recommend the use of a "banged up pc" for
anything serious). The fact that the used machine would work fine is
irrelevant.
--
John Hasler
jha...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA
Richard B. Gilbert
If you have money to waste on appearances, fine! Were I running a
business, I would be pleased by someone with the initiative to recycle
an otherwise useless machine instead of buying a new one. Just open the
case, vacuum out the dust bunnies and go!
If I were setting something up for a customer, I would recommend using
an older machine. If the customer wanted to pay for a new machine I
would be happy to spend his money.
My NTP server is an old, old, Sun Ultra 10 workstation (I'm guessing)
ca. 1998. It gets the job done. If there were any 486/33 processors
left, one of those fifteen or twenty year old machines could do a very
good job of running NTPD.
nemo_outis
news:873a3pv...@thumper.dhh.gt.org:
I am a professional engineer with 43 years of experience, 26 of them in
independent consulting practice.
I well understand the engineering concept of "fit for purpose." An
older, less powerful machine may be entirely appropriate for a
particular use (e.g., as an ntp server).
Nor am I so unethical that I give higher priority to covering my ass
than providing diligent advice and service to my clients.
Overkill is bad engineering and bad ethics.
Regards,
Dave Hart
> My NTP server is an old, old, Sun Ultra 10 workstation (I'm guessing)
> ca. 1998. It gets the job done. If there were any 486/33 processors
> left, one of those fifteen or twenty year old machines could do a very
> good job of running NTPD.
For the purposes of ntpd, the older the hardware the better in many
ways. As performance keeps being goosed out of various nooks and
crannies of hardware and software underneath ntpd, consistency is
often lost in favor of throughput.
o Older processors and associated chipsets were simpler designs with
extremely predictable and repeatable performance. Everything in the
x86 space doing hyperthreading or multiple cores has lost in terms of
repeatable timing.
o As is often mentioned, gigabit ethernet has much higher jitter out
of the box, and due to switches, even with tuning, as compared to
10/100.
o Traditional RS-232 serial ports not connected via USB are becoming
rare, making it more difficult to find a suitable PPS hardware
interface.
o When it comes to Windows, Vista and later essentially disable
ntpd's Windows-only interpolation hack by increasing the system clock
precision from 2^-6 to 2^-10 or 2^-11. With the scheduler running at
millisecond (~= 2^-10) granularity, ntpd simply can't sample the clock
and cycle counter fast enough to interpolate. This means ntpd's
precision drops from around 2^-20 to 2^-10 or 2^-11, or microsecond to
millisecond. Finding hardware that supports XP/2003 and older gets
more difficult every day. The situation is probably better on servers
where use of timeBeginPeriod by _any_ application can be avoided,
leaving the system clock precision around 10-15ms. I haven't tested
servers newer than 2003 to know for sure.
In short, ntpd likes speed, but it likes consistency even more.
Cheers,
Dave Hart
John Hasler
> ...Everything in the x86 space...
So don't use x86.
David J Taylor
news:2c2ad514-3566-4a8f...@m7g2000prd.googlegroups.com...
[]
> I am guessing you're actually in a better position than me to provide
> a DLL exposing a function to get the time from ntpd. There is no way
> other than a NTP packet to request a timestamp from ntpd.
> Additionally, if ntpd is busy, it may take some time for ntpd to send
> its response. You'll get a very good idea of the time when you
> receive the response, but not necessarily of the time you requested
> the time. Since waiting on ntpd is involved, such a function could be
> provided with a nonblocking option where the caller is given a socket
> to select for readability while awaiting the response, and calls back
> after its readable to retrieve the time.
>
> Cheers,
> Dave Hart
Dave, thanks for that. I must be missing something here, although I
haven't been able to check the source code. Is there not a routine
somewhere inside ntpd.exe which timestamps the packets in response to a
request over the network? How else are the packets timestamped? Could
not that routine be exposed, or the variables it uses? Yes, I can write a
DLL (in Delphi/Pascal) it I could get access to the data and algorithms,
but it seems to me far easier to re-use the existing NTPD code.
I must confess to not having looked at NTP packets from Windows servers
for a while - don't tell me they have 10-15ms resolution!
Cheers,
David
David J Taylor
news:Xns9CD8AC807...@69.16.185.250...
[]
> Overkill is bad engineering and bad ethics.
>
> Regards,
Suggesting that there is no need to install an extra Linux machine if
Windows can keep time well enough for the job in hand.
Cheers,
David
Dave Hart
> "Dave Hart" <daveh...@gmail.com> wrote
> > I am guessing you're actually in a better position than me to provide
> > a DLL exposing a function to get the time from ntpd. There is no way
> > other than a NTP packet to request a timestamp from ntpd.
>
> haven't been able to check the source code. Is there not a routine
> somewhere inside ntpd.exe which timestamps the packets in response to a
> request over the network? How else are the packets timestamped? Could
> not that routine be exposed, or the variables it uses?
If we wanted to define a new Windows-only service provided by ntpd,
sure, there could be some combination of shared memory and IPC objects
like named events used to expose a way for another program to ask ntpd
to go down its timestamping path and provide the result. There's no
need on non-Windows systems where the system clock is high precision
and typically interpolated. Such a mechanism would be a potential
local DoS avenue again unique to Windows, which while popular in
general, isn't the center of the NTP universe.
The reason I suggested you are in a better position than me to provide
that capability is you've already written code that runs on Windows
and retrives the time via a NTP request/reply pair of packets. Wire
it to [::1]:123 and/or 127.0.0.1:123 and there's your ntpGetTime().
Cheers,
Dave Hart
David J Taylor
news:b51e46f7-4b0d-4d40...@s21g2000prm.googlegroups.com...
[]
> If we wanted to define a new Windows-only service provided by ntpd,
> sure, there could be some combination of shared memory and IPC objects
> like named events used to expose a way for another program to ask ntpd
> to go down its timestamping path and provide the result. There's no
> need on non-Windows systems where the system clock is high precision
> and typically interpolated. Such a mechanism would be a potential
> local DoS avenue again unique to Windows, which while popular in
> general, isn't the center of the NTP universe.
>
> The reason I suggested you are in a better position than me to provide
> that capability is you've already written code that runs on Windows
> and retrives the time via a NTP request/reply pair of packets. Wire
> it to [::1]:123 and/or 127.0.0.1:123 and there's your ntpGetTime().
>
> Cheers,
> Dave Hart
Thanks, Dave. I suppose I was hoping that with a simple compile switch
you might be able to provide ntpd.dll as well as nptd.exe, with the DLL
exposing just one function. I don't believe that using shared memory is
complex on Windows (i.e. between the DLL and the EXE) but it's something
I've never done.
If someone needs the network version and they ask nicely, I could look at
that.
I wonder how the overheads would compare if the SNMP interface could
expose a current time function? Mind you, I have seen SNMP problems with
more than 32-bit numbers!
Cheers,
David
David Woolley
> If I tell a client that he should install a used machine and it fails he
> will blame me. If I tell him to buy a new one and it fails he will
> blame the vendor (or more likely, if I recommend a used machine he will
> buy a new one anyway and then never hire me again since he "knows" that
> no one competent would ever recommend the use of a "banged up pc" for
> anything serious). The fact that the used machine would work fine is
> irrelevant.
And thus the world spirals to global warming and depletion of natural
resources.
On the other hand, all the organisations I have worked for have a long
winded capital expenditure approval process, so requiring a new machine
can kill or seriously delay a project. The likelihood is that the
service gets put on a highly loaded existing Windows box, rather than on
a new dedicated and appropriate system.
(Global warming is a complex issue. I was mainly thinking of
manufacturing carbon costs. However ntpd works best when most power
management functions are disabled.)
Dave Baxter
un...@wormhole.physics.ubc.ca says...
Hi.
As others have said, the time spent learning the new OS is somewhat
counter productive when one has a task to do, be it for a hobby, or job.
Otherwise, having played a little with F'BSD, I can see where you are
coming from.
Regards
Dave Baxter
Dave Baxter
@h10g2000vbm.googlegroups.com>, eva...@mailinator.com says...
>
> On Dec 4, 2:10ï¿œpm, "Richard B. Gilbert" <rgilber...@comcast.net>
> wrote:
> >
> > unruh wrote:
> >
> > > Please, do not use a Windows box as your main server. get a cheap ( your
> > > local flea market should have one for $50) computer, install linux or
> > > freebsd, purely for running ntp on it, and use it as your server.
> >
> > nothing wrong with them, they are just old and/or slow. ï¿œNTP does not
> > require a lot of computing power!! ï¿œIf these old wrecks will boot some
> > form of Windows or Linux they are well suited to not very demanding jobs
> > like running NTPD.
>
> No engineer or analyst or consultant worth its salt would suggest a
> banged up PC to perform any role in a project.
>
> Such suggestion may be fine for one's own garage project, but not
> anywhere else.
Hi..
Not long ago, on my journey home from work, along some dark country
lanes, I had to swerve to avoid some "Junk" in the middle of the road.
I stopped, went back to chuck it in the hedgerow, but saw sense and
decided to take it to the tip later that weekend instead. It was the
remains (carcase, PSU and CDROM drive!) from what I suspect was an old
486 class PC. Total trash...
As often happens, I had a little time to spare, and ended up salvaging
the CD-ROM drive! Though the thing looked like it had been run over
several times, the drive itself works fine! It now has a new life in
my garage playing audio CD's through an old set of powered PC speakers!
;-)
Otherwise I agree, using old "thrown out" hardware can lead you to
trouble. But, as I found, some of the "Old" hardware can be suprisingly
rugged!
Cheers.
Dave Baxter.
nemo_outis
part.co.uk.invalid> wrote in news:pzISm.12393$Ym4.11362
@text.news.virginmedia.com:
> "nemo_outis" <a...@xyz.com> wrote in message
> news:Xns9CD8AC807...@69.16.185.250...
> []
>> Overkill is bad engineering and bad ethics.
>
> Suggesting that there is no need to install an extra Linux machine if
> Windows can keep time well enough for the job in hand.
"IF" your aunt had wheels she'd be a trolleycar (and there are coarser
variants on the theme).
However, whether Windows can keep time well enough for the job in hand is,
in fact, disputed by several. Using petitio principii as a springboard for
jumping to further conclusions is itself less than elegant engineering :-)
Regards,
David J Taylor
[]
> However, whether Windows can keep time well enough for the job in hand
> is,
> in fact, disputed by several. Using petitio principii as a springboard
> for
> jumping to further conclusions is itself less than elegant engineering
> :-)
>
> Regards,
Stated requirement:
- around 1 millisecond (on Window 2000 or XP IIRC).
Observed performance examples:
Windows 2000:
http://www.satsignal.eu/mrtg/bacchus_ntp-b.html
Windows XP:
http://www.satsignal.eu/mrtg/feenix_ntp_2.html
Windows-7:
http://www.satsignal.eu/mrtg/stamsund_ntp_2.html
Now, let's see the evidence against.
Cheers,
David
David Woolley
> Stated requirement:
>
> - around 1 millisecond (on Window 2000 or XP IIRC).
>
> Observed performance examples:
These don't tell you the jitter due to the scheduling of the application
program and interrupt latencies from the real world events to the point
where the code tries to read the time.
David J Taylor
news:hfgvt5$g6f$1...@news.eternal-september.org...
Of course the application has to be well-designed and use appropriate
interactions with the OS - that goes without saying. NTP can measure
better than a millisecond on Windows. As the application is an existing
Windows one, the OS is fixed, and the challenge is then to provide the
best timekeeping within the imposed constraints.
Cheers,
David
Dave Baxter
From: Dave Baxter <g8...@nospam.uko2.co.uk>
In article <5_9Sm.11792$Ym4....@text.news.virginmedia.com>, david-
tay...@blueyonder.not-this-bit.nor-this-part.co.uk.invalid says...
>
> "Dave Baxter" <sp...@goes.nowhere.com> wrote in message
> news:MPG.2582f2d76...@news.btopenworld.com...
> []
> > Hi...
> >
> > First, thanks for the direct email, I'll look at things in detail again
> > this evening/over the weekend.
> []
> > Your sumizing above, is exactly what I'd like to do, idealy all on one
> > physical box if posible. But as elsewhere, I'm not haveing much success
> > stitching it all together on a box of its own at present. The latest
> > being that the 'Reg' command, usd by Dave Hart's serialpps install batch
> > file, does not exist on Win2k! (XP and later only I think.) Oh well.
> []
> > Regards to all, and thanks for being tolerant.
> >
> > Dave Baxter.
>
> Dave,
>
> As I mentioned in the private e-mail, I suggest you don't bother with the
> PPS DLL stuff until after everything else is working, because when I
> tested it although you could see a noticeable improvement in the jitter
> level as reported by NTP, the offsets seemed to be very similar with and
> without the kernel-mode stuff. See:
>
> http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html#PPSAPI_DLLS
>
> I accept that if the system was more heavily loaded the results might be
> different, though.
>
> Hope the head cold soon clears!
>
> 73,
> David
Hi again.
Well, after spending a lot if time reading (while sniffing) again, and
restarting from zero (again!) I seem to have the Meinberg Windows port
of NTPD etc working as a local Stratum 3 server on my LAN. From that
you will note I have not yet got the GPS hooked up, but I have installed
all Dave Hart's code to (hopefully) enable PPS support when I get to do
that.
I've also made a note to configure the GPS to only output the GPRMC
sentence, shame, as I was hoping to share the other info with some other
app's, via VSPE (by Eterlogic) or GPS-Gate (by Franson.) I have other
GPS RX's though, so no real problem, they dont use much energy.
I have also pointed Faros to this new local NTP server, and the server
is the only "thing" that now "goes out" and gets it's synch from the
'net (uk ntp pool) So my public "NTP Footprint" has hopefully srunk
somewhat.
Faros seems very happy too, so a good result just getting this far.
At the moment, all the NTP server stuff is on a seperate (more or less
dedicated to NTP, running Win2k) machine to the one running Faros, but
as my experience with all this improves, I will eventualy put it all on
one physical machine.
My ISP have done yet another huge re-arangement with their network, but
at present what effect that will have on the 'net based NTP service I
don't know, but whatever, I'm well on the road now to becoming NTP "self
sufficent" as it were.
Many thanks to all here for their advice and support with all this.
Very much appreciated I can tell you!
I will probably be back when I get the GPS RX sorted an reconnected.
Thanks again so far.
Best Regards to All.
David J Taylor
[]
> Hi again.
>
> Well, after spending a lot if time reading (while sniffing) again, and
> restarting from zero (again!) I seem to have the Meinberg Windows port
> of NTPD etc working as a local Stratum 3 server on my LAN. From that
> you will note I have not yet got the GPS hooked up, but I have installed
> all Dave Hart's code to (hopefully) enable PPS support when I get to do
> that.
> Many thanks to all here for their advice and support with all this.
> Very much appreciated I can tell you!
>
> I will probably be back when I get the GPS RX sorted an reconnected.
>
> Thanks again so far.
>
> Best Regards to All.
Good to hear of progress, Dave and thanks for your reports. If you see
something missing or wrong on my Web site, or something you feel might be
better explained, just shout.
Good luck!
73,
David
Danny Mayer
> On Dec 6, 6:50 UTC, "David J Taylor" wrote:
>> "Dave Hart" <daveh...@gmail.com> wrote
>>> I am guessing you're actually in a better position than me to provide
>>> a DLL exposing a function to get the time from ntpd. There is no way
>>> other than a NTP packet to request a timestamp from ntpd.
>> Dave, thanks for that. I must be missing something here, although I
>> haven't been able to check the source code. Is there not a routine
>> somewhere inside ntpd.exe which timestamps the packets in response to a
>> request over the network? How else are the packets timestamped? Could
>> not that routine be exposed, or the variables it uses?
>
> sure, there could be some combination of shared memory and IPC objects
> like named events used to expose a way for another program to ask ntpd
> to go down its timestamping path and provide the result. There's no
> need on non-Windows systems where the system clock is high precision
> and typically interpolated. Such a mechanism would be a potential
> local DoS avenue again unique to Windows, which while popular in
> general, isn't the center of the NTP universe.
>
> The reason I suggested you are in a better position than me to provide
> that capability is you've already written code that runs on Windows
> and retrives the time via a NTP request/reply pair of packets. Wire
> it to [::1]:123 and/or 127.0.0.1:123 and there's your ntpGetTime().
>
Why on earth would you do this? Just copy the get_systime() function and
be done:
get_systime(&arrival_time);
It's in systime.c.
Danny
P.S. [::1]:123 is not a valid IPv6 address. The IPv6 address is ::1. The
normal way to write the above is ::1#123.
Danny
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Maze
> Hi all,
>
> After reading Dave Hart's message, I realized that I didn't configure
> the GPS device to only emit $GPRMC messages. After doing this, the NTP
> software starts to function. So that's big progress for me.
>
> Right now, I am using:
>
> server 127.127.20.1 minpoll 4 prefer
> server 127.127.22.1 minpoll 4
>
> NTPStatus shows that it's syncing to PPS(1) although the offset and
> jitter are still quite big (-3ms and 0.2ms respectively).
>
> I tried the following combination but the offset actually increased.
> server 127.127.20.1 minpoll 4 prefer
> fudge 127.127.20.1 flag1 1
>
> Right now I am trying to figure out how to switch to kernel mode. I
> have
> 1) serialpps.sys
> 2) the correspond DLL
> 3) the environment variable that points to the DLL
> I am unclear as to what should be done to switch to kernel mode.
>
> Thanks to all for the help.
>
> Jack
>
> On Nov 27, 9:12 am, jack <j.jack.w...@gmail.com> wrote:
> > David,
> >
> > You assumed right. I did start with a USB emulated port. The GPS I
> > bought is from U-Blox and it has both USB and serial output. The
> > serial output has the 1PPS signal (with an LED indicator). I thought I
> > would start with the USB output since it's rather hard to find a
> > computer with a serial port. Also I would like to see the accuracy by
> > using the USB port only. I later switched to a machine with a serial
> > port and started using the serial output of the U-Blox GPS device and
> > 1PPS. My objective is to use two of these devices to sync two separate
> > computers to within ms so they can share time-sensitive data (time
> > stamped).
> >
> > I left the device running overnight and I noticed it computed an
> > offset at one time. It's currently not updating (everything is zero
> > now). I will read carefully what Dave Hart said and follow his advice.
> >
> > Thanks to everyone for your help.
> >
> > Jack
> >
> > On Nov 27, 1:51 am, "David J Taylor" <david-tay...@blueyonder.not-this-
> >
> >
> > bit.nor-this-part.co.uk.invalid> wrote:
> > > "jack" <> wrote in message
> >
> >
> > > > David,
> >
> > > > I only have the following in the configure file:
> >
> > > > server 127.127.20.1 minpoll 4 prefer
> >
> > > > I found the following entry in the log file:
> >
> > > > Using user-mode PPS timestamp
> >
> > > > Does it mean NTP reads the GPS strings and sees the 1PPS signal?
> >
> > > > All the values are still 0 including reach. At one point for about 10
> > > > minutes, I saw some values after rebooting the machine but they
> > > > disappeared quickly.
> >
> > > > Thanks.
> >
> > > > jack
> >
> > > > ps: I am using the latest NTP from Dave Hart's website. I also
> > > > installed serialpps.sys.
> >
> > > Jack,
> >
> > > As Dave Hart has answered you are talking to the expert in this area!
> >
> > > I had assumed in my first response that you had a GPS receiver with a
> > > serial output connected to a serial-USB convertor, but I see now that this
> > > may not be the case. How well the PPS output is emulated in the
> > > USB-serial port software you will need to check. You need somehow to
> > > "connect" the PPS output from the GPS to the virtual DCD line of the
> > > emulated COM1 port. Not quite sure how you do that. What GPS and
> > > software are you using
> >
> > > Cheers,
> > > David
Dear Jack.
I am doing the same as you do with ubloc evaluation kit(neo-m8t). but i still have problem. I see in u-center that there are lots of ubx messages which I'm not sure whether make any problem in ntp or not. i configured ublox chip to just send $GPRMC among NMEA messages but i couldn't disable sending ubx messages.
i am in a hurry .could you please help me make this working??
Thanks.
Maze
Jakob Bohm
abilities of traditional serial port circuits (a 16550 or equivalent
chip connected to the main CPU bus like in the serial adapters for the
original 1981 IBM PC).
This is because the standard for USB-to-RS-232 is all about transferring
the data over an essentially "polled" USB 1.1/2.0 bus that polls once
per ms, with the conversion chip buffering stuff until the next
available 1ms USB frame. This is sufficient for talking to stuff like
modems and machine control serial ports.
Wiring GPS PPS signals to the modem control line inputs on a serial port
was a trick to get access to the near-instantaneous CPU interrupt line
that was indirectly wired to those lines on the old IBM PC serial ports.
To transfer precision time over USB would be much better done by a
special specification where the USB device reports when the PPS instant
happened relative to the USB frame pulses from the computer, such as a
special NMEA message stating "Time was 2019-07-30 01:35:36.12345678 at
the USB frame marker right before the first char of this message was
sent on the USB BUS", combined with a USB driver extension reporting the
exact computer HPET time of the frame containing a "serial" character
bundle. An NTP driver for USB could then tell the ntp daemon that
"time was 2019-07-30 01:35:36.12345678 at local time 2019-07-30
01:25:36.12345876" . Each of these messages would of cause be encoded
in protocol-appropriate ways.
As a transitional solution for such a technique, one could use an
enhanced USB-to-RS-232 adapter including a timestamp in its reporting of
"modem-control" inputs, such as "CD line went high 2.3456ms before the
start of this USB frame" (because it happened 0.3456ms before a frame,
but 2 frames were busy). An appropriate USB protocol format would be a
20 bit count of 48MHz USB "full speed" typical USB interface clocks
between the reported event and the leading edge SOF of the frame
containing the report, internally an adapter can do this with a 16 bit
hardware timer and software adding 48000 for each frame of additional
delay. A host-side driver could combine this with the USB frame number
reported by the USB host controller to get time relative to the USB host
controllers clocking, and an extensions to the USB controller driver
could report the local clock time of every 1000th USB frame as a
queryable statistic.
Incorporating these things into a variation of the USB Communications
Class protocol and drivers is left as an exercise for the maker
community, for example some MicroChip inc microcontrollers have the
hardware to implement the proposed timestamping.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
Chris
with the wide range of usb to serial devices on the market, none of
which were designed for this class of precision work and none of which
are likely have specified delays.
Seems to me a better plan would be to find a gps module or receiver
with a serial interface and interface to that. New GPS modules are cheap
as chips on Ebay and elsewhere and so are s/h gps boxes, so why make
life difficult ?...
Chris
Jakob Bohm
on many currently available computers. This tendency to remove the
hardware interfaces historically used to feed PPS signals to commonly
available computers began way back in the 1990s where a powerful OS
vendor actively began encouraging this change.
Hence my suggestions for how the time synchronization community could
(belatedly) adapt to the absence of those interfaces and seek ways to
get the precise time data into such "legacy-free" computers.
Now, there are still computers with input pins that can efficiently
convey a traditional PPS signal to ntp software, but they are no longer
the general majority of fast commodity computers.
Chris
>
> The problem that many people face is the absence of actual serial ports
> on many currently available computers. This tendency to remove the
> hardware interfaces historically used to feed PPS signals to commonly
> available computers began way back in the 1990s where a powerful OS
> vendor actively began encouraging this change.
>
> Hence my suggestions for how the time synchronization community could
> (belatedly) adapt to the absence of those interfaces and seek ways to
> get the precise time data into such "legacy-free" computers.
>
> Now, there are still computers with input pins that can efficiently
> convey a traditional PPS signal to ntp software, but they are no longer
> the general majority of fast commodity computers.
>
>
> Enjoy
>
> Jakob
that ?. Not expensive either, especially if s/hand.
USB never was designed for real time work and trying to use it for
such is always going to be hard work and a compromise...
Chris