[ntp:questions] help with setting up NTP on windows with a USB GPS

[jack]

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:

# 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 at 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.jack.wang at gmail.com> wrote in message

Post by jack
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

[]

Post by jack
11/26/2009 11:28:28 AM NTP Information None 3 N/A JACKXPS ntpd
4.2.4p6 at DLH-QPC-o Mar 15 21:30:20.47 (UTC) 2009 (239)

[]

Post by jack
jack

Jack, are you sure 4.2.4 includes the serial support you need? I've been
using 4.2.5.

Cheers,
David

[jack]

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

On Nov 26, 12:20?pm, "David J Taylor" <david-tay... at blueyonder.not-

"jack" <j.jack.w... at gmail.com> wrote in message

Post by jack
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

[]

Post by jack
11/26/2009 11:28:28 AM NTP Information None 3 N/A JACKXPS ntpd
4.2.4p6 at DLH-QPC-o Mar 15 21:30:20.47 (UTC) ?2009 ?(239)

[]

Post by jack
jack

Jack, are you sure 4.2.4 includes the serial support you need? ?I've been
using 4.2.5.
Cheers,
David

[jack]

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

Post by jack
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
On Nov 26, 12:20?pm, "David J Taylor" <david-tay... at blueyonder.not-

"jack" <j.jack.w... at gmail.com> wrote in message
news:54ad71bf-d76a-47c1-a0b7-df492d9edf9c at m38g2000yqd.googlegroups.com..

[David J Taylor]

"jack" <> wrote in message

Post by jack
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]

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.

On Nov 26, 2:52?pm, "David J Taylor" <david-tay... at blueyonder.not-this-

Post by David J Taylor
"jack" <> wrote in message

Post by jack
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]

Here is the entries in the log:
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
11/26/2009 16:26:30 NTP None 3 n/a DUALCORE
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
11/26/2009 16:26:30 NTP None 3 n/a DUALCORE
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
11/26/2009 16:26:30 NTP None 3 n/a DUALCORE
Raised to realtime priority class
11/26/2009 16:26:30 NTP None 3 n/a DUALCORE
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

Post by jack
David,
server 127.127.20.1 minpoll 4 prefer
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... at blueyonder.not-this-

Post by David J Taylor
"jack" <> wrote in message
news:7a8980f8-5cbc-4100-9d84-2d5e2a93c2de at e27g2000yqd.googlegroups.com..

[David Woolley]

Post by jack
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]

Post by jack
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]

"jack" <> wrote in message

Post by jack
David,
server 127.127.20.1 minpoll 4 prefer
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

[jack]

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... at blueyonder.not-this-

Post by David J Taylor
"jack" <> wrote in message

Post by jack
David,
server 127.127.20.1 minpoll 4 prefer
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

[jack]

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

Post by jack
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... at blueyonder.not-this-

Post by David J Taylor
"jack" <> wrote in message
news:9db25657-9837-4ebe-ab32-ce15ae968af8 at j35g2000vbl.googlegroups.com..

[David Lord]

Post by 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.

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]

Just to let everyone know that the u-blox GPS works well now. The
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

Post by David Lord

Post by 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.

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

[David J Taylor]

Post by jack
Just to let everyone know that the u-blox GPS works well now. The
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]

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

On Nov 27, 2:11?pm, "David J Taylor" <david-tay... at blueyonder.not-this-

Post by jack
Just to let everyone know that the u-blox GPS works well now. The
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

[David J Taylor]

"jack" <> wrote in message

Post by jack
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

[RedGrittyBrick]

Post by David J Taylor
"jack" <> wrote in message

Post by jack
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?

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

[David J Taylor]

Post by 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

Something like that sounds ideal, and somewhere like Dabs (UK) has a
variety of similar types:

http://www.dabs.com/category/components-and-storage,graphics--multimedia-and-i-o,input-output/11139-4294959977-48720000

Not as cheap as they once were, though.

Cheers,
David

[unruh]

Post by RedGrittyBrick

Post by David J Taylor
"jack" <> wrote in message

Post by jack
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.

Post by RedGrittyBrick
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

[Richard B. Gilbert]

Post by unruh

Post by RedGrittyBrick

Post by David J Taylor
"jack" <> wrote in message

Post by jack
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.

[Rob]

Post by Richard B. Gilbert
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...

[jack]

On Nov 28, 1:51?am, "David J Taylor" <david-tay... at blueyonder.not-this-

Post by David J Taylor
"jack" <> wrote in message

Post by jack
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

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]

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

Post by jack
On Nov 28, 1:51?am, "David J Taylor" <david-tay... at blueyonder.not-this-

Post by David J Taylor
"jack" <> wrote in message
news:484bcf3e-dde5-4978-966d-5637918c913f at l35g2000vba.googlegroups.com..

