Re: [ntp:questions] packet: pad header 020 / Leap not in sync

[Danny Mayer]

Folkert van Heusden wrote:
> [EMAIL PROTECTED] root]# ntpd --version
> ntpd: ntpd [EMAIL PROTECTED] Tue Feb 24 06:32:25 EST 2004 (1)
> 
> ntp version on the windows server:
> [EMAIL PROTECTED] root]# ntpq -c ntpversion -version 192.168.0.1
> NTP version being claimed is 2
> ntpq [EMAIL PROTECTED] Tue Feb 24 06:32:31 EST 2004 (1)

Please upgrade to at least 4.2.4. This version is too old to try and
figure out what's wrong.

Danny
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] NTPd instability and openntpd

[Harlan Stenn]

>>> In article <[EMAIL PROTECTED]>, Mij <[EMAIL PROTECTED]> writes:

Somebody wrote:
>> There are issues with OpenNTPd and I believe it does not support mode 6
>> packets which is required to run ntpq against it. In addition it is notan
>> NTP server but an SNTP server.

mij> It's a SNTPv4 + NTPv3 server.  From
mij> 

mij> "ntpd can also act as an NTP server itself, redistributing the local
mij> time. It implements the Simple Network Time Protocol version 4, as
mij> described in RFC 2030, and the Network Time Protocol version 3, as
mij> described inRFC 1305."

Just because something *can* be done does not mean it *should* be done.

In particular, an SMTP implementation should (must?) only distribute time if
it is talking directly to a time source.

mij> Reading from
mij> 
mij> the major additions of NTPv4 wrt NTPv3 involve only advanced features
mij> (autokey authentication, 64bit, multi/many cast) that are pretty
mij> uselessin the ntp pool.

They didn't talk about bugfixes or significant algorithmic improvements.

mij> I'd say the major concerns in pool are accuracy and
mij> compatibility/availability. I see that NTPv4 clients understand NTPv3
mij> reponses, so openntpd would be in service for new clients. Moreover,
mij> from real data this is how myserver responds

There should be no compatibility issues with any version of an NTP client
talking to any NTP server.  The protocol handles differing versions.

SNTP clients are designed for "leaf" nodes.  They SHOULD (and it may be a
MUST) not be used to distribute time unless they are talking directly to a
reference clock.

H

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] NTP Third party client on Windows OS ?

[Evandro Menezes]

On Sep 18, 3:30 pm, "John Allen" <[EMAIL PROTECTED]> wrote:

> This certainly doesn't sound like the normal behaviour of NTP on Windows.
> It might be a hardware/HAL issue, 
> see:http://support.ntp.org/bin/view/Support/KnownHardwareIssues#Section_9

I did try the two possible working HALs, halmacpi.dll and
halaacpi.dll, to no avail...

Thanks.

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] NTP Third party client on Windows OS ?

[John Allen]

"Evandro Menezes" <[EMAIL PROTECTED]> wrote
> What I see is that with NTP the time drifts by .128s quite quickly and
> as soon as the stepout limit of 900s expires, time is stepped by
> about .5s.
...
> I've been running NTP on it for almost 24h now along with your Time
> Server Monitor program and the charts look horrible.  Something like a
> saw-tooth...

This certainly doesn't sound like the normal behaviour of NTP on Windows.
It might be a hardware/HAL issue, see:
http://support.ntp.org/bin/view/Support/KnownHardwareIssues#Section_9.1.7.

--

John Allen
Bofferdange, Luxembourg
allen{at}vo.lu
http://www.homepages.lu/allen 


___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] My ntpd stopped working

[Jan Ceuleers]

rasmus wrote:
>> This sounds as though your firewall is opening port 123/UDP in response
>> to polls sent to remote time servers from your ntpd.
> 
> That could indeed then explain the blinks in my availability as
> reported by the pool. How often does ntpd per default sync time with
> the configured servers?

Do you have a rule like the following in your iptables setup:

-A INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT

If so, can you try and bypass it for 123/udp traffic?

HTH, Jan

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] NTPd instability and openntpd

[Mij]

I'll try to respond to all of your mails at once. Thanks.

I am sure that UDP packets come in:

