Rocksolid Light

Welcome to RetroBBS

mail  files  register  newsreader  groups  login

Message-ID:  

"A car is just a big purse on wheels." -- Johanna Reynolds


devel / comp.protocols.time.ntp / Re: ntpd on busybox ARM system not keeping time with server

SubjectAuthor
* ntpd on busybox ARM system not keeping time with serverAndreas Schick
+* Re: ntpd on busybox ARM system not keeping time with serverAndreas Schick
|`* Re: ntpd on busybox ARM system not keeping time with serverDavid Woolley
| `* Re: ntpd on busybox ARM system not keeping time with serverAndreas Schick
|  `- Re: ntpd on busybox ARM system not keeping time with serverMiroslav Lichvar
`* Re: ntpd on busybox ARM system not keeping time with serverDavid Woolley
 `* Re: ntpd on busybox ARM system not keeping time with serverJakob Bohm
  +* Re: ntpd on busybox ARM system not keeping time with serverTerje Mathisen
  |`* Re: ntpd on busybox ARM system not keeping time with serverJakob Bohm
  | `- Re: ntpd on busybox ARM system not keeping time with serverTerje Mathisen
  `- Re: ntpd on busybox ARM system not keeping time with serverDavid Woolley

1
ntpd on busybox ARM system not keeping time with server

<2d3969e4-d5b8-434c-9eea-ecdfca4972fan@googlegroups.com>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=8&group=comp.protocols.time.ntp#8

 copy link   Newsgroups: comp.protocols.time.ntp
X-Received: by 2002:a37:6084:: with SMTP id u126mr4195786qkb.294.1621337164875;
Tue, 18 May 2021 04:26:04 -0700 (PDT)
X-Received: by 2002:a4a:250e:: with SMTP id g14mr3971653ooa.31.1621337164382;
Tue, 18 May 2021 04:26:04 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.protocols.time.ntp
Date: Tue, 18 May 2021 04:26:04 -0700 (PDT)
Injection-Info: google-groups.googlegroups.com; posting-host=2.204.60.109; posting-account=eGJ0PQoAAABVoBSNuMmCXuGzBM3qc-XI
NNTP-Posting-Host: 2.204.60.109
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <2d3969e4-d5b8-434c-9eea-ecdfca4972fan@googlegroups.com>
Subject: ntpd on busybox ARM system not keeping time with server
From: a.schick81@web.de (Andreas Schick)
Injection-Date: Tue, 18 May 2021 11:26:04 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Andreas Schick - Tue, 18 May 2021 11:26 UTC

Greetings to the community,

I am struggling with some issue on a ARM based embedded system using linux with busybox binary and ntpd for synchrosnisation. From time to time system clock is out of sync in that local network.

1. There is a windows box (IPv4: 192.168.101.35) on the same LAN subnet which is synced to the outside world. The default gateway on that LAN (192.168..101.1) is not the router to the outside world.
2. This is intended but I may be able to configure additional routes on the embedded ARM device
3. The embedded ARM system (IPv4: 192.168.101.2) is synced to the windows box and does not have a proper LCL which is battery buffered or synced otherwise (GPS or DCF etc) so it drifts badly and starts up with bogus time upon boot.

The ARM system has the following ntp.conf.
------------ BEGIN paste ntp.conf
# /etc/ntp.conf - Configuration file for ntpd

##
## Undisciplined Local Clock. This is a fake driver intended for backup
## and when no outside source of synchronized time is available.
##
server 127.127.1.0 # local clock (LCL)
fudge 127.127.1.0 stratum 10 # LCL is unsynchronized

##
## Outside source of synchronized time.
## Uncomment when needed.
##
# IP address of server

##
## Miscellaneous stuff
##

#driftfile /etc/ntp.drift # path for drift file
#driftfile /run/ntp.drift
#logfile /var/log/ntp # alternate log file
#logfile /run/ntp.log
#logconfig =syncstatus + sysevents
logconfig =all

# statsdir /rdisk/ # directory for statistics files
# filegen peerstats file peerstats type day enable
# filegen loopstats file loopstats type day enable
# filegen clockstats file clockstats type day enable
server 192.168.101.35
server 192.168.101.2

END paste ntp.conf -----------------------------------------

