---

Jeg har for tiden 3 Linux maskiner, 2 server og 1 client.

Mine 2 server maskiner er lidt gamle, Intel P-200MHz på iwill
motherboards, og uret taber et sted mellem 30 minuter og flere timer
natten over. Derfor har jeg lagt en kommandofil med følgende indhold i
mappen

/etc/cron.hourly
rdate -s sunsite.auc.dk

på alle 3 maskiner, det virker rigtig godt.

Men jeg syntes det er forkert at bede om det samme data 3 gange på samme
tid, hvad skal der til for at jeg kan udnævne fx server1 til at hente
tiden fra sunsite.auc.dk og så få server2 & client1 til at hente tiden
fra server1 ?

Jeg har forsøgt med denne komando
rdate -s server1.mydomain
og får dette svar
"rdate: couldn't connect to host server1.mydomain: Connection refused"

(Der er nok en-eller-anden process der skal køre på server1 ?) - Henrik

--
Henrik Hammerschmidt. Copenhagen. Denmark ..
When we learn all the answers, they change the questions.
Power to the Penguins

---

On Tue, 16 Jan 2001, Henrik Hammerschmidt wrote:

> Jeg har for tiden 3 Linux maskiner, 2 server og 1 client.
>
> Mine 2 server maskiner er lidt gamle, Intel P-200MHz på iwill
> motherboards, og uret taber et sted mellem 30 minuter og flere timer
> natten over. Derfor har jeg lagt en kommandofil med følgende indhold i
> mappen
>
> /etc/cron.hourly
> rdate -s sunsite.auc.dk
>
> på alle 3 maskiner, det virker rigtig godt.
>
> Men jeg syntes det er forkert at bede om det samme data 3 gange på samme
> tid, hvad skal der til for at jeg kan udnævne fx server1 til at hente
> tiden fra sunsite.auc.dk og så få server2 & client1 til at hente tiden
> fra server1 ?
>
> Jeg har forsøgt med denne komando
> rdate -s server1.mydomain
> og får dette svar
> "rdate: couldn't connect to host server1.mydomain: Connection refused"

Det er en indbygget funktion i inetd eller xinetd (fungerer fint med
begge). I inetd skal du blot udkommentere en enkelt linje (jeg husker
den ikke præcist - men det er time/tcp) i xinetd skal du dumpe følgende
linjer i en fil i /etc/xinetd.d/ (eller tilføje dem til
/etc/xinetd.conf):

-- time/tcp start
{
type = INTERNAL
id = time-stream
socket_type = stream
protocol = tcp
user = root
wait = no
only_from = .amagerkollegiet.dk
}
-- time/tcp stop

Alternativt kan du stille dem med ntp - det understøtter broadcast
(smart hvis mange maskine på samme net skal have stillet uret),
multicast, mikrosekundsnøjagtighed mv.

Rasmus Bøg Hansen

---

Henrik Hammerschmidt <h@mmerschmidt.dk> wrote:

>Mine 2 server maskiner er lidt gamle, Intel P-200MHz på iwill
>motherboards, og uret taber et sted mellem 30 minuter og flere timer
>natten over.

Jeg går ud fra, at maskinerne er slukkede natten over, så det er
bundkortets ur - ikke systemuret - vi taler om.

Er tabet nogenlunde konstant på hver maskine?

I så fald skulle du måske prøve at stille uret på bundkortet nogle
gange med 'hwclock --adjust --utc;hwclock --systohc --utc' (--utc skal
kun medtages, hvis du kører GMT på bundkortet). Så stilles
bundkorturet, så det passer med systemuret, og samtidig registreres
afvigelsen i en fil. Næste gang, maskinen starter, vil der blive taget
højde for afvigelsen, så systemuret sættes nogenlunde præcist.


--
Allan Olesen, Lunderskov

"UNIX er overflødigt." - Lars P. Fischer

---

Allan Olesen wrote:
>
> Henrik Hammerschmidt <h@mmerschmidt.dk> wrote:
>
> >Mine 2 server maskiner er lidt gamle, Intel P-200MHz på iwill
> >motherboards, og uret taber et sted mellem 30 minuter og flere timer
> >natten over.
>
> Jeg går ud fra, at maskinerne er slukkede natten over, så det er
> bundkortets ur - ikke systemuret - vi taler om.

