Loopt jullie tijd nog goed?

[Pippin]

Info hier, hier en hier.

Volgens mij heeft mijn NAS er ook last van.
Telkens als ik de tijd goed zet gaat deze weer voorlopen, ca. 1,5 minuut per dag.

Wie heeft dit ook?

[Robert Koopman]

Ik gebruik daar een NTP server voor.
Mijn beide nassen lopen op tijd.

[Pippin]

Ja ik ook, heb nu een server in de US ingevuld, morgen nog eens kijken of die op tijd blijft lopen.

[Briolet]

Ik wist wel dat je de nas op handmatige tijd kon instellen. Dat is noodzakelijk als de nas niet aan het internet hangt. Ik wist niet dat hij dan synchroniseerde met de lichtnet frequentie.

Inderdaad vervelend. De afgelopen maanden moest ik mijn wekkerradio steeds 1 minuut vooruit zetten. Ze zijn de ontbrekende tijd nu weer aan het corrigeren. Maar zoals zoveel goedkope wekkerradios kan hij niet achteruit gezet worden, maar moet ik hem nu steeds 59 minuten vooruit zetten. (Gelukkig geen 1499 minuten)

NB de meest nabije server is "nl.pool.ntp.org". Dan blijft alles lekker lokaal (Hier zitten 3 IP adressen achter die random geselecteerd worden bij aanroep)

[rodio]

time.google.com
Wel even de goede tijdzone selecteren

[Hofstede]

De digitale klokchips in de NAS hebben hier echt geen last van.

Immers, de wisselspanning wordt omgezet naar gelijkspanning. En de klokfrequentie van het moederbord wordt opgewekt door een aantal frequentiekristallen die gevoed worden door gelijkspanning.

Wij hebben op het werk een eigen centrale, en als we afkoppelen van het landelijke net dan regelen we zelf ook de frequentie met onze eigen turbine met soms een grotere afwijking.
De enige apparaten die hier laat van hebben zijn een paar ouderwetse analoge elektrische klokken. Computers worden er niet warm of koud van ...

[Pippin]

Dat dacht ik ook.
Sinds ik op DSM 6 ben gegaan vermoed ik maar het viel me van de week pas op.
Het vermoeden "sinds DSM 6" door het correleren van logs.

Nu een paar uur verder zie ik de tijd al voorlopen, er is duidelijk iets mis maar heb te weinig kaas gegeten van het ntp.

[Briolet]

Ik heb dat bij DSM 3 of 4 eens gehad dat de tijd steeds 'wegliep'. Mij viel het wat sterker op omdat hij als tijdserver van de camera's fungeerde.

Wat ik me van het ntp proces herinner is dat hij maar een maximale tijd per dag mag corrigeren. Is de afwijking groter dan logt hij dat, maar corrigeert niets.

Bij mij was het probleem plots weer over. Ik vermoed na een update.

Veel logging zie ik niet in dat "/var/log/ntp.log". Maar twee entries en de laatste modificatie datum is ook al oud:

-rw-r--r-- 1 root    root  109   Oct  2  2012 ntp.log

[Pippin]

NTP wordt niet gelogd zover ik kan zien.

De server functie staat ook aan bij mij, puur voor OpenVPN clients maar het gaat hier om de client functie.

een maximale tijd per dag mag corrigeren

Slew rate volgens man ntpd:
Note: Since the slew rate of typical Unix kernels is limited to 0.5 ms/s, each second of adjustment requires an amortization interval of 2000 s. Thus, an adjustment as much as 600 s will take almost 14 days to complete.

[Pippin]

Het lijkt opgelost.

In

Code: [Selecteer]

cat /etc/ntp.conf.userstaan NTP servers die men handmatig een keer heeft ingevuld, worden dus onthouden terwijl de GUI dit niet laat zien.
Die heb ik leeg gemaakt en nu blijft de tijd goed lopen.

[Briolet]

Volgens mij heb ik de tijdserver ook minimaal 1 veranderd. Bij mij is die file echter leeg. Ik gebruik de nas (In elk geval de schijven in de nas) al sinds DSM 3.2, dus daar zou zich in de loop der jaren heel wat rotzooi verzameld hebben.

In "/etc/ntp.conf" staat de tijdserver die ingevuld is.

Code: [Selecteer]

$ cat /etc/ntp.conf
server nl.pool.ntp.org minpoll 6 maxpoll 10 iburst prefer
includefile /usr/share/ntp/ntp-restrict-serveron.conf
includefile /usr/share/ntp/ntp-common.conf
includefile /etc/ntp.conf.user
Op pool.ntp.org vind ik ook wat over instellingen en controle.

Leerzaam is het "ntpq -pn" commando op mijn 2e nas. Daar heb ik als tijdserver mijn 1e nas ingevuld (10.0.1.30):

Code: [Selecteer]

ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*10.0.1.30       88.159.1.197     3 u  407 1024  377    0.200    0.330   0.415
In de 2e kolom staat wel een echt IP adres. Als ik dat opzoek behoort die tot "nl.pool.ntp.org". Blijkbaar geeft de tijdserver op de nas niet alleen de tijd door, maar ook waar hij zelf de tijd vandaan gehaald heeft.

[Pippin]

Het is toch weer terug, nu ca. 4 minuten in 3 weken.
Ga de NTP server uitzetten, kijken wat dat brengt.

[Ben(V)]

Ik gebruik gewoon time.google.com als NTP server en mijn NAs loopt altijd op de juiste tijd.
Heb je soms een firewall in gebruik en het doorlaten van NTP niet aangezet?

[Pippin]

Het is uitgaand verkeer dus firewall van de NAS kan het niet zijn, router waar de NAS staat is ook niets aan veranderd.
Het is begonnen sinds ik update naar DSM 6 heb gedaan.
Huidig ingestelde NTP server is pool.ntp.org
Een tcpdump op de NAS laat ook het antwoord van de NTP server zien:

Code: [Selecteer]

root@NAS:~# tcpdump -v udp port 123
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
19:34:49.560980 IP (tos 0x0, ttl 48, id 18298, offset 0, flags [DF], proto UDP (17), length 76)
    srcf-ntp.stanford.edu.ntp > 192.168.51.250.ntp: NTPv4, length 48
Server, Leap indicator:  (0), Stratum 1 (primary reference), poll 6 (64s), precision -19
Root Delay: 0.000000, Root dispersion: 0.001129, Reference-ID: GPSs
  Reference Timestamp:  3732975012.197509287 (2018/04/17 19:30:12)
  Originator Timestamp: 3732975289.417432933 (2018/04/17 19:34:49)
  Receive Timestamp:    3732975022.025564180 (2018/04/17 19:30:22)
  Transmit Timestamp:   3732975022.025579109 (2018/04/17 19:30:22)
    Originator - Receive Timestamp:  -267.391868753
    Originator - Transmit Timestamp: -267.391853823
-267.391868753 seconden offset...

Deze NAS is nu zo`n vier jaar oud, zal als ik in den Nederlanden ben de knoopcel ook eens vervangen.

Wordt vervolgd...

[Briolet]

Slew rate volgens man ntpd:
Note: Since the slew rate of typical Unix kernels is limited to 0.5 ms/s, …

Dat is dus een maximale correctie van 43 sec. per dag. (teveel correctie kan andere processen verstoren).

In elk geval haalt jouw nas de goede tijd op. Misschien dat je interne klok echt meer dan die 43 sec per dag afwijkt. Kun je nog ergens vinden hoeveel hij corrigeert?