[jack]

New problem:

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

Post by 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

Post by jack
On Nov 28, 1:51?am, "David J Taylor" <david-tay... at blueyonder.not-this-

Post by David J Taylor
"jack" <> wrote in message

Post by jack
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

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

[Dave Hart]

Post by 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.

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]

I manged to start ntpd by delaying it at bootup. However, when
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

Post by Dave Hart

Post by 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.

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
ntpd -g -c \my\ntp.conf -M -D5
Cheers,
Dave Hart

[Dave Hart]

Post by 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.

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

[David J Taylor]

"jack" <> wrote in message

Post by 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

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

[David Woolley]

Post by 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.

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.

[David J Taylor]

"jack" <> wrote in message
news:7cc021d3-4ca9-47b3-8ab8-7aa00424389d at h10g2000vbm.googlegroups.com...
[]

Post by 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

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]

Here is the entries in the log:
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
11/26/2009 16:26:30 NTP None 3 n/a DUALCORE
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
11/26/2009 16:26:30 NTP None 3 n/a DUALCORE
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
11/26/2009 16:26:30 NTP None 3 n/a DUALCORE
Raised to realtime priority class
11/26/2009 16:26:30 NTP None 3 n/a DUALCORE
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

Post by jack
David,
server 127.127.20.1 minpoll 4 prefer
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... at blueyonder.not-this-

Post by David J Taylor
"jack" <> wrote in message
news:7a8980f8-5cbc-4100-9d84-2d5e2a93c2de at e27g2000yqd.googlegroups.com..

[David Woolley]

Post by jack
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]

Post by jack
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]

"jack" <> wrote in message

Post by jack
David,
server 127.127.20.1 minpoll 4 prefer
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

[David J Taylor]

"jack" <> wrote in message

Post by jack
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

[Dave Baxter]

In article <mZAPm.9055$Ym4.4115 at text.news.virginmedia.com>, david-
taylor at blueyonder.not-this-bit.nor-this-part.co.uk.invalid says...

Post by David J Taylor
"jack" <> wrote in message

Post by jack
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,
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.

[David J Taylor]

"Dave Baxter" <g8kbv at uko2.co.uk> wrote in message
news:MPG.257e5228127dac81989680 at news.demon.co.uk...
[]

Post by Dave Baxter
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.

Post by Dave Baxter
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 Baxter]

In article <t63Rm.10421$Ym4.6217 at text.news.virginmedia.com>, david-
taylor at blueyonder.not-this-bit.nor-this-part.co.uk.invalid says...

Post by David J Taylor
"Dave Baxter" <g8kbv at uko2.co.uk> wrote in message
[]

Post by Dave Baxter
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.

Post by Dave Baxter
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.

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 at 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.

[David J Taylor]

"Dave Baxter" <g8kbv at nospam.uko2.co.uk> wrote in message
news:MPG.257f2d55775bad5a989682 at news.demon.co.uk...
[]

Post by Dave Baxter
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....

Post by Dave Baxter
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.

Post by Dave Baxter
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".

Post by Dave Baxter
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,

Post by Dave Baxter
The version on the Meinberg windows port of NTPD I've used so far is:-
ntpd 4.24p7 at 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.

Post by Dave Baxter
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

[jack]

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.

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... at blueyonder.not-this-

"Dave Baxter" <g8... at nospam.uko2.co.uk> wrote in message
[]

Post by Dave Baxter
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....

Post by Dave Baxter
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.

Post by Dave Baxter
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
?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".

Post by Dave Baxter
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,

Post by Dave Baxter
The version on the Meinberg windows port of NTPD I've used so far is:-
ntpd 4.24p7 at 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.

Post by Dave Baxter
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

[David J Taylor]

"jack" <> wrote in message

Post by jack
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.

Post by jack
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]

David,

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... at blueyonder.not-this-

Post by David J Taylor
"jack" <> wrote in message

Post by jack
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.

Post by jack
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

[David J Taylor]

Post by jack
David,
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]

David,

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... at blueyonder.not-this-

Post by David J Taylor

Post by jack
David,
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
?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

[David J Taylor]

Post by jack
David,
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

[jack]

Post by jack
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

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]

Post by jack

Post by jack
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

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. )

Post by jack
Jack

[Dave Hart]

Post by jack
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

[Dave Baxter]

In article <2K9Rm.10560$Ym4.4851 at text.news.virginmedia.com>, david-
taylor at blueyonder.not-this-bit.nor-this-part.co.uk.invalid says...

Post by David J Taylor
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" <spam at goes.nowhere.com> wrote in message
news:MPG.2581b3818527b329989695 at news.btopenworld.com...
[]

