http://www.atl.external.lmco.com/projects/QoS/documents/win7_feb23.png

I decided to start a new thread since the prev. one got a bit long and
also has on going discussions about GPS PPS hardware.

Based on > 1 response I upgraded to

ntp-4.2.7p98-win-x86-bin.zip

from

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

However, though NTP is running and the "offset" values on my win7-32
box are quite horrible. (i should note that on same subnet using same
time server a fedora12 box achieves sub 1msec offset easily and stays
there. )

The graphic below shows how terrible the ntp is behaving on my windows
7 box.

http://www.atl.external.lmco.com/projects/QoS/documents/win7_feb23.png

What else can I try here? This is puzzling. Is there any option/patch
one has to apply to windows7-32 for NTP to work well on it?

Gautam

On Thu, Feb 24, 2011 at 10:47 AM, Gautam Thaker <ghthaker@gmail.com> wrote:


> However, though NTP is running and the "offset" values on my win7-32
> box are quite horrible. (i should note that on same subnet using same
> time server a fedora12 box achieves sub 1msec offset easily and stays
> there. )

One thing to do is verify that the the graph of offset values really
does represent the offset of your PC's system clock.  In other words
"is the graph correct?"

Clearly something is wrong and it's a false assumption to assume
everything is working when you know there must be a problem.    try an
experiment and make the Win 7 ntpd a peer of the Linux ntpd.  See what
ntpq run under Linux says about the ntpd in the Win 7 box.  make sure
the Linux ntps has at least three pool servers so it can apply the
clock select algorithm and be able to identify the Win 7 as a
"falseticker".  This should, I think, prove the problem is real.

Next, assuming the graph is is correct I notice the offset is
quantized to only a few few different values.    This should be a
strong clue.  Seems to me the only way this quantization could happen
is if the system clock where being jumped.  I'd think that if the
clock's rate was being modulated then we'd see many different values
of delay.

-- 
=====
Chris Albertson
Redondo Beach, California

> Based on > 1 response I upgraded to
>
> ntp-4.2.7p98-win-x86-bin.zip
>
> from
>
> http://davehart.net/ntp/win/x86/
>
> However, though NTP is running and the "offset" values on my win7-32
> box are quite horrible. (i should note that on same subnet using same
> time server a fedora12 box achieves sub 1msec offset easily and stays
> there. )
>
> The graphic below shows how terrible the ntp is behaving on my windows
> 7 box.
>
> http://www.atl.external.lmco.com/projects/QoS/documents/win7_feb23.png
>
> What else can I try here? This is puzzling. Is there any option/patch
> one has to apply to windows7-32 for NTP to work well on it?
>
> Gautam

On my LAN, I set minpoll=maxpoll=5 (32 seconds), and this is what I see on 
a LAN-synched Win-7 64-bit PC:

  http://www.satsignal.eu/mrtg/alta-ntp-b.html

One parameter which affected other very network sensitive software was:

  http://en.wikipedia.org/wiki/Multimedia_Class_Scheduler_Service
  http://support.microsoft.com/kb/948066
  http://msdn.microsoft.com/en-us/library/ms684247%28VS.85%29

In: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows 
NT\CurrentVersion\Multimedia\SystemProfile\
I set: NetworkThrottlingIndex to -1 (FFFFFFFF) (stops throttle)
and SystemResponsiveness to 80 (=80% to non-multmedia)

these may make a difference for you, although I didn't change them to get 
better timekeeping.  Feed the box with PPS and you might see:

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

which is from a Windows-7 32-bit system.

Are you sure that, on your system, there are no other programs trying to 
set the time?  What do the NTP entries in the event viewer say?  Have you 
set the "High performance" power option on your PC, or at least stopped 
anything which grossly changes the CPU clock frequency?  I would like to 
see your systems as good as mine, if I can help!

Cheers,
David 

On Thu, Feb 24, 2011 at 12:14 PM, David J Taylor
<david-taylor@blueyonder.co.uk.invalid> wrote:

> Are you sure that, on your system, there are no other programs trying to set
> the time?

That is what I thought, that something was "jumping" the system clock.
 The fact that the offset value is always anice even value I think
