chrony and hwclock

[Roger Oberholtzer]

On Sat, 2011-07-16 at 02:43 +0200, Carlos E. R. wrote:

> When ntp is running, it will adjust the clock very slowly, so slow that you
> will not notice it is changing. If there is one minute error it may take
> hours to correct.
>
> However, if you restart the daemon, using the script, the first step is
> jump-set the clock, even by hours if needed, and after that it will run the
> daemon to keep it correct.

So, there is a flaw in the ntp start logic when the network interface on
which it's server lives only becomes available some time after ntp
starts. It seems never to re-check that a server that was initially not
available later becomes available.

IMO, the problem is ntp, not the system start stuff. Since I have
effectively removed my network from the system startup environment, I
would find it hard to see that environment being able to solve ordering
or dependency issues. How could a system service know that some user
will, via their own non-system configuration, eventually, maybe start a
network where an interesting server lives?

Hence chrony. It does not give up so easily as ntp seems to do. Since it
has as a core assumption that time servers may not always be present (to
an apparently stronger degree than does ntp), it will try again.

I am fully aware that ntp is well tested and understood, while chrony is
less prevalent. But I think (don't know yet) chrony uses much logic from
ntp after it has located a server.

> Ntp does check, but it can not jump-set the clock once it is running. As
> documented.

'As documented' is not always the same thing as 'As I need' :(

> If the users move around time zones, and _they_ set the clock, weird things
> will happen. For this to work, bios must keep UTC time. The linux
> timesetting logic is not designed for people on the move. The original
> design is for stable machines, server type.

The box does keep UTC. It is possible that they change the timezone as
they move around to different countries. I suspect it depends on how
long they will be in a country. I will have to investigate user
activity.

> > Nope! The init scripts CANNOT make my wireless connection available to
> > ntp. They have no connection to networks brought up outside the
> > traditional ifup method. Like KDE/GNOME Network Manager-type
> > initialization.
>
> Then you have to make sure that NTP is restarted later, no matter what.

So I would have to make ntp start SUID or something so it would start
when a user does something. Not my preferred solution.

> >> Ah! Perhaps 'systemd' will be able to cure that :-)
> >
> > Nope. See my comment above.
>
> It might, if it can restart services on events (network goes up).

That sounds interesting. Of course, this will not help my installed
systems. Our current 'official' platform is openSUSE 11.2. We are always
a little behind in our use of releases...



Yours sincerely,

Roger Oberholtzer

OPQ Systems / Ramböll RST

Office: Int [phone]
Mobile: Int [phone]
***@ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se


--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Roger Oberholtzer]

On Sat, 2011-07-16 at 10:22 +0200, Per Jessen wrote:
> Roger Oberholtzer wrote:
>
> > I am on a laptop that exhibits the problem. hwclock -r is showing the
> > correct UTC time that I expect. The network is up via NetworkManager
> > when I logged in graphically. The ntp that started when I booted is
> > still running. But, alas, the time is incorrect. It can sit like this
> > for hours, and the time will NEVER be corrected. Ever. Consistently.
> >
> > All I have to do now is run 'rcntp restart', and time will be
> > corrected.
>
> Carlos explained this issue very well. Now you need to examine why your
> system clock is off by two(?) hours when it is started. (Two hours
> discrepancy is not an inaccuracy, it is a clock that has been wrongly
> set).

The two hours is because the hardware clock is set to UTC time. That is
two hours from local time in Sweden. So one question I have that I have
not brought up (isn't the current question enough to keep us busy? :) )
is why when ntp fails does the system seem to ignore the system
timezone?

I have been assuming that the system does in fact set the time according
to the timezone (in the hwclock startup script). Then, when the ntp
startup script is run, it does it's own thing which involves setting the
time back to the hardware time, expecting to correct it when a time
server is found. As no time server is found, step one of the ntp startup
process is all that happens, leaving the time in the original hardware
state.

> > I suspect it is that the ntp rc script is assuming that since it is
> > set to start after networking, it can assume that access to time
> > servers is available when it starts. Alas, when a network device
> > starts some time afterward, this assumption is faulty.
>
> The ntp init-script is not really intended to fix enormous hour-size
> gaps of time - on a normal startup the time offset of the local system
> might be measured in seconds, which ntp will then correct immediately
> provided a time source is available. If the time cannot be set, and
> the gap is 1000s or more, ntpd will exit immediately.

Once again, the difference between the hardware clock and local time is
because the hardware clock is in UTC time. It is not really wrong. I
would have thought that was the preferred method on Linux. Things like
daylight savings time switching only happen if the hardware clock is in
UTC time.


Yours sincerely,

Roger Oberholtzer

OPQ Systems / Ramböll RST

Office: Int [phone]
Mobile: Int [phone]
***@ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se


--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Roger Oberholtzer]

On Sat, 2011-07-16 at 10:35 +0200, Per Jessen wrote:
> Per Jessen wrote:
>
> > If you need a higher
> > degree of accuracy without a more accurate external time source, you
> > have to improve the local time source - temperature controlled xtal
> > oscillator etc.
>
> btw, this is perfectly feasible. You can build/buy very stable TXCOs
> that will supply a very good PPS signal. Companies such www.rakon.com
> make very tiny devices with very good accuracies.

In our case, we are using high end GPS receivers with a PPS signal on
the serial port. This causes a hardware interrupt when a time update is
available. This is a rather accurate event when used in conjunction with
a time setting daemon that can use the data and associated PPS signal
from a GPS. In newer kernels, there is a PPS driver that has finally
abstracted all these possible PPS signals into a single interface
(/dev/pps).

We currently do some of this time synchronizing in our own application.
I do not want to do that anymore. It is because I am investigating what
the caveats are when this is done at the system level when a system is
not connected to the internet (an assumption that is unfortunately
becoming more and more common) that the original question came up.

And that question (still not answered) is: is there any unexpected side
effect of not running the hwclock shutdown script? In my case, chrony
wants to maintain the hardware clock between boots. It is understood
that the jury is out as to whether chrony is a useful solution. But that
was not the question. Does the hwclock shutdown script maintain any
information used by any systems other than hwclock itself?


Yours sincerely,

Roger Oberholtzer

OPQ Systems / Ramböll RST

Office: Int [phone]
Mobile: Int [phone]
***@ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se


--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Joachim Schrod]

Roger Oberholtzer wrote:

> Does the hwclock shutdown script maintain any
> information used by any systems other than hwclock itself?

No. (If you mean "hwclock shutdown script" to be
/etc/init.d/boot.clock.)

If chrony maintains the hardware clock / system clock relationship
itself, chkconfig --del boot.clock and turn on chrony.

But if chrony is only concerned with the system clock (as ntpd is),
don't turn boot.clock off.

Joachim

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod Email: ***@acm.org
Roedermark, Germany

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Per Jessen]

Roger Oberholtzer wrote:

> On Sat, 2011-07-16 at 10:22 +0200, Per Jessen wrote:
>>
>> Carlos explained this issue very well. Now you need to examine why
>> your system clock is off by two(?) hours when it is started. (Two
>> hours discrepancy is not an inaccuracy, it is a clock that has been
>> wrongly set).
>
> The two hours is because the hardware clock is set to UTC time. That
> is two hours from local time in Sweden. So one question I have that I
> have not brought up (isn't the current question enough to keep us
> busy? :) ) is why when ntp fails does the system seem to ignore the
> system timezone?

ntp isn't concerned about timezones - timezones are really for
interaction with humans only. Let ntp keep the time in UTC, then you
(or your systems) apply your local timezone whenever you need to work
with the time.

> I have been assuming that the system does in fact set the time
> according to the timezone (in the hwclock startup script).

I'm not sure, but I don't think so. There's probably someone here who
understands hwclock better than I do.

> Then, when the ntp startup script is run, it does it's own thing which
> involves setting the time back to the hardware time, expecting to
> correct it when a time server is found. As no time server is found,
> step one of the ntp startup process is all that happens, leaving the
> time in the original hardware state.

The ntp init-script does essentially two things:

1) sets time when available
2) start ntp - will exit if time is not sane.

> Once again, the difference between the hardware clock and local time
> is because the hardware clock is in UTC time. It is not really wrong.
> I would have thought that was the preferred method on Linux. Things
> like daylight savings time switching only happen if the hardware clock
> is in UTC time.

Right. Your system sounds like it is running exactly like mine. Where
exactly do you see the wrong time? And what is the wrong time, i.e.
why is it wrong?



--
Per Jessen, Zürich (15.7°C)

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Roger Oberholtzer]

On Mon, 2011-07-18 at 10:00 +0200, Per Jessen wrote:

> Right. Your system sounds like it is running exactly like mine. Where
> exactly do you see the wrong time? And what is the wrong time, i.e.
> why is it wrong?

The time as used everywhere in the system is the BIOS UTC time. I see
this via 'date', or in a desktop GUI clock. If I disable ntp the
timezone is correctly applied during boot. If ntp is restarted after the
network is available the timezone is also correctly applied (a sudden
jump of two hours occurs). If the network is not available when ntp
starts, the time stays the BIOS UTC time. The timezone seems to be
ignored.



Yours sincerely,

Roger Oberholtzer

OPQ Systems / Ramböll RST

Office: Int [phone]
Mobile: Int [phone]
***@ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se


--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Per Jessen]

Roger Oberholtzer wrote:

> On Sat, 2011-07-16 at 02:43 +0200, Carlos E. R. wrote:
>
>> When ntp is running, it will adjust the clock very slowly, so slow
>> that you will not notice it is changing. If there is one minute error
>> it may take hours to correct.
>>
>> However, if you restart the daemon, using the script, the first step
>> is jump-set the clock, even by hours if needed, and after that it
>> will run the daemon to keep it correct.
>
> So, there is a flaw in the ntp start logic when the network interface
> on which it's server lives only becomes available some time after ntp
> starts. It seems never to re-check that a server that was initially
> not available later becomes available.

I don't think that is correct. As my logs showed last week, ntp is
perfectly capable of switching time source/server when the
availability/quality changes. However, if ntp fails to start, it would
(obviously) also not be checking any servers later. Have you looked at
the output of "ntpq -p" at different points of your problem scenario?

> IMO, the problem is ntp, not the system start stuff. Since I have
> effectively removed my network from the system startup environment, I
> would find it hard to see that environment being able to solve
> ordering or dependency issues. How could a system service know that
> some user will, via their own non-system configuration, eventually,
> maybe start a network where an interesting server lives?

A daemon would just try to reach the interesting server, and when the
error says "network not reachable" (or something similar) it means it's
still not there.

Personally I don't think there is a problem with ntp here - maybe in the
network config or the ntp config, but not ntp itself. Your options are
probably to 1) debug your ntp setup or 2) pursue a chrony setup. If
you want, I'll be happy to help with option 1), but I'll need some more
detailed info.


--
Per Jessen, Zürich (16.1°C)

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Per Jessen]

Roger Oberholtzer wrote:

