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@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

"jack" <j.jack.wang@gmail.com> wrote in message 
news:54ad71bf-d76a-47c1-a0b7-df492d9edf9c@m38g2000yqd.googlegroups.com...
> Hi all,
>
> I am trying to setup NTP on Windows XP with a USB GPS at "COM1". I can
> verify that the GPS is outputing $GPRMC strings at 1Hz with some other
> strings occasionally (eg at startup).
>
> I installed the Meinberg NTP server and then overwrote ntpd.exe with
> Dave Hart's executable. I disabled all internet servers and add the
> following line:
[]
> 11/26/2009 11:28:28 AM NTP Information None 3 N/A JACKXPS ntpd
> 4.2.4p6@DLH-QPC-o Mar 15 21:30:20.47 (UTC)  2009  (239)
[]
> jack

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

Cheers,
David 

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=A0pm, "David J Taylor" <david-tay...@blueyonder.not-
this-bit.nor-this-part.co.uk.invalid> wrote:
> "jack" <j.jack.w...@gmail.com> wrote in message
>
> news:54ad71bf-d76a-47c1-a0b7-df492d9edf9c@m38g2000yqd.googlegroups.com...
>
> > Hi all,
>
> > I am trying to setup NTP on Windows XP with a USB GPS at "COM1". I can
> > verify that the GPS is outputing $GPRMC strings at 1Hz with some other
> > strings occasionally (eg at startup).
>
> > I installed the Meinberg NTP server and then overwrote ntpd.exe with
> > Dave Hart's executable. I disabled all internet servers and add the
> > following line:
> []
> > 11/26/2009 11:28:28 AM NTP Information None 3 N/A JACKXPS ntpd
> > 4.2.4p6@DLH-QPC-o Mar 15 21:30:20.47 (UTC) =A02009 =A0(239)
> []
> > jack
>
> Jack, are you sure 4.2.4 includes the serial support you need? =A0I've be=
en
> using 4.2.5.
>
> Cheers,
> David

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

On Nov 26, 1:15=A0pm, jack <j.jack.w...@gmail.com> wrote:
> 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=A0pm, "David J Taylor" <david-tay...@blueyonder.not-
>
>
>
> this-bit.nor-this-part.co.uk.invalid> wrote:
> > "jack" <j.jack.w...@gmail.com> wrote in message
>
> >news:54ad71bf-d76a-47c1-a0b7-df492d9edf9c@m38g2000yqd.googlegroups.com..=
..
>
> > > Hi all,
>
> > > I am trying to setup NTP on Windows XP with a USB GPS at "COM1". I ca=
n
> > > verify that the GPS is outputing $GPRMC strings at 1Hz with some othe=
r
> > > strings occasionally (eg at startup).
>
> > > I installed the Meinberg NTP server and then overwrote ntpd.exe with
> > > Dave Hart's executable. I disabled all internet servers and add the
> > > following line:
> > []
> > > 11/26/2009 11:28:28 AM NTP Information None 3 N/A JACKXPS ntpd
> > > 4.2.4p6@DLH-QPC-o Mar 15 21:30:20.47 (UTC) =A02009 =A0(239)
> > []
> > > jack
>
> > Jack, are you sure 4.2.4 includes the serial support you need? =A0I've =
been
> > using 4.2.5.
>
> > Cheers,
> > David

"jack" <> wrote in message 
news:c9339bbd-a773-44dc-92af-261308e3e284@31g2000vbf.googlegroups.com...
> David,
>
> I read instructions on your web site especially the section on USB GPS
> receivers. Version 4.2.4 dated March 15 2009 is the latest on Dave
> Hart's website. Why do you get 4.2.5 from?
>
> jack

Jack,

Sorry for any confustion.  On this page:

  http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html#usb

it says: "Tested with Dave Hart's: ntpd 4.2.5p161...".  There are a 
variety of 4.2.5 development versions here.  I would normally go for the 
most recent.

  http://www.davehart.net/ntp/win/x86/

  http://www.davehart.net/ntp/win/x86/ntp-4.2.5p246-RC-win-x86-bin.zip

My thanks to Dave for making these Windows versions available for testing.

Cheers,
David 

"jack" <> wrote in message 
news:7a8980f8-5cbc-4100-9d84-2d5e2a93c2de@e27g2000yqd.googlegroups.com...
> David,
>
> I switched to a machine with an RS232 port and also found version
> 4.2.5. NTP now opens port COM1 with no problem. However, status shows
> that it doesn't seem to be reading from GPS since all values (jitter,
> offset etc) are 0. Any suggestions?
>
> Jack

I've only tested with a PPS line connected to the DCD port.  Do you have 
that?  Is the reach value showing 0 as well?  I can't recall now what baud 
rate you need - 4800 by default, perhaps?

Cheers,
David 

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=A0pm, "David J Taylor" <david-tay...@blueyonder.not-this-
bit.nor-this-part.co.uk.invalid> wrote:
> "jack" <> wrote in message
>
> news:7a8980f8-5cbc-4100-9d84-2d5e2a93c2de@e27g2000yqd.googlegroups.com...
>
> > David,
>
> > I switched to a machine with an RS232 port and also found version
> > 4.2.5. NTP now opens port COM1 with no problem. However, status shows
> > that it doesn't seem to be reading from GPS since all values (jitter,
> > offset etc) are 0. Any suggestions?
>
> > Jack
>
> I've only tested with a PPS line connected to the DCD port. =A0Do you hav=
e
> that? =A0Is the reach value showing 0 as well? =A0I can't recall now what=
 baud
> rate you need - 4800 by default, perhaps?
>
> Cheers,
> David

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 =3D 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

On Nov 26, 4:30=A0pm, jack <j.jack.w...@gmail.com> wrote:
> 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=A0pm, "David J Taylor" <david-tay...@blueyonder.not-this-
>
>
>
> bit.nor-this-part.co.uk.invalid> wrote:
> > "jack" <> wrote in message
>
> >news:7a8980f8-5cbc-4100-9d84-2d5e2a93c2de@e27g2000yqd.googlegroups.com..=
..
>
> > > David,
>
> > > I switched to a machine with an RS232 port and also found version
> > > 4.2.5. NTP now opens port COM1 with no problem. However, status shows
> > > that it doesn't seem to be reading from GPS since all values (jitter,
> > > offset etc) are 0. Any suggestions?
>
> > > Jack
>
> > I've only tested with a PPS line connected to the DCD port. =A0Do you h=
ave
> > that? =A0Is the reach value showing 0 as well? =A0I can't recall now wh=
at baud
> > rate you need - 4800 by default, perhaps?
>
> > Cheers,
> > David

jack wrote:
> 
> I am trying to setup NTP on Windows XP with a USB GPS at "COM1". I can

You are making life difficult.  Without PPS, GPS has poor accuracy, and 
potentially high jitter.  USB adds a lot of extra jitter.  Windows is 
not the best platform for time keeping.

> 
> I installed the Meinberg NTP server and then overwrote ntpd.exe with

Meinberg don't do an NTP server, they do a Windows installer for the 
reference version of ntpd.

jack wrote:

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

>
> 

On Nov 26, 9:30=A0pm, jack wrote:
> I found the following entry in the log file:
> Using user-mode PPS timestamp
> Does it mean NTP reads the GPS strings and sees the 1PPS signal?

Pretty much, yes.  That message occurs only upon reading a CR when a
DCD transition has been observed and its timestamp is used instead of
the end-of-line CR/LF timestamp.  That "user-mode" PPS hack only works
if the GPS is configured to emit only one sentence per second, and it
allow you to get most of the benefit of PPS without requiring
serialpps.sys.

Since the topic mentions a USB GPS, unless the GPS is documented to
deliver PPS via its emulated serial's DCD, you may be seeing
meaningless DCD transitions rather than PPS.

You have serialpps.sys, so you might consider enabling PPSAPI use by
the NMEA refclock driver using

fudge 127.127.20.1 flag1 1

Good luck figuring out the problem that's keeping it unreachable.

Cheers,
Dave Hart

"David Woolley" <david@ex.djwhome.demon.invalid> wrote in message 
news:hen3cv$nit$1@news.eternal-september.org...
> jack wrote:
>>
>> I am trying to setup NTP on Windows XP with a USB GPS at "COM1". I can
>
> You are making life difficult.  Without PPS, GPS has poor accuracy, and 
> potentially high jitter.  USB adds a lot of extra jitter.  Windows is 
> not the best platform for time keeping.
>
>>
>> I installed the Meinberg NTP server and then overwrote ntpd.exe with
>
> Meinberg don't do an NTP server, they do a Windows installer for the 
> reference version of ntpd.

So in these days of energy economy would your solution be to install 
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 

"jack" <> wrote in message 
news:9db25657-9837-4ebe-ab32-ce15ae968af8@j35g2000vbl.googlegroups.com...
> David,
>
> I only have the following in the configure file:
>
> server 127.127.20.1 minpoll 4 prefer
>
> I found the following entry in the log file:
>
> Using user-mode PPS timestamp
>
> Does it mean NTP reads the GPS strings and sees the 1PPS signal?
>
> All the values are still 0 including reach. At one point for about 10
> minutes, I saw some values after rebooting the machine but they
> disappeared quickly.
>
> Thanks.
>
> jack
>
> ps: I am using the latest NTP from Dave Hart's website. I also
> installed serialpps.sys.

Jack,

As Dave Hart has answered you are talking to the expert in this area!

I had assumed in my first response that you had a GPS receiver with a 
serial output connected to a serial-USB convertor, but I see now that this 
may not be the case.  How well the PPS output is emulated in the 
USB-serial port software you will need to check.  You need somehow to 
"connect" the PPS output from the GPS to the virtual DCD line of the 
emulated COM1 port.  Not quite sure how you do that.  What GPS and 
software are you using