Ja, det glemte jeg at skrive.

>
> Er tabet nogenlunde konstant på hver maskine?

Nej, den ene ca 15 - 30 minutter, den anden ca 3 timer.

>
> I så fald skulle du måske prøve at stille uret på bundkortet nogle
> gange med 'hwclock --adjust --utc;hwclock --systohc --utc' (--utc skal
> kun medtages, hvis du kører GMT på bundkortet). Så stilles
> bundkorturet, så det passer med systemuret, og samtidig registreres
> afvigelsen i en fil. Næste gang, maskinen starter, vil der blive taget
> højde for afvigelsen, så systemuret sættes nogenlunde præcist.

Jeg har nu kørt flg komandoer:

#1: rdate -s sunsite.auc.dk
#2: hwclock --systohc
#3: hwclock --adjust

en anden rækkefølge end det du skriver, idet jeg regner med at #1
stiller systemuret, #2 henter klokken fra systemuret og skriver det til
hardware uret, #3 laver noget smart sammenligning mellem "en fil" og
hardware uret og system uret; næste gang jeg booter. Er det rigtigt
opfattet?

Jeg har nu fjernet kommandoen fra /etc/cron.hourly (vi skal jo ikke
grisse med resurserne og vil holde øje med urne i de kommende dage.

Mange tak for hjælpen (også til Rasmus & Karsten i denne tråd) - Henrik

--
Henrik Hammerschmidt. Copenhagen. Denmark ..
When we learn all the answers, they change the questions.
Power to the Penguins

---

Henrik Hammerschmidt <h@mmerschmidt.dk> wrote:

>Nej, den ene ca 15 - 30 minutter, den anden ca 3 timer.

Om de er ens, er egentlig ligegyldigt. Jeg tænkte mere på, om de hver
især går med nogenlunde konstant hastighed - uanset hvor forkert
hastigheden så måtte være. Så vil softwaren altid kunne regne sig frem
til den rigtige tid.

>>
>> I så fald skulle du måske prøve at stille uret på bundkortet nogle
>> gange med 'hwclock --adjust --utc;hwclock --systohc --utc' (--utc skal
>> kun medtages, hvis du kører GMT på bundkortet). Så stilles
>> bundkorturet, så det passer med systemuret, og samtidig registreres
>> afvigelsen i en fil. Næste gang, maskinen starter, vil der blive taget
>> højde for afvigelsen, så systemuret sættes nogenlunde præcist.
>
>Jeg har nu kørt flg komandoer:
>
>#1: rdate -s sunsite.auc.dk

Fint, stiller kernel-uret nøjagtigt.

>#2: hwclock --systohc

Stiller bundkortets ur efter kernel-uret. Beregner samtidig
bundkort-urets afvigelse pr. døgn ved at se, hvor lang tid, der er
gået siden sidste justering, og hvor meget tiden er skredet siden da.
Denne afvigelse skrives i filen /etc/adjtime sammen med tidspunkt for
kalibrering.

>#3: hwclock --adjust

Korrigerer bundkortets tid ud fra data i /etc/adjtime og den tid, der
er gået siden sidst.

Af en eller anden grund regner --systohc forkert[1], hvis der ikke
umiddelbart forinden er kørt en --adjust. Det er grunden til min
rækkefølge. Derudover skal --systohc køres et par gange, gerne med
nogle dages mellemrum, før afvigelsen pr. døgn kan beregnes.

Dermed er den korrekte rækkefølge:

#1: rdate -s sunsite.auc.dk

#2: hwclock --systohc

....og så efter nogle timer eller dage:

#3: rdate -s sunsite.auc.dk

#4: hwclock --adjust

#5: hwclock --systohc

Men måske var det en ide at få en egentlig tidsstyrings-daemon ind på
maskinerne. De to mest udbredte er nok:

- xntp3, som er meget præcis og anerkendt, men har det bedst med, at
maskinen konstant er tændt og på nettet.

- chronyd, som er specielt udviklet til maskiner, som kun periodisk
er tændt og på nettet. Det vil blandt andet sige, at den i
modsætning til xntp3 også kan holde styr på bundkort-uret.



[1]: Det er i hvert fald min overbevisning efter at have kigget lidt
på afvigelses-beregningen, som man kan få at se med verbose-optionen.


--
Allan Olesen, Lunderskov

"UNIX er overflødigt." - Lars P. Fischer

---

Henrik Hammerschmidt <h@mmerschmidt.dk> wrote:

> #1: rdate -s sunsite.auc.dk

ntpdate -s sunsite.dk

vil nok være bedre, da den bruger ntp, der er mere præcis.

-s betyder, at der skal logges til syslog, den sætter uret som default.

--
Niels, The Offspring Mailinglist www.image.dk/~teglsbo

---

Allan Olesen <aolesen@post3.tele.dk> wrote:

> I så fald skulle du måske prøve at stille uret på bundkortet nogle
> gange med 'hwclock --adjust --utc;hwclock --systohc --utc' (--utc skal
> kun medtages, hvis du kører GMT på bundkortet). Så stilles
> bundkorturet, så det passer med systemuret, og samtidig registreres
> afvigelsen i en fil. Næste gang, maskinen starter, vil der blive taget
> højde for afvigelsen, så systemuret sættes nogenlunde præcist.

Hvorfor skal der køres --adjust? Som jeg læser man-siden vil --systohc
sørge for, at afvigelsen registreres.

"Every time you calibrate (set) the clock (using --set or
--systohc ), hwclock recalculates the systematic drift
rate based on how long it has been since the last calibra­
tion, how long it has been since the last adjustment, what
drift rate was assumed in any intervening adjustments, and
the amount by which the clock is presently off."