05:59:13.157285 IP zeta.33075 > 10.0.0.5.ntp: NTPv2, Reserved, length
12 05:59:13.157361 IP 10.0.0.5.ntp > zeta.33075: NTPv2, Reserved,
length 432 05:59:13.157390 IP 10.0.0.5.ntp > zeta.33075: NTPv2,
Reserved, length 180 06:13:13.278316 IP zeta.33075 > 10.0.0.5.ntp:
NTPv2, Reserved, length 12 06:13:18.272598 IP zeta.33075 >
10.0.0.5.ntp: NTPv2, Reserved, length 12 06:27:13.352924 IP zeta.33075
> 10.0.0.5.ntp: NTPv2, Reserved, length 12 06:27:13.353035 IP
10.0.0.5.ntp > zeta.33075: NTPv2, Reserved, length 32

and in fact the poller machine "zeta" logs

Tue Sep 18 06:14:11 CEST 2007
no answer

Another sniffer report that logs the packets that are filtered by
thefirewall is empty

tcpdump -n -w /var/ntpdenied.dump -i pflog0 udp and port 123
ls -l /var/ntpdenied.dump
-rwxr-xr-x   1 root  wheel  0 Sep  7 10:22 /var/ntpdenied.dump

>  There is no such thing as L1 and L2 in ntpd (at least the reference
>  implementation).

debug level 1 and 2. -D1 and -D2

>  What version are you running?

ntpd 4.2.0-a

>  You run debug mode by adding the -D2 or -d arguments to the command
> line. Please post the output of ntpq -p

if this is useful... :
 remote   refid  st t when poll reach   delay   offset
 jitter
===
=== *193.204.114.233 .UTCI.   1 u  510 1024  3777.277
  1.227   0.777 +80.83.192.129   150.254.183.15   2 u  580 1024  377
15.5253.803   0.206 +62.173.184.58   193.204.114.233  2 u  529
1024  377   22.609   -8.480   3.044 -85.88.21.202192.36.144.22
2 u  634 1024  377   46.788   15.443   0.654 +194.42.48.120
192.53.103.104   2 u  577 1024  3777.6500.281   0.418

>  your config file

it's pretty simple (comments stripped)

server ntp2.inrim.it prefer
server ntps.net4u.it
server ntp2.altarisoluzione.com
server time.proxgate.net
server clock.tix.ch
driftfile /var/db/ntp.drift
statistics clockstats loopstats peerstats sysstats
statsdir /var/log/ntpd/
filegen clockstats file clockstats.log type month enable
filegen loopstats file loopstats.log type month enable
filegen peerstats file peerstats.log type month enable
filegen sysstats file sysstats.log type month enable

> and the command-line arguments.

/usr/sbin/ntpd -c /etc/ntp.conf -p /var/run/ntpd.pid

>  It's hard to determine what's wrong without any information. Also
> postanything logged in your syslog which might show what's going on.

Besides a lot of
Sep 14 23:47:02 voodoo ntpd[21093]: kernel time sync disabled 2041
Sep 14 23:49:09 voodoo ntpd[21093]: kernel time sync enabled 2001
..
Sep 15 08:09:03 voodoo ntpd[23987]: kernel time sync enabled 6001


3 of these appeared

Sep 14 23:19:30 voodoo ntpd[20438]: too many recvbufs allocated (40)
Sep 14 23:36:39 voodoo ntpd[21058]: too many recvbufs allocated
(40)Sep 17 17:34:10 voodoo ntpd[33902]: too many recvbufs allocated
(40)

confronting with the downtimes as reported from

none of these seems a justification.

>  There are issues with OpenNTPd and I believe it does not support
> mode 6 packets which is required to run ntpq against it. In addition
> it is notan NTP server but an SNTP server.

It's a SNTPv4 + NTPv3 server.
>From 

"ntpd can also act as an NTP server itself, redistributing the local
time. It implements the Simple Network Time Protocol version 4, as
described in RFC 2030, and the Network Time Protocol version 3, as
described inRFC 1305."

Reading from

 the major additions of NTPv4 wrt NTPv3 involve only advanced features
(autokey authentication, 64bit, multi/many cast) that are pretty
uselessin the ntp pool. 

I'd say the major concerns in pool are accuracy and
compatibility/availability. I see that NTPv4 clients understand NTPv3
reponses, so openntpd would be in service for new clients. Moreover,
from real data this is how myserver responds

ntpdc 81.208.58.150
ntpdc> sysstats
current version:4612
previous version:   36810