What I want to achieve is just the ARM system syncing itself to the windows box, that I maybe will swap out for a meinberg lantime device serving as a proper ntp-server in the future.

What I do not understand is is this all LCL stuff needed at all? And why is the servers section listing the system itself as a server? Does this make any sense in this configuration? To be honest I received this mess and have to figure out now how to get it to work. Googling gave nothing of value and the results I found were even sometimes controversial.

What I achieved so far:
1. ntpdate -q 192.168.101.35 yields correct time and intends to step clock as the offset of the embedded ARM box is approx. 1 minute now compared to the windows box having startum 4 - following is the output:

---- BEGIN
# ntpdate -q 192.168.101.35
server 192.168.101.35, stratum 4, offset 64.145311, delay 0.02582
18 May 13:20:07 ntpdate[9548]: step time server 192.168.101.35 offset 64.145311 sec
---- END

2. ntpd process seems running OK on startup, with ps showing:
ntpd -g -c /tmp/ntp.conf -f /tmp/ntp.2021-05-07T13:11:54+0200.drift -l /tmp/ntp.2021-05-07T13:11:54+0200.log

3. Logfile seems strange as the only output I see is dated to May 7th this year and I checked it today.

Please point me in the right direction, as I am out of ideas now.

Re: ntpd on busybox ARM system not keeping time with server

<4ec39431-7f1e-4336-9987-833a8a7d3089n@googlegroups.com>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=9&group=comp.protocols.time.ntp#9

 copy link   Newsgroups: comp.protocols.time.ntp
X-Received: by 2002:a05:620a:126d:: with SMTP id b13mr5053533qkl.436.1621337947638;
Tue, 18 May 2021 04:39:07 -0700 (PDT)
X-Received: by 2002:a4a:2cc5:: with SMTP id o188mr2281693ooo.15.1621337947274;
Tue, 18 May 2021 04:39:07 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.protocols.time.ntp
Date: Tue, 18 May 2021 04:39:06 -0700 (PDT)
In-Reply-To: <2d3969e4-d5b8-434c-9eea-ecdfca4972fan@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2.204.60.109; posting-account=eGJ0PQoAAABVoBSNuMmCXuGzBM3qc-XI
NNTP-Posting-Host: 2.204.60.109
References: <2d3969e4-d5b8-434c-9eea-ecdfca4972fan@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <4ec39431-7f1e-4336-9987-833a8a7d3089n@googlegroups.com>
Subject: Re: ntpd on busybox ARM system not keeping time with server
From: a.schick81@web.de (Andreas Schick)
Injection-Date: Tue, 18 May 2021 11:39:07 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Andreas Schick - Tue, 18 May 2021 11:39 UTC

Addition: After I reboot the embedded ARM system time is in sync with the windows box and ntp.log shows this:

# cat /tmp/ntp.2021-05-18T13\:29\:43\+0200.log
18 May 13:29:43 ntpd[1224]: proto: precision = 0.666 usec
18 May 13:29:43 ntpd[1224]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
18 May 13:29:43 ntpd[1224]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
18 May 13:29:43 ntpd[1224]: Listen and drop on 1 v6wildcard :: UDP 123
18 May 13:29:43 ntpd[1224]: Listen normally on 2 lo 127.0.0.1 UDP 123
18 May 13:29:43 ntpd[1224]: Listen normally on 3 eth0 192.0.2.16 UDP 123
18 May 13:29:43 ntpd[1224]: Listen normally on 4 eth0:aka00 192.168.101.2 UDP 123
18 May 13:29:43 ntpd[1224]: Listen normally on 5 eth0 fe80::205:51ff:fe0a:ef05 UDP 123
18 May 13:29:43 ntpd[1224]: Listen normally on 6 lo ::1 UDP 123
18 May 13:29:43 ntpd[1224]: peers refreshed
18 May 13:29:43 ntpd[1224]: Listening on routing socket on fd #23 for interface updates
18 May 13:29:43 ntpd[1224]: 0.0.0.0 c016 06 restart
18 May 13:29:43 ntpd[1224]: 0.0.0.0 c012 02 freq_set kernel 0.000 PPM
18 May 13:29:43 ntpd[1224]: 0.0.0.0 c011 01 freq_not_set
18 May 13:29:44 ntpd[1224]: 0.0.0.0 c514 04 freq_mode