proves the clock is not drifting or noisy by being set.
-- 
=====
Chris Albertson
Redondo Beach, California

On Feb 24, 3:14=A0pm, "David J Taylor" <david-
tay...@blueyonder.co.uk.invalid> wrote:

> In: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
> NT\CurrentVersion\Multimedia\SystemProfile\
> I set: NetworkThrottlingIndex to -1 (FFFFFFFF) (stops throttle)
> and SystemResponsiveness to 80 (=3D80% to non-multmedia)
>
> these may make a difference for you, although I didn't change them to get
> better timekeeping.

OK, i changed the regedit NetworkThrottleIndex  to hex FFFFFFFF but it
did not show (-1), instead it shows
(4294967295) which is unsigned version of -1.. hopefully ok.

i have min and max poll to 32. and i restarted service. Not seeing
improvements. I will have to try other suggestions next.
istry values (tho
>=A0Feed the box with PPS and you might see:
>
> =A0http://www.satsignal.eu/mrtg/stamsund_ntp_2.html

Unfortunately, can't do PPS and just need to be within +/- 5msec and
not jump aroudn so much. (Right now obviously I am not syncing at
all.)

I understand win7 service pack 1 jsut was released, wonder if it might
make a difference....


>
> which is from a Windows-7 32-bit system.
>
> Are you sure that, on your system, there are no other programs trying to
> set the time? =A0What do the NTP entries in the event viewer say? =A0Have=
 you
> set the "High performance" power option on your PC, or at least stopped
> anything which grossly changes the CPU clock frequency? =A0I would like t=
o
> see your systems as good as mine, if I can help!

this is  DELL R710 server class machine, i believe we have no power
saving etc. options at all.

Gautam
PS Appreciate again all the help, i must be missing something simple/
obvious or something subtle/devilish.

>
> Cheers,
> David

On Feb 24, 4:03=A0pm, Chris Albertson <albertson.ch...@gmail.com> wrote:
> On Thu, Feb 24, 2011 at 12:14 PM, David J Taylor
>
> <david-tay...@blueyonder.co.uk.invalid> wrote:
> > Are you sure that, on your system, there are no other programs trying t=
o set
> > the time?
>
> That is what I thought, that something was "jumping" the system clock.
> =A0The fact that the offset value is always anice even value I think
> proves the clock is not drifting or noisy by being set.

Well, the windows Time adjustments are off. In the graph the
measurements are taken every 10 seconds, and w/ Poll value reaching
1024 there are it seems many samples over which the value does not
change. W/ minpoll=3Dmaxpoll=3D32, i still see jumps in offset and offsetl
values are all positive, as in the past and between 0 and ~175msec in
about 2 hours of running.

Gautam


> --
> =3D=3D=3D=3D=3D
> Chris Albertson
> Redondo Beach, California

Here is what the Windows7's event log says. The last restart w/
4.2.7.p98 was started at 3:51. (It is not giving a good sync). Earlier
than that I had an error in specifying minpoll=maxpoll=32, but i fixed
that and i do see "poll" value of 32.


Level	Date and Time	Source	Event ID	Task Category
Information	2/24/2011 3:51:02 PM	NTP	3	None	peers refreshed

Information	2/24/2011 3:51:02 PM	NTP	3	None	Listen normally on 9
Loopback Pseudo-Interface 1 127.0.0.1:123

Information	2/24/2011 3:51:02 PM	NTP	3	None	Listen normally on 8
Loopback Pseudo-Interface 1 [::1]:123

Information	2/24/2011 3:51:02 PM	NTP	3	None	Listen normally on 7 Local
Area Connection 169.254.111.50:123

Information	2/24/2011 3:51:02 PM	NTP	3	None	Listen normally on 6 Local
Area Connection [fe80::fc5c:66dc:373d:6f32%11]:123

Information	2/24/2011 3:51:02 PM	NTP	3	None	Listen normally on 5 Local
Area Connection 3 192.168.214.17:123

Information	2/24/2011 3:51:02 PM	NTP	3	None	Listen normally on 4 Local
Area Connection 3 [fe80::84ef:f517:698:908e%15]:123

Information	2/24/2011 3:51:02 PM	NTP	3	None	Listen normally on 3 Local
Area Connection 4 169.254.64.63:123

Information	2/24/2011 3:51:02 PM	NTP	3	None	Listen normally on 2 Local
Area Connection 4 [fe80::a9ac:1886:5edd:403f%16]:123

Information	2/24/2011 3:51:02 PM	NTP	3	None	Listen and drop on 1
v6wildcard [::]:123

Information	2/24/2011 3:51:02 PM	NTP	3	None	Listen and drop on 0
v4wildcard 0.0.0.0:123

Information	2/24/2011 3:51:02 PM	NTP	3	None	proto: precision = 999.600
usec

Information	2/24/2011 3:51:02 PM	NTP	3	None	using Windows clock
directly

Information	2/24/2011 3:51:02 PM	NTP	3	None	Windows clock precision
1.000 msec, min. slew 6.410 ppm/s

Information	2/24/2011 3:51:02 PM	NTP	3	None	Clock interrupt period
15.600 msec (startup slew -6.4 usec/period)

Information	2/24/2011 3:51:02 PM	NTP	3	None	Performance counter
frequency 2.083 MHz

Information	2/24/2011 3:51:02 PM	NTP	3	None	MM timer resolution:
1..1000000 msec, set to 1 msec

Information	2/24/2011 3:51:02 PM	NTP	3	None	Raised to realtime
priority class

Information	2/24/2011 3:51:02 PM	NTP	3	None	ntpd 4.2.7p98-o Dec 20
9:19:18.70 (UTC-00:00) 2010  (1)

Information	2/24/2011 3:50:37 PM	NTP	3	None	ntservice: The Network
Time Protocol Service is stopping.

Information	2/24/2011 3:48:55 PM	NTP	3	None	HZ 64.102 using 43 msec
timer 23.256 Hz 64 deep

Information	2/24/2011 3:48:49 PM	NTP	3	None	peers refreshed

Information	2/24/2011 3:48:49 PM	NTP	3	None	Listen normally on 9
Loopback Pseudo-Interface 1 127.0.0.1:123

Information	2/24/2011 3:48:49 PM	NTP	3	None	Listen normally on 8
Loopback Pseudo-Interface 1 [::1]:123

Information	2/24/2011 3:48:49 PM	NTP	3	None	Listen normally on 7 Local
Area Connection 169.254.111.50:123

Information	2/24/2011 3:48:49 PM	NTP	3	None	Listen normally on 6 Local
Area Connection [fe80::fc5c:66dc:373d:6f32%11]:123

Information	2/24/2011 3:48:49 PM	NTP	3	None	Listen normally on 5 Local
Area Connection 3 192.168.214.17:123

Information	2/24/2011 3:48:49 PM	NTP	3	None	Listen normally on 4 Local
Area Connection 3 [fe80::84ef:f517:698:908e%15]:123

Information	2/24/2011 3:48:49 PM	NTP	3	None	Listen normally on 3 Local
Area Connection 4 169.254.64.63:123

Information	2/24/2011 3:48:49 PM	NTP	3	None	Listen normally on 2 Local
Area Connection 4 [fe80::a9ac:1886:5edd:403f%16]:123

Information	2/24/2011 3:48:49 PM	NTP	3	None	Listen and drop on 1
v6wildcard [::]:123

Information	2/24/2011 3:48:49 PM	NTP	3	None	Listen and drop on 0
v4wildcard 0.0.0.0:123

Error	2/24/2011 3:48:49 PM	NTP	1	None	syntax error in C:\Tools\NTP\etc
\ntp.conf line 18, column 1

Error	2/24/2011 3:48:49 PM	NTP	1	None	line 18 column 1 syntax error,
unexpected T_Minpoll, expecting $end

Information	2/24/2011 3:48:49 PM	NTP	3	None	proto: precision = 0.400
usec

Information	2/24/2011 3:48:46 PM	NTP	3	None	HZ 64.102 using 43 msec
timer 23.256 Hz 64 deep

Information	2/24/2011 3:48:46 PM	NTP	3	None	Windows clock precision
15.600 msec, min. slew 6.410 ppm/s

Information	2/24/2011 3:48:46 PM	NTP	3	None	Clock interrupt period
15.600 msec

Information	2/24/2011 3:48:46 PM	NTP	3	None	Performance counter
frequency 2.083 MHz

Information	2/24/2011 3:48:46 PM	NTP	3	None	MM timer resolution:
1..1000000 msec, set to 1 msec

Information	2/24/2011 3:48:46 PM	NTP	3	None	Raised to realtime
priority class

Information	2/24/2011 3:48:46 PM	NTP	3	None	ntpd 4.2.7p98-o Dec 20
9:19:18.70 (UTC-00:00) 2010  (1)

Information	2/24/2011 3:48:20 PM	NTP	3	None	ntservice: The Network
Time Protocol Service is stopping.

Warning	2/24/2011 3:41:11 PM	NTP	2	None	Unable to remove prior drift
file C:\Tools\NTP\etc\ntp.drift, No such file or directory

Information	2/24/2011 3:26:16 PM	VSS	8224	None	The VSS service is
shutting down due to idle timeout.
Information	2/24/2011 3:08:04 PM	Windows Error Reporting	1001
None	"Fault bucket , type 0
Event Name: MpTelemetry
Response: Not available
Cab Id: 0

On 2/24/2011 1:03 PM, Chris Albertson wrote:
> On Thu, Feb 24, 2011 at 12:14 PM, David J Taylor
> <david-taylor@blueyonder.co.uk.invalid> wrote:
>
>> Are you sure that, on your system, there are no other programs trying to set
>> the time?
>
> That is what I thought, that something was "jumping" the system clock.
>  The fact that the offset value is always anice even value I think
> proves the clock is not drifting or noisy by being set.

Can't noselect be used?
 If the offsets still jump around (as opposed to just drifting away),
  you will have a better idea if something else is messing with the time.

   Several (4?) noselect servers might be necessary to
    verify that it is the client, not the inhouse server,
    that is jumping around.

-- 
E-Mail Sent to this address <BlackList@Anitech-Systems.com>
  will be added to the BlackLists.

David:

In looking at the data on all your machines I note a few things:

http://www.satsignal.eu/mrtg/performance_ntp.php

1) hydra is a windows7 machine, and running NTP 4.2.7, but Molde is
also a Win7 machine and seems to be doing just fine running NTP 4.2.4
version.