Cheers,
David 

David Woolley wrote:
> jack wrote:
[...]
>> I installed the Meinberg NTP server and then overwrote ntpd.exe with
> 
> Meinberg don't do an NTP server, they do a Windows installer for the
> reference version of ntpd.

They do also NTP servers, see:
http://www.meinberg.de/english/products/#network_sync

Take care, I'm biased ;-))

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

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=A0am, "David J Taylor" <david-tay...@blueyonder.not-this-
bit.nor-this-part.co.uk.invalid> wrote:
> "jack" <> wrote in message
>
> news:9db25657-9837-4ebe-ab32-ce15ae968af8@j35g2000vbl.googlegroups.com...
>
>
>
>
>
> > David,
>
> > I only have the following in the configure file:
>
> > server 127.127.20.1 minpoll 4 prefer
>
> > I found the following entry in the log file:
>
> > Using user-mode PPS timestamp
>
> > Does it mean NTP reads the GPS strings and sees the 1PPS signal?
>
> > All the values are still 0 including reach. At one point for about 10
> > minutes, I saw some values after rebooting the machine but they
> > disappeared quickly.
>
> > Thanks.
>
> > jack
>
> > ps: I am using the latest NTP from Dave Hart's website. I also
> > installed serialpps.sys.
>
> Jack,
>
> As Dave Hart has answered you are talking to the expert in this area!
>
> I had assumed in my first response that you had a GPS receiver with a
> serial output connected to a serial-USB convertor, but I see now that thi=
s
> may not be the case. =A0How well the PPS output is emulated in the
> USB-serial port software you will need to check. =A0You need somehow to
> "connect" the PPS output from the GPS to the virtual DCD line of the
> emulated COM1 port. =A0Not quite sure how you do that. =A0What GPS and
> software are you using
>
> Cheers,
> David

Hi all,

After reading Dave Hart's message, I realized that I didn't configure
the GPS device to only emit $GPRMC messages. After doing this, the NTP
software starts to function. So that's big progress for me.

Right now, I am using:

server 127.127.20.1 minpoll 4 prefer
server 127.127.22.1 minpoll 4

NTPStatus shows that it's syncing to PPS(1) although the offset and
jitter are still quite big (-3ms and 0.2ms respectively).

I tried the following combination but the offset actually increased.
server 127.127.20.1 minpoll 4 prefer
fudge 127.127.20.1 flag1 1

Right now I am trying to figure out how to switch to kernel mode. I
have
1) serialpps.sys
2) the correspond DLL
3) the environment variable that points to the DLL
I am unclear as to what should be done to switch to kernel mode.

Thanks to all for the help.

Jack

On Nov 27, 9:12=A0am, jack <j.jack.w...@gmail.com> wrote:
> David,
>
> You assumed right. I did start with a USB emulated port. The GPS I
> bought is from U-Blox and it has both USB and serial output. The
> serial output has the 1PPS signal (with an LED indicator). I thought I
> would start with the USB output since it's rather hard to find a
> computer with a serial port. Also I would like to see the accuracy by
> using the USB port only. I later switched to a machine with a serial
> port and started using the serial output of the U-Blox GPS device and
> 1PPS. My objective is to use two of these devices to sync two separate
> computers to within ms so they can share time-sensitive data (time
> stamped).
>
> I left the device running overnight and I noticed it computed an
> offset at one time. It's currently not updating (everything is zero
> now). I will read carefully what Dave Hart said and follow his advice.
>
> Thanks to everyone for your help.
>
> Jack
>
> On Nov 27, 1:51=A0am, "David J Taylor" <david-tay...@blueyonder.not-this-
>
>
>
> bit.nor-this-part.co.uk.invalid> wrote:
> > "jack" <> wrote in message
>
> >news:9db25657-9837-4ebe-ab32-ce15ae968af8@j35g2000vbl.googlegroups.com..=
..
>
> > > David,
>
> > > I only have the following in the configure file:
>
> > > server 127.127.20.1 minpoll 4 prefer
>
> > > I found the following entry in the log file:
>
> > > Using user-mode PPS timestamp
>
> > > Does it mean NTP reads the GPS strings and sees the 1PPS signal?
>
> > > All the values are still 0 including reach. At one point for about 10
> > > minutes, I saw some values after rebooting the machine but they
> > > disappeared quickly.
>
> > > Thanks.
>
> > > jack
>
> > > ps: I am using the latest NTP from Dave Hart's website. I also
> > > installed serialpps.sys.
>
> > Jack,
>
> > As Dave Hart has answered you are talking to the expert in this area!
>
> > I had assumed in my first response that you had a GPS receiver with a
> > serial output connected to a serial-USB convertor, but I see now that t=
his
> > may not be the case. =A0How well the PPS output is emulated in the
> > USB-serial port software you will need to check. =A0You need somehow to
> > "connect" the PPS output from the GPS to the virtual DCD line of the
> > emulated COM1 port. =A0Not quite sure how you do that. =A0What GPS and
> > software are you using
>
> > Cheers,
> > David

jack wrote:

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

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

On Nov 27, 11:17=A0am, David Lord <sn...@lordynet.org> wrote:
> jack wrote:
>
> > 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

> 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,

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=A0pm, "David J Taylor" <david-tay...@blueyonder.not-this-
bit.nor-this-part.co.uk.invalid> wrote:
> > 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. =A0For 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. =A0A 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 PC=
s
> to be synced to within the millisecond. =A0Perhaps much better to have
> completely separate time stamp to which both PCs refer.
>
> Cheers,
> David

"David J Taylor" <david-taylor@blueyonder.not-this-bit.nor-this-part.co.uk.invalid> writes:

>"David Woolley" <david@ex.djwhome.demon.invalid> wrote in message 
>news:hen3cv$nit$1@news.eternal-september.org...
>> jack wrote:
>>>
>>> I am trying to setup NTP on Windows XP with a USB GPS at "COM1". I can
>>
>> You are making life difficult.  Without PPS, GPS has poor accuracy, and 
>> potentially high jitter.  USB adds a lot of extra jitter.  Windows is 
>> not the best platform for time keeping.
>>
>>>
>>> I installed the Meinberg NTP server and then overwrote ntpd.exe with
>>
>> Meinberg don't do an NTP server, they do a Windows installer for the 
>> reference version of ntpd.

>So in these days of energy economy would your solution be to install 

So throw away all your computers. Then all of these problems disappear. 

>another PC running a different OS (with all the associated extra learning) 
>just so that accuracy could be improved from scores of microseconds to 

I think you mean 10s of msec to 1s of microseconds. If you do not need
it, certainly using a separate computer would be overkill. If you need
it, then presumably you have to factor in the costs and figure out how
much you need it. 
I would certainly NOT use USB for accuracy. I would certainly not use
Windows for accuracy. 
On a windows system, using the net (Ie external servers ) might well be
just as good or better than a usb gps. 


>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 

"jack" <> wrote in message 
news:484bcf3e-dde5-4978-966d-5637918c913f@l35g2000vba.googlegroups.com...
> David,
>
> Would you mind looking up the model number of the Sitecom serial to
> USB converter that has the DCD line? I am very interested in a
> solution like that.
>
> Jack

Jack, the convertor I had was Sitecom DK01 USB dock from 2002.  It's no 
longer available new.

Cheers,
David 

"Unruh" <unruh-spam@physics.ubc.ca> wrote in message 
news:e5_Pm.33822$cd7.2012@newsfe04.iad...
[]
> I think you mean 10s of msec to 1s of microseconds. If you do not need
> it, certainly using a separate computer would be overkill. If you need
> it, then presumably you have to factor in the costs and figure out how
> much you need it.
> I would certainly NOT use USB for accuracy. I would certainly not use
> Windows for accuracy.
> On a windows system, using the net (Ie external servers ) might well be
> just as good or better than a usb gps.

No, on Windows I measure reported offsets well under a fraction of a 
millisecond for both Windows 2000 and Windows XP stratum-1 GPS/PPS 
reference clocks, not tens of milliseconds you think it is.  On my 
LAN-synced clients I measure under two milliseconds offset.  On my 
GPS/PPS/USB tests I measured better than LAN-synced offsets.

My results are based on actual measurements.  Where do your figures come 
from?

David 

David J Taylor wrote:
> "jack" <> wrote in message 
> news:484bcf3e-dde5-4978-966d-5637918c913f@l35g2000vba.googlegroups.com...
>> David,
>>
>> Would you mind looking up the model number of the Sitecom serial to
>> USB converter that has the DCD line? I am very interested in a
>> solution like that.
>>
>> Jack
> 
> Jack, the convertor I had was Sitecom DK01 USB dock from 2002.  It's no 
> longer available new.

Internal serial cards seem like an inexpensive way to add a serial port 
for a GPS connection - do people use them for NTP?

e.g.

StarTech.com 1 port Native PCI Express RS232 Serial Adapter Card with 
16550 UART - Serial adapter - PCI Express x1 - RS-232
Manufacturer Part : PEX1S552
Dell Part : A2309415

-- 
RGB

> 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 

On Nov 28, 1:51=A0am, "David J Taylor" <david-tay...@blueyonder.not-this-
bit.nor-this-part.co.uk.invalid> wrote:
> "jack" <> wrote in message
>
> news:484bcf3e-dde5-4978-966d-5637918c913f@l35g2000vba.googlegroups.com...
>
> > David,
>
> > Would you mind looking up the model number of the Sitecom serial to
> > USB converter that has the DCD line? I am very interested in a
> > solution like that.
>
> > Jack
>
> Jack, the convertor I had was Sitecom DK01 USB dock from 2002. =A0It'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

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