Skal man gøre noget for, at hwclock --adjust bliver kørt inden hwclock
--hctosys ved opstart?

Hvor sker det henne?

--
Niels, The Offspring Mailinglist www.image.dk/~teglsbo

---

Niels@fabel.dk (Niels Teglsbo) wrote:

>Hvorfor skal der køres --adjust?

Fordi programmøren af hwclock er dum?

Prøv at kigge på nedenstående. Jeg mener, der må være en fejl i
hwclock, som fører til forkert beregning af drift, hvis ikke man først
kører en --adjust. Hvis du er enig, bør jeg måske tage mig sammen og
få skrevet til programmøren (altså ikke, at han er dum).

>[root@aho1 /root]# hwclock --systohc --utc --test --debug
>Using /dev/rtc interface to clock.
>Last drift adjustment done at 975957221 seconds after 1969
>Last calibration done at 974064648 seconds after 1969
>Waiting for clock tick...
>...got clock tick
>Time read from Hardware Clock: 22:30:30
>Hw clock time : 22:30:30 = 979684230 seconds since 1969
>Time elapsed since reference time has been 0.908817 seconds.
>Delaying further to reach the next full second.
>Setting Hardware Clock to 22:29:52 = 979684192 seconds since 1969
>Clock not changed - testing only.
>Clock drifted -39 seconds in the past 5619582 seconds in spite of a drift factor of -2.731
>085 seconds/day.
>Adjusting drift factor by -0.599618 seconds/day
>Not updating adjtime file because of testing mode.
>Would have written the following to /etc/adjtime:
>-3.330703 979684191 0.000000
>979684191

>[root@aho1 /root]# hwclock --adjust --utc --debug
>Using /dev/rtc interface to clock.
>Last drift adjustment done at 975957221 seconds after 1969
>Last calibration done at 974064648 seconds after 1969
>Waiting for clock tick...
>...got clock tick
>Time read from Hardware Clock: 22:30:43
>Hw clock time : 22:30:43 = 979684243 seconds since 1969
>Time since last adjustment is 3727022 seconds
>Need to insert -118 seconds and refer time back 0.189652 seconds ago
>Time elapsed since reference time has been 0.205347 seconds.
>Delaying further to reach the next full second.
>Setting Hardware Clock to 22:28:46 = 979684126 seconds since 1969
>ioctl(RTC_SET_TIME) was successful.