Post by Dave Baxter
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.

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]

In article <YQPRm.11377$Ym4.1985 at text.news.virginmedia.com>,
david-taylor at 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.

[David J Taylor]

"Dave Baxter" <spam at goes.nowhere.com> wrote in message
news:MPG.2582f2d76a9bb78e989699 at news.btopenworld.com...
[]

Post by Dave Baxter
Hi...
First, thanks for the direct email, I'll look at things in detail again
this evening/over the weekend.

[]

Post by Dave Baxter
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.

[]

Post by Dave Baxter
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]

Post by David J Taylor
"Dave Baxter" <spam at goes.nowhere.com> wrote in message
[]

Post by Dave Baxter
Hi...
First, thanks for the direct email, I'll look at things in detail again
this evening/over the weekend.

[]

Post by Dave Baxter
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.

[]

Post by Dave Baxter
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
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.

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

Post by David J Taylor
Hope the head cold soon clears!
73,
David

[unruh]

Post by Dave Baxter
In article <YQPRm.11377$Ym4.1985 at text.news.virginmedia.com>,
david-taylor at blueyonder.not-this-bit.nor-this-part.co.uk.invalid says...

....

Post by Dave Baxter
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]

Post by unruh

Post by Dave Baxter
In article <YQPRm.11377$Ym4.1985 at text.news.virginmedia.com>,
david-taylor at blueyonder.not-this-bit.nor-this-part.co.uk.invalid says...

....

Post by Dave Baxter
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.

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.

[Evandro Menezes]

On Dec 4, 2:10?pm, "Richard B. Gilbert" <rgilber... at comcast.net>

Post by unruh
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.

[unruh]

Post by Evandro Menezes
On Dec 4, 2:10?pm, "Richard B. Gilbert" <rgilber... at comcast.net>

Post by unruh
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.

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.

Post by Evandro Menezes
Such suggestion may be fine for one's own garage project, but not
anywhere else.

[John Hasler]

Post by Evandro Menezes
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

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.

[nemo_outis]

John Hasler <jhasler at newsguy.com> wrote in

Post by John Hasler

Post by Evandro Menezes
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

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.

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,

[David J Taylor]

"nemo_outis" <abc at xyz.com> wrote in message
news:Xns9CD8AC8074753pqwertyu at 69.16.185.250...
[]

Post by nemo_outis
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

[nemo_outis]

"David J Taylor" <david-taylor at blueyonder.not-this-bit.nor-this-
part.co.uk.invalid> wrote in news:pzISm.12393$Ym4.11362

Post by David J Taylor
"nemo_outis" <abc at xyz.com> wrote in message
[]

Post by nemo_outis
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]

"nemo_outis" <abc at xyz.com> wrote in message
news:Xns9CD96997339D9pqwertyu at 69.16.185.247...
[]

Post by nemo_outis
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]

Post by David J Taylor
- around 1 millisecond (on Window 2000 or XP IIRC).

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]

"David Woolley" <david at ex.djwhome.demon.invalid> wrote in message

Post by David Woolley

Post by David J Taylor
- around 1 millisecond (on Window 2000 or XP IIRC).

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.

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

[David Woolley]

Post by John Hasler
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.)

[Richard B. Gilbert]

On Dec 4, 2:10 pm, "Richard B. Gilbert" <rgilber... at comcast.net>

Post by Richard B. Gilbert

Post by unruh
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.

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.

[Dave Hart]

Post by Richard B. Gilbert
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.

[Dave Baxter]

In article <ab949720-16c4-4032-9266-8bdc88c636b9
@h10g2000vbm.googlegroups.com>, evandro at mailinator.com says...

Post by Evandro Menezes
On Dec 4, 2:10?pm, "Richard B. Gilbert" <rgilber... at comcast.net>

Post by unruh
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.

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.

[David J Taylor]

"unruh" <unruh at wormhole.physics.ubc.ca> wrote in message
news:slrnhhilur.scb.unruh at wormhole.physics.ubc.ca...
[]

Post by unruh
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]

Post by David J Taylor
"unruh" <unruh at wormhole.physics.ubc.ca> wrote in message
[]

Post by unruh
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

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]

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

Post by David J Taylor
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

[David J Taylor]

"jack" <> wrote in message

Post by jack
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

[Dave Hart]

Post by David J Taylor
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,
? ntpGetTime
and returning a 64-bit timestamp value (as perhttp://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?

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

[David J Taylor]

"Dave Hart" <davehart at gmail.com> wrote in message
news:2c2ad514-3566-4a8f-a5eb-fa62c737ac73 at m7g2000prd.googlegroups.com...
[]

Post by Dave Hart
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

[Dave Hart]

Post by Dave Hart
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? ?

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]