> On Mon, 2011-07-18 at 10:00 +0200, Per Jessen wrote:
>
>> Right. Your system sounds like it is running exactly like mine.
>> Where
>> exactly do you see the wrong time? And what is the wrong time, i.e.
>> why is it wrong?
>
> The time as used everywhere in the system is the BIOS UTC time. I see
> this via 'date', or in a desktop GUI clock. If I disable ntp the
> timezone is correctly applied during boot. If ntp is restarted after
> the network is available the timezone is also correctly applied (a
> sudden jump of two hours occurs).

Restarting ntp also means running 'ntpd -g -q' which disables the 1000s
sanity check, sets the time and exits.

Okay - can you post contents of /etc/adjtime as well as output
from "date" and "date -u", please?


--
Per Jessen, Zürich (16.8°C)

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Roger Oberholtzer]

On Mon, 2011-07-18 at 10:28 +0200, Per Jessen wrote:
> Roger Oberholtzer wrote:
>
> > On Sat, 2011-07-16 at 02:43 +0200, Carlos E. R. wrote:
> >
> >> When ntp is running, it will adjust the clock very slowly, so slow
> >> that you will not notice it is changing. If there is one minute error
> >> it may take hours to correct.
> >>
> >> However, if you restart the daemon, using the script, the first step
> >> is jump-set the clock, even by hours if needed, and after that it
> >> will run the daemon to keep it correct.
> >
> > So, there is a flaw in the ntp start logic when the network interface
> > on which it's server lives only becomes available some time after ntp
> > starts. It seems never to re-check that a server that was initially
> > not available later becomes available.
>
> I don't think that is correct. As my logs showed last week, ntp is
> perfectly capable of switching time source/server when the
> availability/quality changes. However, if ntp fails to start, it would
> (obviously) also not be checking any servers later. Have you looked at
> the output of "ntpq -p" at different points of your problem scenario?

ntp is started and running. I will run the suggested command when I have
access to an offending system.

>
> > IMO, the problem is ntp, not the system start stuff. Since I have
> > effectively removed my network from the system startup environment, I
> > would find it hard to see that environment being able to solve
> > ordering or dependency issues. How could a system service know that
> > some user will, via their own non-system configuration, eventually,
> > maybe start a network where an interesting server lives?
>
> A daemon would just try to reach the interesting server, and when the
> error says "network not reachable" (or something similar) it means it's
> still not there.

But how would a daemon know which network the interesting server is on?
Perhaps a moot point. It could re-try each time the network
configuration changed.

> Personally I don't think there is a problem with ntp here - maybe in the
> network config or the ntp config, but not ntp itself. Your options are
> probably to 1) debug your ntp setup or 2) pursue a chrony setup. If
> you want, I'll be happy to help with option 1), but I'll need some more
> detailed info.

I would prefer to attempt to sort out ntp before moving to chrony. I
need to set up a system with only a GPS. This is the current stumbling
block as I have not sorted out how to get an antenna on the roof of our
office building. My window accesses an urban canyon with a northern
exposure, which is the GPS kiss of death in Nordic latitudes...


Yours sincerely,

Roger Oberholtzer

OPQ Systems / Ramböll RST

Office: Int [phone]
Mobile: Int [phone]
***@ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se


--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Per Jessen]

Roger Oberholtzer wrote:

> On Sat, 2011-07-16 at 10:35 +0200, Per Jessen wrote:
>> Per Jessen wrote:
>>
>> > If you need a higher
>> > degree of accuracy without a more accurate external time source,
>> > you have to improve the local time source - temperature controlled
>> > xtal oscillator etc.
>>
>> btw, this is perfectly feasible. You can build/buy very stable TXCOs
>> that will supply a very good PPS signal. Companies such
>> www.rakon.com make very tiny devices with very good accuracies.
>
> In our case, we are using high end GPS receivers with a PPS signal on
> the serial port. This causes a hardware interrupt when a time update
> is available. This is a rather accurate event when used in conjunction
> with a time setting daemon that can use the data and associated PPS
> signal from a GPS. In newer kernels, there is a PPS driver that has
> finally abstracted all these possible PPS signals into a single
> interface (/dev/pps).

That is understood, but I thought you had an issue with the GPS PPS
signal being unavailable and the local clock not being sufficiently
accurate.

> And that question (still not answered) is: is there any unexpected
> side effect of not running the hwclock shutdown script?

I can't answer that - I think you'll have to google some more.

> In my case, chrony wants to maintain the hardware clock between boots.

That makes sense, I'm sure I read somewhere that it's important that
only one process maintain the hardware clock.



--
Per Jessen, Zürich (17.0°C)

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Per Jessen]

Roger Oberholtzer wrote:

>> > IMO, the problem is ntp, not the system start stuff. Since I have
>> > effectively removed my network from the system startup environment,
>> > I would find it hard to see that environment being able to solve
>> > ordering or dependency issues. How could a system service know that
>> > some user will, via their own non-system configuration, eventually,
>> > maybe start a network where an interesting server lives?
>>
>> A daemon would just try to reach the interesting server, and when the
>> error says "network not reachable" (or something similar) it means
>> it's still not there.
>
> But how would a daemon know which network the interesting server is
> on? Perhaps a moot point. It could re-try each time the network
> configuration changed.

It doesn't care about the network config - for arguments sake, let's
assume it uses TCP. In pseudo-code, you would issue a

connect(<desired server address>);

If the network is not available, the connect() does not succeed. This
is no different to you trying to access an external website when your
network is down. Slightly different for UDP, but essentially the same.



--
Per Jessen, Zürich (17.4°C)

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Roger Oberholtzer]

On Mon, 2011-07-18 at 11:21 +0200, Per Jessen wrote:
> Roger Oberholtzer wrote:
>
> >> > IMO, the problem is ntp, not the system start stuff. Since I have
> >> > effectively removed my network from the system startup environment,
> >> > I would find it hard to see that environment being able to solve
> >> > ordering or dependency issues. How could a system service know that
> >> > some user will, via their own non-system configuration, eventually,
> >> > maybe start a network where an interesting server lives?
> >>
> >> A daemon would just try to reach the interesting server, and when the
> >> error says "network not reachable" (or something similar) it means
> >> it's still not there.
> >
> > But how would a daemon know which network the interesting server is
> > on? Perhaps a moot point. It could re-try each time the network
> > configuration changed.
>
> It doesn't care about the network config - for arguments sake, let's
> assume it uses TCP. In pseudo-code, you would issue a
>
> connect(<desired server address>);
>
> If the network is not available, the connect() does not succeed. This
> is no different to you trying to access an external website when your
> network is down. Slightly different for UDP, but essentially the same.

Of course. But, at some point in the future, will ntp retry to make the
connection? On that point the jury is still out. You have presented
evidence where it seems to. I have presented a counter claim that shows
up in my usage. I suspect ntp does retry the connection when it does,
and does not try again when it does not...



Yours sincerely,

Roger Oberholtzer

OPQ Systems / Ramböll RST

Office: Int [phone]
Mobile: Int [phone]
***@ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se


--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Roger Oberholtzer]

On Mon, 2011-07-18 at 11:11 +0200, Per Jessen wrote:

> That is understood, but I thought you had an issue with the GPS PPS
> signal being unavailable and the local clock not being sufficiently
> accurate.

Exactly. Sometimes the systems are powered on when the vehicle is in,
say, a garage. Or under trees. The GPS may or may not provide the PPS
signal before it sees satellites. It is not deterministic. At least
using rules the operators can also follow reliably. This points out
another requirement: we need to be able to indicate to the operator when
the system thinks it has an accurate time. Meaning when the system
thinks the time matches the GPS as closely as it can (ignoring the basic
hardware drift that will always bring in tiny changes).

> > And that question (still not answered) is: is there any unexpected
> > side effect of not running the hwclock shutdown script?
>
> I can't answer that - I think you'll have to google some more.

It is more an openSUSE issue than a general Linux question. So I started
with the openSUSE list thinking there was some rather specialized
knowledge here. Which there indeed is!

> > In my case, chrony wants to maintain the hardware clock between boots.
>
> That makes sense, I'm sure I read somewhere that it's important that
> only one process maintain the hardware clock.

Indeed. chrony point out specifically that if anyone else is fiddling
with the clock between reboots all bets are off.


Yours sincerely,

Roger Oberholtzer

OPQ Systems / Ramböll RST

Office: Int [phone]
Mobile: Int [phone]
***@ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se


--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Per Jessen]

Roger Oberholtzer wrote:

> On Mon, 2011-07-18 at 11:21 +0200, Per Jessen wrote:
>> Roger Oberholtzer wrote:
>>
>> >> > IMO, the problem is ntp, not the system start stuff. Since I
>> >> > have effectively removed my network from the system startup
>> >> > environment, I would find it hard to see that environment being
>> >> > able to solve ordering or dependency issues. How could a system
>> >> > service know that some user will, via their own non-system
>> >> > configuration, eventually, maybe start a network where an
>> >> > interesting server lives?
>> >>
>> >> A daemon would just try to reach the interesting server, and when
>> >> the error says "network not reachable" (or something similar) it
>> >> means it's still not there.
>> >
>> > But how would a daemon know which network the interesting server is
>> > on? Perhaps a moot point. It could re-try each time the network
>> > configuration changed.
>>
>> It doesn't care about the network config - for arguments sake, let's
>> assume it uses TCP. In pseudo-code, you would issue a
>>
>> connect(<desired server address>);
>>
>> If the network is not available, the connect() does not succeed.
>> This is no different to you trying to access an external website when
>> your network is down. Slightly different for UDP, but essentially
>> the same.
>
> Of course. But, at some point in the future, will ntp retry to make
> the connection? On that point the jury is still out.
> You have presented evidence where it seems to. I have presented a
> counter claim that shows up in my usage. I suspect ntp does retry the
> connection when it does, and does not try again when it does not...

To stick to the legal metaphors, I think the judge will dismiss your
claim as hear-say :-) At least until you present evidence that the
server is configured but not used ("ntpq -p" will show the peers).


--
Per Jessen, Zürich (18.5°C)

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Per Jessen]

Roger Oberholtzer wrote:

> On Mon, 2011-07-18 at 11:11 +0200, Per Jessen wrote:
>
>> That is understood, but I thought you had an issue with the GPS PPS
>> signal being unavailable and the local clock not being sufficiently
>> accurate.
>
> Exactly. Sometimes the systems are powered on when the vehicle is in,
> say, a garage. Or under trees. The GPS may or may not provide the PPS
> signal before it sees satellites. It is not deterministic. At least
> using rules the operators can also follow reliably. This points out
> another requirement: we need to be able to indicate to the operator
> when the system thinks it has an accurate time.

ntp will tell you that - it is one of the status indicators in the ntpq
display. Or you could monitor the logfile and check for stratum
changes. (stratum 0 = GPS, anything else = unsynced). There might
even be an SNMP trap for this, you never know.


Here is an example:

# ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
*127.127.8.1 .DCFa. 0 l 57 64 177 0.000 -8.956 2.714
127.127.1.0 .LOCL. 10 l 59 64 377 0.000 0.000 0.008
+162.23.41.34 .HBGi. 1 u 58 64 377 55.101 -5.126 120.944
+129.132.2.21 129.132.2.22 2 u 48 64 377 38.736 -12.524 99.586
192.168.7.255 .BCST. 16 u - 16 0 0.000 0.000 0.008
212.25.14.63 .BCST. 16 u - 16 0 0.000 0.000 0.008

This says that this time server is synced to DCF (the asterisk indicator),
and that two good external time sources are available (stratum 1 and 2). There
is also an indicator for a PPS signal, but I don't use one.


--
Per Jessen, Zürich (17.9°C)

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Roger Oberholtzer]

On Mon, 2011-07-18 at 12:22 +0200, Per Jessen wrote:
> Roger Oberholtzer wrote:
>
> > On Mon, 2011-07-18 at 11:11 +0200, Per Jessen wrote:
> >
> >> That is understood, but I thought you had an issue with the GPS PPS
> >> signal being unavailable and the local clock not being sufficiently
> >> accurate.
> >
> > Exactly. Sometimes the systems are powered on when the vehicle is in,
> > say, a garage. Or under trees. The GPS may or may not provide the PPS
> > signal before it sees satellites. It is not deterministic. At least
> > using rules the operators can also follow reliably. This points out
> > another requirement: we need to be able to indicate to the operator
> > when the system thinks it has an accurate time.
>
> ntp will tell you that - it is one of the status indicators in the ntpq
> display. Or you could monitor the logfile and check for stratum
> changes. (stratum 0 = GPS, anything else = unsynced). There might
> even be an SNMP trap for this, you never know.
>
>
> Here is an example:
>
> # ntpq -pn
> remote refid st t when poll reach delay offset jitter
> ==============================================================================
> *127.127.8.1 .DCFa. 0 l 57 64 177 0.000 -8.956 2.714
> 127.127.1.0 .LOCL. 10 l 59 64 377 0.000 0.000 0.008
> +162.23.41.34 .HBGi. 1 u 58 64 377 55.101 -5.126 120.944
> +129.132.2.21 129.132.2.22 2 u 48 64 377 38.736 -12.524 99.586
> 192.168.7.255 .BCST. 16 u - 16 0 0.000 0.000 0.008
> 212.25.14.63 .BCST. 16 u - 16 0 0.000 0.000 0.008
>
> This says that this time server is synced to DCF (the asterisk indicator),
> and that two good external time sources are available (stratum 1 and 2). There
> is also an indicator for a PPS signal, but I don't use one.

This looks promising. I guess I will need to make a log file parser if
SNMP is not available. Thanks for this pointer.

Of course, I need to sort out the ntp issues I have before this is an
issue.


>
>
> --
> Per Jessen, Zürich (17.9°C)
>

Yours sincerely,

Roger Oberholtzer

OPQ Systems / Ramböll RST

Office: Int [phone]
Mobile: Int [phone]
***@ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se


--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Per Jessen]

Roger Oberholtzer wrote:

> This looks promising. I guess I will need to make a log file parser if
> SNMP is not available. Thanks for this pointer.

I _know_ there is an ntp MIB, but I have never played with it - it's on
my (long) todo-list. I'm sure it must be possible to have a trap sent
when the stratum changes.

> Of course, I need to sort out the ntp issues I have before this is an
> issue.

Yup.



--
Per Jessen, Zürich (18.1°C)

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Anton Aylward]

Roger Oberholtzer said the following on 07/18/2011 03:00 AM:
> So, there is a flaw in the ntp start logic when the network interface on
> which it's server lives only becomes available some time after ntp
> starts. It seems never to re-check that a server that was initially not
> available later becomes available.
>
> IMO, the problem is ntp, not the system start stuff. Since I have
> effectively removed my network from the system startup environment, I
> would find it hard to see that environment being able to solve ordering
> or dependency issues. How could a system service know that some user
> will, via their own non-system configuration, eventually, maybe start a
> network where an interesting server lives?

Your reasoning is valid, but it is also an example of a much more
general problem, that of dependencies.

You are stating, quite rightly, that NTP should be started when a
specific network comes up.

We've discussed a similar problem here recently, a function needing a
wifi network but the "network up"of a wired network was allowing it to
proceed.

The real solution is a proper management of dependencies and triggers.

I've said before that this is a situation that 'systemd' addresses; it
was intended to address these kinds of dependencies.

http://en.opensuse.org/SDB:Systemd

http://en.wikipedia.org/wiki/Systemd
http://fedoraproject.org/wiki/Features/systemd


# zypper se systemd
Loading repository data...
Reading installed packages...

S | Name | Summary | Type
--+------------------+-------------------------------------+-----------
| systemd | A System and Session Manager | package
| systemd | A System and Session Manager | srcpackage
| systemd-gtk | Graphical front-end for systemd | package
| systemd-sysvinit | System V init tools | package


# zypper info systemd
Information for package systemd:

Repository: mozilla
Name: systemd
Version: 18-1.2.4
Arch: i586
Vendor: openSUSE
Installed: No
Status: not installed
Installed Size: 2.0 MiB
Summary: A System and Session Manager
Description:
Systemd is a system and service manager, compatible with SysV and LSB
init scripts for Linux. systemd provides aggressive parallelization
capabilities, uses socket and D-Bus activation for starting services,
offers on-demand starting of daemons, keeps track of processes using
Linux cgroups, supports snapshotting and restoring of the system state,
maintains mount and automount points and implements an elaborate
transactional dependency-based service control logic. It can work as a
drop-in replacement for sysvinit.



I have Fedora 15 running on one machine with systemd.
As someone who has been using init scripts since SVR4 in the late 0s it
feels ... well, weird, but somehow very logical. I keep feeing that I
want DBUS and Cgroups to be better explained/documented. Th examples
make sense but I'm find it hard to extrapolate about DBUS and Cgroups.
Systemd itself is sooooo logical I keep asking 'why didn't someone do
that a decade ago?'



--
APL is a mistake, carried through to perfection. It is
the language of the future for the programming techniques
of the past: it creates a new generation of coding bums.
-- Edsger W. Dijkstra,
SIGPLAN Notices, Volume 17, Number 5
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Per Jessen]

Anton Aylward wrote:

> Your reasoning is valid, but it is also an example of a much more
> general problem, that of dependencies.
>
> You are stating, quite rightly, that NTP should be started when a
> specific network comes up.

Provided that ntp is properly configured, it doesn't really matter.



--
Per Jessen, Zürich (19.2°C)

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Roger Oberholtzer]

On Mon, 2011-07-18 at 15:01 +0200, Per Jessen wrote:
> Anton Aylward wrote:
>
> > Your reasoning is valid, but it is also an example of a much more
> > general problem, that of dependencies.
> >
> > You are stating, quite rightly, that NTP should be started when a
> > specific network comes up.
>
> Provided that ntp is properly configured, it doesn't really matter.

My ntp setup is out-of-the-box openSUSE. All I have done is select a
time server via YaST. I have been saving the fun of learning the details
of ntp configuration for when I start using GPS/PPS in a road vehicle.

Have you made changes to ntp to achieve your fantasmagorical ntp
robustness?



Yours sincerely,

Roger Oberholtzer

OPQ Systems / Ramböll RST

Office: Int [phone]
Mobile: Int [phone]
***@ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se


--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Roger Oberholtzer]

On Mon, 2011-07-18 at 08:49 -0400, Anton Aylward wrote:

> The real solution is a proper management of dependencies and triggers.
>
> I've said before that this is a situation that 'systemd' addresses; it
> was intended to address these kinds of dependencies.

> http://en.opensuse.org/SDB:Systemd
>
> http://en.wikipedia.org/wiki/Systemd
> http://fedoraproject.org/wiki/Features/systemd

I will have to investigate. If for no other reason than that we have our
own scripts in this environment. Those will probably need to work in a
systemd environment at some point in the future.


Yours sincerely,

Roger Oberholtzer

OPQ Systems / Ramböll RST

Office: Int [phone]
Mobile: Int [phone]
***@ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se


--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Per Jessen]

Roger Oberholtzer wrote:

> On Mon, 2011-07-18 at 15:01 +0200, Per Jessen wrote:
>> Anton Aylward wrote:
>>
>> > Your reasoning is valid, but it is also an example of a much more
>> > general problem, that of dependencies.
>> >
>> > You are stating, quite rightly, that NTP should be started when a
>> > specific network comes up.
>>
>> Provided that ntp is properly configured, it doesn't really matter.
>
> My ntp setup is out-of-the-box openSUSE. All I have done is select a
> time server via YaST. I have been saving the fun of learning the
> details of ntp configuration for when I start using GPS/PPS in a road
> vehicle.
>
> Have you made changes to ntp to achieve your fantasmagorical ntp
> robustness?

Hehe, nothing fantastic about it, it is really standard - here is my
main server config, comments omitted:

server 127.127.8.1 mode 16 prefer # dcf77

server 127.127.1.0 # local clock (LCL)
fudge 127.127.1.0 stratum 10 # LCL is unsynchronized

server ntp.metas.ch
server swisstime.ethz.ch

driftfile /var/lib/ntp/drift/ntp.drift # path for drift file

logfile /var/log/ntp # alternate log file
logconfig =all


I don't use NetworkManager, and my systems run all the time. The
hardware clock is of course UTC, local time is CET/CEST.


--
Per Jessen, Zürich (19.5°C)

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Per Jessen]

Joachim Schrod wrote:

> Per Jessen wrote:
>>
>> I don't use NetworkManager, and my systems run all the time. The
>> hardware clock is of course UTC, local time is CET/CEST.
>
> So, did you ever run systems with intermittent and unreliable
> time-delivered-by-GPS situations and used NTPD in such or similar
> environments?

No, never with GPS, but with less-than-100% active connections, yes.

> This reads more as in "my systems are almost always on-line and
> ntpd works there; it can handle the occasional drop in Internet
> connections". It's quite clear that ntpd works there like a charm.

It is also clear that the switching of time servers according to
availability and quality works very well, just as it is (fairly) clear
that Roger's problem is more of a timezone issue than an ntp ditto.

> I had big problems in the past when ntpd decides that a time source
> is too unreliable and either drops it, or maybe even terminates
> itself because all time sources are too much off.

But localhost would surely always be available?

> I hope that it's clear that this is not handled by the ntpd service
> start when the servers are *not reachable at all* during startup.

That is no doubt true, but when would localhost not be reachable?

> When they suddenly appear later on and are off completely, ntpd may
> lose its mind. ntpd has also great difficulties when time sources
> disagree massively what the time is.

So do I. :-)