>[root@aho1 /root]# hwclock --systohc --utc --test --debug
>Using /dev/rtc interface to clock.
>Last drift adjustment done at 979684125 seconds after 1969
>Last calibration done at 974064648 seconds after 1969
>Waiting for clock tick...
>...got clock tick
>Time read from Hardware Clock: 22:28:53
>Hw clock time : 22:28:53 = 979684133 seconds since 1969
>Time elapsed since reference time has been 0.226390 seconds.
>Delaying further to reach the next full second.
>Setting Hardware Clock to 22:30:13 = 979684213 seconds since 1969
>Clock not changed - testing only.
>Clock drifted 79 seconds in the past 5619485 seconds in spite of a drift factor of -2.7310
>85 seconds/day.
>Adjusting drift factor by 1.214631 seconds/day
>Not updating adjtime file because of testing mode.
>Would have written the following to /etc/adjtime:
>-1.516454 979684212 0.000000
>979684212


--
Allan Olesen, Lunderskov

"UNIX er overflødigt." - Lars P. Fischer

---

Allan Olesen <aolesen@post3.tele.dk> wrote:

> Niels@fabel.dk (Niels Teglsbo) wrote:
> >Hvorfor skal der køres --adjust?
> Fordi programmøren af hwclock er dum?
> Prøv at kigge på nedenstående. Jeg mener, der må være en fejl i
> hwclock, som fører til forkert beregning af drift, hvis ikke man først
> kører en --adjust. Hvis du er enig, bør jeg måske tage mig sammen og
> få skrevet til programmøren (altså ikke, at han er dum).

Hvad præcist mener du er fejlen?

--
Niels, The Offspring Mailinglist www.image.dk/~teglsbo

---

Niels@fabel.dk (Niels Teglsbo) wrote:

>Hvad præcist mener du er fejlen?

At hwclock --systohc indsætter forkerte data i /etc/adjtime, hvis der
ikke er kørt en --adjust umiddelbart forinden.

Prøv at kigge i mine to kørsler af --systohc. Den beregnede drift
burde være ens, men der er en voldsom forskel, fordi jeg før den anden
kørsel har udført en --adjust.


--
Allan Olesen, Lunderskov

"UNIX er overflødigt." - Lars P. Fischer

---

Allan Olesen <aolesen@post3.tele.dk> wrote:

> Niels@fabel.dk (Niels Teglsbo) wrote:
> >Hvad præcist mener du er fejlen?
> At hwclock --systohc indsætter forkerte data i /etc/adjtime, hvis der
> ikke er kørt en --adjust umiddelbart forinden.

"Clock drifted -39 seconds in the past 5619582 seconds in spite of a
drift factor of -2.731085 seconds/day."

Det kan der være noegt om, det er som om systohc forventer, at adjust
bliver kørt med jævne mellemrum. For hvis adjust ikke er blevet kørt
giver det ovenfor citerede ikke meget mening.

--
Niels, The Offspring Mailinglist www.image.dk/~teglsbo

---

Niels@fabel.dk (Niels Teglsbo) wrote:

>"Clock drifted -39 seconds in the past 5619582 seconds in spite of a
>drift factor of -2.731085 seconds/day."
>
>Det kan der være noegt om, det er som om systohc forventer, at adjust
>bliver kørt med jævne mellemrum. For hvis adjust ikke er blevet kørt
>giver det ovenfor citerede ikke meget mening.

Lige præcis. Det var faktisk den linie, jeg selv faldt over, da jeg så
et output fra hwclock første gang.


--
Allan Olesen, Lunderskov

"UNIX er overflødigt." - Lars P. Fischer

---

>>>>> "Henrik" == Henrik Hammerschmidt <h@mmerschmidt.dk> writes:

Henrik> Jeg har for tiden 3 Linux maskiner, 2 server og 1 client.

Henrik> Mine 2 server maskiner er lidt gamle, Intel P-200MHz på iwill
Henrik> motherboards, og uret taber et sted mellem 30 minuter og
Henrik> flere timer natten over. Derfor har jeg lagt en kommandofil
Henrik> med følgende indhold i mappen

Henrik> /etc/cron.hourly rdate -s sunsite.auc.dk

Henrik> på alle 3 maskiner, det virker rigtig godt.

Både ja og nej. rdate "stiller" klokken ved at flytte viseren
(billedligt talt), men hvis du bruger NTP istedet, så vil den justere
hastigheden på dit ur, så den svinger ind og er
synkroniseret. Ydermere giver NTP meget mere præcis indstilling af
tiden...