Any advice would be helpful.
Sidenote: As per my understanding I could safely remove the LCL entries and the server line where it lists own IPv4 address of the ARM box. I know that under normal circumstances I should provide at least three server addresses. But this is not the case here as I just want to sync the box to one device (currentlywindows box) non the local LAN, that itself is synced to the outside world via internet or GPS or DCF or the like.

Re: ntpd on busybox ARM system not keeping time with server

<s80a1u$flp$1@dont-email.me>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=10&group=comp.protocols.time.ntp#10

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: david@ex.djwhome.demon.invalid (David Woolley)
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntpd on busybox ARM system not keeping time with server
Date: Tue, 18 May 2021 12:56:45 +0100
Organization: No affiliation
Lines: 22
Message-ID: <s80a1u$flp$1@dont-email.me>
References: <2d3969e4-d5b8-434c-9eea-ecdfca4972fan@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 18 May 2021 11:56:46 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="7712ef1f59870cfb46eac0cdf09e4fba";
logging-data="16057"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/j5JrdR9QpKe5MdffkR8JO2HmGxYJb4xc="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.6.0
Cancel-Lock: sha1:kRhxPNL4UbRRb/9fJiehBHa71aw=
In-Reply-To: <2d3969e4-d5b8-434c-9eea-ecdfca4972fan@googlegroups.com>
Content-Language: en-GB
 by: David Woolley - Tue, 18 May 2021 11:56 UTC

On 18/05/2021 12:26, Andreas Schick wrote:
> server 127.127.1.0 # local clock (LCL)
> fudge 127.127.1.0 stratum 10 # LCL is unsynchronized

Delete these lines. As described, this system is not suitable as a time
server, and including these lines on a pure client can actually
frustrate synchronisation. This fake server is likely to vote against
the genuine server.

> server 192.168.101.2

This appears to be the machine itself, so it will be voting that's its
own time is correct. Delete it.

Windows machines can vary from fair to atrocious as time servers. A
workstation running a default configuration of w32time will be at the
atrocious end.

You should make sure that the ARM starts in the right ball park, by
either using a file timestamp to record the time at, or close to,
shutdown, or, as a last resort, setting a fixed time that isn't too far
from reality.

Re: ntpd on busybox ARM system not keeping time with server

<s80a5l$flp$2@dont-email.me>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=11&group=comp.protocols.time.ntp#11

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: david@ex.djwhome.demon.invalid (David Woolley)
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntpd on busybox ARM system not keeping time with server
Date: Tue, 18 May 2021 12:58:45 +0100
Organization: No affiliation
Lines: 5
Message-ID: <s80a5l$flp$2@dont-email.me>
References: <2d3969e4-d5b8-434c-9eea-ecdfca4972fan@googlegroups.com>
<4ec39431-7f1e-4336-9987-833a8a7d3089n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 18 May 2021 11:58:45 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="7712ef1f59870cfb46eac0cdf09e4fba";
logging-data="16057"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX192zGPx1YcE5OZAQHm/2IHdY/3fQAD0DxE="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.6.0
Cancel-Lock: sha1:/cr/ga05EBxpsh/bbE9Fv39jkKE=
In-Reply-To: <4ec39431-7f1e-4336-9987-833a8a7d3089n@googlegroups.com>
Content-Language: en-GB
 by: David Woolley - Tue, 18 May 2021 11:58 UTC

On 18/05/2021 12:39, Andreas Schick wrote:
> I could safely remove the LCL entries and the server line where it lists own IPv4 address of the ARM box

I think it is more accurate to say that you CANNOT safely keep these!
The self reference is plain wrong.

Re: ntpd on busybox ARM system not keeping time with server

<1435a556-1951-4acb-a0da-7ac89e455796n@googlegroups.com>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=12&group=comp.protocols.time.ntp#12

 copy link   Newsgroups: comp.protocols.time.ntp