> ntpd works great if you have multiple time-sources that are almost
> always available and where only quality of connection is managed by
> ntpd. The more spurious your connection becomes, and especially the
> more bad time source data quality is, the more problematic is its
> behavious -- and analysing "why for heaven's sake" the time got
> wrong this time is a herculean task that I wouldn't want to do for
> an embedded system that is literally off-roads.
>
> In the case of Roger, there is the additional problem that ntpd
> uses inherently a polling model for its time sources, with

Yes, typically polling, but broadcast and using a PPS signal are
alternatives that also work well (I use broadcast on my local systems).
Using a PPS signal should now (as of 2.6.34) be possible directly too.
I have not yet played with that.


--
Per Jessen, Zürich (18.7°C)

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Joachim Schrod]

Per Jessen wrote:
> Joachim Schrod wrote:
>
> It is also clear that the switching of time servers according to
> availability and quality works very well, just as it is (fairly) clear
> that Roger's problem is more of a timezone issue than an ntp ditto.

I wasn't referring to Roger's laptop problem. That clearly seems
like a configuration error.

I referred to his goal to get robust and reliable time syncs in his
automotive IT systems, i.e., in embedded car systems with
intermittent GPS connections.

>> I had big problems in the past when ntpd decides that a time source
>> is too unreliable and either drops it, or maybe even terminates
>> itself because all time sources are too much off.
>
> But localhost would surely always be available?

That's not the problem. If you start ntpd with only localhost, and
if a time server gets available later whose time is different by
more than 20 minutes, ntpd will terminate itself. (To be more
precise: the difference must be as large for some polls, 8 IIRC, to
get a full reach shift register of 0377. But polling is not good
for Roger's automotive IT use case and should be avoided anyhow, we
have already agreed upon that.)

Joachim

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod Email: ***@acm.org
Roedermark, Germany

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Per Jessen]

Joachim Schrod wrote:

>>> I had big problems in the past when ntpd decides that a time source
>>> is too unreliable and either drops it, or maybe even terminates
>>> itself because all time sources are too much off.
>>
>> But localhost would surely always be available?
>
> That's not the problem. If you start ntpd with only localhost, and
> if a time server gets available later whose time is different by
> more than 20 minutes, ntpd will terminate itself. (To be more
> precise: the difference must be as large for some polls, 8 IIRC, to
> get a full reach shift register of 0377.

I agree, this is a potential problem. (the sanity check is 1000s ~
16min).


--
Per Jessen, Zürich (18.1°C)

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Roger Oberholtzer]

On Mon, 2011-07-18 at 19:36 +0200, Per Jessen wrote:
> Joachim Schrod wrote:
>
> >>> I had big problems in the past when ntpd decides that a time source
> >>> is too unreliable and either drops it, or maybe even terminates
> >>> itself because all time sources are too much off.
> >>
> >> But localhost would surely always be available?
> >
> > That's not the problem. If you start ntpd with only localhost, and
> > if a time server gets available later whose time is different by
> > more than 20 minutes, ntpd will terminate itself. (To be more
> > precise: the difference must be as large for some polls, 8 IIRC, to
> > get a full reach shift register of 0377.
>
> I agree, this is a potential problem. (the sanity check is 1000s ~
> 16min).

Can I be sure ntp knows that my 2 hour time difference on the hardware
clock is correct and not an error? Remember that the hardware clock is
UTC time. And we do not all live in that timezone. I can't help but feel
that when a non-localhost server is not found, ntp gets confused about
this.


--
Roger Oberholtzer

OPQ Systems / Ramböll RST

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden

Office: Int [phone]
Mobile: Int [phone]

SHAW'S PRINCIPAL
Build a system that even a fool can use,
and only a fool will want to use it.


--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Joachim Schrod]

Roger Oberholtzer wrote:
>
> Can I be sure ntp knows that my 2 hour time difference on the hardware
> clock is correct and not an error? Remember that the hardware clock is
> UTC time.

As Carlos explained, ntp doesn't know anything about hardware
clock. The CMOS hardware clock's clock, time is transferred by
boot.clock to the system hardware clock. ntpd only works with the
system hardware clock, not with the battery-buffered CMOS hardware
clock.

> And we do not all live in that timezone.

Per and I are from Europe as well, and it works at our installations.

Joachim

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod Email: ***@acm.org
Roedermark, Germany

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Roger Oberholtzer]

On Tue, 2011-07-19 at 11:09 +0200, Joachim Schrod wrote:
> Roger Oberholtzer wrote:
> >
> > Can I be sure ntp knows that my 2 hour time difference on the hardware
> > clock is correct and not an error? Remember that the hardware clock is
> > UTC time.
>
> As Carlos explained, ntp doesn't know anything about hardware
> clock. The CMOS hardware clock's clock, time is transferred by
> boot.clock to the system hardware clock. ntpd only works with the
> system hardware clock, not with the battery-buffered CMOS hardware
> clock.
>
> > And we do not all live in that timezone.
>
> Per and I are from Europe as well, and it works at our installations.

It also works for all my systems that are permanently attached to the
network where the time server lives. My issue is with system where that
is not the case.



Yours sincerely,

Roger Oberholtzer

OPQ Systems / Ramböll RST

Office: Int [phone]
Mobile: Int [phone]
***@ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se


--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Joachim Schrod]

Roger Oberholtzer wrote:
> On Tue, 2011-07-19 at 11:09 +0200, Joachim Schrod wrote:
>> Roger Oberholtzer wrote:
>> >
>> > Can I be sure ntp knows that my 2 hour time difference on the hardware
>> > clock is correct and not an error? Remember that the hardware clock is
>> > UTC time.
>>
>> As Carlos explained, ntp doesn't know anything about hardware
>> clock. The CMOS hardware clock's clock, time is transferred by
>> boot.clock to the system hardware clock. ntpd only works with the
>> system hardware clock, not with the battery-buffered CMOS hardware
>> clock.
>>
>> > And we do not all live in that timezone.
>>
>> Per and I are from Europe as well, and it works at our installations.
>
> It also works for all my systems that are permanently attached to the
> network where the time server lives. My issue is with system where that
> is not the case.

Are you sure?

If you have the same error on the other systems, that error will
get corrected at start of ntpd immediately. You might not notice
the erroneous initial setting.

If the syslog timestamps are correct directly before ntpd starts,
then its a safe assumption to say so, though. :-)

Joachim

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod Email: ***@acm.org
Roedermark, Germany

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Anton Aylward]

Roger Oberholtzer said the following on 07/18/2011 06:29 PM:
>
> Can I be sure ntp knows that my 2 hour time difference on the hardware
> clock is correct and not an error? Remember that the hardware clock is
> UTC time. And we do not all live in that timezone. I can't help but feel
> that when a non-localhost server is not found, ntp gets confused about
> this.

Many of us who don't like in the UTC timezone can say "it works for me".

I set this all up CLI from the man pages and a How-To a long time ago,
so I don't think I can led you though it, and as hers have pointed out,
my idea of what goes where is a bit confused.

But I don't have the problems you describe.


What you seem to be saying is that if NTP can't find an external
reference (e.g. the network isn't up, the laptop is 'standalone') you
see a problem.

You think the problem is that the hardware clock being UTC and being 2
hours different from localtime is the problem.

Well my hardware clock s FIVE hours away from my local time.
But I don't have your problems.

In "man hwclock: I read

<quote>
-u, --utc

--localtime
Indicates that the Hardware Clock is kept in Coordinated
Universal Time or local time, respectively. It is your choice
whether to keep your clock in UTC or local time, but nothing in
the clock tells which you've chosen. So this option is how you
give that information to hwclock.

If you specify the wrong one of these options (or specify
neither and take a wrong default), both setting and querying
of the Hardware Clock will be messed up.

If you specify neither --utc nor --localtime , the default
is whichever was specified the last time hwclock was
used to set the clock (i.e. hwclock was successfully run
with the --set, --systohc, or --adjust options), as
recorded in the adjtime file.
<quote>



My understanding is that "under the hood" UNIX of old ALWAYS worked in
GMT, which we now UTC. I believe all Internet clocks work in UTC as
well.. At the application layer the translation from UTC/GMT to local
time is done. That's where DST and the like are accommodated.

It may be that you have the variable "TZ" in the environment.
Or not. In which case, as the manual says, a system default is used.
Which is probably the timezone information in compiled form in /etc/timezone

See "apropos timezone"

However the above quote makes it clear that you can mess things up.

[1] http://www.nist.gov/pml/div688/grp40/its.cfm
<quote>
Many of the available NTP software clients for personal computers
don’t do any averaging at all. Instead, they make a single timing
request to a signal server (just like a Daytime or Time client) and
then use this information to set their computer’s clock. The proper
name for this type of client is SNTP (Simple Network Time Protocol).

The NIST servers listen for a NTP request on port 123, and respond
by sending a udp/ip data packet in the NTP format. The data packet
includes a 64-bit timestamp containing the time in UTC seconds
since January 1, 1900 with a resolution of 200 ps.
</quote>

I use three reference servers in North America


--
Knowledge will forever govern ignorance: And a people who mean to be
their own governours, must arm themselves with the power which knowledge
gives.
--James Madison, quoted on the Library of Congress
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Per Jessen]

Roger Oberholtzer wrote:

> On Mon, 2011-07-18 at 19:36 +0200, Per Jessen wrote:
>> Joachim Schrod wrote:
>>
>> >>> I had big problems in the past when ntpd decides that a time
>> >>> source is too unreliable and either drops it, or maybe even
>> >>> terminates itself because all time sources are too much off.
>> >>
>> >> But localhost would surely always be available?
>> >
>> > That's not the problem. If you start ntpd with only localhost, and
>> > if a time server gets available later whose time is different by
>> > more than 20 minutes, ntpd will terminate itself. (To be more
>> > precise: the difference must be as large for some polls, 8 IIRC, to
>> > get a full reach shift register of 0377.
>>
>> I agree, this is a potential problem. (the sanity check is 1000s ~
>> 16min).
>
> Can I be sure ntp knows that my 2 hour time difference on the hardware
> clock is correct and not an error? Remember that the hardware clock is
> UTC time. And we do not all live in that timezone.

ntp doesn't care about timezones.

http://en.wikipedia.org/wiki/Network_Time_Protocol

"It provides Coordinated Universal Time (UTC). No information about time
zones or daylight saving time is transmitted; this information is
outside its scope and must be obtained separately."


--
Per Jessen, Zürich (16.1°C)

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Per Jessen]

Roger Oberholtzer wrote:

> The system was set up by YaST during installation. In one of the first
> dialogs, I specified that the PC clock was set to UTC time (I had done
> this in the BIOS before installation)

In the BIOS settings? I don't think I ever had reason to do that. If
your BIOS knowns about timezones, maybe there's an interaction here
that we're not aware of.

> and I indicated that I was in Sweden. We do this all the time in all
> our remote systems and it has always worked, including things like
> daylight savings time changes being automatic.

Yep, that's what I do too (except I pick Switzerland :-), but the
timezone is the same).


--
Per Jessen, Zürich (16.4°C)

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Roger Oberholtzer]