On Nov 30, 9:56=A0am, jack <j.jack.w...@gmail.com> wrote:
> On Nov 28, 1:51=A0am, "David J Taylor" <david-tay...@blueyonder.not-this-
>
>
>
>
>
> bit.nor-this-part.co.uk.invalid> wrote:
> > "jack" <> wrote in message
>
> >news:484bcf3e-dde5-4978-966d-5637918c913f@l35g2000vba.googlegroups.com..=
..
>
> > > David,
>
> > > Would you mind looking up the model number of the Sitecom serial to
> > > USB converter that has the DCD line? I am very interested in a
> > > solution like that.
>
> > > Jack
>
> > Jack, the convertor I had was Sitecom DK01 USB dock from 2002. =A0It'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" <> wrote in message 
news:7cc021d3-4ca9-47b3-8ab8-7aa00424389d@h10g2000vbm.googlegroups.com...
[]
> Thank you, David. You're very helpful!
>
> I ran both my setups over the weekend. The GPS with 1PPS has the worst
> offset of 200us and the GPS without jumped up to 80ms, clearly due to
> loss of satellite signals. I am happy with the performance of the GPS
> with 1PPS out.
>
> RGB: I have a similar PCI-serial card in my computer. I will try my
> GPS with this board and let you know the results.
>
> Jack

The 80ms could have been due to all sorts of things, particularly with 
Windows Vista or Windows-7 with certain peripherals, but with the Windows 
XP you are running it should be reasonably free from odd effects. 
Certainly, without PPS a pure serial GPS may be no better than using a LAN 
server.  My own XP/GPS/PPS system is usually well within 250us, as you can 
see here:

  http://www.satsignal.eu/mrtg/feenix_ntp_2.html

That's with a GPS on the roof of the house with a view of about half the 
sky.

Cheers,
David 

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

On Nov 30, 10:25=A0am, jack <j.jack.w...@gmail.com> wrote:
> 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
>
> On Nov 30, 9:56=A0am, jack <j.jack.w...@gmail.com> wrote:
>
>
>
> > On Nov 28, 1:51=A0am, "David J Taylor" <david-tay...@blueyonder.not-thi=
s-
>
> > bit.nor-this-part.co.uk.invalid> wrote:
> > > "jack" <> wrote in message
>
> > >news:484bcf3e-dde5-4978-966d-5637918c913f@l35g2000vba.googlegroups.com=
....
>
> > > > David,
>
> > > > Would you mind looking up the model number of the Sitecom serial to
> > > > USB converter that has the DCD line? I am very interested in a
> > > > solution like that.
>
> > > > Jack
>
> > > Jack, the convertor I had was Sitecom DK01 USB dock from 2002. =A0It'=
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" <> wrote in message 
news:b15dd4f8-2611-4e3f-9ace-ad21c5f78892@f20g2000vbl.googlegroups.com...
> RGB:
>
> I tried the serial port on my B&B serial board and the 1PPS signal is
> not detected. I don't how how serialpps.sys sees the signal and am
> thinking the DCD signal is not sent over the PCI bus.
>
> jack

Jack,

Dave Hart is obviously the man who knows most about this, but my 
understanding is that the DCD transition should create a hardware 
interrupt, which then creates a software interrupt, which serialpp.sys 
handles and notes the time of the transition, which the DLL/ntpd.exe can 
later retrieve.  Even without the special serialpps.sys and DLL, ntpd.exe 
can note the time of the transition, only just not as accurately.  We're 
talking microsecond-level differences here.

I suspect that you may find an option to enable or disable DCD.  You seem 
to have other COM-port issues from your next post.

Cheers,
David 

On Nov 30, 3:25=A0pm, jack <j.jack.w...@gmail.com> wrote:
> 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

On Nov 30, 3:51=A0pm, jack <j.jack.w...@gmail.com> wrote:
> 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). =A0I 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

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



On Nov 30, 11:12=A0am, Dave Hart <daveh...@gmail.com> wrote:
> On Nov 30, 3:51=A0pm, jack <j.jack.w...@gmail.com> wrote:
>
> > 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). =A0I 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 wrote:

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

In article <mZAPm.9055$Ym4.4115@text.news.virginmedia.com>, david-
taylor@blueyonder.not-this-bit.nor-this-part.co.uk.invalid says...
> 
> "jack" <> wrote in message 
> news:c9339bbd-a773-44dc-92af-261308e3e284@31g2000vbf.googlegroups.com...
> > David,
> >
> > I read instructions on your web site especially the section on USB GPS
> > receivers. Version 4.2.4 dated March 15 2009 is the latest on Dave
> > Hart's website. Why do you get 4.2.5 from?
> >
> > jack
> 
> Jack,
> 
> Sorry for any confustion.  On this page:
> 
>   http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html#usb
> 
> it says: "Tested with Dave Hart's: ntpd 4.2.5p161...".  There are a 
> variety of 4.2.5 development versions here.  I would normally go for the 
> most recent.
> 
>   http://www.davehart.net/ntp/win/x86/
> 
>   http://www.davehart.net/ntp/win/x86/ntp-4.2.5p246-RC-win-x86-bin.zip
> 
> My thanks to Dave for making these Windows versions available for testing.
> 
> Cheers,
> David 

Hi.

I'm also trying to get this working, haveing failed miserably with the 
FreeBSD system (it would never seem to respond to the GPS, and as I 
don't know squat about 'BSD, decided to revert to Winders...)

Anyway, I have a working install of the Meinberg NTPD Windows port on 
Win2k, and it is sync'ing OK to online servers, but they are the trouble 
I'm trying to get round, due to variable and huge BT/ISP induced 
latency, screwing arround with NTP during the weekday, that I use with 
"Faros" a HF Radio propagation beacon monitor.

Long story short, I'm trying to put together a Stratum 1 time server for 
my LAN only, maybe even on the same physical PC as Faros.

I had (killed it now) a version of the patched serial.sys for PPS 
support, but it BSOD'd the machine at boot time (black screen) needing a 
physical removal of the hard drive, and temporary fitment into another 
PC to put the original file back.

At present, I can't find a ready-to-use binary of that file.  Dave 
Hart's site befuddles me, all I can see there is a *Huge* collection of 
files, what file do I need and where from, exactly please.?

I have a Garmin GPS16LVC with PPS output.  (Two of them, both work fine 
AFAICS, with VisualGPS and a 'scope looking at the PPS signal, that 
needed buffering to RS232 levels.)

Comments, hints?

Regards
Dave Baxter.

On 2009-11-30, RedGrittyBrick <RedGrittyBrick@spamweary.invalid> wrote:
>
> David J Taylor wrote:
>> "jack" <> wrote in message 
>> news:484bcf3e-dde5-4978-966d-5637918c913f@l35g2000vba.googlegroups.com...
>>> David,
>>>
>>> Would you mind looking up the model number of the Sitecom serial to
>>> USB converter that has the DCD line? I am very interested in a
>>> solution like that.
>>>
>>> Jack
>> 
>> Jack, the convertor I had was Sitecom DK01 USB dock from 2002.  It's no 
>> longer available new.
>
> Internal serial cards seem like an inexpensive way to add a serial port 
> for a GPS connection - do people use them for NTP?

That is fine if your system is a desktop which can take internal cards 
 But laptops for example do not.

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

unruh wrote:
> On 2009-11-30, RedGrittyBrick <RedGrittyBrick@spamweary.invalid> wrote:
>> David J Taylor wrote:
>>> "jack" <> wrote in message 
>>> news:484bcf3e-dde5-4978-966d-5637918c913f@l35g2000vba.googlegroups.com...
>>>> David,
>>>>
>>>> Would you mind looking up the model number of the Sitecom serial to
>>>> USB converter that has the DCD line? I am very interested in a
>>>> solution like that.
>>>>
>>>> Jack
>>> Jack, the convertor I had was Sitecom DK01 USB dock from 2002.  It's no 
>>> longer available new.
>> Internal serial cards seem like an inexpensive way to add a serial port 
>> for a GPS connection - do people use them for NTP?
> 
> That is fine if your system is a desktop which can take internal cards 
>  But laptops for example do not.
> 

Some laptops can take plug-in cards that offer Ethernet or RS-232C:
U.S. Robotics/Dell Model XJ4338 is a 33.6 baud modem.
Dell Ethernet Card 10BASE-T/100Base-2
D-Link DFE-670TXD 10/100 Base-T

I've not used them myself; my laptop came equipped with Ethernet and 
RS232-C.  If I ever buy another laptop, I will be sure that it has both 
Ethernet and RS232-C interfaces.

"Dave Baxter" <g8kbv@uko2.co.uk> wrote in message 
news:MPG.257e5228127dac81989680@news.demon.co.uk...
[]
> Hi.
>
> I'm also trying to get this working, haveing failed miserably with the
> FreeBSD system (it would never seem to respond to the GPS, and as I
> don't know squat about 'BSD, decided to revert to Winders...)

On reason for me writing my Web page was that I felt a similar level of 
ignorance about FreeBSD, so I hoped it would help.  However, I believe 
some of the port names and perhaps other things have changed in later 
versions of FreeBSD, so if what I wrote doesn't help, then neither can I. 
Windows is getting sub-millisecond for me.

> Anyway, I have a working install of the Meinberg NTPD Windows port on
> Win2k, and it is sync'ing OK to online servers, but they are the trouble
> I'm trying to get round, due to variable and huge BT/ISP induced
> latency, screwing arround with NTP during the weekday, that I use with
> "Faros" a HF Radio propagation beacon monitor.
>
> Long story short, I'm trying to put together a Stratum 1 time server for
> my LAN only, maybe even on the same physical PC as Faros.
>
> I had (killed it now) a version of the patched serial.sys for PPS
> support, but it BSOD'd the machine at boot time (black screen) needing a
> physical removal of the hard drive, and temporary fitment into another
> PC to put the original file back.
>
> At present, I can't find a ready-to-use binary of that file.  Dave
> Hart's site befuddles me, all I can see there is a *Huge* collection of
> files, what file do I need and where from, exactly please.?
>
> I have a Garmin GPS16LVC with PPS output.  (Two of them, both work fine
> AFAICS, with VisualGPS and a 'scope looking at the PPS signal, that
> needed buffering to RS232 levels.)
>
> Comments, hints?
>
> Regards
> Dave Baxter.

Dave,

You don't need the serialpps.sys except for the ultimate in performance. 
Having said that, it's working here on Windows 2000, Windows XP, and 
Windows-7, and I would be rather surprised if it didn't work on Windows 
Vista as well.  Dave Hart would probably appreciate more details of the 
BSOD failure.

Having installed the most recent Meinberg NTP (Copenhagen), copy the files 
from this archive:

  http://www.davehart.net/ntp/win/x86/
  http://www.davehart.net/ntp/win/x86/ntp-4.2.5p246-RC-win-x86-bin.zip

on top of the Meinberg-installed files.  Dave is very helpful in providing 
the recent development builds of NTP, and in case some error is 
introduced, he leaves working versions.  The version I suggested is one I 
am using so I know it's OK.  In each release there is a normal build, a 
build with extra debugging information, and the file containing the 
symbols for each build in case you want to debug the programs by stepping 
through a line at a time - "normal" users would not need to do this.

On my own system, I found that the PPS line worked directly to RS232 
without any buffering, indeed I have a GPS 18 LVC feeding two RS232 ports 
in parallel.  My newer GPS 18x LVC feeds just one RS232 port directly.

Cheers,
David 

On Nov 30 22:06=A0UTC, Dave Baxter wrote:
> I had (killed it now) a version of the patched serial.sys for PPS
> support, but it BSOD'd the machine at boot time (black screen) needing a
> physical removal of the hard drive, and temporary fitment into another
> PC to put the original file back.

I'm sorry to hear that.  I note that to me, BSOD/bluescreen means
something distinct from hanging with a black/blank screen.  The former
implies a "bugcheck", akin to a kernel panic.

I managed to develop the two revisions of serialpps.sys without
experiencing any bluescreens.  In fact, it was about as painless as I
could have hoped for, but then I haven't actually tried any of the 64-
bit builds.  Given the tiny changes between serial.sys and
serialpps.sys, and the fact that the code to implement the new "ioctl"
interface is cloned from several other examples in serial.sys,
combined with experience from a number of other users, I will be
surprised if there turns out to be a bug unique to serialpps.sys
involved here.

> At present, I can't find a ready-to-use binary of that file. =A0Dave
> 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=3Dc:\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

In article <t63Rm.10421$Ym4.6217@text.news.virginmedia.com>, david-
taylor@blueyonder.not-this-bit.nor-this-part.co.uk.invalid says...
> 
> "Dave Baxter" <g8kbv@uko2.co.uk> wrote in message 
> news:MPG.257e5228127dac81989680@news.demon.co.uk...
> []
> > Hi.
> >
> > I'm also trying to get this working, haveing failed miserably with the
> > FreeBSD system (it would never seem to respond to the GPS, and as I
> > don't know squat about 'BSD, decided to revert to Winders...)
> 
> On reason for me writing my Web page was that I felt a similar level of 
> ignorance about FreeBSD, so I hoped it would help.  However, I believe 
> some of the port names and perhaps other things have changed in later 
> versions of FreeBSD, so if what I wrote doesn't help, then neither can I. 
> Windows is getting sub-millisecond for me.
> 
> > Anyway, I have a working install of the Meinberg NTPD Windows port on
> > Win2k, and it is sync'ing OK to online servers, but they are the trouble
> > I'm trying to get round, due to variable and huge BT/ISP induced
> > latency, screwing arround with NTP during the weekday, that I use with
> > "Faros" a HF Radio propagation beacon monitor.
> >
> > Long story short, I'm trying to put together a Stratum 1 time server for
> > my LAN only, maybe even on the same physical PC as Faros.
> >
> > I had (killed it now) a version of the patched serial.sys for PPS
> > support, but it BSOD'd the machine at boot time (black screen) needing a
> > physical removal of the hard drive, and temporary fitment into another
> > PC to put the original file back.
> >
> > At present, I can't find a ready-to-use binary of that file.  Dave
> > Hart's site befuddles me, all I can see there is a *Huge* collection of
> > files, what file do I need and where from, exactly please.?
> >
> > I have a Garmin GPS16LVC with PPS output.  (Two of them, both work fine
> > AFAICS, with VisualGPS and a 'scope looking at the PPS signal, that
> > needed buffering to RS232 levels.)
> >
> > Comments, hints?
> >
> > Regards
> > Dave Baxter.
> 
> Dave,
> 
> You don't need the serialpps.sys except for the ultimate in performance. 
> Having said that, it's working here on Windows 2000, Windows XP, and 
> Windows-7, and I would be rather surprised if it didn't work on Windows 
> Vista as well.  Dave Hart would probably appreciate more details of the 
> BSOD failure.

Hi David...

I'll put the BSOD details in another post, beneath David Harts post, to 
keep the tree branches sane...

You did help me out a while back, by pointing me at the exact same 
distribution of F'BSD as you used, I managed (at the third attempt) to 
get it to install on a suiable PC (P3/766MHz, 512M Ram) and it in it's 
original guise seemed happy.  At least, all the things I tried sort of 
worked as documented.

It took me two more attempts to get the kernel recompiled with PPS 
support enabled (needing another full re-install in the process, though 
I now know where the "backup" kernel file is if I do that again!)