"Dave Hart" <> wrote in message
news:b51e46f7-4b0d-4d40-a6b2-574d459ba7bd at s21g2000prm.googlegroups.com...
[]

Post by Dave Hart
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

[Danny Mayer]

Post by Dave Hart

Post by David J Taylor

Post by Dave Hart
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?

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().

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

[Dave Baxter]

In article <slrnhhilur.scb.unruh at wormhole.physics.ubc.ca>,
unruh at wormhole.physics.ubc.ca says...

Post by unruh

Post by Dave Baxter
In article <YQPRm.11377$Ym4.1985 at text.news.virginmedia.com>,
david-taylor at blueyonder.not-this-bit.nor-this-part.co.uk.invalid says...

....

Post by Dave Baxter
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.

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]

Subject: Re: help with setting up NTP on windows with a USB GPS
From: Dave Baxter <g8kbv at nospam.uko2.co.uk>

In article <5_9Sm.11792$Ym4.5933 at text.news.virginmedia.com>, david-
taylor at blueyonder.not-this-bit.nor-this-part.co.uk.invalid says...

Post by David J Taylor
"Dave Baxter" <spam at goes.nowhere.com> wrote in message
[]

Post by Dave Baxter
Hi...
First, thanks for the direct email, I'll look at things in detail again
this evening/over the weekend.

[]

Post by Dave Baxter
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.

[]

Post by Dave Baxter
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
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]

"Dave Baxter" <spam at goes.nowhere.com> wrote in message
news:MPG.25871af0923a862f9896a4 at news.btopenworld.com...
[]

Post by Dave Baxter
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.

[]

Post by Dave Baxter
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

[Dave Hart]

Post by Dave Baxter
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.

Post by Dave Baxter
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]

In article <de5f9a1f-d0bc-4949-980c-76a98680a087
@g4g2000pri.googlegroups.com>, davehart at gmail.com says...

Post by Dave Hart

Post by Dave Baxter
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.

Post by Dave Baxter
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
...
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]

"Dave Baxter" <g8kbv at nospam.uko2.co.uk> wrote in message
news:MPG.257f313bfbd49ce989683 at news.demon.co.uk...
[]

Post by Dave Baxter
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!)

[]

Post by Dave Baxter
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:

Loading Image...

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

[Dave Hart]

Post by Dave Baxter
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

[Dave Baxter]

In article <517b0b0d-1557-4c0e-b6b4-2d92d627258c@
2g2000prl.googlegroups.com>, davehart at gmail.com says...

Post by Dave Hart

Post by Dave Baxter
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

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 Hart]

Post by Dave Baxter
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]

In article <c237b62f-b9bb-4848-a117-
2911fa33aabf at b25g2000prb.googlegroups.com>, davehart at gmail.com says...

Post by Dave Hart

Post by Dave Baxter
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
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.

[Dave Baxter]

In article <MPG.2582ed6310d763dc989698 at news.btopenworld.com>,
spam at goes.nowhere.com says...

Post by Dave Baxter
2g2000prl.googlegroups.com>, davehart at gmail.com says...

Post by Dave Hart

Post by Dave Baxter
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

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.

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.

[David J Taylor]

"jack" <> wrote in message

Post by jack
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 Woolley]

Post by jack
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.

Post by jack
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 J Taylor]

"David Woolley" <david at ex.djwhome.demon.invalid> wrote in message

Post by David Woolley

Post by jack
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.

Post by jack
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
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

[Unruh]

Post by David J Taylor
"David Woolley" <david at ex.djwhome.demon.invalid> wrote in message

Post by David Woolley

Post by jack
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.

Post by jack
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.

Post by David J Taylor
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.

Post by David J Taylor
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]

"Unruh" <unruh-spam at physics.ubc.ca> wrote in message
news:e5_Pm.33822$cd7.2012 at newsfe04.iad...
[]

Post by Unruh
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

[Martin Burnicki]

[...]

Post by David Woolley

Post by jack
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

[David J Taylor]

"David Woolley" <david at ex.djwhome.demon.invalid> wrote in message

Post by David Woolley

Post by jack
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.

Post by jack
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
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

[Martin Burnicki]

[...]

Post by David Woolley

Post by jack
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

[David J Taylor]

"jack" <j.jack.wang at gmail.com> wrote in message

Post by jack
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

[]

Post by jack
11/26/2009 11:28:28 AM NTP Information None 3 N/A JACKXPS ntpd
4.2.4p6 at DLH-QPC-o Mar 15 21:30:20.47 (UTC) 2009 (239)

[]

Post by jack
jack

Jack, are you sure 4.2.4 includes the serial support you need? I've been
using 4.2.5.

Cheers,
David

[David Woolley]

Post by jack
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.

Post by jack
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.