2) Gemini, hydra and molde, all as Windows Vista and newer, yet you
are not having any problems that I seem to not overcome.

Gautam

If the following provides some clue to any one.

As for the question if the server is jumping or the client is jumping,
i also have a fedora12 linux machine on the same subnet getting NTP
time for the same server as this windows 7 machine. The fedora machine
sync's to submsec and stays there with slight variations but pretty
solid overall.

Gautam

$ ntpq -pnc rv
     remote           refid      st t when poll reach   delay
offset  jitter
==============================================================================
*192.168.214.3   192.168.35.253   2 u    1   32  377    0.060
138.779  23.994
associd=0 status=0613 leap_none, sync_ntp, 1 event, spike_detect,
version="ntpd 4.2.7p98-o Dec 20 9:19:18.70 (UTC-00:00) 2010  (1)",
processor="x86", system="Windows", leap=00, stratum=3, precision=-10,
rootdelay=0.091, rootdisp=179.010, refid=192.168.214.3,
reftime=d11169fb.a790a9bb  Thu, Feb 24 2011 18:36:27.654,
clock=d1116a1e.8acb1056  Thu, Feb 24 2011 18:37:02.542, peer=17943,
tc=5,
mintc=3, offset=95.446, frequency=-325.007, sys_jitter=28.860,
clk_jitter=27.862, clk_wander=3.082