On Mon, 2011-07-18 at 19:57 -0400, Anton Aylward wrote:
> Roger Oberholtzer said the following on 07/18/2011 06:29 PM:
> >
> > Can I be sure ntp knows that my 2 hour time difference on the hardware
> > clock is correct and not an error? Remember that the hardware clock is
> > UTC time. And we do not all live in that timezone. I can't help but feel
> > that when a non-localhost server is not found, ntp gets confused about
> > this.
>
> Many of us who don't like in the UTC timezone can say "it works for me".
>
> I set this all up CLI from the man pages and a How-To a long time ago,
> so I don't think I can led you though it, and as hers have pointed out,
> my idea of what goes where is a bit confused.
>
> But I don't have the problems you describe.

[Stuff about setting it up by hand deleted.]

The system was set up by YaST during installation. In one of the first
dialogs, I specified that the PC clock was set to UTC time (I had done
this in the BIOS before installation) and I indicated that I was in
Sweden. We do this all the time in all our remote systems and it has
always worked, including things like daylight savings time changes being
automatic.

It is only when I introduced ntp that the mystery appeared. And ntp is
also set up by YaST. I posted my settings elsewhere in the thread.


Yours sincerely,

Roger Oberholtzer

OPQ Systems / Ramböll RST

Office: Int [phone]
Mobile: Int [phone]
***@ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se


--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Roger Oberholtzer]

On Tue, 2011-07-19 at 08:14 +0200, Per Jessen wrote:

>
> ntp doesn't care about timezones.
>
> http://en.wikipedia.org/wiki/Network_Time_Protocol
>
> "It provides Coordinated Universal Time (UTC). No information about time
> zones or daylight saving time is transmitted; this information is
> outside its scope and must be obtained separately."

OK. That should not be a problem, I guess. The timezone thing is a
per-user setting, not a system setting. The question asked during the
openSUSE install about this is just to get a default value for this.

That my clock in Linux is off by the same difference could always be an
unfortunate coincidence.

More time checking will happen this evening when I have access to the
offending system.



Yours sincerely,

Roger Oberholtzer

OPQ Systems / Ramböll RST

Office: Int [phone]
Mobile: Int [phone]
***@ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se


--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Roger Oberholtzer]

On Tue, 2011-07-19 at 08:20 +0200, Per Jessen wrote:
> Roger Oberholtzer wrote:
>
> > The system was set up by YaST during installation. In one of the first
> > dialogs, I specified that the PC clock was set to UTC time (I had done
> > this in the BIOS before installation)
>
> In the BIOS settings? I don't think I ever had reason to do that. If
> your BIOS knowns about timezones, maybe there's an interaction here
> that we're not aware of.

The clock seen in the BIOS is the one that survives power cycling. It is
the battery powered clock that is the start of all this. The time that
the SUSE install asks about being in UTC time, is this clock. So I have
it set to UTC. It does not know about timezones. It is simply the UTC
clock.

> > and I indicated that I was in Sweden. We do this all the time in all
> > our remote systems and it has always worked, including things like
> > daylight savings time changes being automatic.
>
> Yep, that's what I do too (except I pick Switzerland :-), but the
> timezone is the same).
>
>
> --
> Per Jessen, Zürich (16.4°C)
>

Yours sincerely,

Roger Oberholtzer

OPQ Systems / Ramböll RST

Office: Int [phone]
Mobile: Int [phone]
***@ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se


--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Per Jessen]

Roger Oberholtzer wrote:

> On Tue, 2011-07-19 at 08:14 +0200, Per Jessen wrote:
>
>>
>> ntp doesn't care about timezones.
>>
>> http://en.wikipedia.org/wiki/Network_Time_Protocol
>>
>> "It provides Coordinated Universal Time (UTC). No information about
>> time
>> zones or daylight saving time is transmitted; this information is
>> outside its scope and must be obtained separately."
>
> OK. That should not be a problem, I guess. The timezone thing is a
> per-user setting, not a system setting.

Hmm, I think it's a system thing too - see /etc/localtime


--
Per Jessen, Zürich (17.3°C)

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Roger Oberholtzer]

On Tue, 2011-07-19 at 10:44 +0200, Per Jessen wrote:
> Roger Oberholtzer wrote:
>
> > On Tue, 2011-07-19 at 08:14 +0200, Per Jessen wrote:
> >
> >>
> >> ntp doesn't care about timezones.
> >>
> >> http://en.wikipedia.org/wiki/Network_Time_Protocol
> >>
> >> "It provides Coordinated Universal Time (UTC). No information about
> >> time
> >> zones or daylight saving time is transmitted; this information is
> >> outside its scope and must be obtained separately."
> >
> > OK. That should not be a problem, I guess. The timezone thing is a
> > per-user setting, not a system setting.
>
> Hmm, I think it's a system thing too - see /etc/localtime

There are two possible usage scenarios:

1. The hardware is in UTC time, and there is a timezone specified that
specifies how to report the local time from the UTC time.

2. The hardware is in localtime, and there is a timezone specified that
specifies how this differs from UTC time.

If ntp is used in a scenario 2, wouldn't it need to be able to set the
clock to local time and not UTC time? How would it do this if it did not
deal with timezones?

Or does the boot.clock always put the clock in UTC time no matter? So,
in my case, the clock would be left alone - it is specified as already
being in UTC time. In scenario 2, the system would change the hardware
clock, based on the timezone, to UTC time. And set it back when the
system is shutdown. Then ntp would indeed only fiddle with UTC time,
which it assumes the hardware clock always to be using. So I am really
confused why restarting ntp moves the time by 2 hours.

Plenty of places where something can go amiss.



Yours sincerely,

Roger Oberholtzer

OPQ Systems / Ramböll RST

Office: Int [phone]
Mobile: Int [phone]
***@ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se


--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Per Jessen]

Roger Oberholtzer wrote:

> On Tue, 2011-07-19 at 10:44 +0200, Per Jessen wrote:
>>
>> Hmm, I think it's a system thing too - see /etc/localtime
>
> There are two possible usage scenarios:
>
> 1. The hardware is in UTC time, and there is a timezone specified
> that specifies how to report the local time from the UTC time.

Right.

> 2. The hardware is in localtime, and there is a timezone specified
> that specifies how this differs from UTC time.

No, I don't that is an option. It doesn't matter what UTC time when
everything is in local time.



--
Per Jessen, Zürich (18.4°C)

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Dave Howorth]

Per Jessen wrote:
> Roger Oberholtzer wrote:
>
>> On Tue, 2011-07-19 at 10:44 +0200, Per Jessen wrote:
>>> Hmm, I think it's a system thing too - see /etc/localtime
>> There are two possible usage scenarios:
>>
>> 1. The hardware is in UTC time, and there is a timezone specified
>> that specifies how to report the local time from the UTC time.
>
> Right.
>
>> 2. The hardware is in localtime, and there is a timezone specified
>> that specifies how this differs from UTC time.
>
> No, I don't that is an option. It doesn't matter what UTC time when
> everything is in local time.

No! The kernel always runs in UTC. Or at least it thinks it does and all
applications are designed assuming that it does. The hardware clock
should preferably be in UTC but may need to be in localtime if the
machine dual boots windows.

If the hwclock is in localtime, then configuration needs to say what the
hwclock offset is. http://linux.die.net/man/8/hwclock

The hardware of the machine exists in some time zone and /etc/localtime
records the timezone of the physical machine.

Each user can then set their own timezone offset from UTC, if it differs
from the machine's.

A common newbie error is to have the hwclock in localtime, fail to
configure the offset (thus defaulting to zero) and everything appears to
work. Then a user explicitly sets their timezone and everything goes crazy.
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Roger Oberholtzer]

On Tue, 2011-07-19 at 10:53 +0100, Dave Howorth wrote:
> Per Jessen wrote:
> > Roger Oberholtzer wrote:
> >
> >> On Tue, 2011-07-19 at 10:44 +0200, Per Jessen wrote:
> >>> Hmm, I think it's a system thing too - see /etc/localtime
> >> There are two possible usage scenarios:
> >>
> >> 1. The hardware is in UTC time, and there is a timezone specified
> >> that specifies how to report the local time from the UTC time.
> >
> > Right.
> >
> >> 2. The hardware is in localtime, and there is a timezone specified
> >> that specifies how this differs from UTC time.
> >
> > No, I don't that is an option. It doesn't matter what UTC time when
> > everything is in local time.
>
> No! The kernel always runs in UTC. Or at least it thinks it does and all
> applications are designed assuming that it does. The hardware clock
> should preferably be in UTC but may need to be in localtime if the
> machine dual boots windows.

'preferably' yes (and in my case it is). But it is not a requirement. So
it must be dealt with.

> If the hwclock is in localtime, then configuration needs to say what the
> hwclock offset is. http://linux.die.net/man/8/hwclock

On openSUSE, it is determined by HWCLOCK, which is
in /etc/sysconfig/clock.

>
> The hardware of the machine exists in some time zone and /etc/localtime
> records the timezone of the physical machine.
>
> Each user can then set their own timezone offset from UTC, if it differs
> from the machine's.
>
> A common newbie error is to have the hwclock in localtime, fail to
> configure the offset (thus defaulting to zero) and everything appears to
> work. Then a user explicitly sets their timezone and everything goes crazy.

Not the case here. Although the case is still undecided...


Yours sincerely,

Roger Oberholtzer

OPQ Systems / Ramböll RST

Office: Int [phone]
Mobile: Int [phone]
***@ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se


--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Roger Oberholtzer]

On Tue, 2011-07-19 at 11:35 +0200, Per Jessen wrote:
> Roger Oberholtzer wrote:
>
> > On Tue, 2011-07-19 at 10:44 +0200, Per Jessen wrote:
> >>
> >> Hmm, I think it's a system thing too - see /etc/localtime
> >
> > There are two possible usage scenarios:
> >
> > 1. The hardware is in UTC time, and there is a timezone specified
> > that specifies how to report the local time from the UTC time.
>
> Right.
>
> > 2. The hardware is in localtime, and there is a timezone specified
> > that specifies how this differs from UTC time.

Maybe I should have written that like this (which is what I meant):

2. The hardware is in localtime when the system is booted, and there is
a timezone specified that specifies how this differs from UTC time.



Yours sincerely,

Roger Oberholtzer

OPQ Systems / Ramböll RST

Office: Int [phone]
Mobile: Int [phone]
***@ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se


--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Anton Aylward]

Roger Oberholtzer said the following on 07/19/2011 06:45 AM:
> Maybe I should have written that like this (which is what I meant):
>
> 2. The hardware is in localtime when the system is booted, and there is
> a timezone specified that specifies how this differs from UTC time.
>

That might be your problem.
If the setup assumes you scenario #1 but the hardware is actually in #2
that could account for the offset you see.


--
"You may delegate authority, but not responsibility."
Frank's Management Rule #1.
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Roger Oberholtzer]

On Tue, 2011-07-19 at 07:40 -0400, Anton Aylward wrote:
> Roger Oberholtzer said the following on 07/19/2011 06:45 AM:
> > Maybe I should have written that like this (which is what I meant):
> >
> > 2. The hardware is in localtime when the system is booted, and there is
> > a timezone specified that specifies how this differs from UTC time.
> >
>
> That might be your problem.
> If the setup assumes you scenario #1 but the hardware is actually in #2
> that could account for the offset you see.

It would. But I have scenario 1 through and through. And I think the
system is set up that way in that in /etc/sysconfig/clock I have:

HWCLOCK="-u"

TIMEZONE="Europe/Stockholm"

Which I think it the only place this is set. All else derives from this.



>
>
> --
> "You may delegate authority, but not responsibility."
> Frank's Management Rule #1.

Yours sincerely,

Roger Oberholtzer

OPQ Systems / Ramböll RST

Office: Int [phone]
Mobile: Int [phone]
***@ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se


--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Joachim Schrod]

Roger Oberholtzer wrote:
> On Tue, 2011-07-19 at 07:40 -0400, Anton Aylward wrote:
>> Roger Oberholtzer said the following on 07/19/2011 06:45 AM:
>> > Maybe I should have written that like this (which is what I meant):
>> >
>> > 2. The hardware is in localtime when the system is booted, and there is
>> > a timezone specified that specifies how this differs from UTC time.
>> >
>>
>> That might be your problem.
>> If the setup assumes you scenario #1 but the hardware is actually in #2
>> that could account for the offset you see.
>
> It would. But I have scenario 1 through and through. And I think the
> system is set up that way in that in /etc/sysconfig/clock I have:
>
> HWCLOCK="-u"
>
> TIMEZONE="Europe/Stockholm"
>
> Which I think it the only place this is set. All else derives from this.

No.

The TIMEZONE value is only documentation by openSUSE what time zone
was set up during installation.

During actual operation, /etc/localtime is used. More relevant,
during boot & shutdown, *ONLY* /etc/localtime is used, since no TZ
environment variable exists then.

You can verify my statement by calling

strace hwclock -r >hwclock.log 2>&1

and examining the log file. There you will see that /etc/localtime
is opened for reading.

That's why I posted the 5 action steps which include the test if
/etc/localtime has the correct value.

Joachim

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod Email: ***@acm.org
Roedermark, Germany

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Anton Aylward]

Per Jessen said the following on 07/19/2011 02:14 AM:

>> > Can I be sure ntp knows that my 2 hour time difference on the hardware
>> > clock is correct and not an error? Remember that the hardware clock is
>> > UTC time. And we do not all live in that timezone.

> ntp doesn't care about timezones.
>
> http://en.wikipedia.org/wiki/Network_Time_Protocol
>
> "It provides Coordinated Universal Time (UTC). No information about time
> zones or daylight saving time is transmitted; this information is
> outside its scope and must be obtained separately."

If you think about it for a moment that *HAS* to be the case.
Any particular reference site can be accessed from anywhere in the world
- that is from any time zone.

The 'seperately' in teh case of Linux comes from _either_ consulting the
TZ environment variable _or_ consulting /etc/timezone

--
I clicked my heels together three times and wished I was in Cuba, but
the reality fairy smacked me in the head and flew away laughing!
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Anton Aylward]

Roger Oberholtzer said the following on 07/19/2011 03:08 AM:
> The clock seen in the BIOS is the one that survives power cycling. It is
> the battery powered clock that is the start of all this. The time that
> the SUSE install asks about being in UTC time, is this clock. So I have
> it set to UTC. It does not know about timezones. It is simply the UTC
> clock.

Quite correct.
It is, as I said, the application layers that know about timezones.

It is how you set up /etc/timezone and the parameters you give to
'hwclock' -- as I said in my previous post - that determine the
behaviour you are having problems with.
--
Mary had a little key (It's all she could export),
and all the email that she sent was opened at the Fort.
-- Ron Rivest
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Anton Aylward]

Roger Oberholtzer said the following on 07/19/2011 03:12 AM:
> On Tue, 2011-07-19 at 08:14 +0200, Per Jessen wrote:
>
>> >
>> > ntp doesn't care about timezones.
>> >
>> > http://en.wikipedia.org/wiki/Network_Time_Protocol
>> >
>> > "It provides Coordinated Universal Time (UTC). No information about time
>> > zones or daylight saving time is transmitted; this information is
>> > outside its scope and must be obtained separately."

> OK. That should not be a problem, I guess. The timezone thing is a
> per-user setting, not a system setting.

Perhaps. But I think it is a system setting.
It is on my installations - openSUSE, Mandriva and Redhat
It is in /etc/timezone.

Yes, it can be overridden on a per user basis with the TZ environment
variable. Check to see if you have that set.

> The question asked during the
> openSUSE install about this is just to get a default value for this.


--
"Education must precede motivation." Jim Rohn
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Joachim Schrod]

Anton Aylward wrote:
> Roger Oberholtzer said the following on 07/19/2011 03:12 AM:
>
>> OK. That should not be a problem, I guess. The timezone thing is a
>> per-user setting, not a system setting.
>
> Perhaps. But I think it is a system setting.
> It is on my installations - openSUSE, Mandriva and Redhat
> It is in /etc/timezone.
>
> Yes, it can be overridden on a per user basis with the TZ environment
> variable. Check to see if you have that set.

TZ is not relevant as it is not set during boot, when
/etc/init.d/{boot.clock,ntpd} are run.

You are currect in your first assumption that hwclock during boot
and shutdown only cares for /etc/localtime.

Joachim

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod Email: ***@acm.org
Roedermark, Germany

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Anton Aylward]

Joachim Schrod said the following on 07/19/2011 10:44 AM:

>> > Yes, it can be overridden on a per user basis with the TZ environment
>> > variable. Check to see if you have that set.

> TZ is not relevant as it is not set during boot, when
> /etc/init.d/{boot.clock,ntpd} are run.

100% true and 100% beside the point.

As I said .... there is the system level setting, but once a user logs
in he may not be in the same time zone as the machine and will need to
be able to over-ride the timezone for his session.

Since the time the user sees, the time that Roger sees, is when he logs
in and runs commands, he should make sure that his session is not
running in a different timezone from the machine, that TZ has not been
set somewhere in the _shell_ initialization and then used by the
commands that display the - interpreted - local time.

Since he is running commands a reporting their output rather than using
some "raw" core inspection language it is possible that TZ has been set.
Maybe in /etc/profile.d/ or maybe in ~/.profile.
Maybe.
Unlikely, and I hope not, but the possibility needs to be eliminated so
we don't turn round and say "DUH!"


--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Roger Oberholtzer]

On Tue, 2011-07-19 at 07:33 -0400, Anton Aylward wrote:
> Per Jessen said the following on 07/19/2011 02:14 AM:
>
> >> > Can I be sure ntp knows that my 2 hour time difference on the hardware
> >> > clock is correct and not an error? Remember that the hardware clock is
> >> > UTC time. And we do not all live in that timezone.
>
> > ntp doesn't care about timezones.
> >
> > http://en.wikipedia.org/wiki/Network_Time_Protocol
> >
> > "It provides Coordinated Universal Time (UTC). No information about time
> > zones or daylight saving time is transmitted; this information is
> > outside its scope and must be obtained separately."
>
> If you think about it for a moment that *HAS* to be the case.
> Any particular reference site can be accessed from anywhere in the world
> - that is from any time zone.
>
> The 'seperately' in teh case of Linux comes from _either_ consulting the
> TZ environment variable _or_ consulting /etc/timezone

The ntp protocol would be most sane if it were transmitted only as UTC.
What a local system decides to do with that information is a whole
different question - and one the ntp protocol really can't address.
openSUSE seems to expect that the system clock is UTC, no matter what
the battery clock is. Or this is how it looks to me.


Yours sincerely,

Roger Oberholtzer

OPQ Systems / Ramböll RST

Office: Int [phone]
Mobile: Int [phone]
***@ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se


--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Anton Aylward]

Roger Oberholtzer said the following on 07/19/2011 08:00 AM:
> The ntp protocol would be most sane if it were transmitted only as UTC.

That is in fact the case as both Per and I have pointed out by reference.

> What a local system decides to do with that information is a whole
> different question - and one the ntp protocol really can't address.

Sort of.
NTP only has to set the itnernal - software I beelive - system clock.
That runs on UTC.

> openSUSE seems to expect that the system clock is UTC,

I think that is so.
It has always been the case, to the best of my knowledge, with UNIX
systems. It needs to be so since different users or different
applciations may be working in different timezones, so each have their
offset from UTC.

> no matter what
> the battery clock is. Or this is how it looks to me.

I have referred to "man hwclock" and that seems to be the point at which
the battery clock being UTC or local comes into it.

Once again:
<quote>
-u, --utc

--localtime
Indicates that the Hardware Clock is kept in Coordinated
Universal Time or local time, respectively. It is your choice
whether to keep your clock in UTC or local time, but nothing in
the clock tells which you've chosen. So this option is how you
give that information to hwclock.

If you specify the wrong one of these options (or specify
neither and take a wrong default), both setting and querying
of the Hardware Clock will be messed up.

If you specify neither --utc nor --localtime , the default
is whichever was specified the last time hwclock was
used to set the clock (i.e. hwclock was successfully run
with the --set, --systohc, or --adjust options), as
recorded in the adjtime file.
<quote>



--
"Nothing is more difficult to carry out, nor more doubtful of
success, nor more dangerous to handle, than to initiate a new
order of things." -- Machiavelli
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Dave Howorth]

Roger Oberholtzer wrote:
> openSUSE seems to expect that the system clock is UTC, no matter what
> the battery clock is. Or this is how it looks to me.

Exactly so, and not just opensuse. The kernels of all Unix and Linux
systems run in UTC. Bad things happen if they are made not to.
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Joachim Schrod]

Per Jessen wrote:
>
> I don't use NetworkManager, and my systems run all the time. The
> hardware clock is of course UTC, local time is CET/CEST.

So, did you ever run systems with intermittent and unreliable
time-delivered-by-GPS situations and used NTPD in such or similar
environments?

This reads more as in "my systems are almost always on-line and
ntpd works there; it can handle the occasional drop in Internet
connections". It's quite clear that ntpd works there like a charm.

I had big problems in the past when ntpd decides that a time source
is too unreliable and either drops it, or maybe even terminates
itself because all time sources are too much off. I hope that it's
clear that this is not handled by the ntpd service start when the
servers are *not reachable at all* during startup. When they
suddenly appear later on and are off completely, ntpd may lose its
mind. ntpd has also great difficulties when time sources disagree
massively what the time is.

ntpd works great if you have multiple time-sources that are almost
always available and where only quality of connection is managed by
ntpd. The more spurious your connection becomes, and especially the
more bad time source data quality is, the more problematic is its
behavious -- and analysing "why for heaven's sake" the time got
wrong this time is a herculean task that I wouldn't want to do for
an embedded system that is literally off-roads.

In the case of Roger, there is the additional problem that ntpd
uses inherently a polling model for its time sources, with
staggering polling intervals that shall spare the time servers from
overload. AFAIU, Roger needs the complete opposite, a triggering
model that takes into account each available PPS signal. Since I
don't know chrony, I don't know if it delivers that -- but if it
does so, if it is robust, and if the code looks good, I would go
with chrony in the use case that Roger describes.

Cheers,
Joachim

PS: In case this isn't clear: I fought with error analysis in big
ntpd installations over several continents more often than I care
to remember; at least if I want to sleep good at night.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod Email: ***@acm.org
Roedermark, Germany

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Roger Oberholtzer]

On Mon, 2011-07-18 at 12:05 +0200, Per Jessen wrote:

> To stick to the legal metaphors, I think the judge will dismiss your
> claim as hear-say :-) At least until you present evidence that the
> server is configured but not used ("ntpq -p" will show the peers).
>

I finally got a chance to run this (after boot, logged in and network
up, time still wrong):

# ntpq -p
ntpq: read: Connection refused


After boot (real time was 21.48), I see this is /var/log/messages:

Jul 18 23:48:59 barracuda ntpd[3033]: ntpd ***@1.2290-o Tue Jun 7 03:10:56 UTC 2011 (1)
Jul 18 23:48:59 barracuda ntpd[3034]: proto: precision = 0.243 usec
Jul 18 23:48:59 barracuda ntpd[3034]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
Jul 18 23:48:59 barracuda ntpd[3034]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
Jul 18 23:48:59 barracuda ntpd[3034]: Listen and drop on 1 v6wildcard :: UDP 123
Jul 18 23:48:59 barracuda ntpd[3034]: Listen normally on 2 lo 127.0.0.1 UDP 123
Jul 18 23:48:59 barracuda ntpd[3034]: Listen normally on 3 lo ::1 UDP 123
Jul 18 23:48:59 barracuda ntpd[3034]: peers refreshed

/var/log/ntp has (wireless up at 23:54:00):

18 Jul 23:48:59 ntpd[3034]: Deferring DNS for ntp1.sth.netnod.se 1
18 Jul 23:49:02 ntpd[3069]: host name not found: ntp1.sth.netnod.se
18 Jul 23:50:04 ntpd[3069]: host name not found: ntp1.sth.netnod.se
18 Jul 23:52:06 ntpd[3069]: host name not found: ntp1.sth.netnod.se
18 Jul 23:54:00 ntpd[3034]: Listen normally on 4 wlan0 192.168.1.17 UDP 123
18 Jul 23:54:01 ntpd[3034]: Listen normally on 5 wlan0 fe80::227:10ff:fe71:6724 UDP 123
18 Jul 23:54:01 ntpd[3034]: peers refreshed
18 Jul 23:54:01 ntpd[3034]: new interface(s) found: waking up resolver
18 Jul 23:54:03 ntpd[3069]: DNS ntp1.sth.netnod.se -> 192.36.144.22

My /etc/sysconfig has:

NTPD_OPTIONS="-g -u ntp:ntp"

My /etc/ntp.conf file is:

server 127.127.1.0
fudge 127.127.1.0 stratum 10
driftfile /var/lib/ntp/drift/ntp.drift
logfile /var/log/ntp
keys /etc/ntp.keys
trustedkey 1
requestkey 1
server ntp1.sth.netnod.se iburst



So, it seems that the time source is retried, but nothing happens. And,
the -p option is failing.

--
Roger Oberholtzer

OPQ Systems / Ramböll RST

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden

Office: Int [phone]
Mobile: Int [phone]

SHAW'S PRINCIPAL
Build a system that even a fool can use,
and only a fool will want to use it.

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Roger Oberholtzer]

On Tue, 2011-07-19 at 08:35 +0200, Per Jessen wrote:
> Roger Oberholtzer wrote:
>
> > On Mon, 2011-07-18 at 12:05 +0200, Per Jessen wrote:
> >
> >> To stick to the legal metaphors, I think the judge will dismiss your
> >> claim as hear-say :-) At least until you present evidence that the
> >> server is configured but not used ("ntpq -p" will show the peers).
> >>
> >
> > I finally got a chance to run this (after boot, logged in and network
> > up, time still wrong):
> >
> > # ntpq -p
> > ntpq: read: Connection refused
>
> At this point, could you also do 'pidof ntpd', please. I'm pretty
> certain ntpd isn't running.

But it is! I see it in the process list. It is always there. When I
restart it, I get a message (in /var/log/ntp) from the original one that
it is shutting down. Then the messages from the newly started one.

> > After boot (real time was 21.48), I see this is /var/log/messages:
> >
> > Jul 18 23:48:59 barracuda ntpd[3033]: ntpd ***@1.2290-o Tue Jun 7
> > 03:10:56 UTC 2011 (1) Jul 18 23:48:59 barracuda ntpd[3034]: proto:
>
> So the question now is - _who_ adjusted the system clock? It was _not_
> ntpd, because that is only just starting.
>
> > /var/log/ntp has (wireless up at 23:54:00):
> >
> > 18 Jul 23:48:59 ntpd[3034]: Deferring DNS for ntp1.sth.netnod.se 1
> > 18 Jul 23:49:02 ntpd[3069]: host name not found: ntp1.sth.netnod.se
> > 18 Jul 23:50:04 ntpd[3069]: host name not found: ntp1.sth.netnod.se
> > 18 Jul 23:52:06 ntpd[3069]: host name not found: ntp1.sth.netnod.se
> > 18 Jul 23:54:00 ntpd[3034]: Listen normally on 4 wlan0 192.168.1.17
> > UDP 123 18 Jul 23:54:01 ntpd[3034]: Listen normally on 5 wlan0
> > fe80::227:10ff:fe71:6724 UDP 123 18 Jul 23:54:01 ntpd[3034]: peers
> > refreshed 18 Jul 23:54:01 ntpd[3034]: new interface(s) found: waking
> > up resolver 18 Jul 23:54:03 ntpd[3069]: DNS ntp1.sth.netnod.se ->
> > 192.36.144.22
>
> what about the next 20-30mins of log?

The system had been running for about 60 minutes when I took the logs.
That is all there was. Nothing more in either file.

> > My /etc/sysconfig has:
> >
> > NTPD_OPTIONS="-g -u ntp:ntp"
> >
> > My /etc/ntp.conf file is:
> >
> > server 127.127.1.0
> > fudge 127.127.1.0 stratum 10
> > driftfile /var/lib/ntp/drift/ntp.drift
> > logfile /var/log/ntp
> > keys /etc/ntp.keys
> > trustedkey 1
> > requestkey 1
> > server ntp1.sth.netnod.se iburst
>
> All fine.
>
> > So, it seems that the time source is retried, but nothing happens.
> > And, the -p option is failing.
>
> Because ntpd has left the building.

Or has decided to hide in the basement.

> A wild guess at what is happening - before ntp starts, something adjusts
> your system clock 2 hours forward. ntp starts, but has no network, so
> just resumes normal working mode. Network comes up, ntpd say "yippee!",
> gets fresh time from netnod.se and then leaves as the time gap is more
> than the sanity check of 1000s.

Seems as good a guess as any. The other player here is boot.clock.

I will try disabling ntp and see if the time comes up correctly.


Yours sincerely,

Roger Oberholtzer

OPQ Systems / Ramböll RST

Office: Int [phone]
Mobile: Int [phone]
***@ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se


--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Per Jessen]

Roger Oberholtzer wrote:

> On Mon, 2011-07-18 at 12:05 +0200, Per Jessen wrote:
>
>> To stick to the legal metaphors, I think the judge will dismiss your
>> claim as hear-say :-) At least until you present evidence that the
>> server is configured but not used ("ntpq -p" will show the peers).
>>
>
> I finally got a chance to run this (after boot, logged in and network
> up, time still wrong):
>
> # ntpq -p
> ntpq: read: Connection refused

At this point, could you also do 'pidof ntpd', please. I'm pretty
certain ntpd isn't running.

> After boot (real time was 21.48), I see this is /var/log/messages:
>
> Jul 18 23:48:59 barracuda ntpd[3033]: ntpd ***@1.2290-o Tue Jun 7
> 03:10:56 UTC 2011 (1) Jul 18 23:48:59 barracuda ntpd[3034]: proto:

So the question now is - _who_ adjusted the system clock? It was _not_
ntpd, because that is only just starting.

> /var/log/ntp has (wireless up at 23:54:00):
>
> 18 Jul 23:48:59 ntpd[3034]: Deferring DNS for ntp1.sth.netnod.se 1
> 18 Jul 23:49:02 ntpd[3069]: host name not found: ntp1.sth.netnod.se
> 18 Jul 23:50:04 ntpd[3069]: host name not found: ntp1.sth.netnod.se
> 18 Jul 23:52:06 ntpd[3069]: host name not found: ntp1.sth.netnod.se
> 18 Jul 23:54:00 ntpd[3034]: Listen normally on 4 wlan0 192.168.1.17
> UDP 123 18 Jul 23:54:01 ntpd[3034]: Listen normally on 5 wlan0
> fe80::227:10ff:fe71:6724 UDP 123 18 Jul 23:54:01 ntpd[3034]: peers
> refreshed 18 Jul 23:54:01 ntpd[3034]: new interface(s) found: waking
> up resolver 18 Jul 23:54:03 ntpd[3069]: DNS ntp1.sth.netnod.se ->
> 192.36.144.22

what about the next 20-30mins of log?

> My /etc/sysconfig has:
>
> NTPD_OPTIONS="-g -u ntp:ntp"
>
> My /etc/ntp.conf file is:
>
> server 127.127.1.0
> fudge 127.127.1.0 stratum 10
> driftfile /var/lib/ntp/drift/ntp.drift
> logfile /var/log/ntp
> keys /etc/ntp.keys
> trustedkey 1
> requestkey 1
> server ntp1.sth.netnod.se iburst

All fine.

> So, it seems that the time source is retried, but nothing happens.
> And, the -p option is failing.

Because ntpd has left the building.

A wild guess at what is happening - before ntp starts, something adjusts
your system clock 2 hours forward. ntp starts, but has no network, so
just resumes normal working mode. Network comes up, ntpd say "yippee!",
gets fresh time from netnod.se and then leaves as the time gap is more
than the sanity check of 1000s.


--
Per Jessen, Zürich (16.4°C)

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Per Jessen]

Roger Oberholtzer wrote:

> On Tue, 2011-07-19 at 08:35 +0200, Per Jessen wrote:
>> Roger Oberholtzer wrote:
>>
>> > # ntpq -p
>> > ntpq: read: Connection refused
>>
>> At this point, could you also do 'pidof ntpd', please. I'm pretty
>> certain ntpd isn't running.
>
> But it is! I see it in the process list. It is always there.

Okay - clearly something isn't quite working here. I have never seen
ntpd running, yet not responding to ntpq. Could you perhaps try
adding '-d' to the command line options.

> The system had been running for about 60 minutes when I took the logs.
> That is all there was. Nothing more in either file.

Okay, then it would be interesting to add "logconfig =all" to your ntp
config file.

> I will try disabling ntp and see if the time comes up correctly.

You can also in /var/log/messages instead and see when you get the
2-hour time-jump. ntp was clearly starting when the time had already
been adjusted. It's probably sntp that does it as part of the ntp
init-script.


--
Per Jessen, Zürich (17.8°C)

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Per Jessen]

Per Jessen wrote:

> Okay - clearly something isn't quite working here. I have never seen
> ntpd running, yet not responding to ntpq. Could you perhaps try
> adding '-d' to the command line options.

Ignore that, there is no -d option for ntpq.


--
Per Jessen, Zürich (17.5°C)

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Joachim Schrod]

Roger Oberholtzer wrote:
>
> After boot (real time was 21.48), I see this is /var/log/messages:
>
> Jul 18 23:48:59 barracuda ntpd[3033]: ntpd ***@1.2290-o Tue Jun 7 03:10:56 UTC 2011 (1)

As Per wrote, at the time of start of ntpd, system time is already
set incorrect. You need to investigate that first and stop to fuss
about ntpd not synchronizing to its time sources - you can do that
later... ;-)

First, you have to assure that book.clock works:

1) Check that "hwclock -r -u" outputs roughly correct time in UTC.

2) Check: HWCLOCK="-u" in /etc/sysconfig/clock.

3) Check that /etc/sysconfig/clock has a European timezone name
as TIMEZONE value. (The value of DEFAULT_TIMEZONE doesn't
matter.)

4) Check that /etc/localtime is correct:
$ bash
$ . /etc/sysconfig/clock
$ cmp /etc/localtime /usr/share/zoneinfo/$TIMEZONE
# This must output no message
$ exit

5) Call "/etc/init.d/boot.clock restart" and check with "date"
if the time is off by 2 hours afterwards.

Report back if all of these tests are OK at your installation.
If yes, debugging the ntpd startup will be the next step.

Joachim

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod Email: ***@acm.org
Roedermark, Germany

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Per Jessen]

Per Jessen wrote:

> Roger Oberholtzer wrote:
>
>> On Tue, 2011-07-19 at 08:35 +0200, Per Jessen wrote:
>>> Roger Oberholtzer wrote:
>>>
>>> > # ntpq -p
>>> > ntpq: read: Connection refused
>>>
>>> At this point, could you also do 'pidof ntpd', please. I'm pretty
>>> certain ntpd isn't running.
>>
>> But it is! I see it in the process list. It is always there.
>
> Okay - clearly something isn't quite working here. I have never seen
> ntpd running, yet not responding to ntpq.

I just don't understand this - it's really important to be able to use
ntpq, because the configuration can be changed in-flight. Is there any
chance that your DHCP server is dishing out a time- or ntp-server
option that points your ntp to a local server? Try grepping
through /var/log/messages looking for 'ntp.*runtime'


--
Per Jessen, Zürich (18.5°C)

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Roger Oberholtzer]

On Tue, 2011-07-19 at 11:39 +0200, Per Jessen wrote:
> Per Jessen wrote:
>
> > Roger Oberholtzer wrote:
> >
> >> On Tue, 2011-07-19 at 08:35 +0200, Per Jessen wrote:
> >>> Roger Oberholtzer wrote:
> >>>
> >>> > # ntpq -p
> >>> > ntpq: read: Connection refused
> >>>
> >>> At this point, could you also do 'pidof ntpd', please. I'm pretty
> >>> certain ntpd isn't running.
> >>
> >> But it is! I see it in the process list. It is always there.
> >
> > Okay - clearly something isn't quite working here. I have never seen
> > ntpd running, yet not responding to ntpq.
>
> I just don't understand this - it's really important to be able to use
> ntpq, because the configuration can be changed in-flight. Is there any
> chance that your DHCP server is dishing out a time- or ntp-server
> option that points your ntp to a local server? Try grepping
> through /var/log/messages looking for 'ntp.*runtime'

When looking for the messages I sent earlier I searched for 'ntp'. I saw
nothing other than what I sent before.



Yours sincerely,

Roger Oberholtzer

OPQ Systems / Ramböll RST

Office: Int [phone]
Mobile: Int [phone]
***@ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se


--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Roger Oberholtzer]

On Tue, 2011-07-19 at 11:23 +0200, Joachim Schrod wrote:
> Roger Oberholtzer wrote:
> >
> > After boot (real time was 21.48), I see this is /var/log/messages:
> >
> > Jul 18 23:48:59 barracuda ntpd[3033]: ntpd ***@1.2290-o Tue Jun 7 03:10:56 UTC 2011 (1)
>
> As Per wrote, at the time of start of ntpd, system time is already
> set incorrect. You need to investigate that first and stop to fuss
> about ntpd not synchronizing to its time sources - you can do that
> later... ;-)

Of course. But my goal here is not so much to simply correct my broken
system. I could do that is short order. My exercise is to see why it is
wrong with the goal being that I can keep it from happening again (if
possible). Since we will be using this time as part of a data timestamp
system, I need to know what could mess it up so it does not happen
again. Of course, as there are probably a zillion things that could
cause this, perhaps I have a loosing battle ahead of me.


Yours sincerely,

Roger Oberholtzer

OPQ Systems / Ramböll RST

Office: Int [phone]
Mobile: Int [phone]
***@ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se


--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Joachim Schrod]

Roger Oberholtzer wrote:
> On Tue, 2011-07-19 at 11:23 +0200, Joachim Schrod wrote:
>> Roger Oberholtzer wrote:
>> >
>> > After boot (real time was 21.48), I see this is /var/log/messages:
>> >
>> > Jul 18 23:48:59 barracuda ntpd[3033]: ntpd ***@1.2290-o Tue Jun 7 03:10:56 UTC 2011 (1)
>>
>> As Per wrote, at the time of start of ntpd, system time is already
>> set incorrect. You need to investigate that first and stop to fuss
>> about ntpd not synchronizing to its time sources - you can do that
>> later... ;-)
>
> Of course. But my goal here is not so much to simply correct my broken
> system. I could do that is short order. My exercise is to see why it is
> wrong with the goal being that I can keep it from happening again (if
> possible).

I understand this. But to see "why it is wrong" means to find first
the root cause of this issue and then decide if that's an isolated
issue or one that could happen more often.

And by now we can tell with a very high probability that the root
cause is not ntpd itself, but either boot.clock or the ntpd start
script with any action that happens before ntpd. Thus I posted the
proposed actions for analysis if boot.clock runs amok or if one has
to look at /etc/init.d/ntpd.

Joachim

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod Email: ***@acm.org
Roedermark, Germany

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Per Jessen]

Roger Oberholtzer wrote:

> On Tue, 2011-07-19 at 11:39 +0200, Per Jessen wrote:
>> Per Jessen wrote:
>>
>> > Roger Oberholtzer wrote:
>> >
>> >> On Tue, 2011-07-19 at 08:35 +0200, Per Jessen wrote:
>> >>> Roger Oberholtzer wrote:
>> >>>
>> >>> > # ntpq -p
>> >>> > ntpq: read: Connection refused
>> >>>
>> >>> At this point, could you also do 'pidof ntpd', please. I'm
>> >>> pretty certain ntpd isn't running.
>> >>
>> >> But it is! I see it in the process list. It is always there.
>> >
>> > Okay - clearly something isn't quite working here. I have never
>> > seen ntpd running, yet not responding to ntpq.
>>
>> I just don't understand this - it's really important to be able to
>> use
>> ntpq, because the configuration can be changed in-flight. Is there
>> any chance that your DHCP server is dishing out a time- or ntp-server
>> option that points your ntp to a local server? Try grepping
>> through /var/log/messages looking for 'ntp.*runtime'
>
> When looking for the messages I sent earlier I searched for 'ntp'. I
> saw nothing other than what I sent before.

Okay, than we have strace ntpq to find out what is happening:

strace -ofile ntpq -pn

If you email <file> to me directly, I'll take a look.


--
Per Jessen, Zürich (19.6°C)

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org

[Roger Oberholtzer]

On Mon, 2011-07-18 at 12:05 +0200, Per Jessen wrote:
> Roger Oberholtzer wrote:
>
> > On Mon, 2011-07-18 at 11:21 +0200, Per Jessen wrote:
> >> Roger Oberholtzer wrote:
> >>
> >> >> > IMO, the problem is ntp, not the system start stuff. Since I
> >> >> > have effectively removed my network from the system startup
> >> >> > environment, I would find it hard to see that environment being
> >> >> > able to solve ordering or dependency issues. How could a system
> >> >> > service know that some user will, via their own non-system
> >> >> > configuration, eventually, maybe start a network where an
> >> >> > interesting server lives?
> >> >>
> >> >> A daemon would just try to reach the interesting server, and when
> >> >> the error says "network not reachable" (or something similar) it
> >> >> means it's still not there.
> >> >
> >> > But how would a daemon know which network the interesting server is
> >> > on? Perhaps a moot point. It could re-try each time the network
> >> > configuration changed.
> >>
> >> It doesn't care about the network config - for arguments sake, let's
> >> assume it uses TCP. In pseudo-code, you would issue a
> >>
> >> connect(<desired server address>);
> >>
> >> If the network is not available, the connect() does not succeed.
> >> This is no different to you trying to access an external website when
> >> your network is down. Slightly different for UDP, but essentially
> >> the same.
> >
> > Of course. But, at some point in the future, will ntp retry to make
> > the connection? On that point the jury is still out.
> > You have presented evidence where it seems to. I have presented a
> > counter claim that shows up in my usage. I suspect ntp does retry the
> > connection when it does, and does not try again when it does not...
>
> To stick to the legal metaphors, I think the judge will dismiss your
> claim as hear-say :-) At least until you present evidence that the
> server is configured but not used ("ntpq -p" will show the peers).

I should add that when I restart ntp, I see this:

# rcntp restart
Shutting down network time protocol daemon (NTPD) done
19 Jul 00:48:36 sntp[6212]: Started sntp
2011-07-19 00:48:36.113523 (-0100) -7199.729726 +/- 0.001343 secs
Time synchronized with ntp1.sth.netnod.se
Starting network time protocol daemon (NTPD) done

# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*LOCAL(0) .LOCL. 10 l 7 64 3 0.000 0.000 0.000
+ntp1.sth.netnod .PPS. 1 u 1 64 3 2.506 -0.626 1.228


>
>
> --
> Per Jessen, Zürich (18.5°C)
>

--
Roger Oberholtzer

OPQ Systems / Ramböll RST

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden

Office: Int [phone]
Mobile: Int [phone]

SHAW'S PRINCIPAL
Build a system that even a fool can use,
and only a fool will want to use it.

--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org