X-Received: by 2002:ad4:5766:: with SMTP id r6mr5554457qvx.23.1621343508491;
Tue, 18 May 2021 06:11:48 -0700 (PDT)
X-Received: by 2002:a54:4103:: with SMTP id l3mr3873859oic.81.1621343508179;
Tue, 18 May 2021 06:11:48 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.protocols.time.ntp
Date: Tue, 18 May 2021 06:11:47 -0700 (PDT)
In-Reply-To: <s80a5l$flp$2@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2.204.60.109; posting-account=eGJ0PQoAAABVoBSNuMmCXuGzBM3qc-XI
NNTP-Posting-Host: 2.204.60.109
References: <2d3969e4-d5b8-434c-9eea-ecdfca4972fan@googlegroups.com>
<4ec39431-7f1e-4336-9987-833a8a7d3089n@googlegroups.com> <s80a5l$flp$2@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <1435a556-1951-4acb-a0da-7ac89e455796n@googlegroups.com>
Subject: Re: ntpd on busybox ARM system not keeping time with server
From: a.schick81@web.de (Andreas Schick)
Injection-Date: Tue, 18 May 2021 13:11:48 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Andreas Schick - Tue, 18 May 2021 13:11 UTC

David Woolley schrieb am Dienstag, 18. Mai 2021 um 13:58:46 UTC+2:
> On 18/05/2021 12:39, Andreas Schick wrote:
> > I could safely remove the LCL entries and the server line where it lists own IPv4 address of the ARM box
> I think it is more accurate to say that you CANNOT safely keep these!
> The self reference is plain wrong.

@David:Wooley: Thank you for confirming that. I was 'forced/asked' to set it up this way by one of my former colleagues, who is frankly speaking not really familiar with ntpd functionality. People here sadly (my employer) tend to assume stuff without exactly knowing the technical backgrounds. I think this idea initially came up because we are also using several of these ARM machines on one network and all of them are running ntpd and people used to always put all of them into server lines assuming they will get some strange sort of pooling redundancy or something. I still doubt it is the right way in that scenario and I'd rather prefer one server that is reasonably safe provided it is synced to some sort of outside world and has at least a battery buffered LCL.

Regarding w32time I know it is not the solution anyone using ntp mechanisms would prefer (me included), but at least it gives me some means of time syncronisation as the network is missing a real ntp timeserver (eiteher a dedicated device or a reliable linux server machine running 24/7). The windows workstation is actually a server machine running 24/7 and it is connected to the internet via a router and a secondary NIC. Sadly I had the mentioned router already failing or dropping the internet connection and that lead to the windows machine dropping to stratum 16 and then clients have to say goodbye to synchronisation. But this risk I currently have to take.

If I could I'd replace that windows host by some dedicated time server (e.g.. the meinberg lantime series). But at the moment unfortunately I can not do that.

Another question I have is: does adding iburst to the server entry improve startup behavior of ntpd, as far as I saw it does not make much difference in my scenario, as I only have one accessible server on my network.
And as per the documents I read so far it just makes the server send out several requests in a shorter time period. I do not think it will improve the situation I am having in regards to startup, as it already seems to work fine now without it.

One further idea I had was just modifying some startup scripts (which run before ntpd process is started and after the network is up) to include some from of a ntpd-run-sync-and-quit or ntpdate call that steps the clock at system startup on the ARM device. I have to avoid stepping the system time during normal system runtime as timers in some software can misbehave if a leap in time is detected. But at the moment startup behavior seems fine after boot and the time just is not in sync after a couple of hours days of the system running.

Thank you for helping anyway.

Re: ntpd on busybox ARM system not keeping time with server