Prøv at se lidt på NTP pakkerne (ntp-4 eller xntp) - du kan definere
sunsite.dk som server eller bruge en af de mange andre NTP servere på
nettet - lad være med at definere en hel bunke - dit ur bliver ikke
meget mere præcis, og det skaber blot en masse trafik.

Karsten
SunSITE.dk

---

Karsten Thygesen <karthy@SunSITE.dk> wrote:

> Både ja og nej. rdate "stiller" klokken ved at flytte viseren
> (billedligt talt), men hvis du bruger NTP istedet, så vil den justere
> hastigheden på dit ur, så den svinger ind og er
> synkroniseret. Ydermere giver NTP meget mere præcis indstilling af
> tiden...

Hvad er der egentlig af programmer til dialup-maskiner?

Jeg har kørt med chronyd i et stykke tid nu, men ofte har uret været
mange minutter galt også efter chronyd har "flyttet viserne". Før det
brugte jeg NTP, men det var for langsomt til at stille tiden.

--
Niels, The Offspring Mailinglist www.image.dk/~teglsbo

---

Niels@fabel.dk (Niels Teglsbo) wrote:

>Jeg har kørt med chronyd i et stykke tid nu, men ofte har uret været
>mange minutter galt også efter chronyd har "flyttet viserne". Før det
>brugte jeg NTP, men det var for langsomt til at stille tiden.

Hvordan bruger du det? Er maskinen slukket af og til?

Hvis du kører de rigtige chrony-kommandoer på de rigtige tidspunkter i
forbindelse med opstart og nedlukning, burde din tid aldrig være flere
minutter ved siden af, eftersom chronyd sørger for at holde
informationerne om bundkort-urets drift opdaterede.

Dvs. at næste gang, maskinen starter, stiller den kernel-uret ud fra
bundkort-urets klokkeslæt, sammenholdt med den kendte drift. Hvis ikke
maskinen står slukket i flere uger ad gangen eller bundkort-uret er
meget ustabilt, burde fejlen ligge på nogle få sekunder.


--
Allan Olesen, Lunderskov

"UNIX er overflødigt." - Lars P. Fischer

---

Allan Olesen <aolesen@post3.tele.dk> wrote:

> Niels@fabel.dk (Niels Teglsbo) wrote:
> >Jeg har kørt med chronyd i et stykke tid nu, men ofte har uret været
> >mange minutter galt også efter chronyd har "flyttet viserne". Før det
> >brugte jeg NTP, men det var for langsomt til at stille tiden.
> Hvordan bruger du det?

I /etc/ppp/ip-up.local har jeg

# Fortæl chrony, at vi er online
cat <<EOF | /usr/local/bin/chronyc
password xxxxxxxxxxxxx
online
EOF

og i ip-down.local har jeg

#cat <<EOF | /usr/local/bin/chronyc
password xxxxxxxxxxxxx
offline
dump
writertc
EOF

> Er maskinen slukket af og til?

Ja, den er kun tændt når jeg bruger den.

> Hvis du kører de rigtige chrony-kommandoer på de rigtige tidspunkter i
> forbindelse med opstart og nedlukning, burde din tid aldrig være flere
> minutter ved siden af, eftersom chronyd sørger for at holde
> informationerne om bundkort-urets drift opdaterede.

Chrony kører som service og bliver startet ved opstart.

> Dvs. at næste gang, maskinen starter, stiller den kernel-uret ud fra
> bundkort-urets klokkeslæt, sammenholdt med den kendte drift. Hvis ikke
> maskinen står slukket i flere uger ad gangen eller bundkort-uret er
> meget ustabilt, burde fejlen ligge på nogle få sekunder.

Jeg har oplevet at være online, og set at chrony har stillet uret flere
minutter tilbage, selvom uret gik for langsomt i forvejen.

Nedenfor er de justeringer på over 100 sekunder i de logfiler jeg har
liggende. Noget kunne tyde på, at den ikke kan justere uret nok. Se
forresten også den 7. januar, der er den også helt gal.

Dec 18 17:52:56 by -186.566555 seconds
Dec 19 12:00:57 by -190.841182 seconds
Dec 19 20:40:54 by -194.000324 seconds
Dec 20 17:33:19 by -198.507586 seconds
Dec 20 20:04:47 by -198.698401 seconds
Dec 21 08:29:51 by -201.383981 seconds
Dec 21 17:31:10 by -203.789042 seconds
Dec 21 22:38:25 by -205.007322 seconds
Dec 22 14:25:55 by -209.145701 seconds
Dec 22 22:35:01 by -212.176945 seconds
Dec 23 16:22:56 by -215.612188 seconds
Dec 25 02:04:22 by -223.554800 seconds
Dec 25 15:12:57 by -227.347686 seconds
Dec 26 20:53:03 by -233.852999 seconds
Dec 27 16:57:10 by -238.452818 seconds
Dec 27 23:21:35 by -239.944016 seconds
Dec 28 17:52:08 by -244.469368 seconds
Dec 28 22:40:55 by -245.941366 seconds
Jan 1 19:15:23 by -270.500677 seconds
Jan 2 22:56:05 by -276.904437 seconds
Jan 3 14:42:58 by -280.944600 seconds
Jan 3 20:23:36 by -282.502087 seconds
Jan 4 16:39:39 by -287.541047 seconds
Jan 4 23:15:51 by -289.137332 seconds
Jan 5 17:18:54 by -293.495539 seconds
Jan 6 16:30:49 by -298.898642 seconds
Jan 6 21:13:59 by -299.959514 seconds
Jan 7 17:44:46 by -304.702695 seconds
Jan 7 19:19:21 by 327.100041 seconds
Jan 7 21:48:40 by -305.669171 seconds
Jan 8 18:51:41 by -310.728932 seconds
Jan 9 16:16:14 by -315.658832 seconds
Jan 9 20:53:31 by -316.533686 seconds
Jan 10 01:10:59 by -316.629952 seconds
Jan 10 12:31:47 by -319.736604 seconds
Jan 10 16:49:23 by -321.425807 seconds
Jan 12 02:14:25 by -329.319866 seconds

Mvh
--
Niels, The Offspring Mailinglist www.image.dk/~teglsbo

---

Niels@fabel.dk (Niels Teglsbo) wrote:

>Chrony kører som service og bliver startet ved opstart.

Nu kan jeg ikke helt huske konfigurationen af chrony mht.
hardware-uret. Jeg har den kun installeret på en maskine på arbejde.
Med lidt held får jeg tid til at kigge på i morgen, hvordan jeg selv
har sat det op i sin tid.

Der foresvæver mig dog noget med, at jeg dengang fandt ud af, at
chrony og hwclock kan komme i konflikt med hinanden, så man får noget
dobbeltkorrektion. På en RedHat-maskine køres der en 'hwclock --adjust
--hctosys' under opstart. Hvis chronyd oven i laver en lignende
korrektion, baseret på _sin_ beregning af hardware-urets drift, kan
det måske gå galt.

>Jeg har oplevet at være online, og set at chrony har stillet uret flere
>minutter tilbage, selvom uret gik for langsomt i forvejen.

Sært.

>Nedenfor er de justeringer på over 100 sekunder i de logfiler jeg har
>liggende. Noget kunne tyde på, at den ikke kan justere uret nok. Se
>forresten også den 7. januar, der er den også helt gal.

Bortset fra den 7. januar ser det jo egentlig smukt ud - eller i hvert
fald systematisk. Du har en jævnt stigende fejl hele vejen. Må jeg
have lov at gætte på, at alle disse linier stammer fra allerførste
synkronisering med en ekstern server, efter du har startet maskinen?

I så fald kan problemet vel isoleres til, at kernel-uret i din maskine
ved opstart bliver stillet efter bundkort-uret, men der korrigeres
forkert for bundkort-urets drift - enten fordi værdierne i
/etc/adjtime er forkerte, eller fordi både hwclock og chrony forsøger
at kompensere for drift. Derefter går du på Internettet og får
kernel-uret stillet korrekt, hvilket medfører en korrektion på flere
minutter..

--
Allan Olesen, Lunderskov

"UNIX er overflødigt." - Lars P. Fischer

---

Allan Olesen <aolesen@post3.tele.dk> wrote:

> >Nedenfor er de justeringer på over 100 sekunder i de logfiler jeg har
> >liggende. Noget kunne tyde på, at den ikke kan justere uret nok. Se
> >forresten også den 7. januar, der er den også helt gal.
> Bortset fra den 7. januar ser det jo egentlig smukt ud - eller i hvert
> fald systematisk. Du har en jævnt stigende fejl hele vejen. Må jeg
> have lov at gætte på, at alle disse linier stammer fra allerførste
> synkronisering med en ekstern server, efter du har startet maskinen?

Præcis. Efter hver boot er mønsteret, at klokken bliver sat meget først,
og så kun lidt senere.

> I så fald kan problemet vel isoleres til, at kernel-uret i din maskine
> ved opstart bliver stillet efter bundkort-uret, men der korrigeres
> forkert for bundkort-urets drift - enten fordi værdierne i
> /etc/adjtime er forkerte, eller fordi både hwclock og chrony forsøger
> at kompensere for drift. Derefter går du på Internettet og får
> kernel-uret stillet korrekt, hvilket medfører en korrektion på flere
> minutter..

Lyder meget sandsynligt, hvordan undgår jeg det?

--
Niels, The Offspring Mailinglist www.image.dk/~teglsbo

---

Niels@fabel.dk (Niels Teglsbo) wrote:

>Lyder meget sandsynligt, hvordan undgår jeg det?

Det er dæleme et godt spørgsmål. Nu har jeg kigget på min maskine på
arbejde, og jeg er ikke sikker på, at jeg ikke selv vil have samme
problem, hvis den en gang skal genstartes.

Jeg tror, det bedste er at lade chrony overtage opgaven med at passe
hardware-uret. På min RH ligger kaldet til hwclock i
/etc/rc.d/rc.sysinit, hvor linien '$CLOCK --adjust' skal fjernes.

Fordelen ved den løsning er, at hele processen med kalibrering og så
videre er automatiseret i chronyd.

Ulempen er, at chronyd køres en del senere under opstart (i hvert fald
på mit system), så hvis bundkort-uret er meget ved siden af, vil det
føre til nogle sjove logfiler. Det bør dog kunne forebygges ved at
lade chrony stille bundkort-uret ved hver nedlukning af maskinen. Jeg
kan ikke huske kaldet, men prøv at søge på 'rtc' i dokumentationen til
chronyd.

--
Allan Olesen, Lunderskov

"UNIX er overflødigt." - Lars P. Fischer

---

Allan Olesen <aolesen@post3.tele.dk> wrote:

> Niels@fabel.dk (Niels Teglsbo) wrote:
> >Lyder meget sandsynligt, hvordan undgår jeg det?
> Jeg tror, det bedste er at lade chrony overtage opgaven med at passe
> hardware-uret. På min RH ligger kaldet til hwclock i
> /etc/rc.d/rc.sysinit, hvor linien '$CLOCK --adjust' skal fjernes.

[niels@lisa rc.d]$ grep adjust rc.sysinit
[niels@lisa rc.d]$

Hvilken version af RH kører du med? Min er en 6.2.

Men jeg tror nu jeg vil prøve den "manuelle" version (ntpdate og hwclock
adjust) lidt, så jeg prøver at indsætte en
/sbin/hwclock $CLOCKFLAGS --adjust
i /etc/rc.d/rc.sysconfig selvom det undrer mig, at man ikke ved at
skrive noget i /etc/sysconfig/clock kan køre adjust ved hver opstart,
men det understøtter /etc/rc.d/rc.sysconfig ikke, så vidt jeg kan se.

> Ulempen er, at chronyd køres en del senere under opstart (i hvert fald
> på mit system), så hvis bundkort-uret er meget ved siden af, vil det
> føre til nogle sjove logfiler. Det bør dog kunne forebygges ved at
> lade chrony stille bundkort-uret ved hver nedlukning af maskinen. Jeg
> kan ikke huske kaldet, men prøv at søge på 'rtc' i dokumentationen til
> chronyd.

writertc hedder den.

--
Niels, The Offspring Mailinglist www.image.dk/~teglsbo

---

Niels@fabel.dk (Niels Teglsbo) wrote:

>[niels@lisa rc.d]$ grep adjust rc.sysinit
>[niels@lisa rc.d]$

Min maskine hjemme kører 6.0:

[root@aho1 rc.d]# grep adjust rc.sysinit
$CLOCK --adjust
[root@aho1 rc.d]#

Min maskine på arbejde, som kører chronyd, er en 6.2, men den kommer
jeg først forbi på torsdag. Jeg skal først på en halvtåbelig visit til
England uden ip. Så må vi se, om jeg klarer det.

Men har de ikke bare flyttet kaldet?

Hvad siger 'grep -r adjust /etc/*'?


--
Allan Olesen, Lunderskov

"UNIX er overflødigt." - Lars P. Fischer

---

Allan Olesen <aolesen@post3.tele.dk> wrote:

> Men har de ikke bare flyttet kaldet?
> Hvad siger 'grep -r adjust /etc/*'?

Ikke andet hwclock end det jeg nu selv har skrevet i rc.sysinit og
/etc/ppp/ip-down.local

Men det udelukker jo ikke, at RH6.2 måske bruger et og eller andet
program, hvor parametren ikke hedder adjust, men så skulle man jo tro,
at det var i rc.sysinit, hvor jeg ikke kan se noget mistænkeligt.

--
Niels, The Offspring Mailinglist www.image.dk/~teglsbo

---

On Tue, 16 Jan 2001, Niels Teglsbo wrote:

> Karsten Thygesen <karthy@SunSITE.dk> wrote:
>
> > Både ja og nej. rdate "stiller" klokken ved at flytte viseren
> > (billedligt talt), men hvis du bruger NTP istedet, så vil den justere
> > hastigheden på dit ur, så den svinger ind og er
> > synkroniseret. Ydermere giver NTP meget mere præcis indstilling af
> > tiden...
>
> Hvad er der egentlig af programmer til dialup-maskiner?

Hvad med ntpdate?

> Jeg har kørt med chronyd i et stykke tid nu, men ofte har uret været
> mange minutter galt også efter chronyd har "flyttet viserne". Før det
> brugte jeg NTP, men det var for langsomt til at stille tiden.

/Rasmus

---

Rasmus Bøg Hansen <moffespam@amagerkollegiet.dk> wrote:

> > Hvad er der egentlig af programmer til dialup-maskiner?
> Hvad med ntpdate?

Yep, den er i hvert fald lidt bedre end rdate, og så med hwclock. Men
det ligner alligevel ikke en helt rigtig løsning, der er fx ikke noget,
der justerer hastigheden på uret, så det passer med tiden.

Forresten så jeg også gerne, at den kunne levere tid på en og eller
anden måde til min windows-maskine.

--
Niels, The Offspring Mailinglist www.image.dk/~teglsbo

---

On Wed, 17 Jan 2001, Niels Teglsbo wrote:

> Rasmus Bøg Hansen <moffespam@amagerkollegiet.dk> wrote:
>
> > > Hvad er der egentlig af programmer til dialup-maskiner?
> > Hvad med ntpdate?
>
> Yep, den er i hvert fald lidt bedre end rdate, og så med hwclock. Men
> det ligner alligevel ikke en helt rigtig løsning, der er fx ikke noget,
> der justerer hastigheden på uret, så det passer med tiden.
>
> Forresten så jeg også gerne, at den kunne levere tid på en og eller
> anden måde til min windows-maskine.

Konfigurer ntpd og sæt Tardis eller K9 op på din Windows:

http://www.kaska.demon.co.uk/

Rasmus Bøg Hansen

---

Niels@fabel.dk (Niels Teglsbo) wrote:

>Forresten så jeg også gerne, at den kunne levere tid på en og eller
>anden måde til min windows-maskine.

Hvis de to maskiner i forvejen snakker sammen, kører du vel samba på
Linux-maskinen? Har du prøvet at køre en
'net time \\netbios_navn_på_linuxmaskine /set /yes' ?


--
Allan Olesen, Lunderskov

"UNIX er overflødigt." - Lars P. Fischer

---

Rasmus Bøg Hansen <moffespam@amagerkollegiet.dk> wrote:

>Hvad med ntpdate?

ntpdate er en del af xntp3, som allerede har været nævnt et par gange.

Men ntpdate i sig selv stiller altså bare uret. Den gør ikke noget for
at få uret til at gå rigtigt.


--
Allan Olesen, Lunderskov

"UNIX er overflødigt." - Lars P. Fischer