>> Are you sure that, on your system, there are no other programs trying 
>> to set
>> the time?
>
> That is what I thought, that something was "jumping" the system clock.
> The fact that the offset value is always anice even value I think
> proves the clock is not drifting or noisy by being set.
> -- 
> =====
> Chris Albertson
> Redondo Beach, California

Check that W32time isn't showing in the process list (with "Show processes 
from all users" set).  I asked what NTP had logged in the event viewer. 
Also: what is in the drift file (in NTP's "etc" directory).  If it's a 
number near 500 (either positive or negative) that may indicate that the 
clock on your PC is rather too far off correct for NTP to be able to 
correct it (more than 500 parts per million away).

Cheers,
David 

> David:
>
> In looking at the data on all your machines I note a few things:
>
> http://www.satsignal.eu/mrtg/performance_ntp.php
>
> 1) hydra is a windows7 machine, and running NTP 4.2.7, but Molde is
> also a Win7 machine and seems to be doing just fine running NTP 4.2.4
> version.
>
> 2) Gemini, hydra and molde, all as Windows Vista and newer, yet you
> are not having any problems that I seem to not overcome.
>
> Gautam

Yes, Gautam, (2) is what is puzzling me as well!

There was an issue with the Vista PC Gemini as the hardware connected (a 
USB DVB data receiver) appears to interact badly with the particular 
motherboard and AMD CPU.

