Skudsekund 30 juni 2012 23:59:60

Se først mit blogindlæg på ing.dk

Den IT mæssige vinkel er flg:

Det rammer heldigvis natten mellem lørdag og søndag.

Det rammer klokken 23:59:60 UTC tid, hvilket er 01:59:60 lokal dansk tid.

Med mindre i har gjort en allehelvedes stor indsats med jeres systemer, kan I ikke vide hvad de gør.

Der er tre problem-områder:

1. Ved jeres systemer om der kommer skudsekunder ?

Check jeres NTP konfiguration, check om jeres upstream server annoncerer skudsekundet, nogle gør det en måned før, andre en dag før, nogle kun en time før.

GPS annoncerer det formodentlig om nogle ugers tid.
DCF77 annoncerer det kun en time før.

2. Gør jeres systemer det samme når skudsekundet sker ?

Næppe. Overvej Windows/Unix forskel etc.

3. Bliver jeres programmer forvirret ?

Sidste skudsekunder fik bla. visse Oracle databaser til at gå i sort der krævede maskinboot.

Mit forslag: Sluk hele shoppen lørdag eftermiddag og tænd igen søndag morgen.

Brug evt tiden til at rydde op i kabler, teste nødstrømmen og støvsuge computerrummet (også under det hævede gulv).

Overvej at kime alle relevante styrelser/politikere ned de næste to uger for at sikre at Danmark stemmer nej til skudsekunder i Geneve om to uger.

Og ja, jeg er helt seriøs: Jeg er på ferie den dag.

phk

Kommentarer (20)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Flemming Frandsen

I gamle dage testede TDC nødstrømmen hver fredag ved at slukke på hovedtavlen, det gjorde at intet vigtigt udstyr kom til at sidde uden nødstrøm fordi man hurtigt opdagede at man var afhængig af bystrøm.

Ved rent sløseri er der mange der sikrer sig mod at være afhængige af korrekt tid ved simpelthen at sætte ntp op tilfældigt eller slet ikke, så deres ure går flere sekunder forkert.

  • 0
  • 0
#7 Per Erik Rønne

Uden skudsekunder ender det med at vi her på den nordlige halvkugle kan fejre jul til SOMMERsolhverv. Er det det vi ønsker?

Sådan nogle små software-problemer er da vel til at løse, og sker det virkelig aldrig at programmel kører lidt galt rent tidsmæssigt?

  • 0
  • 0
#8 Torben Mogensen Blogger

Uden skudsekunder ender det med at vi her på den nordlige halvkugle kan fejre jul til SOMMERsolhverv.

Selv om vi bare lod stå til, så vil det ikke ske før længe efter, at vi er holdt op med at fejre jul -- hvis der i det hele taget er mennesker tilbage på jorden til den tid. Længe inden da vil soltidsmidnat og urets midnat dog forrykkes.

Men det hyppigst foreslåede alternativ til skudsekunder er ikke at lade uret skride i forhold til soltiden, men at "strække" nogen sekunder til at vare lidt længere, så man normaliserer i forhold til soltid.

Personligt synes jeg, at den officielle tid alligevel er ret langt fra soltid mange steder på jorden, og solhverv er alligevel ikke sammenfaldende med nytår, så for min skyld kunne man godt lade uret skride i forhold til soltid og "blot" flytte tidszonerne nogle få kilometer en gang hvert tusinde år. Dem, der har behov for ægte soltid (eller stjernetid), skal nok finde ud af at kompensere.

  • 1
  • 0
#10 Anonym

For hvilke kendte programmer eller systemer eller design er det et alvorligt problem? Jeg spørger blot dumt, da jeg aldrig er blevet ramt af det. Eller jeg ikke har opdaget det. Er det kun i mere eller mindre komplekse distribuerede systemer agtigt, det er et relevant problem?

Mit største problem med tid og computere er virtualisering. Her går det sommetider (sjovt?) i ged for eksempelvis host operativsystemet, hvor tiden skøjter rundt eller opfører sig forkert.

  • 0
  • 0
#11 Henning Makholm

Torben:

Men det hyppigst foreslåede alternativ til skudsekunder er ikke at lade uret skride i forhold til soltiden, men at "strække" nogen sekunder til at vare lidt længere, så man normaliserer i forhold til soltid.

Hvaba?

Mig bekendt er det eneste seriøse alternativ forslag at man bevarer SI-sekundet og til gengæld fastfryser forskellen mellem TAI og civil tidsregnings tidszone +0000. Så kan man i løbet af et par årtusinder bliver nødt til at gå over til at bruge en anden tidszone hvis man stadig vil have klokken 00 borgerlig tid til at stemme nogenlunde med midt om natten -- men skiftende UTC-offsets kan vores systemer sagtens finde ud af, dem hopper vi mellem to gange om året alligevel.

  • 1
  • 0
#13 Henning Makholm

Martin:

For hvilke kendte programmer eller systemer eller design er det et alvorligt problem? Jeg spørger blot dumt, da jeg aldrig er blevet ramt af det. Eller jeg ikke har opdaget det. Er det kun i mere eller mindre komplekse distribuerede systemer agtigt, det er et relevant problem?

Jeg har oplevet en håndfuld servere gå ned 1. juli klokken 0 fordi systemtiden pludselig hoppede et sekund tilbage, idet unix-tiden ikke kan repræsentere 23:59:60-sekundet, og blev ved med at gå fremad indtil ntpd stillede den hårdt.

Der var ikke særlig meget distribueret over selve nedbruddet. Serverne var blot programmeret til at opfatte det som en fatal fejl at tiden gik baglæns. Alternativet ville være at et uvist antal interne datastrukturer der afhang af tidsstempler nu var potententielt inkonsistente.

Det værste var at der ikke engang skulle være noget skudsekund det år -- men en eller anden upstream ntp-server må have bildt sig ind at der var.

Og vi kan ikke bare slukke for serverne i risikoperioden, for vi har brugerer både i Østasien og den amerikanske vestkyst, hvor det er højlys dag på det pågældende tidspunkt.

  • 2
  • 0
#15 Anonym

Det ved vi ikke, for der er (stort set) ingen der tester deres software for håndtering af skudsekunder.

Branchen har vist generelt større udfordringer end skudsekunder. Så det nok langt nede på listen over "manglende vigtige tests".

Ud over det nørdede og hyggelige i at dyrke den slags fænomener, er der vel også et PR (markedsførings-) aspekt. En slags indikator for hvor omhyggelig (pedantisk sågar måske), man er. Er den slags detaljer i orden, er der nok også styr på resten.

  • 0
  • 0
#16 Jesper Louis Andersen

Nu har en del erlangsystemer i telekombranchen det her problem for fuld udblæsning. De skal køre uden at gå ned, så der er man nødt til at håndtere skudsekunder eksplicit. Men det er så også til dels begrænset hvor meget hjælp du får af systemet og hvor meget du selv skal implementere. Kaldet erlang:now() er "beskyttet" på en sådan måde at den altid leverer et "fudged" resultat der er strengt stigende. Men det giver dig kun en pseudostabil source: Den kan i visse tilfælde være alt andet end tidskorrekt, fordi den kan være op til skudsekundet "foran". Så nu har du et stabilt erlang-system men databasen der er koblet til, der kører oracle er det nok ikke. Så det er i bedste fald en "løsning". Du kan naturligvis sætte en watchdog fra Erlang-systemet på Oracle-dyret, men det hjælper ikke altid.

Så moralen er at nok får du hjælp fra Erlang-systemet men du skal have styr på hvad din applikation gør selv for at gøre det sikkert. Og ikke mindst teste for det.

  • 0
  • 0
#17 Kurt Mielke

Med alt respekt, så er dette altså flueknepperi i en grad så det nærmer sig egentlig misbrug:-) Der er godt styr på sagen hvis man kører NTPv3 (RFC1305 fra 1992). Det håndteres ved at der sættes et flag, som betyder at det tager to sekunder at komme fra 23:59:59 til 00:00:00. Der er så to muligheder: Enten understøtter ens kerne det, og så opleves det bare som om den er 2 sekunder om det ene sekund, dvs tiden opskrives langsommere. Understøtter kernen det ikke, vil NTP langsomt skubbe tiden, så man oplever altså ikke tidsspring.

Så jeg mener ikke det er nødvendigt at teste almindeligt software hvis blot det tror på den tid som OS oplyser. Egentlig tidskritisk software, skal jo i forvejen være robuste over for justeringen at OS' ur. Så er der det med forskelle i tiden mellem maskiner. Hvis man synkronisere dem til de samme servere, går det nok. Har man maskiner på den Amerikanske vestkyst og i Østasien, så er der alene på grund af afstanden en forskel i tid på op mod 100 ms, så her må man i forvejen være forberedt på tidsforskelle.

På Unix løser man skudsekunder ved at flytte alle skudsekunder hen til 1970, så der er altid 86400 sekunder i et døgn (UTC). GPS har en tæller for skudsekunder, er vist på 19 sekunder på indeværende tidspunkt, så man skal nok ikke forvente nogen kører forkert i en sen nattetime til sommer! Med fare for at nedkalde hybris over sagen, vil jeg bare ønske PHK god ferie til sommer:-)

Om NTP: http://www.ntp.org/ntpfaq/NTP-s-algo-real.htm (sekt. 2.4 + 5.3.4)

  • 3
  • 0
#20 Leif Neland

På Unix løser man skudsekunder ved at flytte alle skudsekunder hen til 1970, så der er altid 86400 sekunder i et døgn (UTC). GPS har en tæller for skudsekunder, er vist på 19 sekunder på indeværende tidspunkt

Jeg kom 15 sekunder for tidligt i mål i weekenden, (i en diciplin, hvor man skal gennemføre en vis strækning med en vis hastighed,) fordi jeg brugte min GPS-app som ur; den korrigerer åbenbart ikke for skudsekunder.

  • 0
  • 0
Log ind eller Opret konto for at kommentere