<Yc2dnWKOF8Xs_zn9nZ2dnUU78dPNnZ2d@giganews.com>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=13&group=comp.protocols.time.ntp#13

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!2.eu.feeder.erje.net!feeder.erje.net!border1.nntp.ams1.giganews.com!nntp.giganews.com!buffer1.nntp.ams1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 18 May 2021 19:57:21 -0500
Subject: Re: ntpd on busybox ARM system not keeping time with server
Newsgroups: comp.protocols.time.ntp
References: <2d3969e4-d5b8-434c-9eea-ecdfca4972fan@googlegroups.com>
<s80a1u$flp$1@dont-email.me>
From: jb-usenet@wisemo.com.invalid (Jakob Bohm)
Organization: WiseMo A/S
Date: Wed, 19 May 2021 02:57:20 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:4.8) Goanna/20210402
Interlink/52.9.7762
MIME-Version: 1.0
In-Reply-To: <s80a1u$flp$1@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <Yc2dnWKOF8Xs_zn9nZ2dnUU78dPNnZ2d@giganews.com>
Lines: 52
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-UDZXE53dWbEFxdEhuFaIUmWgcFIKDpXoPZ+3a75S2nw6fa1PbRhgq/Yi3xoORz3Q1GVM89abWsTnync!DLCQUePRsHs0p6+xOmrN7RJ6q9WSOnkFCMyeikhSLOcJXCtFX7I4wnW4qgL7pIG/algU0ATYM/c=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 3410
 by: Jakob Bohm - Wed, 19 May 2021 00:57 UTC

On 2021-05-18 13:56, David Woolley wrote:
> On 18/05/2021 12:26, Andreas Schick wrote:
>> server 127.127.1.0              # local clock (LCL)
>> fudge  127.127.1.0 stratum 10   # LCL is unsynchronized
>
> Delete these lines.  As described, this system is not suitable as a time
> server, and including these lines on a pure client can actually
> frustrate synchronisation. This fake server is likely to vote against
> the genuine server.
>

Perhaps the "tos orphan" option is a better way to make ntpd continue
after loss of all time sources.

Maybe some option to force treating the Windows server as stratum 12,
even if it looses outside synch and reports itself as stratum 16.

>> server  192.168.101.2
>
> This appears to be the machine itself, so it will be voting that's its
> own time is correct.  Delete it.
>
> Windows machines can vary from fair to atrocious as time servers.  A
> workstation running a default configuration of w32time will be at the
> atrocious end.

Fortunately, this is reportedly a server, which means it will keep time
with a somewhat coarse granularity and include a battery backed TOY
(Time Of Year) clock to keep time even across power outages.

W32Time in server mode has a tendency to fluctuate about +/- 10ms from
the time sources. It is designed to provide an SNTP time source for
Kerberos clients that need to stay within +/- 5 minutes of the Kerberos
KDC.

>
> You should make sure that the ARM starts in the right ball park, by
> either using a file timestamp to record the time at, or close to,
> shutdown, or, as a last resort, setting a fixed time that isn't too far
> from reality.

Perhaps using the sntp program to do initial synchronization to the
server machine (as a better alternative to ntpd -g).

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Re: ntpd on busybox ARM system not keeping time with server

<s82g9p$1ad5$1@gioia.aioe.org>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=14&group=comp.protocols.time.ntp#14

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!aioe.org!/FKOcGQMirZgkZJCo9x3IA.user.gioia.aioe.org.POSTED!not-for-mail
From: terje.mathisen@tmsw.no (Terje Mathisen)
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntpd on busybox ARM system not keeping time with server
Date: Wed, 19 May 2021 09:55:37 +0200
Organization: Aioe.org NNTP Server
Lines: 54
Message-ID: <s82g9p$1ad5$1@gioia.aioe.org>
References: <2d3969e4-d5b8-434c-9eea-ecdfca4972fan@googlegroups.com>
<s80a1u$flp$1@dont-email.me> <Yc2dnWKOF8Xs_zn9nZ2dnUU78dPNnZ2d@giganews.com>
NNTP-Posting-Host: /FKOcGQMirZgkZJCo9x3IA.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101
Firefox/60.0 SeaMonkey/2.53.7
X-Notice: Filtered by postfilter v. 0.9.2
 by: Terje Mathisen - Wed, 19 May 2021 07:55 UTC