My single biggest problem, and no disrespect to you or anyone else here, 
is that (and I've done exactly the same with stuff I work with for other 
lesser people) is one is "too close" to it all in many ways to get a 
truly idiot proof (for that's what us newbies need :) ) install working 
safely.   (If at all in some instances!)

I think I now know what I did wrong with the serialpps.sys in Windows, 
you'll probably laugh when you read it in my reply to the other Dave 
(maybe we should all use the name Bruce instead?)

The version on the Meinberg windows port of NTPD I've used so far is:-
ntpd 4.24p7@copenhagen-o May 22 2009   If that helps (as shown in the 
NTP monitor program)

I realy would preffer a stable version, rather than any bleading edge 
versions, as the rest of the system can be left to it's own devices for 
weeks if needed with no issues.

I think I need at least single figure mS stability and resolution, not 
absolute uS accuracy, but better is sort of better I guess, I'll bow to 
superior knowledge on that though.

There are at least two other Faros users (just thought of someone else) 
so that's 4 that I know of, who would also like a fully self contained 
system for this purpose (Faros) as they are not well connected to the 
'net, with resulting NTP issues as a reuslt. 

Have to say, my main problem with this, is that there are so many 
versions of this and that, plus knowledge I'm still learning is needed 
to make it fly.

Best Regards.  Now to answer Dave Harts post.

Dave Baxter.

In article <de5f9a1f-d0bc-4949-980c-76a98680a087
@g4g2000pri.googlegroups.com>, davehart@gmail.com says...
> 
> On Nov 30 22:06�UTC, Dave Baxter wrote:
> > I had (killed it now) a version of the patched serial.sys for PPS
> > support, but it BSOD'd the machine at boot time (black screen) needing a
> > physical removal of the hard drive, and temporary fitment into another
> > PC to put the original file back.
> 
> I'm sorry to hear that.  I note that to me, BSOD/bluescreen means
> something distinct from hanging with a black/blank screen.  The former
> implies a "bugcheck", akin to a kernel panic.
> 
> I managed to develop the two revisions of serialpps.sys without
> experiencing any bluescreens.  In fact, it was about as painless as I
> could have hoped for, but then I haven't actually tried any of the 64-
> bit builds.  Given the tiny changes between serial.sys and
> serialpps.sys, and the fact that the code to implement the new "ioctl"
> interface is cloned from several other examples in serial.sys,
> combined with experience from a number of other users, I will be
> surprised if there turns out to be a bug unique to serialpps.sys
> involved here.
> 
> > 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.
> 

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.

"Dave Baxter" <g8kbv@nospam.uko2.co.uk> wrote in message 
news:MPG.257f313bfbd49ce989683@news.demon.co.uk...
[]
> Is there a blow by blow (with screenshots?) description as to how to put
> all this together anywhere?   David Taylor's site gets close, but I
> suffer "informaion overload" after a while.   (The Grey cell version of
> a buffer overun I think!)
[]
> Comments, suggestions welcome.
>
> Regards.   You can all stop laughing now!
>
> Dave Baxter.

Dave,

I would not worry about adding the special serialpps.sys, at least not 
initially.  Why?  If you take a look at the offset graph here:

  http://www.satsignal.eu/ntp/2009-05-17-Feenix_offset.png

I would challenge you to see which "half" of it was with the kernel-mode 
serialpps.sys and which was with the standard driver.  Yes, it's more 
obvious if you look at the jitter graph here:

  http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html#PPSAPI_DLLS

but even then the averaged jitter only changes from just over three to 
just over two microseconds - to me negligible in comparison with the ~150 
microseconds of offset.  Temperature appears to be the main enemy I'm 
facing.

Just concentrate on getting the basic GPS/PPS working.

73,
David - GM8ARV 

"Dave Baxter" <g8kbv@nospam.uko2.co.uk> wrote in message 
news:MPG.257f2d55775bad5a989682@news.demon.co.uk...
[]
> Hi David...
>
> I'll put the BSOD details in another post, beneath David Harts post, to
> keep the tree branches sane...
>
> You did help me out a while back, by pointing me at the exact same
> distribution of F'BSD as you used, I managed (at the third attempt) to
> get it to install on a suiable PC (P3/766MHz, 512M Ram) and it in it's
> original guise seemed happy.  At least, all the things I tried sort of
> worked as documented.

Ah, I remember now....

> It took me two more attempts to get the kernel recompiled with PPS
> support enabled (needing another full re-install in the process, though
> I now know where the "backup" kernel file is if I do that again!)

I was luckier.

> My single biggest problem, and no disrespect to you or anyone else here,
> is that (and I've done exactly the same with stuff I work with for other
> lesser people) is one is "too close" to it all in many ways to get a
> truly idiot proof (for that's what us newbies need :) ) install working
> safely.   (If at all in some instances!)

I agree, and that's why I have a user-group for my own software and 
encourage people to try beta versions.  Having different people explain 
things in different ways can often be helpful when you have a mental block 
about something.  I've tried to simplify things at the top of my Web page:

  http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html

by adding a "for the impatient" paragraph - i.e. for those who don't or 
can't RTFM!  I'd welcome any input to try and improve that page for 
"novices".

> I think I now know what I did wrong with the serialpps.sys in Windows,
> you'll probably laugh when you read it in my reply to the other Dave
> (maybe we should all use the name Bruce instead?)

You can save playing with that for another day, though,

> The version on the Meinberg windows port of NTPD I've used so far is:-
> ntpd 4.24p7@copenhagen-o May 22 2009   If that helps (as shown in the
> NTP monitor program)
>
> I realy would preffer a stable version, rather than any bleading edge
> versions, as the rest of the system can be left to it's own devices for
> weeks if needed with no issues.

I agree, but the "stable" branch doesn't yet include the PPS support, so 
we're stuck with the "development" branch.  Quite honestly, I would treat 
most of the development branch as being of "production" quality.  I had 
one problem when it wouldn't work with Windows 2000 (now resolved, I 
think, I'm using ntpd 4.2.5p231 on PC Bacchus), and one more subtle 
problem where something didn't work as well after a reboot of a Windows-7 
system.  That's also now resolved.

> I think I need at least single figure mS stability and resolution, not
> absolute uS accuracy, but better is sort of better I guess, I'll bow to
> superior knowledge on that though.
>
> There are at least two other Faros users (just thought of someone else)
> so that's 4 that I know of, who would also like a fully self contained
> system for this purpose (Faros) as they are not well connected to the
> 'net, with resulting NTP issues as a reuslt.
>
> Have to say, my main problem with this, is that there are so many
> versions of this and that, plus knowledge I'm still learning is needed
> to make it fly.
>
> Best Regards.  Now to answer Dave Harts post.
>
> Dave Baxter.

Keep asking the questions, even if they seem elementary - and I will try 
to both provide answers and record them on my Web site for others.  One 
issue which you haven't addressed (as far as I know) is how the Faros 
program uses an accurate time.  I take it that the author of the program 
gets the time from Windows - he does know that time is typically only 
updated once every ten milliseconds, I guess?  NTP doesn't have an API 
which can tell you the time more accurately than that, which is a pity 
because that would be very handy....

73,
David 

On Dec 1, 13:58=A0UTC, Dave Baxter wrote:
> What colateral effects will the serialpps.sys driver have on the other
> com port, as that will be used for controling the radio (data lines
> only.) =A0 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

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=A0am, "David J Taylor" <david-tay...@blueyonder.not-this-
bit.nor-this-part.co.uk.invalid> wrote:
> "Dave Baxter" <g8...@nospam.uko2.co.uk> wrote in message
>
> news:MPG.257f2d55775bad5a989682@news.demon.co.uk...
> []
>
> > 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. =A0At least, all the things I tried sort o=
f
> > worked as documented.
>
> Ah, I remember now....
>
> > It took me two more attempts to get the kernel recompiled with PPS
> > support enabled (needing another full re-install in the process, though
> > I now know where the "backup" kernel file is if I do that again!)
>
> I was luckier.
>
> > My single biggest problem, and no disrespect to you or anyone else here=
,
> > is that (and I've done exactly the same with stuff I work with for othe=
r
> > 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. =A0 (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. =A0Having different people explain
> things in different ways can often be helpful when you have a mental bloc=
k
> about something. =A0I've tried to simplify things at the top of my Web pa=
ge:
>
> =A0http://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! =A0I'd welcome any input to try and improve that page for
> "novices".
>
> > I think I now know what I did wrong with the serialpps.sys in Windows,
> > you'll probably laugh when you read it in my reply to the other Dave
> > (maybe we should all use the name Bruce instead?)
>
> You can save playing with that for another day, though,
>
> > The version on the Meinberg windows port of NTPD I've used so far is:-
> > ntpd 4.24p7@copenhagen-o May 22 2009 =A0 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. =A0Quite honestly, I would tre=
at
> most of the development branch as being of "production" quality. =A0I 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. =A0That's also now resolved.
>
>
>
>
>
> > I think I need at least single figure mS stability and resolution, not
> > absolute uS accuracy, but better is sort of better I guess, I'll bow to
> > superior knowledge on that though.
>
> > There are at least two other Faros users (just thought of someone else)
> > so that's 4 that I know of, who would also like a fully self contained
> > system for this purpose (Faros) as they are not well connected to the
> > 'net, with resulting NTP issues as a reuslt.
>
> > Have to say, my main problem with this, is that there are so many
> > versions of this and that, plus knowledge I'm still learning is needed
> > to make it fly.
>
> > Best Regards. =A0Now 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. =A0One
> issue which you haven't addressed (as far as I know) is how the Faros
> program uses an accurate time. =A0I take it that the author of the progra=
m
> gets the time from Windows - he does know that time is typically only
> updated once every ten milliseconds, I guess? =A0NTP 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" <> wrote in message 
news:72491452-f89d-454b-8bcc-f945c825915f@j19g2000yqk.googlegroups.com...
> David,
>
> I would like to add that, from my own experiences, the GPS has to be
> configured to output $GPRMC sentences only. Otherwise the PPS part of
> NTP doesn't work.

Good point - added.

> I have a related question: given that my system clock is synced to an
> external GPS within ms, how do I read time that gives me the same
> accuracy? When I tried to read time at 60Hz, I found that the times
> returned are not periodic, sometimes even the same.
>
> Jack

That was my point about using Windows!  By default, the clock only returns 
new values at either 16ms or 10ms intervals - depending on the OS version. 
You can enable the Multimedia timers which increase the clock frequency, 
but I can't remember off-hand whether that increases the read-out 
precision in /all/ versions of Windows, or just Vista and Windows-7.  Use 
the timeBeginPeriod and timeEndPeriod functions, but be aware that 
switching these functions on and off can result in timekeeping transients, 
so with NTP and pre-Vista systems it's best to use NTP to keep the MM 
timer enabled.
  http://msdn.microsoft.com/en-us/library/dd757624%28VS.85%29.aspx
  http://msdn.microsoft.com/en-us/library/dd743611%28VS.85%29.aspx

This source looks interesting for XP, but old:
  http://www.lochan.org/2005/keith-cl/useful/win32time.html

On my XP system, with the MM timer enabled, I see a resolution for a 
timeGetTime call of just under a millisecond.  I wrote a small program 
here:

  http://www.satsignal.eu/software/net.htm#PCClockTiming

Cheers,
David 

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=A0pm, "David J Taylor" <david-tay...@blueyonder.not-this-
bit.nor-this-part.co.uk.invalid> wrote:
> "jack" <> wrote in message
>
> news:72491452-f89d-454b-8bcc-f945c825915f@j19g2000yqk.googlegroups.com...
>
> > David,
>
> > I would like to add that, from my own experiences, the GPS has to be
> > configured to output $GPRMC sentences only. Otherwise the PPS part of
> > NTP doesn't work.
>
> Good point - added.
>
> > I have a related question: given that my system clock is synced to an
> > external GPS within ms, how do I read time that gives me the same
> > accuracy? When I tried to read time at 60Hz, I found that the times
> > returned are not periodic, sometimes even the same.
>
> > Jack
>
> That was my point about using Windows! =A0By default, the clock only retu=
rns
> 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. =A0U=
se
> 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.
> =A0http://msdn.microsoft.com/en-us/library/dd757624%28VS.85%29.aspx
> =A0http://msdn.microsoft.com/en-us/library/dd743611%28VS.85%29.aspx
>
> This source looks interesting for XP, but old:
> =A0http://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. =A0I wrote a small program
> here:
>
> =A0http://www.satsignal.eu/software/net.htm#PCClockTiming
>
> Cheers,
> David

On Dec 1 16:58=A0UTC, jack wrote:
> I have a related question: given that my system clock is synced to an
> external GPS within ms, how do I read time that gives me the same
> accuracy? When I tried to read time at 60Hz, I found that the times
> returned are not periodic, sometimes even the same.

Depending on the version of Windows, hardware, and the interface used
(GetSystemTime[AsFileTime] vs timeGetTime/GetTickCount) the best
resolution you can get for the clock is 0.5ms, the worst about
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

On Dec 1, 5:11=A0pm, Dave Hart <daveh...@gmail.com> wrote:
> On Dec 1 16:58=A0UTC, jack wrote:
>
> > I have a related question: given that my system clock is synced to an
> > external GPS within ms, how do I read time that gives me the same
> > accuracy? When I tried to read time at 60Hz, I found that the times
> > returned are not periodic, sometimes even the same.
>
> Depending on the version of Windows, hardware, and the interface used
> (GetSystemTime[AsFileTime] vs timeGetTime/GetTickCount) the best
> resolution you can get for the clock is 0.5ms, the worst about
> 15.625ms. =A0To 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. =A0You
> 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

On 2009-12-01, jack <j.jack.wang@gmail.com> wrote:
> On Dec 1, 5:11?pm, Dave Hart <daveh...@gmail.com> wrote:
>> On Dec 1 16:58?UTC, jack wrote:
>>
>> > I have a related question: given that my system clock is synced to an
>> > external GPS within ms, how do I read time that gives me the same
>> > accuracy? When I tried to read time at 60Hz, I found that the times
>> > returned are not periodic, sometimes even the same.
>>
>> Depending on the version of Windows, hardware, and the interface used
>> (GetSystemTime[AsFileTime] vs timeGetTime/GetTickCount) the best
>> resolution you can get for the clock is 0.5ms, the worst about
>> 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. )

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

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=A0am, "David J Taylor" <david-tay...@blueyonder.not-this-
bit.nor-this-part.co.uk.invalid> wrote:
> > 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 tim=
e
> from NTP - that's a bit of a pain when it's running locally. =A0A pity th=
at
> Dave's new DLL couldn't include a very simple get current time call! =A0H=
int
> Dave! =A0Call: GetNTPTime - returns a 64-bit value. =A0However, a network
> query should take less than a millisecond on the local PC, so you could
> then use the timeGetTime function. =A0The ambiguity is around 49 days, so=
 it
> shouldn't be an issue. =A0The other much more accurate way /may/ be to us=
e
> QueryPerformanceCounter - a 64 bit counter running at either a few MHz or
> even at CPU-speed. =A0Yes, it would need calibrating, and you may also ha=
ve
> 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:
>
> =A0http://www.ietf.org/rfc/rfc2030.txt
>
> It's what my Delphi SNTP monitor program uses, and has about a dozen
> fields to complete.
>
> =A0http://www.satsignal.eu/software/net.htm#NTPmonitor
>
> 73,
> David

> 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 

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

> Keep asking the questions, even if they seem elementary - and I will
> try to both provide answers and record them on my Web site for others. 
> One issue which you haven't addressed (as far as I know) is how the 
> Faros program uses an accurate time.  I take it that the author of the 
> program gets the time from Windows - he does know that time is 
> typically only updated once every ten milliseconds, I guess?
> NTP doesn't have an API which can tell you the time more accurately
> than that, which is a pity because that would be very handy....
>
> 73,
> David 

Hi..

Back after getting diverted by my central heating system going on the 
blink...

Re Faros.  Good question, well presented, unknown (exactly) at this 
time!

It does run it's own internal software clock, that I do know having 
asked Alex (VE3NEA) questions about it in the past.   That in turn is 
synched to a reference by NTP (not SNTP) it does not (AFIK) use 
"Windows" time in any way.

(Sadly, he's totally uninterested in making it able to use a local GPS 
receiver with PPS, or a radio time code RX.)

It's own internal timekeeping routines use a Kalman Filter (Think that's 
what it's called) to determine "true" time from a number of NTP sources.  
It is also quite "chatty" I expect compared to a true NTP client, as it 
will poll the NTP server (or selected collection of servers in rotation) 
about every 10 seconds!  Another reason I think a local server would be 
best :-)

Generally it keeps good time, to within a mS or so, as it can reliably 
tell if a received signal comes the short or long way round the globe, 
even from New Zealand!  (A close call that one though.)

However, it (for whatever reason) is not good at handling variable 
network latency, especially if the flight times to/from the server are 
different, as seems to be the case at odd times of day at present.

With the Meinberg NTP server in the path now, doing the synchronization 
to the outside world's NTP boxes (for now) things are a little better.  
At least, it takes longer for the variable latency problem to screw 
things up, but it also takes longer to recover too.   Extra "filtering" 
in the overall path I guess.  (Software algorithms etc in the Meinberg 
software.)

Anyway.  After reading all the info here, I now think I know how to do 
it correctly, setting up the Meinberg program, and overlaying Dave Harts 
binaries on it, also doing the registry thing pointing at the PPS 
supporting serial driver, so when I get enough of the right sort of time 
next time, I'll try again.

One thing I picked up on, is the parameters in the NTP config file, 
regarding poll times.  The units of measure are not mS, but 2^n mS, I 
think?

By the time I get my head round all this, we'll have probably lost HF to 
PLT anyway.

Regards to All.

Dave Baxter.

"Dave Baxter" <spam@goes.nowhere.com> wrote in message 
news:MPG.2581b3818527b329989695@news.btopenworld.com...
[]
> 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 

In article <517b0b0d-1557-4c0e-b6b4-2d92d627258c@
2g2000prl.googlegroups.com>, davehart@gmail.com says...
> 
> On Dec 1, 13:58�UTC, Dave Baxter wrote:
> > What colateral effects will the serialpps.sys driver have on the other
> > com port, as that will be used for controling the radio (data lines
> > 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.

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

In article <MPG.2582ed6310d763dc989698@news.btopenworld.com>, 
spam@goes.nowhere.com says...
> 
> In article <517b0b0d-1557-4c0e-b6b4-2d92d627258c@
> 2g2000prl.googlegroups.com>, davehart@gmail.com says...
> > 
> > On Dec 1, 13:58�UTC, Dave Baxter wrote:
> > > What colateral effects will the serialpps.sys driver have on the other
> > > com port, as that will be used for controling the radio (data lines
> > > 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.

On Dec 4, 9:57=A0UTC, Dave Baxter wrote:
> I tried last night to "install" your serialPPS driver, onto the Win2k
> machine I have temporaraly made available to try all this.
>
> Sadly, all I get are errors like...
>
> "'reg' is not recognized as an internal or external command,
> operable program or batch file."
>
> So, I guess it's a delicate manual install for Windows then? =A0XP has th=
e
> '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"=3Dhex(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=3Dsystem32\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

In article <c237b62f-b9bb-4848-a117-
2911fa33aabf@b25g2000prb.googlegroups.com>, davehart@gmail.com says...
> 
> On Dec 4, 9:57�UTC, Dave Baxter wrote:
> > I tried last night to "install" your serialPPS driver, onto the Win2k
> > machine I have temporaraly made available to try all this.
> >
> > Sadly, all I get are errors like...
> >
> > "'reg' is not recognized as an internal or external command,
> > operable program or batch file."
> >
> > 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

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" <spam@goes.nowhere.com> wrote in message 
news:MPG.2582f2d76a9bb78e989699@news.btopenworld.com...
[]
> Hi...
>
> First, thanks for the direct email, I'll look at things in detail again
> this evening/over the weekend.
[]
> Your sumizing above, is exactly what I'd like to do, idealy all on one
> physical box if posible.  But as elsewhere, I'm not haveing much success
> stitching it all together on a box of its own at present.   The latest
> being that the 'Reg' command, usd by Dave Hart's serialpps install batch
> file, does not exist on Win2k!  (XP and later only I think.)  Oh well.
[]
> Regards to all, and thanks for being tolerant.
>
> Dave Baxter.

Dave,

As I mentioned in the private e-mail, I suggest you don't bother with the 
PPS DLL stuff until after everything else is working, because when I 
tested it although you could see a noticeable improvement in the jitter 
level as reported by NTP, the offsets seemed to be very similar with and 
without the kernel-mode stuff.  See:

  http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html#PPSAPI_DLLS

I accept that if the system was more heavily loaded the results might be 
different, though.

Hope the head cold soon clears!

73,
David 

David J Taylor wrote:
> "Dave Baxter" <spam@goes.nowhere.com> wrote in message 
> news:MPG.2582f2d76a9bb78e989699@news.btopenworld.com...
> []
>> Hi...
>>
>> First, thanks for the direct email, I'll look at things in detail again
>> this evening/over the weekend.
> []
>> Your sumizing above, is exactly what I'd like to do, idealy all on one
>> physical box if posible.  But as elsewhere, I'm not haveing much success
>> stitching it all together on a box of its own at present.   The latest
>> being that the 'Reg' command, usd by Dave Hart's serialpps install batch
>> file, does not exist on Win2k!  (XP and later only I think.)  Oh well.
> []
>> Regards to all, and thanks for being tolerant.
>>
>> Dave Baxter.
> 
> Dave,
> 
> As I mentioned in the private e-mail, I suggest you don't bother with 
> the PPS DLL stuff until after everything else is working, because when I 
> tested it although you could see a noticeable improvement in the jitter 
> level as reported by NTP, the offsets seemed to be very similar with and 
> without the kernel-mode stuff.  See:
> 
>  http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html#PPSAPI_DLLS
> 
> I accept that if the system was more heavily loaded the results might be 
> different, though.

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

> 
> Hope the head cold soon clears!
> 
> 73,
> David

On 2009-12-04, Dave Baxter <spam@goes.nowhere.com> wrote:
> In article <YQPRm.11377$Ym4.1985@text.news.virginmedia.com>, 
> david-taylor@blueyonder.not-this-bit.nor-this-part.co.uk.invalid says...
.....
>
> Your sumizing above, is exactly what I'd like to do, idealy all on one 
> physical box if posible.  But as elsewhere, I'm not haveing much success 
> stitching it all together on a box of its own at present.   The latest 
> being that the 'Reg' command, usd by Dave Hart's serialpps install batch 
> file, does not exist on Win2k!  (XP and later only I think.)  Oh well.

Please, do not use a Windows box as your main server. get a cheap ( your
local flea market should have one for $50) computer, install linux or
freebsd, purely for running ntp on it, and use it as your server. 

unruh wrote:
> On 2009-12-04, Dave Baxter <spam@goes.nowhere.com> wrote:
>> In article <YQPRm.11377$Ym4.1985@text.news.virginmedia.com>, 
>> david-taylor@blueyonder.not-this-bit.nor-this-part.co.uk.invalid says...
> ....
>> Your sumizing above, is exactly what I'd like to do, idealy all on one 
>> physical box if posible.  But as elsewhere, I'm not haveing much success 
>> stitching it all together on a box of its own at present.   The latest 
>> being that the 'Reg' command, usd by Dave Hart's serialpps install batch 
>> file, does not exist on Win2k!  (XP and later only I think.)  Oh well.
> 
> Please, do not use a Windows box as your main server. get a cheap ( your
> local flea market should have one for $50) computer, install linux or
> freebsd, purely for running ntp on it, and use it as your server. 
> 

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.

"unruh" <unruh@wormhole.physics.ubc.ca> wrote in message 
news:slrnhhilur.scb.unruh@wormhole.physics.ubc.ca...
[]
> Please, do not use a Windows box as your main server. get a cheap ( your
> local flea market should have one for $50) computer, install linux or
> freebsd, purely for running ntp on it, and use it as your server.

Bill,

The requirement is to provide time within a millisecond or so for a 
program running on a Windows PC.  It makes much more sense to have that 
same PC work as its own NTP server using a GPS/PPS source, purely from a 
performance point of view.

Providing an extra PC with a network connection, would result in poorer 
performance for the task in hand, together with all the overheads of 
learning a different OS and the time that would take, plus all the energy 
costs of running that extra PC!

Yes, you can get better absolute performance from a FreeBSD box, but in 
this case that performance is not needed, could not be communicated to the 
application which needs the time, and would provide a quite unnecessary 
overhead.  Linux/FreeBSD provides a /worse/ solution in this case.

I tire of the anti-Windows mantra which sometimes appears in this group, 
particularly when it occurs with no consideration for the task in hand.  A 
good solution will not be over-engineered nor require two PCs where one 
would do.

David 

David J Taylor wrote:
> "unruh" <unruh@wormhole.physics.ubc.ca> wrote in message 
> news:slrnhhilur.scb.unruh@wormhole.physics.ubc.ca...
> []
>> Please, do not use a Windows box as your main server. get a cheap ( your
>> local flea market should have one for $50) computer, install linux or
>> freebsd, purely for running ntp on it, and use it as your server.
> 
> Bill,
> 
> The requirement is to provide time within a millisecond or so for a 
> program running on a Windows PC.  It makes much more sense to have that 
> same PC work as its own NTP server using a GPS/PPS source, purely from a 
> performance point of view.
> 
> Providing an extra PC with a network connection, would result in poorer 
> performance for the task in hand, together with all the overheads of 
> learning a different OS and the time that would take, plus all the 
> energy costs of running that extra PC!
> 
> Yes, you can get better absolute performance from a FreeBSD box, but in 
> this case that performance is not needed, could not be communicated to 
> the application which needs the time, and would provide a quite 
> unnecessary overhead.  Linux/FreeBSD provides a /worse/ solution in this 
> case.
> 
> I tire of the anti-Windows mantra which sometimes appears in this group, 
> particularly when it occurs with no consideration for the task in hand.  
> A good solution will not be over-engineered nor require two PCs where 
> one would do.
> 
> David

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!

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

> 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. =
=A0A
> good solution will not be over-engineered nor require two PCs where one
> would do.
>
> David

"jack" <> wrote in message 
news:edbf7025-8578-48f5-b714-3a06b5c3ce61@c34g2000yqn.googlegroups.com...
> David,
>
> I totally agree with you. My main application runs on Windows for
> various reasons (cheap hardware for one) and had been using PCI IRIG
> board to keep time. I was not merely looking for a solution to keep
> time. I was looking for a millisecond solution that my application can
> access on a Windows box.
>
> PS: I experimented with falling/rising edge of the 1PPS and now the
> difference between NTP and my IRIG board is a few milliseconds.
>
> Jack

Glad you resolved the leading/trailing edge issue, Jack.  Now we need a 
way to tune out those remaining few microseconds accurately!

It sounds as if your application - like some of mine - would benefit if 
NTP were able to provide a new function where you could call it on your 
local PC to get the time, rather than having to use a call via a network 
packet, with all those overheads.  The function would be really simple, 
taking no arguments:

  ntpGetTime

and returning a 64-bit timestamp value (as per 
http://www.ietf.org/rfc/rfc2030.txt).

Would some kind soul like Dave Hart care to provide a small DLL which 
could do this - perhaps even as part of his serial kernel-mode PPS support 
DLL?

Perhaps there is some fundamental point I'm missing which makes this 
difficult, though?

Cheers,
David 

Richard B. Gilbert <rgilbert88@comcast.net> wrote:
> 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...

On Dec 4, 2:10=A0pm, "Richard B. Gilbert" <rgilber...@comcast.net>
wrote:
>
> unruh wrote:
>
> > Please, do not use a Windows box as your main server. get a cheap ( you=
r
> > 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. =A0Often, there is
> nothing wrong with them, they are just old and/or slow. =A0NTP does not
> require a lot of computing power!! =A0If 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.

On Dec 5, 6:56=A0UTC, "David J Taylor" wrote:
> 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. =A0The function would be really simple,
> taking no arguments:
>
> =A0 ntpGetTime
>
> and returning a 64-bit timestamp value (as perhttp://www.ietf.org/rfc/rfc=
2030.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 suppor=
t
> 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

On 2009-12-05, Evandro Menezes <evandro@mailinator.com> wrote:
> On Dec 4, 2:10?pm, "Richard B. Gilbert" <rgilber...@comcast.net>
> wrote:
>>
>> unruh wrote:
>>
>> > Please, do not use a Windows box as your main server. get a cheap ( your
>> > local flea market should have one for $50) computer, install linux or
>> > freebsd, purely for running ntp on it, and use it as your server.
>>
>> 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. 

>
> Such suggestion may be fine for one's own garage project, but not
> anywhere else.

Evandro Menezes writes:
> No engineer or analyst or consultant worth its salt would suggest a
> banged up PC to perform any role in a project.

Bill Unruh writes:
> Especially if he were getting a kickback on the purchase

If I tell a client that he should install a used machine and it fails he
will blame me.  If I tell him to buy a new one and it fails he will
blame the vendor (or more likely, if I recommend a used machine he will
buy a new one anyway and then never hire me again since he "knows" that
no one competent would ever recommend the use of a "banged up pc" for
anything serious).  The fact that the used machine would work fine is
irrelevant.
-- 
John Hasler 
jhasler@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

Evandro Menezes wrote:
> On Dec 4, 2:10 pm, "Richard B. Gilbert" <rgilber...@comcast.net>
> wrote:
>> unruh wrote:
>>
>>> Please, do not use a Windows box as your main server. get a cheap ( your
>>> local flea market should have one for $50) computer, install linux or
>>> freebsd, purely for running ntp on it, and use it as your server.
>> 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.

John Hasler <jhasler@newsguy.com> wrote in
news:873a3pvuqr.fsf@thumper.dhh.gt.org: 

> Evandro Menezes writes:
>> No engineer or analyst or consultant worth its salt would suggest a
>> banged up PC to perform any role in a project.
> 
> Bill Unruh writes:
>> Especially if he were getting a kickback on the purchase
> 
> If I tell a client that he should install a used machine and it fails
> he will blame me.  If I tell him to buy a new one and it fails he will
> blame the vendor (or more likely, if I recommend a used machine he
> will buy a new one anyway and then never hire me again since he
> "knows" that no one competent would ever recommend the use of a
> "banged up pc" for anything serious).  The fact that the used machine
> would work fine is irrelevant.


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,

On Dec 6, 12:48=A0am, "Richard B. Gilbert" wrote:
> My NTP server is an old, old, Sun Ultra 10 workstation (I'm guessing)
> ca. 1998. =A0It gets the job done. =A0If 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 (~=3D 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

Dave Hart writes:
> ...Everything in the x86 space...

So don't use x86.
-- 
John Hasler 
jhasler@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

"Dave Hart" <davehart@gmail.com> wrote in message 
news:2c2ad514-3566-4a8f-a5eb-fa62c737ac73@m7g2000prd.googlegroups.com...
[]
> I am guessing you're actually in a better position than me to provide
> a DLL exposing a function to get the time from ntpd.  There is no way
> other than a NTP packet to request a timestamp from ntpd.
> Additionally, if ntpd is busy, it may take some time for ntpd to send
> its response.  You'll get a very good idea of the time when you
> receive the response, but not necessarily of the time you requested
> the time.  Since waiting on ntpd is involved, such a function could be
> provided with a nonblocking option where the caller is given a socket
> to select for readability while awaiting the response, and calls back
> after its readable to retrieve the time.
>
> Cheers,
> Dave Hart

Dave, thanks for that.  I must be missing something here, although I 
haven't been able to check the source code.  Is there not a routine 
somewhere inside ntpd.exe which timestamps the packets in response to a 
request over the network?  How else are the packets timestamped?  Could 
not that routine be exposed, or the variables it uses?  Yes, I can write a 
DLL (in Delphi/Pascal) it I could get access to the data and algorithms, 
but it seems to me far easier to re-use the existing NTPD code.

I must confess to not having looked at NTP packets from Windows servers 
for a while - don't tell me they have 10-15ms resolution!

Cheers,
David 

"nemo_outis" <abc@xyz.com> wrote in message 
news:Xns9CD8AC8074753pqwertyu@69.16.185.250...
[]
> Overkill is bad engineering and bad ethics.
>
> Regards,

Suggesting that there is no need to install an extra Linux machine if 
Windows can keep time well enough for the job in hand.

Cheers,
David 

On Dec 6, 6:50=A0UTC, "David J Taylor" wrote:
> "Dave Hart" <daveh...@gmail.com> wrote
> > I am guessing you're actually in a better position than me to provide
> > a DLL exposing a function to get the time from ntpd. =A0There is no way
> > other than a NTP packet to request a timestamp from ntpd.
>
> Dave, thanks for that. =A0I must be missing something here, although I
> haven't been able to check the source code. =A0Is there not a routine
> somewhere inside ntpd.exe which timestamps the packets in response to a
> request over the network? =A0How else are the packets timestamped? =A0Cou=
ld
> not that routine be exposed, or the variables it uses? =A0

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

"Dave Hart" <> wrote in message 
news:b51e46f7-4b0d-4d40-a6b2-574d459ba7bd@s21g2000prm.googlegroups.com...
[]
> If we wanted to define a new Windows-only service provided by ntpd,
> sure, there could be some combination of shared memory and IPC objects
> like named events used to expose a way for another program to ask ntpd
> to go down its timestamping path and provide the result.  There's no
> need on non-Windows systems where the system clock is high precision
> and typically interpolated.  Such a mechanism would be a potential
> local DoS avenue again unique to Windows, which while popular in
> general, isn't the center of the NTP universe.
>
> The reason I suggested you are in a better position than me to provide
> that capability is you've already written code that runs on Windows
> and retrives the time via a NTP request/reply pair of packets.  Wire
> it to [::1]:123 and/or 127.0.0.1:123 and there's your ntpGetTime().
>
> Cheers,
> Dave Hart

Thanks, Dave.  I suppose I was hoping that with a simple compile switch 
you might be able to provide ntpd.dll as well as nptd.exe, with the DLL 
exposing just one function.  I don't believe that using shared memory is 
complex on Windows (i.e. between the DLL and the EXE) but it's something 
I've never done.

If someone needs the network version and they ask nicely, I could look at 
that.

I wonder how the overheads would compare if the SNMP interface could 
expose a current time function?  Mind you, I have seen SNMP problems with 
more than 32-bit numbers!

Cheers,
David 

John Hasler wrote:
> 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.)

In article <slrnhhilur.scb.unruh@wormhole.physics.ubc.ca>, 
unruh@wormhole.physics.ubc.ca says...
> 
> On 2009-12-04, Dave Baxter <spam@goes.nowhere.com> wrote:
> > In article <YQPRm.11377$Ym4.1985@text.news.virginmedia.com>, 
> > david-taylor@blueyonder.not-this-bit.nor-this-part.co.uk.invalid says...
> ....
> >
> > Your sumizing above, is exactly what I'd like to do, idealy all on one 
> > physical box if posible.  But as elsewhere, I'm not haveing much success 
> > stitching it all together on a box of its own at present.   The latest 
> > being that the 'Reg' command, usd by Dave Hart's serialpps install batch 
> > file, does not exist on Win2k!  (XP and later only I think.)  Oh well.
> 
> Please, do not use a Windows box as your main server. get a cheap ( your
> local flea market should have one for $50) computer, install linux or
> freebsd, purely for running ntp on it, and use it as your server. 

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

In article <ab949720-16c4-4032-9266-8bdc88c636b9
@h10g2000vbm.googlegroups.com>, evandro@mailinator.com says...
> 
> On Dec 4, 2:10�pm, "Richard B. Gilbert" <rgilber...@comcast.net>
> wrote:
> >
> > unruh wrote:
> >
> > > Please, do not use a Windows box as your main server. get a cheap ( your
> > > local flea market should have one for $50) computer, install linux or
> > > freebsd, purely for running ntp on it, and use it as your server.
> >
> > 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" <david-taylor@blueyonder.not-this-bit.nor-this-
part.co.uk.invalid> wrote in news:pzISm.12393$Ym4.11362
@text.news.virginmedia.com:

> "nemo_outis" <abc@xyz.com> wrote in message 
> news:Xns9CD8AC8074753pqwertyu@69.16.185.250...
> []
>> Overkill is bad engineering and bad ethics.
> 
> Suggesting that there is no need to install an extra Linux machine if 
> Windows can keep time well enough for the job in hand.


"IF" your aunt had wheels she'd be a trolleycar (and there are coarser 
variants on the theme).  

However, whether Windows can keep time well enough for the job in hand is, 
in fact, disputed by several.  Using petitio principii as a springboard for 
jumping to further conclusions is itself less than elegant engineering :-)

Regards,

"nemo_outis" <abc@xyz.com> wrote in message 
news:Xns9CD96997339D9pqwertyu@69.16.185.247...
[]
> 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 J Taylor wrote:

> Stated requirement:
> 
>  - around 1 millisecond (on Window 2000 or XP IIRC).
> 
> Observed performance examples:

These don't tell you the jitter due to the scheduling of the application 
program and interrupt latencies from the real world events to the point 
where the code tries to read the time.

"David Woolley" <david@ex.djwhome.demon.invalid> wrote in message 
news:hfgvt5$g6f$1@news.eternal-september.org...
> David J Taylor wrote:
>
>> Stated requirement:
>>
>>  - around 1 millisecond (on Window 2000 or XP IIRC).
>>
>> Observed performance examples:
>
> These don't tell you the jitter due to the scheduling of the application 
> program and interrupt latencies from the real world events to the point 
> where the code tries to read the time.

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 

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

In article <5_9Sm.11792$Ym4.5933@text.news.virginmedia.com>, david-
taylor@blueyonder.not-this-bit.nor-this-part.co.uk.invalid says...
> 
> "Dave Baxter" <spam@goes.nowhere.com> wrote in message 
> news:MPG.2582f2d76a9bb78e989699@news.btopenworld.com...
> []
> > Hi...
> >
> > First, thanks for the direct email, I'll look at things in detail again
> > this evening/over the weekend.
> []
> > Your sumizing above, is exactly what I'd like to do, idealy all on one
> > physical box if posible.  But as elsewhere, I'm not haveing much success
> > stitching it all together on a box of its own at present.   The latest
> > being that the 'Reg' command, usd by Dave Hart's serialpps install batch
> > file, does not exist on Win2k!  (XP and later only I think.)  Oh well.
> []
> > Regards to all, and thanks for being tolerant.
> >
> > Dave Baxter.
> 
> Dave,
> 
> As I mentioned in the private e-mail, I suggest you don't bother with the 
> PPS DLL stuff until after everything else is working, because when I 
> tested it although you could see a noticeable improvement in the jitter 
> level as reported by NTP, the offsets seemed to be very similar with and 
> without the kernel-mode stuff.  See:
> 
>   http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html#PPSAPI_DLLS
> 
> I accept that if the system was more heavily loaded the results might be 
> different, though.
> 
> Hope the head cold soon clears!
> 
> 73,
> David 

Hi again.

Well, after spending a lot if time reading (while sniffing) again, and 
restarting from zero (again!)  I seem to have the Meinberg Windows port 
of NTPD etc working as a local Stratum 3 server on my LAN.  From that 
you will note I have not yet got the GPS hooked up, but I have installed 
all Dave Hart's code to (hopefully) enable PPS support when I get to do 
that.

I've also made a note to configure the GPS to only output the GPRMC 
sentence, shame, as I was hoping to share the other info with some other 
app's, via VSPE (by Eterlogic) or GPS-Gate (by Franson.)  I have other 
GPS RX's though, so no real problem, they dont use much energy.

I have also pointed Faros to this new local NTP server, and the server 
is the only "thing" that now "goes out" and gets it's synch from the 
'net (uk ntp pool)  So my public "NTP Footprint" has hopefully srunk 
somewhat.

Faros seems very happy too, so a good result just getting this far.

At the moment, all the NTP server stuff is on a seperate (more or less 
dedicated to NTP, running Win2k) machine to the one running Faros, but 
as my experience with all this improves, I will eventualy put it all on 
one physical machine.

My ISP have done yet another huge re-arangement with their network, but 
at present what effect that will have on the 'net based NTP service I 
don't know, but whatever, I'm well on the road now to becoming NTP "self 
sufficent" as it were.

Many thanks to all here for their advice and support with all this.  
Very much appreciated I can tell you!

I will probably be back when I get the GPS RX sorted an reconnected.

Thanks again so far.

Best Regards to All.

"Dave Baxter" <spam@goes.nowhere.com> wrote in message 
news:MPG.25871af0923a862f9896a4@news.btopenworld.com...
[]
> Hi again.
>
> Well, after spending a lot if time reading (while sniffing) again, and
> restarting from zero (again!)  I seem to have the Meinberg Windows port
> of NTPD etc working as a local Stratum 3 server on my LAN.  From that
> you will note I have not yet got the GPS hooked up, but I have installed
> all Dave Hart's code to (hopefully) enable PPS support when I get to do
> that.
[]
> Many thanks to all here for their advice and support with all this.
> Very much appreciated I can tell you!
>
> I will probably be back when I get the GPS RX sorted an reconnected.
>
> Thanks again so far.
>
> Best Regards to All.

Good to hear of progress, Dave and thanks for your reports.  If you see 
something missing or wrong on my Web site, or something you feel might be 
better explained, just shout.

Good luck!

73,
David 

Dave Hart wrote:
> On Dec 6, 6:50 UTC, "David J Taylor" wrote:
>> "Dave Hart" <daveh...@gmail.com> wrote
>>> I am guessing you're actually in a better position than me to provide
>>> a DLL exposing a function to get the time from ntpd.  There is no way
>>> other than a NTP packet to request a timestamp from ntpd.
>> Dave, thanks for that.  I must be missing something here, although I
>> haven't been able to check the source code.  Is there not a routine
>> somewhere inside ntpd.exe which timestamps the packets in response to a
>> request over the network?  How else are the packets timestamped?  Could
>> not that routine be exposed, or the variables it uses?  
> 
> 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

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.