In <list-11992267@2rosenthals.com>, on 01/20/25
at 10:08 AM, "Massimo S." <ecs-isp@2rosenthals.com> said:
Hi Massimo,
>i've seen, but it do not document in details
Section IV states:
1) From the command line and accessing a single server using command line
arguments:
os2_ntpd.exe [ntp server(name or dotted decimal)
initial polling interval (integer seconds)
number of requests to send (integer)]
How much more detail did you expect?
>anyway
>os2_ntpd 193.204.114.232 2 2
That's compatible with what the docs say.
>ntp server RFC 5905, hour and date is right
You are looking at the wrong RFC
5905 Network Time Protocol Version 4: Protocol and Algorithms
As I mentioned, OS2_NTPD impliements
1305 Network Time Protocol (Version 3) Specification,
While both use the same NTP server data, the protocols are quite
different.
>but how can i be sure?
What do you mean? If you run os2_ntpd one shot mode, what you get is what
you get? If you run os2_ntpd as a daemon, errors get filtered out by the
algorithm.
>how to make it to save a log?
Logging is automatic when you run detached. Logging is not supported in
one shot mode. I suspect Bruce implemented one-shot mode as a testing
tool. I don't know anyone who thinks it's a good idea to use one-shot
mode on a production setup.
>should i run also
>os2_ntpd 193.204.114.233 2 2
You could, but if you choose to run os2_ntpd this way, and you have NTP
servers that are returning bad data, you might see the same kind of errors
you are seeing with the time sync tools you are currently using.
>or is there another way to give it a list?
os2_ntpd does not support multiple servers in one-shot mode.
>> That said, os2_ntpd is an NTP client which is designed to work best
>> running as a detached daemon.
>i will run scheduled some times per day
You can do that. os2_ntpd already automatically adjusts it's polling
interval to match the quality of the data and the implementation.
According the the RFC, the maximum interval is about 17 minutes. For some
unknown reason, Bruce chose to set this limit to 256 seconds. It's been
on my list almost forever to figure out why.
For those reading long, when running os2_ntpd in the foreground, the
typical status display is:
(Server-Client) Ensemble µ = -0.083, Õ = 0.014 seconds using 7
servers Loop Filter Output = +0.004, Loop þ = 384, Local Clock Ùf/f =
-8.0e+01 PPM
No Local Clock Correction Necessary
The NTP protocol differs quite a bit from other time sync protocols.
Rather than just setting the clock to some value returned by the time
server, it calculates the current error in local hardware's clock
frequency and uses this to adjust the clock. This is Local Clock Ùf/f
(delta f / f) in the above.
This has the advantage that once the frequency error is known, the clock
can be updated accurately even when the NTP servers are not accessible.
There are exceptions. Server access is needed to handle DST and leap
second adjustments. If the hardare clock frequency error varies for some
reason, the clock updates will not be as accurate as they would be if the
NTP servers were accessible.
Tillbaks till lista