Jakob Bohm wrote:
> On 2021-05-18 13:56, David Woolley wrote:
>> On 18/05/2021 12:26, Andreas Schick wrote:
>>> server 127.127.1.0              # local clock (LCL)
>>> fudge  127.127.1.0 stratum 10   # LCL is unsynchronized
>>
>> Delete these lines.  As described, this system is not suitable as a
>> time server, and including these lines on a pure client can actually
>> frustrate synchronisation. This fake server is likely to vote against
>> the genuine server.
>>
>
> Perhaps the "tos orphan" option is a better way to make ntpd continue
> after loss of all time sources.
>
> Maybe some option to force treating the Windows server as stratum 12,
> even if it looses outside synch and reports itself as stratum 16.
>
>>> server  192.168.101.2
>>
>> This appears to be the machine itself, so it will be voting that's its
>> own time is correct.  Delete it.
>>
>> Windows machines can vary from fair to atrocious as time servers.  A
>> workstation running a default configuration of w32time will be at the
>> atrocious end.
>
> Fortunately, this is reportedly a server, which means it will keep time
> with a somewhat coarse granularity and include a battery backed TOY
> (Time Of Year) clock to keep time even across power outages.
>
> W32Time in server mode has a tendency to fluctuate about +/- 10ms from
> the time sources.  It is designed to provide an SNTP time source for
> Kerberos clients that need to stay within +/- 5 minutes of the Kerberos
> KDC.
>
>>
>> You should make sure that the ARM starts in the right ball park, by
>> either using a file timestamp to record the time at, or close to,
>> shutdown, or, as a last resort, setting a fixed time that isn't too
>> far from reality.
>
> Perhaps using the sntp program to do initial synchronization to the
> server machine (as a better alternative to ntpd -g).

ntpd with iburst is pretty much always better, even more so when you
have multiple servers configured.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Re: ntpd on busybox ARM system not keeping time with server

<s82gr4$1kps$1@gioia.aioe.org>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=15&group=comp.protocols.time.ntp#15

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!aioe.org!H7Y0FZ47LN90c6W7hPpRYw.user.gioia.aioe.org.POSTED!not-for-mail
From: mlichvar@redhat.com (Miroslav Lichvar)
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntpd on busybox ARM system not keeping time with server
Date: Wed, 19 May 2021 08:04:52 +0000 (UTC)
Organization: Aioe.org NNTP Server
Lines: 13
Message-ID: <s82gr4$1kps$1@gioia.aioe.org>
References: <2d3969e4-d5b8-434c-9eea-ecdfca4972fan@googlegroups.com>
<4ec39431-7f1e-4336-9987-833a8a7d3089n@googlegroups.com>
<s80a5l$flp$2@dont-email.me>
<1435a556-1951-4acb-a0da-7ac89e455796n@googlegroups.com>
NNTP-Posting-Host: H7Y0FZ47LN90c6W7hPpRYw.user.gioia.aioe.org
X-Complaints-To: abuse@aioe.org
User-Agent: slrn/1.0.3 (Linux)
X-Notice: Filtered by postfilter v. 0.9.2
 by: Miroslav Lichvar - Wed, 19 May 2021 08:04 UTC

On 2021-05-18, Andreas Schick <a.schick81@web.de> wrote:
> One further idea I had was just modifying some startup scripts (which
> run before ntpd process is started and after the network is up) to
> include some from of a ntpd-run-sync-and-quit or ntpdate call that
> steps the clock at system startup on the ARM device.

Another possibility is to start ntpd normally and wait for it to set the
clock. There is the ntp-wait script for that. On systemd-based
distributions there is a time-sync target which delay start of services
that need accurate clock.

--
Miroslav Lichvar

Re: ntpd on busybox ARM system not keeping time with server

<4cSdnZavjKB7fjn9nZ2dnUU78ffNnZ2d@giganews.com>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=16&group=comp.protocols.time.ntp#16

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!4.us.feeder.erje.net!2.eu.feeder.erje.net!feeder.erje.net!feeds.phibee-telecom.net!border2.nntp.ams1.giganews.com!nntp.giganews.com!buffer2.nntp.ams1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 19 May 2021 05:09:42 -0500
Subject: Re: ntpd on busybox ARM system not keeping time with server
Newsgroups: comp.protocols.time.ntp
References: <2d3969e4-d5b8-434c-9eea-ecdfca4972fan@googlegroups.com>
<s80a1u$flp$1@dont-email.me> <Yc2dnWKOF8Xs_zn9nZ2dnUU78dPNnZ2d@giganews.com>
<s82g9p$1ad5$1@gioia.aioe.org>
From: jb-usenet@wisemo.com.invalid (Jakob Bohm)
Organization: WiseMo A/S
Date: Wed, 19 May 2021 12:09:41 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:4.8) Goanna/20210402
Interlink/52.9.7762
MIME-Version: 1.0
In-Reply-To: <s82g9p$1ad5$1@gioia.aioe.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <4cSdnZavjKB7fjn9nZ2dnUU78ffNnZ2d@giganews.com>
Lines: 64
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-2j4DUAuZyhOL8zdmF+t9Utvt9DEatzQ9atpVVTyiqIvNiLD43NRDzfuXKu/yWAQIfzGDDwia9WPheu7!NxqhqrPvNzNmmj0FPDRXpp1KGtuRiJF2LXQ+o/boaEogMrOjPmwwmfUbKbU9HOBkW2PreUnrCkc=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 3982
 by: Jakob Bohm - Wed, 19 May 2021 10:09 UTC

On 2021-05-19 09:55, Terje Mathisen wrote:
> Jakob Bohm wrote:
>> On 2021-05-18 13:56, David Woolley wrote:
>>> On 18/05/2021 12:26, Andreas Schick wrote:
>>>> server 127.127.1.0              # local clock (LCL)
>>>> fudge  127.127.1.0 stratum 10   # LCL is unsynchronized
>>>
>>> Delete these lines.  As described, this system is not suitable as a
>>> time server, and including these lines on a pure client can actually
>>> frustrate synchronisation. This fake server is likely to vote against
>>> the genuine server.
>>>
>>
>> Perhaps the "tos orphan" option is a better way to make ntpd continue
>> after loss of all time sources.
>>
>> Maybe some option to force treating the Windows server as stratum 12,
>> even if it looses outside synch and reports itself as stratum 16.
>>
>>>> server  192.168.101.2
>>>
>>> This appears to be the machine itself, so it will be voting that's
>>> its own time is correct.  Delete it.
>>>
>>> Windows machines can vary from fair to atrocious as time servers.  A
>>> workstation running a default configuration of w32time will be at the
>>> atrocious end.
>>
>> Fortunately, this is reportedly a server, which means it will keep time
>> with a somewhat coarse granularity and include a battery backed TOY
>> (Time Of Year) clock to keep time even across power outages.
>>
>> W32Time in server mode has a tendency to fluctuate about +/- 10ms from
>> the time sources.  It is designed to provide an SNTP time source for
>> Kerberos clients that need to stay within +/- 5 minutes of the Kerberos
>> KDC.
>>
>>>
>>> You should make sure that the ARM starts in the right ball park, by
>>> either using a file timestamp to record the time at, or close to,
>>> shutdown, or, as a last resort, setting a fixed time that isn't too
>>> far from reality.
>>
>> Perhaps using the sntp program to do initial synchronization to the
>> server machine (as a better alternative to ntpd -g).
>
> ntpd with iburst is pretty much always better, even more so when you
> have multiple servers configured.
>

In my experience, ntpd algorithms converge very slowly in the trivial
cases where the initial local clock is not set, and all (or only in the
OPs case) sources agree on the correct time (TrueChimers).

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Re: ntpd on busybox ARM system not keeping time with server

<s82o9o$aa2$1@dont-email.me>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=17&group=comp.protocols.time.ntp#17

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: david@ex.djwhome.demon.invalid (David Woolley)
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntpd on busybox ARM system not keeping time with server
Date: Wed, 19 May 2021 11:12:07 +0100
Organization: No affiliation
Lines: 9
Message-ID: <s82o9o$aa2$1@dont-email.me>
References: <2d3969e4-d5b8-434c-9eea-ecdfca4972fan@googlegroups.com>
<s80a1u$flp$1@dont-email.me> <Yc2dnWKOF8Xs_zn9nZ2dnUU78dPNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 19 May 2021 10:12:08 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="89c5a1975d88a53c12bf0e5a3ffd49f8";
logging-data="10562"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18ZPTTwc3AhHl2B7fqVaZrLcTQRz+7P5ew="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.6.0
Cancel-Lock: sha1:nu3wkQO1UK/V5GMRH3C70QuhEfo=
In-Reply-To: <Yc2dnWKOF8Xs_zn9nZ2dnUU78dPNnZ2d@giganews.com>
Content-Language: en-GB
 by: David Woolley - Wed, 19 May 2021 10:12 UTC