There was also a still-unresolved issue between NTP version 4.2.4 and 
4.2.5 where only versions built by Dave Hart up to around his 273 build 
worked significantly better than later 4.2.4 versions and 4.2.5.  This has 
been reported but is not resolved.  For that reason, if I want the best 
timekeeping on Vista or Windows-7 systems I might use 4.2.4 (273), or if I 
want to reproduce the more typical user experience I will just run the 
latest NTP.  There was some discussion about this here:

  http://www.satsignal.eu/ntp/V4.2.4.vs.V4.2.5.html

but the "bad" performance was nothing like you are seeing.  So once you 
remove the steps, 4.2.4 (273) may be a treasured version of NTP!

Cheers,
David 

> Here is what the Windows7's event log says. The last restart w/
> 4.2.7.p98 was started at 3:51. (It is not giving a good sync). Earlier
> than that I had an error in specifying minpoll=maxpoll=32, but i fixed
> that and i do see "poll" value of 32.
>
>
> Level Date and Time Source Event ID Task Category
> Information 2/24/2011 3:51:02 PM NTP 3 None peers refreshed
[]
> Information 2/24/2011 3:51:02 PM NTP 3 None proto: precision = 999.600
> usec
>
> Information 2/24/2011 3:51:02 PM NTP 3 None using Windows clock
> directly
>
> Information 2/24/2011 3:51:02 PM NTP 3 None Windows clock precision
> 1.000 msec, min. slew 6.410 ppm/s
>
> Information 2/24/2011 3:51:02 PM NTP 3 None Clock interrupt period
> 15.600 msec (startup slew -6.4 usec/period)
>
> Information 2/24/2011 3:51:02 PM NTP 3 None Performance counter
> frequency 2.083 MHz
>
> Information 2/24/2011 3:51:02 PM NTP 3 None MM timer resolution:
> 1..1000000 msec, set to 1 msec
[]

Thanks, Gautam.  The entries look completely normal (compared to a Windows 
Vista system I have), and in particular, the correct choice of 
interpolation scheme is being made (I left those entries above).  What I 
am /not/ seeing is any entries by NTP saying that NTP is stepping the 
time.

No, I don't expect Win-7 SP1 to make any difference.  I would check again 
for any power-saving stuff.  I would also suggest installing on another 
Win-7 PC to convince yourself  that NTP does work, and to have a base to 
compare against.

Cheers,
David 

Here are some updates based on overnight running of "ntpq -p" every 10
seconds.
win7 is running w/ minpoll=maxpoll=32, Linux is running as just
standard NTP install (fedora 12).

win7 NTP is version 4.2.7p98 overlayed on top of Meinberg install.
Linux NTP is version 4.2.4

Offset, delay and jitter values from ntpq -p are plotted below.

What is seen is that after flaying around wildly for some time win7
starts to settle down, though zooming in shows that it is still
swinging around quite a bit though in smaller steps.

http://www.atl.external.lmco.com/projects/QoS/documents/feb24_1.png
http://www.atl.external.lmco.com/projects/QoS/documents/feb24_1_zoom_1.png
http://www.atl.external.lmco.com/projects/QoS/documents/feb24_delay.png
http://www.atl.external.lmco.com/projects/QoS/documents/feb24_jitter_1.png

Gautam

one more graph, the drift file. link is below. Interestingly, the
drift file values on win7 do not get written out for a long time,
after the win7 somewhat starts to stablilize.



http://www.atl.external.lmco.com/projects/QoS/documents/feb24_drift.png

Gautam

> Here are some updates based on overnight running of "ntpq -p" every 10
> seconds.
> win7 is running w/ minpoll=maxpoll=32, Linux is running as just
> standard NTP install (fedora 12).
>
> win7 NTP is version 4.2.7p98 overlayed on top of Meinberg install.
> Linux NTP is version 4.2.4
>
> Offset, delay and jitter values from ntpq -p are plotted below.
>
> What is seen is that after flaying around wildly for some time win7
> starts to settle down, though zooming in shows that it is still
> swinging around quite a bit though in smaller steps.
>
> http://www.atl.external.lmco.com/projects/QoS/documents/feb24_1.png
> http://www.atl.external.lmco.com/projects/QoS/documents/feb24_1_zoom_1.png
> http://www.atl.external.lmco.com/projects/QoS/documents/feb24_delay.png
> http://www.atl.external.lmco.com/projects/QoS/documents/feb24_jitter_1.png
>
> Gautam

Gautam,

I would have said those figures are broadly similar to what I see on the 
LAN-synched, Win-7 64-bit PC Alta here, including the offset and jitter 
values, except that when I rebooted Alta at 07:00 UTC yesterday there was 
no transient at all.  I wonder whether you've never let NTP run long 
enough that a drift file was created (although I thought that was one 
hour, and I recall you saying NTP had been running for some time).

So I think your problem may have changed from "why doesn't it sync?" to 
"why doesn't it sync more quickly?".  The tail in offset once the sync has 
started is typical of the reference NTP - but the oscillation I have only 
seen when the drift file has been way out, or NTP has two servers telling 
it different times.

Cheers,
David 

> one more graph, the drift file. link is below. Interestingly, the
> drift file values on win7 do not get written out for a long time,
> after the win7 somewhat starts to stablilize.
>
>
>
> http://www.atl.external.lmco.com/projects/QoS/documents/feb24_drift.png
>
> Gautam

There's a big clue there, but I'm not sure what it tells us - perhaps that 
NTP needs one long run before it stabilises?  I'm not sure when the drift 
file /should/ be written - once an hour is the rate, and I think NTP has 
to be fairly certain of the value before it first writes anything - others 
here will surely know.

Cheers,
David 

Also, it seems that running w/ minpoll=maxpoll=32 is important for
win7.

For a variety of technical reasons our machines get rebuilt over and
over. Clearly we will need a way for each time it is rebuild to
restore its drift file. This is a standard technique used by folks in
similar use case as ours, and i had anticipated that i will need to
save/restore drift file each time, but i was/am quite surprised how
long it has taken to converge here on win7 w/o an initial drift file
as compared to time it takes on fedora 12 (BTW, there are no other NTP
related events logged on win7 beyond what I had posted yesterday.)

Gautam

>There was some discussion about this here:
>
> =A0http://www.satsignal.eu/ntp/V4.2.4.vs.V4.2.5.html
>
Hello David:

THere is good info at the link above but it appears no conclusion was
drawn about this issue you raised.

I guess I will have to carefully test w/ 4.2.4 and 4.2.6 (or 4.2.5
also?) and draw my own conclusion as to what works best on Win7.

Gautam

>>There was some discussion about this here:
>>
>>  http://www.satsignal.eu/ntp/V4.2.4.vs.V4.2.5.html
>>
> Hello David:
>
> THere is good info at the link above but it appears no conclusion was
> drawn about this issue you raised.
>
> I guess I will have to carefully test w/ 4.2.4 and 4.2.6 (or 4.2.5
> also?) and draw my own conclusion as to what works best on Win7.
>
> Gautam

Gautam,

Yes, as far as I am concerned, the issue is still outstanding, but no-one 
seems to know what changed, and it appears that the source code for that 
particular version is either no longer available, or that so many changes 
were made that determining which was responsible for the performance 
change cannot be ascertained.  I forget which.  So I treasure my copy of:

  ntpd 4.2.4p6@DLH-QPC-o May 30 3:58:32.88 (UTC) 2009 (273)

It was from Dave Hart, in a file named: ntpd-QPC-20090614-0900.zip, which 
I can no longer find on his Web site.  If you want a copy to try out, I 
have one, if Dave Hart can't help.

Cheers,
David 

On Feb 26, 5:44=A0am, Dave Hart <daveh...@gmail.com> wrote:

> http://davehart.net/moo/ntpd-QPC-20090614-0900.zip
>
> That represents the last in a series of 4.2.4p6-based private releases
> of mine. =A0

OK, so started to use this 4.2.4p6 version and immediately  saw a
reduction in variations in the "offset" value.

see graphic at:

http://www.atl.external.lmco.com/projects/QoS/documents/feb26_offset.png

I should note a few things:

1) when i switched to this version of ntpd.exe, the ntpq.exe from
4.2.7p98 did not seem to be able to query the daemon.

2) Meingberg Time Service Monitor GUI program was reporting status
(presumably since it is based on 4.2.4 ?)

3) I switched to using ntpq.exe from  4.2.4 that comes w/ Meinberg
install and that ntpq.exe worked ok.

4) while the offset reported has become much less wild I noted that
both 'delay' and 'jitter' values reported are ALWAYS now just "0.977".
This should be an indication that something is not right and thus I
don't know if i can trust the improved "offset" value stability.

Any comments welcome.

Gautam

Gautam Thaker wrote:
> On Feb 26, 5:44 am, Dave Hart <daveh...@gmail.com> wrote:
> 
>> http://davehart.net/moo/ntpd-QPC-20090614-0900.zip
>>
>> That represents the last in a series of 4.2.4p6-based private releases
>> of mine.  
> 
> OK, so started to use this 4.2.4p6 version and immediately  saw a
> reduction in variations in the "offset" value.
> 
> see graphic at:
> 
> http://www.atl.external.lmco.com/projects/QoS/documents/feb26_offset.png
> 
> I should note a few things:
> 
> 1) when i switched to this version of ntpd.exe, the ntpq.exe from
> 4.2.7p98 did not seem to be able to query the daemon.

I know you use windows but that behavior can be same on other
platforms. I use NetBSD and when I update it is not just the
ntpd binary and full list for my version of NetBSD is:
ntpd, ntp-keygen ntpdate ntpdc ntpq ntptime ntptrace and sntp.

You need all the executables appropriate for the ntp version
and your windows version otherwise you are likely to have
problems.


David

> 2) Meingberg Time Service Monitor GUI program was reporting status
> (presumably since it is based on 4.2.4 ?)
> 
> 3) I switched to using ntpq.exe from  4.2.4 that comes w/ Meinberg
> install and that ntpq.exe worked ok.
> 
> 4) while the offset reported has become much less wild I noted that
> both 'delay' and 'jitter' values reported are ALWAYS now just "0.977".
> This should be an indication that something is not right and thus I
> don't know if i can trust the improved "offset" value stability.
> 
> Any comments welcome.
> 
> Gautam

"Gautam Thaker" <ghthaker@gmail.com> wrote in message 
news:bbf7043d-935c-4a9d-8b8e-a30d44779058@8g2000prb.googlegroups.com...
> On Feb 26, 5:44 am, Dave Hart <daveh...@gmail.com> wrote:
>
>> http://davehart.net/moo/ntpd-QPC-20090614-0900.zip
>>
>> That represents the last in a series of 4.2.4p6-based private releases
>> of mine.
>
> OK, so started to use this 4.2.4p6 version and immediately  saw a
> reduction in variations in the "offset" value.
>
> see graphic at:
>
> http://www.atl.external.lmco.com/projects/QoS/documents/feb26_offset.png
>
> I should note a few things:
>
> 1) when i switched to this version of ntpd.exe, the ntpq.exe from
> 4.2.7p98 did not seem to be able to query the daemon.
>
> 2) Meingberg Time Service Monitor GUI program was reporting status
> (presumably since it is based on 4.2.4 ?)
>
> 3) I switched to using ntpq.exe from  4.2.4 that comes w/ Meinberg
> install and that ntpq.exe worked ok.
>
> 4) while the offset reported has become much less wild I noted that
> both 'delay' and 'jitter' values reported are ALWAYS now just "0.977".
> This should be an indication that something is not right and thus I
> don't know if i can trust the improved "offset" value stability.
>
> Any comments welcome.
>
> Gautam


Interesting to compare your:

  http://www.atl.external.lmco.com/projects/QoS/documents/feb26_offset.png

with the earlier:

  http://www.atl.external.lmco.com/projects/QoS/documents/feb24_1.png

It shows just how much better the 4.2.4 version was than the current 
version.  I do hope that this will encourage someone to look again at the 
code with a view to discovering the differences and making the current 
version work as well as the previous operation.  Even if I had the source 
code (which I don't), I don't read C well enough, nor do I have the 
necessary understanding of the core algorithms.

Maybe one for that Google Summer of Code, which someone was asking about?

(1) is a real pain - why cannot backwards compatibility be provided?  Does 
it make the query program too complex?

(4) may just be a function of the lack of interpolation under Vista/Win-7 
coupled with the use of a nominal 1000Hz clock (actual interval 0.977ms). 
As I understand it, that likely means ntp is working as intended on that 
platform.

Cheers,
David 

David J Taylor wrote:
.....

> (1) is a real pain - why cannot backwards compatibility be provided?  
> Does it make the query program too complex?

IIRC the data format changed. My several different versions
of ntpd in use at the same time all inter-operated correctly.
What didn't work was the mixing of binaries from different
ntp versions on the same PC.


David

> 
> (4) may just be a function of the lack of interpolation under 
> Vista/Win-7 coupled with the use of a nominal 1000Hz clock (actual 
> interval 0.977ms). As I understand it, that likely means ntp is working 
> as intended on that platform.
> 
> Cheers,
> David

On Feb 27, 3:41=A0am, "David J Taylor" <david-
tay...@blueyonder.co.uk.invalid> wrote:

> It shows just how much better the 4.2.4 version was than the current
> version. =A0I do hope that this will encourage someone to look again at t=
he
> code with a view to discovering the differences and making the current
> version work as well as the previous operation. =A0Even if I had the sour=
ce
> code (which I don't), I don't read C well enough, nor do I have the
> necessary understanding of the core algorithms.

It should be noted that issue is not even that "any" 4.2.4 is better
than the current version but that one needs this unique binary file
(ntpd.exe) from this one source. So situation is even worse I think
than saying "4.2.4 works..." since it does not work (Meinberg comes w/
4.2.4p8 version, while the version that works in 4.2.4p6-custom as far
as I can tell.)

There are a lot of Window7 machines out there - suprising that this is
not considered a serious enough issue. I can read C, but don't know
how if I would be up to this task as I have never worked w/ NTP
innards.

Gautam

On 2/26/2011 2:44 AM, Dave Hart wrote:
> http://davehart.net/moo/ntpd-QPC-20090614-0900.zip
>
> That represents the last in a series of 4.2.4p6-based
>  private releases of mine.  I originally developed the
>  rewritten ntpd interpolation for Windows on this version
>  of ntpd, but those changes were not integrated into the
>  reference implementation until 4.2.5p162.  At that point,
>  my interest in maintaining the private 4.2.4-based
>  releases went way down, as 4.2.4 code had forked from
>  ntp-dev at the end of 2006, and there had been a major
>  cleanup pass on the ntpd source in the summer of 2007
>  which made porting changes between 4.2.4 and 4.2.6
>  nontrivial.
>  Aside from David J Taylor, a few friends of his,
>   and myself, everyone using the new interpolation code
>   on Windows has used 4.2.5p162 or later.

It reads like, versions later than 4.2.5p162
  e.g. the current ntp-dev-4.2.7p134.tar.gz
 should have similar interpolation functionality,
 to 4.2.4p6-DLH-QPC-o;  However David J Taylor still sees
 otherwise on Win 7 in the wild?


Does the source for that version
  (QPC-20090614-0900 / 4.2.4p6-DLH-QPC-o / 2009.03.15.239)
 still exist?

 I'm guessing,
<davehart.net/ntp/refclock/ntp-4.2.4p6-DLH-QPC-20090315-src.zip>


Is it forked off of
 <archive.ntp.org/ntp4/ntp-4.2/ntp-4.2.4p6.tar.gz> ?


-- 
E-Mail Sent to this address <BlackList@Anitech-Systems.com>
  will be added to the BlackLists.