This is what a popular stratum 1 server reports:
ntpdc ntp2.inrim.it
ntpdc> sysstats
current version:137699
previous version:   196733

This makes me think the the vast majority of clients are still NTPv3
orless, and NTPv4 is shyly more popular among servers.

For the accuracy, it might be interesting to try replacing ntpd with
openntpd and see how the accuracy graph from the pool system looks
like.

bye

-- 
I'm trying a new usenet client for Mac, Nemo OS X.
You can download it at http://www.malcom-mac.com/nemo

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] NTP Third party client on Windows OS ?

[Evandro Menezes]

Martin,

First off, I appreciate your interest.

On Sep 18, 3:53 am, Martin Burnicki <[EMAIL PROTECTED]>
wrote:
>
> I would be interested in how you found that out, what version of w32time and
> NTP you were comparing, and what the differences are.

I run Windows XP with W32TIME 5.1.2600.2180 and I tried NTP 4.2.4p3.

> Last time I compared the Windows system which was diciplined by either
> w32time, or NTP, to a reference time provided by one of our GPS cards the
> NTP program provided a much better accuracy than w32time.

Mind you, I don't have an accurate clock source, so I sync up to
pool.ntp.org servers and to company-wide servers (also running NTP).

What I see is that with NTP the time drifts by .128s quite quickly and
as soon as the stepout limit of 900s expires, time is stepped by
about .5s.

It seems to me that my system clock sucks, but yet if use W32TIME,
even if it starts over 1s off, it gets in sync in about 30min, keeping
the difference between it and its reference within 50ms.

Perhaps the PLL algorithms of NTP can't cope with such a lousy clock,
perhaps the Windows kernel doesn't allow for a fine timing control, I
don't really know.  However, as much a fan of NTP as I am, it seems
that my system is happier with W32TIME.

I've been running NTP on it for almost 24h now along with your Time
Server Monitor program and the charts look horrible.  Something like a
saw-tooth...

Thanks.

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] packet: pad header 020 / Leap not in sync

[Martin Burnicki]

Hi,

Folkert van Heusden wrote:
> Hi,
> 
> My ntpd won't sync.
> Situation:
> - windows 2003 server as ntp server
> - vmware esx 3.0.2 server as ntp client
> 
> When I run ntpdate -dq I get:
> 
> [EMAIL PROTECTED] root]# ntpdate -dq 192.168.0.1
> 17 Sep 16:40:22 ntpdate[14661]: ntpdate [EMAIL PROTECTED] Tue Feb 24 06:32:26
> EST 2004 (1) transmit(192.168.0.1)
> receive(192.168.0.1)
> transmit(192.168.0.1)
> receive(192.168.0.1)
> transmit(192.168.0.1)
> receive(192.168.0.1)
> transmit(192.168.0.1)
> receive(192.168.0.1)
> transmit(192.168.0.1)
> 192.168.0.1: Server dropped: Leap not in sync
> server 192.168.0.1, port 123
> stratum 2, precision -6, leap 11, trust 000
> refid [193.67.79.202], delay 0.04144, dispersion 0.00578
> transmitted 4, in filter 4
> reference time:ca98dfb8.5612472a  Mon, Sep 17 2007 13:12:56.336
> originate timestamp: ca99104d.1612472a  Mon, Sep 17 2007 16:40:13.086
> transmit timestamp:  ca991056.a9d5e4a3  Mon, Sep 17 2007 16:40:22.663
> filter delay:  0.04318  0.04926  0.04144  0.04681
>  0.0  0.0  0.0  0.0
> filter offset: -9.56796 -9.57296 -9.57709 -9.57998
>  0.00 0.00 0.00 0.00
> delay 0.04144, dispersion 0.00578
> offset -9.577090
> 
> 17 Sep 16:40:22 ntpdate[14661]: no server suitable for synchronization
> found

Yep, as displayed in the debug output the leap bit are set to "11" which
means the server is not synchronized, so a real NTP client won't accept it.