On 19/05/2021 01:57, Jakob Bohm wrote:
> Perhaps the "tos orphan" option is a better way to make ntpd continue
> after loss of all time sources.

This is a pure client configuration. There is no need for ntpd to
continue to serve time after the loss of all sources. The kernel
software clock will continue to run, using the last available frequency
correction supplied by ntpd, without the need for any time island
mitigation measures.

Re: ntpd on busybox ARM system not keeping time with server

<s82qjq$76a$1@gioia.aioe.org>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=18&group=comp.protocols.time.ntp#18

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!aioe.org!/FKOcGQMirZgkZJCo9x3IA.user.gioia.aioe.org.POSTED!not-for-mail
From: terje.mathisen@tmsw.no (Terje Mathisen)
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntpd on busybox ARM system not keeping time with server
Date: Wed, 19 May 2021 12:51:39 +0200
Organization: Aioe.org NNTP Server
Lines: 65
Message-ID: <s82qjq$76a$1@gioia.aioe.org>
References: <2d3969e4-d5b8-434c-9eea-ecdfca4972fan@googlegroups.com>
<s80a1u$flp$1@dont-email.me> <Yc2dnWKOF8Xs_zn9nZ2dnUU78dPNnZ2d@giganews.com>
<s82g9p$1ad5$1@gioia.aioe.org>
<4cSdnZavjKB7fjn9nZ2dnUU78ffNnZ2d@giganews.com>
NNTP-Posting-Host: /FKOcGQMirZgkZJCo9x3IA.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101
Firefox/60.0 SeaMonkey/2.53.7
X-Notice: Filtered by postfilter v. 0.9.2
 by: Terje Mathisen - Wed, 19 May 2021 10:51 UTC

Jakob Bohm wrote:
> On 2021-05-19 09:55, Terje Mathisen wrote:
>> Jakob Bohm wrote:
>>> On 2021-05-18 13:56, David Woolley wrote:
>>>> On 18/05/2021 12:26, Andreas Schick wrote:
>>>>> server 127.127.1.0              # local clock (LCL)
>>>>> fudge  127.127.1.0 stratum 10   # LCL is unsynchronized
>>>>
>>>> Delete these lines.  As described, this system is not suitable as a
>>>> time server, and including these lines on a pure client can actually
>>>> frustrate synchronisation. This fake server is likely to vote
>>>> against the genuine server.
>>>>
>>>
>>> Perhaps the "tos orphan" option is a better way to make ntpd continue
>>> after loss of all time sources.
>>>
>>> Maybe some option to force treating the Windows server as stratum 12,
>>> even if it looses outside synch and reports itself as stratum 16.
>>>
>>>>> server  192.168.101.2
>>>>
>>>> This appears to be the machine itself, so it will be voting that's
>>>> its own time is correct.  Delete it.
>>>>
>>>> Windows machines can vary from fair to atrocious as time servers.  A
>>>> workstation running a default configuration of w32time will be at
>>>> the atrocious end.
>>>
>>> Fortunately, this is reportedly a server, which means it will keep time
>>> with a somewhat coarse granularity and include a battery backed TOY
>>> (Time Of Year) clock to keep time even across power outages.
>>>
>>> W32Time in server mode has a tendency to fluctuate about +/- 10ms from
>>> the time sources.  It is designed to provide an SNTP time source for
>>> Kerberos clients that need to stay within +/- 5 minutes of the Kerberos
>>> KDC.
>>>
>>>>
>>>> You should make sure that the ARM starts in the right ball park, by
>>>> either using a file timestamp to record the time at, or close to,
>>>> shutdown, or, as a last resort, setting a fixed time that isn't too
>>>> far from reality.
>>>
>>> Perhaps using the sntp program to do initial synchronization to the
>>> server machine (as a better alternative to ntpd -g).
>>
>> ntpd with iburst is pretty much always better, even more so when you
>> have multiple servers configured.
>>
>
> In my experience, ntpd algorithms converge very slowly in the trivial
> cases where the initial local clock is not set, and all (or only in the
> OPs case) sources agree on the correct time (TrueChimers).

Huh?

With an initial iburst I'm seeing 1-5s convergence.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

1
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor