Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #198485 > unrolled thread

What time is it, really?

Back to article view | Back to linux.debian.user

Contents

  What time is it, really? Fred <fred@blakemfg.com> - 2018-08-09 16:40 +0200
    Re: What time is it, really? Martin <keine-eile@online.de> - 2018-08-09 16:40 +0200
    Re: What time is it, really? Greg Wooledge <wooledg@eeg.ccf.org> - 2018-08-09 16:40 +0200
      Re: What time is it, really? Jim Popovitch <jim@k4vqc.com> - 2018-08-09 17:00 +0200
        Re: What time is it, really? Greg Wooledge <wooledg@eeg.ccf.org> - 2018-08-09 17:10 +0200
          Re: What time is it, really? Jim Popovitch <jim@k4vqc.com> - 2018-08-09 17:10 +0200
          Re: What time is it, really? john doe <johndoe65534@mail.com> - 2018-08-09 20:40 +0200
            Re: What time is it, really? Brian <ad44@cityscape.co.uk> - 2018-08-09 21:50 +0200
              Re: What time is it, really? Fred <fred@blakemfg.com> - 2018-08-09 23:40 +0200
                Re: What time is it, really? Shea Alterio <krusete@gmail.com> - 2018-08-10 00:00 +0200
                Re: What time is it, really? David Wright <deblis@lionunicorn.co.uk> - 2018-08-10 17:20 +0200
                  Re: What time is it, really? Michael Stone <mstone@debian.org> - 2018-08-10 17:40 +0200
                    Re: What time is it, really? David Wright <deblis@lionunicorn.co.uk> - 2018-08-10 21:50 +0200
                  Re: What time is it, really? Fred <fred@blakemfg.com> - 2018-08-10 18:40 +0200
                    Re: What time is it, really? Brian <ad44@cityscape.co.uk> - 2018-08-10 19:50 +0200
                    Re: What time is it, really? Fekete Tamás <fektom@gmail.com> - 2018-08-10 19:50 +0200
                      Re: What time is it, really? Greg Wooledge <wooledg@eeg.ccf.org> - 2018-08-10 20:10 +0200
                      Re: What time is it, really? Gene Heskett <gheskett@shentel.net> - 2018-08-10 20:20 +0200
                      Re: What time is it, really? Michael Stone <mstone@debian.org> - 2018-08-10 23:00 +0200
                        Re: What time is it, really? Fekete Tamás <fektom@gmail.com> - 2018-08-11 11:10 +0200
                    Re: What time is it, really? David Wright <deblis@lionunicorn.co.uk> - 2018-08-10 22:40 +0200
      Re: What time is it, really? Gene Heskett <gheskett@shentel.net> - 2018-08-09 17:10 +0200
      Re: What time is it, really? Darac Marjal <mailinglist@darac.org.uk> - 2018-08-09 17:20 +0200
        Re: What time is it, really? Greg Wooledge <wooledg@eeg.ccf.org> - 2018-08-09 18:00 +0200
          Re: What time is it, really? Andre Majorel <aym-naibed@teaser.fr> - 2018-08-09 19:10 +0200
          Re: What time is it, really? Nicolas George <george@nsup.org> - 2018-08-09 19:20 +0200
          Re: What time is it, really? Michael Stone <mstone@debian.org> - 2018-08-09 20:00 +0200
      Re: What time is it, really? deloptes <deloptes@gmail.com> - 2018-08-10 01:30 +0200
    Re: What time is it, really? Nicolas George <george@nsup.org> - 2018-08-09 16:50 +0200
      OT: What time is it, really? Martin <keine-eile@online.de> - 2018-08-09 17:10 +0200
        Re: OT: What time is it, really? Martin <keine-eile@online.de> - 2018-08-09 17:20 +0200
          Re: OT: What time is it, really? Nicolas George <george@nsup.org> - 2018-08-09 17:50 +0200
            Re: OT: What time is it, really? Martin <keine-eile@online.de> - 2018-08-09 18:10 +0200
          Re: OT: What time is it, really? Gene Heskett <gheskett@shentel.net> - 2018-08-09 18:20 +0200
            Re: OT: What time is it, really? Martin <keine-eile@online.de> - 2018-08-09 18:30 +0200
              Re: OT: What time is it, really? Gene Heskett <gheskett@shentel.net> - 2018-08-09 19:40 +0200
                Re: OT: What time is it, really? Anders Andersson <pipatron@gmail.com> - 2018-08-10 12:00 +0200
                  Re: OT: What time is it, really? Gene Heskett <gheskett@shentel.net> - 2018-08-10 13:50 +0200
        Re: OT: What time is it, really? Nicolas George <george@nsup.org> - 2018-08-09 17:20 +0200
      Re: What time is it, really? Fred <fred@blakemfg.com> - 2018-08-09 18:50 +0200
        Re: What time is it, really? Nicolas George <george@nsup.org> - 2018-08-09 19:00 +0200
        Re: What time is it, really? Greg Wooledge <wooledg@eeg.ccf.org> - 2018-08-09 19:00 +0200
        Re: What time is it, really? Michael Stone <mstone@debian.org> - 2018-08-09 20:00 +0200
    Re: What time is it, really? Gene Heskett <gheskett@shentel.net> - 2018-08-09 16:50 +0200

Page 1 of 3  [1] 2 3  Next page →

#198485 — What time is it, really?

Hi,

Someone complained off list about the timestamp in my emails being off.  
Being a hardware person I think hardware should work properly and clocks 
should keep accurate time.  So I installed ntpdate as suggested but it 
is not active yet.

If I ask google what time it is in Mesa AZ. the response agrees closely 
with an "atomic" clock I have.  The computer clock is about 10 min. fast.

fred@ragnok:~$ /usr/sbin/ntpdate -q time.nist.gov
server 2610:20:6f96:96::4, stratum 1, offset -610.512368, delay 0.09421
server 132.163.96.4, stratum 1, offset -610.509394, delay 0.08899
  9 Aug 06:51:15 ntpdate[13672]: step time server 132.163.96.4
offset -610.509394 sec

fred@ragnok:~$ date
Thu Aug  9 06:51:18 MST 2018

The time server is quite close to the computer clock.  What causes the 
discrepancy?  The offset in the time server response is about 10 min.  
The offset is measured from what to what and how is it measured?

Best regards,
Fred

[toc] | [next] | [standalone]

#198486

Hi Fred,

your hardware clock may be off -> man hwclock.
You can sysc it to your system time with 'hwclock -w'. hwclock requires root powers.

Am 09.08.2018 um 16:19 schrieb Fred:
> Hi,
> 
> Someone complained off list about the timestamp in my emails being off.  Being a hardware person I think hardware should work properly and clocks should keep accurate time.  So I installed ntpdate as suggested but it is not active yet.
> 
> If I ask google what time it is in Mesa AZ. the response agrees closely with an "atomic" clock I have.  The computer clock is about 10 min. fast.
> 
> fred@ragnok:~$ /usr/sbin/ntpdate -q time.nist.gov
> server 2610:20:6f96:96::4, stratum 1, offset -610.512368, delay 0.09421
> server 132.163.96.4, stratum 1, offset -610.509394, delay 0.08899
>  9 Aug 06:51:15 ntpdate[13672]: step time server 132.163.96.4
> offset -610.509394 sec
> 
> fred@ragnok:~$ date
> Thu Aug  9 06:51:18 MST 2018
> 
> The time server is quite close to the computer clock.  What causes the discrepancy?  The offset in the time server response is about 10 min.  The offset is measured from what to what and how is it measured?
> 
> Best regards,
> Fred
> 
> 

[toc] | [prev] | [next] | [standalone]

#198487

On Thu, Aug 09, 2018 at 07:19:46AM -0700, Fred wrote:
> So I installed ntpdate as suggested but it is
> not active yet.

Whoever suggested that is using outdated information.  Install ntp and
not ntpdate.

The current versions of the ntp package (since, like, Debian 6.x I think)
incorporate the one-time clock slamming feature of ntpdate, so you don't
need ntpdate at all.

> If I ask google what time it is in Mesa AZ. the response agrees closely with
> an "atomic" clock I have.  The computer clock is about 10 min. fast.

Once you've had ntp installed for several minutes (and possibly rebooted,
if your clock was particularly bad), you can query it with "ntpq -p" to
see how it's doing.

Unfortunately, the output format of ntpq -p isn't DOCUMENTED anywhere, so
it's a bit cryptic.  The most important thing to know, which is not stated
anywhere except word of mouth like this email, is that the "offset" column
is reporting milliseconds, not seconds.

[toc] | [prev] | [next] | [standalone]

#198490

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2018-08-09 at 10:35 -0400, Greg Wooledge wrote:
> Whoever suggested that is using outdated information.  Install ntp


Why not openntpd?

https://packages.debian.org/stretch/openntpd


-Jim P.

[toc] | [prev] | [next] | [standalone]

#198492

On Thu, Aug 09, 2018 at 10:49:52AM -0400, Jim Popovitch wrote:
> On Thu, 2018-08-09 at 10:35 -0400, Greg Wooledge wrote:
> > Whoever suggested that is using outdated information.  Install ntp
> 
> 
> Why not openntpd?
> 
> https://packages.debian.org/stretch/openntpd

Sure, whatever you prefer.  There are at least 4 viable alternatives:

ntp
chrony
openntpd
systemd-timesyncd

Pick your favorite.  ntpdate and rdate are NOT included in this list.

[toc] | [prev] | [next] | [standalone]

#198493

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2018-08-09 at 11:00 -0400, Greg Wooledge wrote:
> On Thu, Aug 09, 2018 at 10:49:52AM -0400, Jim Popovitch wrote:
> > On Thu, 2018-08-09 at 10:35 -0400, Greg Wooledge wrote:
> > > Whoever suggested that is using outdated information.  Install
> > > ntp
> > 
> > 
> > Why not openntpd?
> > 
> > https://packages.debian.org/stretch/openntpd
> 
> Sure, whatever you prefer.  There are at least 4 viable alternatives:
> 
> ntp
> chrony
> openntpd
> systemd-timesyncd
> 
> Pick your favorite.  ntpdate and rdate are NOT included in this list.
> 

Well, It's not for me.  I was just asking why you suggested ntp over
openntpd?  One has more advantages over the other.

-Jim P.

[toc] | [prev] | [next] | [standalone]

#198522

On 8/9/2018 5:00 PM, Greg Wooledge wrote:
> On Thu, Aug 09, 2018 at 10:49:52AM -0400, Jim Popovitch wrote:
>> On Thu, 2018-08-09 at 10:35 -0400, Greg Wooledge wrote:
>>> Whoever suggested that is using outdated information.  Install ntp
>>
>>
>> Why not openntpd?
>>
>> https://packages.debian.org/stretch/openntpd
> 
> Sure, whatever you prefer.  There are at least 4 viable alternatives:
> 
> ntp
> chrony
> openntpd
> systemd-timesyncd
> 

Systemd-timesyncd is only a client and using sntp.

https://www.freedesktop.org/software/systemd/man/systemd-timesyncd.service.html

-- 
John Doe

[toc] | [prev] | [next] | [standalone]

#198526

On Thu 09 Aug 2018 at 20:39:16 +0200, john doe wrote:

> On 8/9/2018 5:00 PM, Greg Wooledge wrote:
> > On Thu, Aug 09, 2018 at 10:49:52AM -0400, Jim Popovitch wrote:
> > > On Thu, 2018-08-09 at 10:35 -0400, Greg Wooledge wrote:
> > > > Whoever suggested that is using outdated information.  Install ntp
> > > 
> > > 
> > > Why not openntpd?
> > > 
> > > https://packages.debian.org/stretch/openntpd
> > 
> > Sure, whatever you prefer.  There are at least 4 viable alternatives:
> > 
> > ntp
> > chrony
> > openntpd
> > systemd-timesyncd
> > 
> 
> Systemd-timesyncd is only a client and using sntp.
> 
> https://www.freedesktop.org/software/systemd/man/systemd-timesyncd.service.html

Ideal for what the OP wants. Either that or chrony, if he would only
make his mind up.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#198529

On 08/09/2018 12:42 PM, Brian wrote:
> On Thu 09 Aug 2018 at 20:39:16 +0200, john doe wrote:
>
>> On 8/9/2018 5:00 PM, Greg Wooledge wrote:
>>> On Thu, Aug 09, 2018 at 10:49:52AM -0400, Jim Popovitch wrote:
>>>> On Thu, 2018-08-09 at 10:35 -0400, Greg Wooledge wrote:
>>>>> Whoever suggested that is using outdated information.  Install ntp
>>>>
>>>> Why not openntpd?
>>>>
>>>> https://packages.debian.org/stretch/openntpd
>>> Sure, whatever you prefer.  There are at least 4 viable alternatives:
>>>
>>> ntp
>>> chrony
>>> openntpd
>>> systemd-timesyncd
>>>
>> Systemd-timesyncd is only a client and using sntp.
>>
>> https://www.freedesktop.org/software/systemd/man/systemd-timesyncd.service.html
> Ideal for what the OP wants. Either that or chrony, if he would only
> make his mind up.
>
Well, what makes you think I haven't made my mind up?

Several years ago I built a "network clock" that receives WWVB time 
signals, has a clock display and an Ethernet interface so computers on 
the local network can ask for the time.  The hardware works and the 
software is able to decode the WWVB time code.  I am interested in 
finishing it now.  The computers on the network can use a Perl program 
to get the time.

Thanks for the help.
Best regards,
Fred

[toc] | [prev] | [next] | [standalone]

#198530

[Multipart message — attachments visible in raw view] — view raw

The only clock in my house that stays perfectly on time without NTP is my
akai s5000 sampler. It runs on a 386 ;)

On Thu, Aug 9, 2018 at 5:39 PM Fred <fred@blakemfg.com> wrote:

> On 08/09/2018 12:42 PM, Brian wrote:
> > On Thu 09 Aug 2018 at 20:39:16 +0200, john doe wrote:
> >
> >> On 8/9/2018 5:00 PM, Greg Wooledge wrote:
> >>> On Thu, Aug 09, 2018 at 10:49:52AM -0400, Jim Popovitch wrote:
> >>>> On Thu, 2018-08-09 at 10:35 -0400, Greg Wooledge wrote:
> >>>>> Whoever suggested that is using outdated information.  Install ntp
> >>>>
> >>>> Why not openntpd?
> >>>>
> >>>> https://packages.debian.org/stretch/openntpd
> >>> Sure, whatever you prefer.  There are at least 4 viable alternatives:
> >>>
> >>> ntp
> >>> chrony
> >>> openntpd
> >>> systemd-timesyncd
> >>>
> >> Systemd-timesyncd is only a client and using sntp.
> >>
> >>
> https://www.freedesktop.org/software/systemd/man/systemd-timesyncd.service.html
> > Ideal for what the OP wants. Either that or chrony, if he would only
> > make his mind up.
> >
> Well, what makes you think I haven't made my mind up?
>
> Several years ago I built a "network clock" that receives WWVB time
> signals, has a clock display and an Ethernet interface so computers on
> the local network can ask for the time.  The hardware works and the
> software is able to decode the WWVB time code.  I am interested in
> finishing it now.  The computers on the network can use a Perl program
> to get the time.
>
> Thanks for the help.
> Best regards,
> Fred
>
>

[toc] | [prev] | [next] | [standalone]

#198578

On Thu 09 Aug 2018 at 14:26:30 (-0700), Fred wrote:
> On 08/09/2018 12:42 PM, Brian wrote:
> >On Thu 09 Aug 2018 at 20:39:16 +0200, john doe wrote:
> >
> >>On 8/9/2018 5:00 PM, Greg Wooledge wrote:
> >>>On Thu, Aug 09, 2018 at 10:49:52AM -0400, Jim Popovitch wrote:
> >>>>On Thu, 2018-08-09 at 10:35 -0400, Greg Wooledge wrote:
> >>>>>Whoever suggested that is using outdated information.  Install ntp
> >>>>
> >>>>Why not openntpd?
> >>>>
> >>>>https://packages.debian.org/stretch/openntpd
> >>>Sure, whatever you prefer.  There are at least 4 viable alternatives:
> >>>
> >>>ntp
> >>>chrony
> >>>openntpd
> >>>systemd-timesyncd
> >>>
> >>Systemd-timesyncd is only a client and using sntp.
> >>
> >>https://www.freedesktop.org/software/systemd/man/systemd-timesyncd.service.html
> >Ideal for what the OP wants. Either that or chrony, if he would only
> >make his mind up.
> >
> Well, what makes you think I haven't made my mind up?

(I wasn't the one seeming impatient, but) I was going to enquire at
some time about how you got along with chrony (which you wrote you'd
try next).

The discussion you referred to might have been the one in June last
year when I wrote that chrony did not do a lot for me. I installed
it naively, ie I didn't poke it with chronyc, and the system remained
five seconds slow. OTOH ntp corrected it immediately and stays
precisely correct all the time. (jessie at the time.)
https://lists.debian.org/debian-user/2017/06/msg00450.html
In a follow-up, Brian had more success with chrony.

> Several years ago I built a "network clock" that receives WWVB time
> signals, has a clock display and an Ethernet interface so computers
> on the local network can ask for the time.  The hardware works and
> the software is able to decode the WWVB time code.  I am interested
> in finishing it now.  The computers on the network can use a Perl
> program to get the time.

Interesting. I played around with a Wireless World design in the
early 70's (TTL) where the "Rugby" time code (the slow one) was
decoded in hardware.

Currently we have a consumer radio clock which is a source of mystery
to me twice a year: the DST change occurs in the early evening on
Saturday instead of Sunday morning. In fact, it's about the time
that a UK clock would be changing if they moved on the same weekend
(which they typically don't). What does your home-built clock
reveal about the WWVB codes (assuming our clock is receiving the
same signal in KS)?

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#198579

On Fri, Aug 10, 2018 at 10:18:19AM -0500, David Wright wrote:
>Currently we have a consumer radio clock which is a source of mystery
>to me twice a year: the DST change occurs in the early evening on
>Saturday instead of Sunday morning.

The clock isn't properly decoding the DST bits. See 
https://en.wikipedia.org/wiki/WWVB

> The DST status bits indicate United States daylight saving time rules. 
> The bits are updated daily during the minute starting at 00:00 UTC. 
> The first DST bit, transmitted at 57 seconds past the minute, changes 
> at the beginning of the UTC day that DST comes into effect or ends. 
> The other DST bit, at second 58, changes 24 hours later (after the DST 
> change). Therefore, if the DST bits differ, DST is changing at 02:00 
> local time during the current UTC day. Before the next 02:00 local 
> time after that, the bits will be the same.

> Each change in the DST bits will first be received in the mainland 
> United States between 16:00 (PST) and 20:00 (EDT), depending on the 
> local time zone and on whether DST is about to begin or end. A receiver 
> in the Eastern time zone (UTC−5) must therefore correctly receive the 
> "DST is changing" indication within a seven-hour period before DST 
> begins, and six hours before DST ends, if it is to change the local time 
> display at the correct time. Receivers in the Central, Mountain, and 
> Pacific time zones have one, two, and three more hours of advance 
> notice, respectively. 

Your clock is probably only looking at the first bit, and skipping the 
logic for when to actually apply the change. A lot of the functionality 
in the time code actually allows for relatively graceful degradation 
like this to facilitate simpler or more complex receivers.

Mike Stone

[toc] | [prev] | [next] | [standalone]

#198592

On Fri 10 Aug 2018 at 11:32:35 (-0400), Michael Stone wrote:
> On Fri, Aug 10, 2018 at 10:18:19AM -0500, David Wright wrote:
> >Currently we have a consumer radio clock which is a source of mystery
> >to me twice a year: the DST change occurs in the early evening on
> >Saturday instead of Sunday morning.
> 
> The clock isn't properly decoding the DST bits. See
> https://en.wikipedia.org/wiki/WWVB
[…]
> Your clock is probably only looking at the first bit, and skipping
> the logic for when to actually apply the change. A lot of the
> functionality in the time code actually allows for relatively
> graceful degradation like this to facilitate simpler or more complex
> receivers.

Ah, that makes sense. So the different time of the change (which meant
I didn't remember precisely what time it happened) is because of the
varying offset (5, 6 hours) in spring and autumn, and a delay after
that hour o'clock would likely indicate varying signal strength and
lapses in reliable code detection. Now I know what's happening, I can
watch for the latter. Being a dial clock, there's no signal strength
indicator. Our LCD clock does display it approximately, but that only
understands MSF, not WWVB, so it's now free-running (remarkably well
especially since the Low Battery warning has been flashing since
before Christmas).

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#198581

On 08/10/2018 08:18 AM, David Wright wrote:
> On Thu 09 Aug 2018 at 14:26:30 (-0700), Fred wrote:
>> On 08/09/2018 12:42 PM, Brian wrote:
>>> On Thu 09 Aug 2018 at 20:39:16 +0200, john doe wrote:
>>>
>>>> On 8/9/2018 5:00 PM, Greg Wooledge wrote:
>>>>> On Thu, Aug 09, 2018 at 10:49:52AM -0400, Jim Popovitch wrote:
>>>>>> On Thu, 2018-08-09 at 10:35 -0400, Greg Wooledge wrote:
>>>>>>> Whoever suggested that is using outdated information.  Install ntp
>>>>>> Why not openntpd?
>>>>>>
>>>>>> https://packages.debian.org/stretch/openntpd
>>>>> Sure, whatever you prefer.  There are at least 4 viable alternatives:
>>>>>
>>>>> ntp
>>>>> chrony
>>>>> openntpd
>>>>> systemd-timesyncd
>>>>>
>>>> Systemd-timesyncd is only a client and using sntp.
>>>>
>>>> https://www.freedesktop.org/software/systemd/man/systemd-timesyncd.service.html
>>> Ideal for what the OP wants. Either that or chrony, if he would only
>>> make his mind up.
>>>
>> Well, what makes you think I haven't made my mind up?
> (I wasn't the one seeming impatient, but) I was going to enquire at
> some time about how you got along with chrony (which you wrote you'd
> try next).
>
> The discussion you referred to might have been the one in June last
> year when I wrote that chrony did not do a lot for me. I installed
> it naively, ie I didn't poke it with chronyc, and the system remained
> five seconds slow. OTOH ntp corrected it immediately and stays
> precisely correct all the time. (jessie at the time.)
> https://lists.debian.org/debian-user/2017/06/msg00450.html
> In a follow-up, Brian had more success with chrony.
>
>> Several years ago I built a "network clock" that receives WWVB time
>> signals, has a clock display and an Ethernet interface so computers
>> on the local network can ask for the time.  The hardware works and
>> the software is able to decode the WWVB time code.  I am interested
>> in finishing it now.  The computers on the network can use a Perl
>> program to get the time.
> Interesting. I played around with a Wireless World design in the
> early 70's (TTL) where the "Rugby" time code (the slow one) was
> decoded in hardware.
>
> Currently we have a consumer radio clock which is a source of mystery
> to me twice a year: the DST change occurs in the early evening on
> Saturday instead of Sunday morning. In fact, it's about the time
> that a UK clock would be changing if they moved on the same weekend
> (which they typically don't). What does your home-built clock
> reveal about the WWVB codes (assuming our clock is receiving the
> same signal in KS)?
>
> Cheers,
> David.
>
>
Hi David,
I haven't tried chrony as I have renewed interest in completing the 
"network clock" project I started some time ago.  There are far more 
interesting "home projects" than you can shake a stick at.  I ran 
ntpdate once as root and it did correct the time.

WWVB supposedly covers the continental US. but I am sure there are areas 
that don't get useful signal strength.  The software for my clock is to 
the point of changing the signal time intervals into bits so the next 
step is doing something with the bits.
Best regards,
Fred

[toc] | [prev] | [next] | [standalone]

#198586

On Fri 10 Aug 2018 at 09:20:42 -0700, Fred wrote:

> On 08/10/2018 08:18 AM, David Wright wrote:
> > On Thu 09 Aug 2018 at 14:26:30 (-0700), Fred wrote:
> > > On 08/09/2018 12:42 PM, Brian wrote:
> > > > On Thu 09 Aug 2018 at 20:39:16 +0200, john doe wrote:
> > > > 
> > > > > On 8/9/2018 5:00 PM, Greg Wooledge wrote:
> > > > > > On Thu, Aug 09, 2018 at 10:49:52AM -0400, Jim Popovitch wrote:
> > > > > > > On Thu, 2018-08-09 at 10:35 -0400, Greg Wooledge wrote:
> > > > > > > > Whoever suggested that is using outdated information.  Install ntp
> > > > > > > Why not openntpd?
> > > > > > > 
> > > > > > > https://packages.debian.org/stretch/openntpd
> > > > > > Sure, whatever you prefer.  There are at least 4 viable alternatives:
> > > > > > 
> > > > > > ntp
> > > > > > chrony
> > > > > > openntpd
> > > > > > systemd-timesyncd
> > > > > > 
> > > > > Systemd-timesyncd is only a client and using sntp.
> > > > > 
> > > > > https://www.freedesktop.org/software/systemd/man/systemd-timesyncd.service.html
> > > > Ideal for what the OP wants. Either that or chrony, if he would only
> > > > make his mind up.
> > > > 
> > > Well, what makes you think I haven't made my mind up?
> > (I wasn't the one seeming impatient, but) I was going to enquire at
> > some time about how you got along with chrony (which you wrote you'd
> > try next).
> > 
> > The discussion you referred to might have been the one in June last
> > year when I wrote that chrony did not do a lot for me. I installed
> > it naively, ie I didn't poke it with chronyc, and the system remained
> > five seconds slow. OTOH ntp corrected it immediately and stays
> > precisely correct all the time. (jessie at the time.)
> > https://lists.debian.org/debian-user/2017/06/msg00450.html
> > In a follow-up, Brian had more success with chrony.
> > 
> > > Several years ago I built a "network clock" that receives WWVB time
> > > signals, has a clock display and an Ethernet interface so computers
> > > on the local network can ask for the time.  The hardware works and
> > > the software is able to decode the WWVB time code.  I am interested
> > > in finishing it now.  The computers on the network can use a Perl
> > > program to get the time.
> > Interesting. I played around with a Wireless World design in the
> > early 70's (TTL) where the "Rugby" time code (the slow one) was
> > decoded in hardware.
> > 
> > Currently we have a consumer radio clock which is a source of mystery
> > to me twice a year: the DST change occurs in the early evening on
> > Saturday instead of Sunday morning. In fact, it's about the time
> > that a UK clock would be changing if they moved on the same weekend
> > (which they typically don't). What does your home-built clock
> > reveal about the WWVB codes (assuming our clock is receiving the
> > same signal in KS)?
> > 
> > Cheers,
> > David.
> > 
> > 
> Hi David,
> I haven't tried chrony as I have renewed interest in completing the "network

Five minutes work. As opposed to ....

> clock" project I started some time ago.  There are far more interesting
> "home projects" than you can shake a stick at.  I ran ntpdate once as root
> and it did correct the time.

The vast majority of users would be content with systemd-timesyncd or
chrony. Both simple, easy and reliable enough to forget about any
time-keeping problems. But each to his own.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#198587

[Multipart message — attachments visible in raw view] — view raw

Dear guys,

I think lot of answers flied through on the original questions and I didn't
see proper answers to them, so I would like to add my contribution to this
topic:
I collected a lot of information some week ago because of industrial
servers where the time sync was an unresolved problem.
As the questions raised by Fred has overlaps with my research results, I
give some answer with links. Hopefully lot of people can use it in the
future.

"The time server is quite close to the computer clock.  What causes the
discrepancy?  The offset in the time server response is about 10 min.  The
offset is measured from what to what and how is it measured?"

Once you synced the time and experience later huge offset, it means that
one side of your synchronization doesn't keep the time properly or the
synchronization doesn't work itself (you can make sure by running ntpq -p
and verify the output. note: ntpd has to run!). Assume, that you choosed
the proper time source for sync, so it means that the mechanism which steps
your clock locally is broken. It can be battery reasons on the mainboard,
temperature can also influence (but not too much nowadays), if you use
virtual machine, that matters a lot, as it gets the CPU cycles from the
host machine, and it's inner time stepping highly depends on the CPU time
given by the host, finally I have never read anything about the effect of
overclocking the CPU, it might have also effect on this, but test should be
run to be sure.

And a quotation about the offset calculation:
"Synchronizing a client to a network server consists of several packet
exchanges where each exchange is a pair of request and reply. When sending
out a request, the client stores its own time (originate timestamp) into
the packet being sent. When a server receives such a packet, it will in
turn store its own time (receive timestamp) into the packet, and the packet
will be returned after putting a transmit timestamp into the packet. When
receiving the reply, the receiver will once more log its own receipt time
to estimate the travelling time of the packet. The travelling time (delay)
is estimated to be half of "the total delay minus remote processing time",
assuming symmetrical delays.

Those time differences can be used to estimate the time offset between both
machines, as well as the dispersion (maximum offset error). The shorter and
more symmetric the round-trip time, the more accurate the estimate of the
current time.

Time is not believed until several packet exchanges have taken place, each
passing a set of sanity checks. Only if the replies from a server satisfy
the conditions defined in the protocol specification, the server is
considered valid. Time cannot be synchronized from a server that is
considered invalid by the protocol. Some essential values are put into
multi-stage filters for statistical purposes to improve and estimate the
quality of the samples from each server. All used servers are evaluated for
a consistent time. In case of disagreements, the largest set of agreeing
servers (truechimers) is used to produce a combined reference time, thereby
declaring other servers as invalid (falsetickers).

Usually it takes about five minutes (five good samples) until a NTP server
is accepted as synchronization source. Interestingly, this is also true for
local reference clocks that have no delay at all by definition."

Source: http://www.ntp.org/ntpfaq/NTP-s-algo.htm

And about ntpdate.
Ntpdate, believe me, is a phantastic tool which helps you the fastest way
in the most critical situations where there is no time to wait until
everything gets better.
We know, that some encryption algorithm depends very much on accurate time,
so for example in a huge infrastructure where Apache webservers using TLS
encryption, and the server also have Kerberos authentication enabled, and
very important things the server is doing, there the communication can not
be broken just because NTP was not able to step the clock enough fast.

Ntpd has higher threshold to step the clock.
"After some time, small offsets (significantly less than a second) will be
slewed (adjusted slowly), while larger offsets will cause the clock to be
stepped (set anew)."
Source: http://www.ntp.org/ntpfaq/NTP-s-algo.htm

In contrast, ntpdate:
"The default is to step the time using settimeofday() if the offset is
greater than +-128 ms. "
Source: http://doc.ntp.org/4.1.1/ntpdate.htm

So in a situtation like that I never wait to ntpd to sync the time slowly.
I use ntpdate, but it can be used only if ntpd or other sync programs
doesn't use UDP123 port. So I stop ntpd and make an ntpdate <IP to
ntpserver> and the clock is stepped right after the syncronization.

About chrony:
chrony has more builtin mechanism to keep the time more accurately on the
server even if it is disconnected from the network.
I think the future is for chrony.
Details (and sorry for the redhat link, but just because it is RedHat, it
is very correct information):
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/system_administrators_guide/#ch-Configuring_NTP_Using_the_chrony_Suite


So guys, I hope it was useful.

Best regards,
Tamas Fekete

2018-08-10 18:20 GMT+02:00 Fred <fred@blakemfg.com>:

> On 08/10/2018 08:18 AM, David Wright wrote:
>
>> On Thu 09 Aug 2018 at 14:26:30 (-0700), Fred wrote:
>>
>>> On 08/09/2018 12:42 PM, Brian wrote:
>>>
>>>> On Thu 09 Aug 2018 at 20:39:16 +0200, john doe wrote:
>>>>
>>>> On 8/9/2018 5:00 PM, Greg Wooledge wrote:
>>>>>
>>>>>> On Thu, Aug 09, 2018 at 10:49:52AM -0400, Jim Popovitch wrote:
>>>>>>
>>>>>>> On Thu, 2018-08-09 at 10:35 -0400, Greg Wooledge wrote:
>>>>>>>
>>>>>>>> Whoever suggested that is using outdated information.  Install ntp
>>>>>>>>
>>>>>>> Why not openntpd?
>>>>>>>
>>>>>>> https://packages.debian.org/stretch/openntpd
>>>>>>>
>>>>>> Sure, whatever you prefer.  There are at least 4 viable alternatives:
>>>>>>
>>>>>> ntp
>>>>>> chrony
>>>>>> openntpd
>>>>>> systemd-timesyncd
>>>>>>
>>>>>> Systemd-timesyncd is only a client and using sntp.
>>>>>
>>>>> https://www.freedesktop.org/software/systemd/man/systemd-tim
>>>>> esyncd.service.html
>>>>>
>>>> Ideal for what the OP wants. Either that or chrony, if he would only
>>>> make his mind up.
>>>>
>>>> Well, what makes you think I haven't made my mind up?
>>>
>> (I wasn't the one seeming impatient, but) I was going to enquire at
>> some time about how you got along with chrony (which you wrote you'd
>> try next).
>>
>> The discussion you referred to might have been the one in June last
>> year when I wrote that chrony did not do a lot for me. I installed
>> it naively, ie I didn't poke it with chronyc, and the system remained
>> five seconds slow. OTOH ntp corrected it immediately and stays
>> precisely correct all the time. (jessie at the time.)
>> https://lists.debian.org/debian-user/2017/06/msg00450.html
>> In a follow-up, Brian had more success with chrony.
>>
>> Several years ago I built a "network clock" that receives WWVB time
>>> signals, has a clock display and an Ethernet interface so computers
>>> on the local network can ask for the time.  The hardware works and
>>> the software is able to decode the WWVB time code.  I am interested
>>> in finishing it now.  The computers on the network can use a Perl
>>> program to get the time.
>>>
>> Interesting. I played around with a Wireless World design in the
>> early 70's (TTL) where the "Rugby" time code (the slow one) was
>> decoded in hardware.
>>
>> Currently we have a consumer radio clock which is a source of mystery
>> to me twice a year: the DST change occurs in the early evening on
>> Saturday instead of Sunday morning. In fact, it's about the time
>> that a UK clock would be changing if they moved on the same weekend
>> (which they typically don't). What does your home-built clock
>> reveal about the WWVB codes (assuming our clock is receiving the
>> same signal in KS)?
>>
>> Cheers,
>> David.
>>
>>
>> Hi David,
> I haven't tried chrony as I have renewed interest in completing the
> "network clock" project I started some time ago.  There are far more
> interesting "home projects" than you can shake a stick at.  I ran ntpdate
> once as root and it did correct the time.
>
> WWVB supposedly covers the continental US. but I am sure there are areas
> that don't get useful signal strength.  The software for my clock is to the
> point of changing the signal time intervals into bits so the next step is
> doing something with the bits.
> Best regards,
> Fred
>
>
>
>

[toc] | [prev] | [next] | [standalone]

#198588

On Fri, Aug 10, 2018 at 07:46:46PM +0200, Fekete Tamás wrote:
> So in a situtation like that I never wait to ntpd to sync the time slowly.
> I use ntpdate, but it can be used only if ntpd or other sync programs
> doesn't use UDP123 port. So I stop ntpd and make an ntpdate <IP to
> ntpserver> and the clock is stepped right after the syncronization.

ntpdate can set the clock BACKWARD as well as forward.  Setting the clock
backward can break all kinds of shit.  Jumping the clock forward by a
large amount can also break things, but it's not as bad as going backward.

If you find that your mission-critical server has lost its clock sync
for some reason, you're better off rebooting it.  Assuming, of course,
you have already fixed whatever caused ntpd to stop working in the first
place.

Because obviously you were running ntpd on it.  Right?  Right.

Rebooting lets ntpd's -g option peform an ntpdate-like clock jump once
again, and this will ideally happen BEFORE anything else that depends
on the clock is started.  So, if all is arranged correctly, by the
time your time-sensitive services come back up, the clock will already
be approximately correct, and it will be monotonically increasing as
it finishes converging toward precision.

[toc] | [prev] | [next] | [standalone]

#198589

On Friday 10 August 2018 13:46:46 Fekete Tamás wrote:

> Dear guys,
>
> I think lot of answers flied through on the original questions and I
> didn't see proper answers to them, so I would like to add my
> contribution to this topic:
> I collected a lot of information some week ago because of industrial
> servers where the time sync was an unresolved problem.
> As the questions raised by Fred has overlaps with my research results,
> I give some answer with links. Hopefully lot of people can use it in
> the future.
>
> "The time server is quite close to the computer clock.  What causes
> the discrepancy?  The offset in the time server response is about 10
> min.  The offset is measured from what to what and how is it
> measured?"
>
> Once you synced the time and experience later huge offset, it means
> that one side of your synchronization doesn't keep the time properly
> or the synchronization doesn't work itself (you can make sure by
> running ntpq -p and verify the output. note: ntpd has to run!).
> Assume, that you choosed the proper time source for sync, so it means
> that the mechanism which steps your clock locally is broken. It can be
> battery reasons on the mainboard, temperature can also influence (but
> not too much nowadays), if you use virtual machine, that matters a
> lot, as it gets the CPU cycles from the host machine, and it's inner
> time stepping highly depends on the CPU time given by the host,
> finally I have never read anything about the effect of overclocking
> the CPU, it might have also effect on this, but test should be run to
> be sure.
>
> And a quotation about the offset calculation:
> "Synchronizing a client to a network server consists of several packet
> exchanges where each exchange is a pair of request and reply. When
> sending out a request, the client stores its own time (originate
> timestamp) into the packet being sent. When a server receives such a
> packet, it will in turn store its own time (receive timestamp) into
> the packet, and the packet will be returned after putting a transmit
> timestamp into the packet. When receiving the reply, the receiver will
> once more log its own receipt time to estimate the travelling time of
> the packet. The travelling time (delay) is estimated to be half of
> "the total delay minus remote processing time", assuming symmetrical
> delays.
>
> Those time differences can be used to estimate the time offset between
> both machines, as well as the dispersion (maximum offset error). The
> shorter and more symmetric the round-trip time, the more accurate the
> estimate of the current time.
>
> Time is not believed until several packet exchanges have taken place,
> each passing a set of sanity checks. Only if the replies from a server
> satisfy the conditions defined in the protocol specification, the
> server is considered valid. Time cannot be synchronized from a server
> that is considered invalid by the protocol. Some essential values are
> put into multi-stage filters for statistical purposes to improve and
> estimate the quality of the samples from each server. All used servers
> are evaluated for a consistent time. In case of disagreements, the
> largest set of agreeing servers (truechimers) is used to produce a
> combined reference time, thereby declaring other servers as invalid
> (falsetickers).
>
> Usually it takes about five minutes (five good samples) until a NTP
> server is accepted as synchronization source. Interestingly, this is
> also true for local reference clocks that have no delay at all by
> definition."
>
> Source: http://www.ntp.org/ntpfaq/NTP-s-algo.htm
>
> And about ntpdate.
> Ntpdate, believe me, is a phantastic tool which helps you the fastest
> way in the most critical situations where there is no time to wait
> until everything gets better.
> We know, that some encryption algorithm depends very much on accurate
> time, so for example in a huge infrastructure where Apache webservers
> using TLS encryption, and the server also have Kerberos authentication
> enabled, and very important things the server is doing, there the
> communication can not be broken just because NTP was not able to step
> the clock enough fast.
>
> Ntpd has higher threshold to step the clock.
> "After some time, small offsets (significantly less than a second)
> will be slewed (adjusted slowly), while larger offsets will cause the
> clock to be stepped (set anew)."
> Source: http://www.ntp.org/ntpfaq/NTP-s-algo.htm
>
> In contrast, ntpdate:
> "The default is to step the time using settimeofday() if the offset is
> greater than +-128 ms. "
> Source: http://doc.ntp.org/4.1.1/ntpdate.htm
>
> So in a situtation like that I never wait to ntpd to sync the time
> slowly. I use ntpdate, but it can be used only if ntpd or other sync
> programs doesn't use UDP123 port. So I stop ntpd and make an ntpdate
> <IP to ntpserver> and the clock is stepped right after the
> syncronization.
>
> About chrony:
> chrony has more builtin mechanism to keep the time more accurately on
> the server even if it is disconnected from the network.
> I think the future is for chrony.
> Details (and sorry for the redhat link, but just because it is RedHat,
> it is very correct information):
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux
>/7/html-single/system_administrators_guide/#ch-Configuring_NTP_Using_th
>e_chrony_Suite
>
As a long term user (19 years) of ntpdate in the early years, before ntp 
grew that function, and ntp after boot all the time, I think a similar 
disection to the above, but for chrony would be a valuable asset to be 
able to reference in detail the man pages skip or gloss over.  Hint, 
hint. It might also disclose its Achilles heel, security leaks etc, 
which will usually lead to improvements in its code. 

> So guys, I hope it was useful.
>
> Best regards,
> Tamas Fekete
>
Tamas Fekete: This discussion has been most worthwhile as I have now 
completed the concept of haveing only my router access the networks 
level 2 servers, then this machine syncing to the router, and the rest 
of my machines now listen to the rebroadcasts this machine makes on 
domain.name.255. So I have good synch system wide, with only one, the 
router, actually querying the nets level 2 servers. If all of us with 
multi-machine home (or business for that matter) networks, we could cut 
the load on the level 2 servers by 50% or more. We should all remember 
the one immutable law about ALL of this stuff, TANSTAAFL.

> 2018-08-10 18:20 GMT+02:00 Fred <fred@blakemfg.com>:
> > On 08/10/2018 08:18 AM, David Wright wrote:
> >> On Thu 09 Aug 2018 at 14:26:30 (-0700), Fred wrote:
> >>> On 08/09/2018 12:42 PM, Brian wrote:
> >>>> On Thu 09 Aug 2018 at 20:39:16 +0200, john doe wrote:
> >>>>
> >>>> On 8/9/2018 5:00 PM, Greg Wooledge wrote:
> >>>>>> On Thu, Aug 09, 2018 at 10:49:52AM -0400, Jim Popovitch wrote:
> >>>>>>> On Thu, 2018-08-09 at 10:35 -0400, Greg Wooledge wrote:
> >>>>>>>> Whoever suggested that is using outdated information. 
> >>>>>>>> Install ntp
> >>>>>>>
> >>>>>>> Why not openntpd?
> >>>>>>>
> >>>>>>> https://packages.debian.org/stretch/openntpd
> >>>>>>
> >>>>>> Sure, whatever you prefer.  There are at least 4 viable
> >>>>>> alternatives:
> >>>>>>
> >>>>>> ntp
> >>>>>> chrony
> >>>>>> openntpd
> >>>>>> systemd-timesyncd
> >>>>>>
> >>>>>> Systemd-timesyncd is only a client and using sntp.
> >>>>>
> >>>>> https://www.freedesktop.org/software/systemd/man/systemd-tim
> >>>>> esyncd.service.html
> >>>>
> >>>> Ideal for what the OP wants. Either that or chrony, if he would
> >>>> only make his mind up.
> >>>>
> >>>> Well, what makes you think I haven't made my mind up?
> >>
> >> (I wasn't the one seeming impatient, but) I was going to enquire at
> >> some time about how you got along with chrony (which you wrote
> >> you'd try next).
> >>
> >> The discussion you referred to might have been the one in June last
> >> year when I wrote that chrony did not do a lot for me. I installed
> >> it naively, ie I didn't poke it with chronyc, and the system
> >> remained five seconds slow. OTOH ntp corrected it immediately and
> >> stays precisely correct all the time. (jessie at the time.)
> >> https://lists.debian.org/debian-user/2017/06/msg00450.html
> >> In a follow-up, Brian had more success with chrony.
> >>
> >> Several years ago I built a "network clock" that receives WWVB time
> >>
> >>> signals, has a clock display and an Ethernet interface so
> >>> computers on the local network can ask for the time.  The hardware
> >>> works and the software is able to decode the WWVB time code.  I am
> >>> interested in finishing it now.  The computers on the network can
> >>> use a Perl program to get the time.
> >>
> >> Interesting. I played around with a Wireless World design in the
> >> early 70's (TTL) where the "Rugby" time code (the slow one) was
> >> decoded in hardware.
> >>
> >> Currently we have a consumer radio clock which is a source of
> >> mystery to me twice a year: the DST change occurs in the early
> >> evening on Saturday instead of Sunday morning. In fact, it's about
> >> the time that a UK clock would be changing if they moved on the
> >> same weekend (which they typically don't). What does your
> >> home-built clock reveal about the WWVB codes (assuming our clock is
> >> receiving the same signal in KS)?
> >>
> >> Cheers,
> >> David.
> >>
> >>
> >> Hi David,
> >
> > I haven't tried chrony as I have renewed interest in completing the
> > "network clock" project I started some time ago.  There are far more
> > interesting "home projects" than you can shake a stick at.  I ran
> > ntpdate once as root and it did correct the time.
> >
> > WWVB supposedly covers the continental US. but I am sure there are
> > areas that don't get useful signal strength.  The software for my
> > clock is to the point of changing the signal time intervals into
> > bits so the next step is doing something with the bits.
> > Best regards,
> > Fred



-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#198598

On Fri, Aug 10, 2018 at 07:46:46PM +0200, Fekete Tamás wrote:
>verify the output. note: ntpd has to run!). Assume, that you choosed the proper
>time source for sync, so it means that the mechanism which steps your clock
>locally is broken. It can be battery reasons on the mainboard, temperature can
>also influence (but not too much nowadays), if you use virtual machine, that
>matters a lot, as it gets the CPU cycles from the host machine, and it's inner
>time stepping highly depends on the CPU time given by the host, finally I have
>never read anything about the effect of overclocking the CPU, it might have
>also effect on this, but test should be run to be sure.

It's also really bad to run more than one time synchronization at 
once--they'll tend to confuse each other and cause random time shifts.

>Ntpd has higher threshold to step the clock.
>"After some time, small offsets (significantly less than a second) will be
>slewed (adjusted slowly), while larger offsets will cause the clock to be
>stepped (set anew)."
>Source: http://www.ntp.org/ntpfaq/NTP-s-algo.htm

This isn't true on ntpd startup; it'll step the clock to get it close 
and slew thereafter. The only case where this a problem is if there are 
major issues with the local clock. (Which generally means you have 
bigger problems.) You may be thinking of the behavior where ntpd will 
exit on startup if the time is too far off. Using the -g option causes 
it to just set the time and carry on. (There are pros and cons to both 
approaches.)

Mike Stone

[toc] | [prev] | [next] | [standalone]

#198607

[Multipart message — attachments visible in raw view] — view raw

Dear Colleagues,

I think the extensions made by others to my comment were very valuable.
Only thing I would like to add, that Fred's (original asker) problem is
probably that time sync daemon can not do it's job in the background
properly.
Ntpd can not sync on startup or later and time async reaches 10 min, which
is huge.
So the problem here is two:

- the time stepper probably broken
- and the time sync software can not do it's job properly.

I would suggest to debug the second first, as you will need time sync even
after you solved the first problem.
Just some suggestion to this:
- check the ntpd logs. If there is no dedicated log file to it, make one by
editing the ntp.conf file
- check if the drift file can be accessed and is writeable to ntpd
- check the restriction section in ntp.conf file. Make sure the service is
available on localhost at least on IPv4
- if ntpd runs, issue ntpq -p command and check it's output (compare it's
output to any other linux machine with working time sync)

Best regards
Tamas Fekete

2018-08-10 22:53 GMT+02:00 Michael Stone <mstone@debian.org>:

> On Fri, Aug 10, 2018 at 07:46:46PM +0200, Fekete Tamás wrote:
>
>> verify the output. note: ntpd has to run!). Assume, that you choosed the
>> proper
>> time source for sync, so it means that the mechanism which steps your
>> clock
>> locally is broken. It can be battery reasons on the mainboard,
>> temperature can
>> also influence (but not too much nowadays), if you use virtual machine,
>> that
>> matters a lot, as it gets the CPU cycles from the host machine, and it's
>> inner
>> time stepping highly depends on the CPU time given by the host, finally I
>> have
>> never read anything about the effect of overclocking the CPU, it might
>> have
>> also effect on this, but test should be run to be sure.
>>
>
> It's also really bad to run more than one time synchronization at
> once--they'll tend to confuse each other and cause random time shifts.
>
> Ntpd has higher threshold to step the clock.
>> "After some time, small offsets (significantly less than a second) will be
>> slewed (adjusted slowly), while larger offsets will cause the clock to be
>> stepped (set anew)."
>> Source: http://www.ntp.org/ntpfaq/NTP-s-algo.htm
>>
>
> This isn't true on ntpd startup; it'll step the clock to get it close and
> slew thereafter. The only case where this a problem is if there are major
> issues with the local clock. (Which generally means you have bigger
> problems.) You may be thinking of the behavior where ntpd will exit on
> startup if the time is too far off. Using the -g option causes it to just
> set the time and carry on. (There are pros and cons to both approaches.)
>
> Mike Stone
>
>

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web