> Also when I run: ntpd -g -d I get:
> 
> [EMAIL PROTECTED] root]# ntpd -g -d
> ntpd [EMAIL PROTECTED] Tue Feb 24 06:32:25 EST 2004 (1)
> create_sockets(123)
> interface  OK
> interface  OK
> bind() fd 4, family 2, port 123, addr 0.0.0.0, flags=1
> bind() fd 5, family 2, port 123, addr 127.0.0.1, flags=0
> bind() fd 6, family 2, port 123, addr 192.168.0.2, flags=1
> init_io: maxactivefd 6
> peer_clear: at 0 assoc ID 0
> newpeer: 192.168.0.2->192.168.0.1 mode 3 vers 4 poll 6 10 flags 201 1 ttl
> 0 key  peer_clear: at 0 assoc ID 0
> newpeer: 127.0.0.1->127.127.1.0 mode 3 vers 4 poll 6 6 flags 21 1 ttl 0
> key  report_event: system event 'event_restart' (0x01) status
> 'sync_alarm, sync_unspec, 1 event, event_unspec' (0xc010) auth_agekeys: at
> 1 keys 1 expired 0 transmit: at 5 192.168.0.2->192.168.0.1 mode 3
> receive: at 5 192.168.0.2<-192.168.0.1 mode 4 code 1
> packet: bad header 020
> refclock_transmit: at 10 127.127.1.0
> refclock_receive: at 10 127.127.1.0
> peer LOCAL(0) event 'event_reach' (0x84) status 'unreach, conf, 1 event,
> event_reach' (0x8014) refclock_sample: n 1 offset 0.00 disp 0.01
> jitter 0.00 clock_filter: n 1 off 0.00 del 0.00 dsp 7.937508
> jit 0.08, age 0 transmit: at 20 192.168.0.2->192.168.0.1 mode 3
> receive: at 20 192.168.0.2<-192.168.0.1 mode 4 code 1
> packet: bad header 020
> 
> What would be the cause?

A short grep over the source code indicates this are the "flash" bits, and
the comment for 0x20 says:
#define TEST6   0x0020  /* peer clock unsynchronized */

So this is the same problem: the server does not claim to be synchronized.

> ntpd version on esx is:
> 
> [EMAIL PROTECTED] root]# ntpd --version
> ntpd: ntpd [EMAIL PROTECTED] Tue Feb 24 06:32:25 EST 2004 (1)
> 
> ntp version on the windows server:
> [EMAIL PROTECTED] root]# ntpq -c ntpversion -version 192.168.0.1
> NTP version being claimed is 2

AFAIK the above is just the version of the protocol ntpq uses when sending
queries to the server, see the documentation for ntpq.

> ntpq [EMAIL PROTECTED] Tue Feb 24 06:32:31 EST 2004 (1)

Overall I'd say you should find out why your server does not claim to be
synchronized.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] NTP Third party client on Windows OS ?

[Martin Burnicki]

Evandro Menezes wrote:
> On Sep 17, 9:44 am, [EMAIL PROTECTED] (Jason Rabel) wrote:
[...]
> I actually noticed that W32TIME with the registry tweaked to keep the
> polling between 64 and 1024s (instead of the default 64 and 32768s) is
> capable of keeping the time in sync better than Meinberg's NTP port.

I would be interested in how you found that out, what version of w32time and
NTP you were comparing, and what the differences are. 

Last time I compared the Windows system which was diciplined by either
w32time, or NTP, to a reference time provided by one of our GPS cards the
NTP program provided a much better accuracy than w32time.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] packet: pad header 020 / Leap not in sync

[Maarten Wiltink]

"Folkert van Heusden" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]

>>> My ntpd won't sync.
>>> Situation:
>>> - windows 2003 server as ntp server
>>> - vmware esx 3.0.2 server as ntp client

>> Virtual machines are best left unsynchronised. ...
>
> This is not the virtual machine, it is the service console. And from
> what I've heard it's neccessary to keep it synced.

Oh yes, definitely. Sorry for the confusion.

Groetjes,
Maarten Wiltink


___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] packet: pad header 020 / Leap not in sync

[Folkert van Heusden]

> > My ntpd won't sync.
> > Situation:
> > - windows 2003 server as ntp server
> > - vmware esx 3.0.2 server as ntp client
> Virtual machines are best left unsynchronised. The host will

This is not the virtual machine, it is the service console. And from
what I've heard it's neccessary to keep it synced.


Folkert van Heusden

-- 
To MultiTail einai ena polymorfiko ergaleio gia ta logfiles kai tin
eksodo twn entolwn. Prosferei: filtrarisma, xrwmatismo, sygxwneysi,
diaforetikes provoles. http://www.vanheusden.com/multitail/
--
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions