Skudsekunder er for dyre...

Der er kommet et blogindlæg fra Googles driftgruppe, om hvorledes de har tænkt sig at klare fremtidige skudsekunder:

[...]we applied a patch to the NTP server software on our internal Stratum 2 NTP servers to [...] tell a small “lie” about the time, modulating this “lie” over a time window w before midnight: lie(t) = (1.0 - cos(pi * t / w)) / 2.0 [...] The leap smear is talked about internally in the Site Reliability Engineering group as one of our coolest workarounds, that took a lot of experimentation and verification, but paid off by ultimately saving us massive amounts of time and energy in inspecting and refactoring code. It meant that we didn’t have to sweep our entire (large) codebase, and Google engineers developing code don’t have to worry about leap seconds.

I praksis betyder det, at Googles servere vil være op til et halvt sekund forkerte i forhold til UTC tid.

Inden nogen siger "so what", er det værd lige at pege på en detalje som de fleste her overser:

I Europa sker skudsekunder midt om natten, ofte midt på den mest alkoholiserede nat på året. I Tokyo eller Los Angeles falder skudsekunder indenfor arbejdstiden.

Teknisk er Googles løsning det vi kalder "gummisekunder": Man forandrer længden af nogle sekunder for at slippe for at se uret vise 23:59:60.

Problemet med den slags tidsskaler er at man ikke kan bruge dem generelt: Hvis man måler halveringstiden af en radioaktiv isotop, eller bølgelængden af noget lys indenfor tidsvinduet "w", får man en anden værdi end resten af året.

I tresserne, længe inden computere var forbundet sammen i netværk, var gummisekunder den officielle måde at håndtere jordens urolige rotation på.

Det virkede ikke, det var derfor man indførte skudsekunder til at begynde med.

Men Googles driftsmiljø kendetegnes ved en meget stor og meget hårdt styret homogenitet. Der er ikke noget med 17 forskellige fabrikater og 18 forskellige hot-lines og derfor kan de få en sådan løsning til at virke for sig selv.

Googles størrelse betyder at det må resten af verden så bare finde sig i.

Hvad med heterogene miljøer ?

ATC systemer er meget heterogene: Radar'en kommer fra et firma, collision-detection and avoidance softwaren fra et andet firma, konsolsoftwaren fra et tredje og de VoIP baserede radioer fra et fjerde.

Flyene kommer naturligvis alle mulige steder fra, med en hastighed op til 300m/s:

Illustration: Privatfoto

Hvad med Googles selvkørende bil ?

Tør de køre rundt i den, midt i Tokyo, under et skudsekund, uden hænder ?

Hvad med koordinerede industrirobotter der bevæger sig op til 8m/s ?

Det er ikke alle der er så heldige som Google...

Men jeg er glad for at Google kommer på banen og siger klart: Skudsekunder er for dyre for os.

Det havde værret mere interessant hvis de havde inkluderet et numerisk estimat af hvad det ville have kostet dem at implementere skudsekunder korrekt i deres software.

Baseret på min egen og andres erfaring, har de, inklusive test og validering sparet mindst et mandår per applikation og mindst et mandår per real-time dataudveksling.

Det er nok noget i den stil de kalder "massive amounts of time and energy".

phk

PS: Nej, jeg ved stadig ikke om Danmark stemmer og hvad vi i givet fald stemmer om skudsekundernes fremtid til februar i ITU-R. Giv ITST et ring hvis du har en holdning.

PPS: Min artikel i ACM Queue og Communications of the ACM om skudsekunder.

Kommentarer (19)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Mikael Boldt

Og skulle vi - mod forventning - være i live kan vi jo bare lade være med at stille urene tilbage til normaltid den sommer.

Når vi nu ønsker at rejse ud i verdensrummet, så kan vi ikke længere bruge skudsekunder til noget! Fremmed væsner vil måske kunne forstå at tid måles med nogle svingninger i et specificeret atom, men at forklare at rotationen af vores lille jordknold skal korrigere målingen er absurd.

PS. Vidste du at i følge den muslimske overbevisning starter døgnet ved sol-opgang, hvilket sammenlignet med vores definition af døgnet gør korrektion af urene til en daglig beskæftigelse.

  • 2
  • 0
#2 Jimmy Krag

Er det mig, eller er der noget galt i den her illustration?

23:59:57       23:59:57         23:59:57  
23:59:58       23:59:58        23:59:58  
23:59:59       23:59:59        23:59:59  
23:59:59       00:00:00        (halt for 1 sec)  
00:00:00       00:00:00        00:00:00  
00:00:01       00:00:01        00:00:00

Burde de ikke alle ende på 00:00:01?

  • 0
  • 0
#4 Morten Andersen

For det første er det underligt at Google roser deres idet som "one of our coolest workarounds". Det er jo som PHK er inde på et tussegammelt koncept med gummisekunder og samme koncept har været anvendt til at håndtere sommetider m.m. Desuden forstår jeg ikke motivationen for at anvende cos() til gummisekunderne... det er jo en relativt dyr operation og den giver noget ujævnt "gummi" - hvorfor ikke bare:

(t/(w/2)) / 2.0

hvor t/(w/2) jo også går fra 0 til 1, når t går fra 0 til w/2.

  • 1
  • 0
#6 Morten Andersen

Poul, men hvorfor gør det cos() foretrukken frem for div?

iøvrigt er deres udtryk lig sin^2(tpi/(2w)) hvor 2*w jo kan beregnes på forhånd... de kan således spare én minus operation og bytte en division til en multiplikation. Gad vide om de smarte fyre hos Google har tænkt på det ;)

  • 0
  • 0
#8 Maciej Szeliga

man finder en måde at måle tid på (cesium) derefter prøver man at tilpasse denne til jordens barske virkelihed.

Ummiddelbart bør man måske finde en uafhængig måde at måle tiden på til kritiske ting (som f.eks. ATC) i stedet for at bruge den tid som passer med solen (og som derfor skal korrigeres) og nej, UTC er ikke svaret. ATC burde f.eks. have en tæller (synkroniseret mellem alle ATC anlæg) så man kunne sige at ved tællerstand TTTTTT er flyet på XXX,XX:YYY,YY:ZZZZZZZ. Desuden skal man gemme UTC for hver 1000 ticks af tælleren.

  • 0
  • 0
#9 Niels Danielsen

Det er egentligt lige meget om skud sekundet falder om natten eller om dagen, det er et problem især for realtids kontrolsystemer der også foretager logning af events og historiske data.

Det er også min erfaring at systemer bliver mere og mere afhængige at ’global time’, og hvor uret i der kontrol system for 10-20 år siden blot blev brugt til logning af events (og det faktisk kunne stå til hvad som helst uden at have indflydelse på processen), påvirker det i dag processen.

Et andet problem er at den ’globale tid’ migrere længere og længere ned i kernen af systemet, derfor kan tids diskontinueritet få effekt for systemet. F.eks. er der systemer der har en software PLL der modificere interrupt prescaler registeret således at scheduleren kommer i sync. (fase) med NTP. Årsagen til dette er at reducere jitter mellem noder i kontrol netværk, og synkronisere statistik på tværs af noder. Dvs. Wall clock og clock ticks overlapper mere og mere og ’man’ forventer at de kan blandes.

PHK din ide med at forberede skudsekunder 20 år frem, er udmærket, men løser ikke alle problemer. Hvis du i dag skriver under på et 30 årig obligations lån, som skal løbe fra 2011-09-19 00:00:00 til 2041-09-19 00:00:00

Så vil der så stå noget andet på computeren om 30 år, f.eks: 2011-09-19 00:00:00 til 2041-09-18 23:59:30.

Jeg tror at vi generelt skal udvide vores tid lagrings format til altid at være baseret på TAI + TZM (’Time Zone Modifier’). Ved at sikre at hvert eneste lagret tids stempel ALTID indeholder en TZM kan tiden beskrives på lognings/indtastnings tidspunktet som feks:

<Earth_Julian, TZ=UTC+60m, DST=+60m, UTC-TAI = -34 s>

<Mars, some other marsian time system stuff >

Det betyder at hvis man idag skal beskriver en event frem i tiden, og bruger TAI + TZM så er det muligt at dekode informationen korrekt ud fra den kontekst det skal bruges i. Det er f.eks. altid muligt at komme tilbage til det den tid som oprindelig er blevet registeret, det er det f.eks. ikke med Unix time.

Man kan også ændre TZ, DST, og UTC-TAI alt det man lyster, det ændre ikke på hvordan systemet køre, kun på hvordan tid udlæses.

TAI+TZM løser mange problemer - Ekvidistant, monotonisk tid - Bibeholder muligheden for at udlæse i ’lokal astronomisk jord tid’ - Mulighed for at regne med tids differencer - Mulighed for at udlæse i ’Oprindelig lokal tid’, ’Nuværende lokal tid’, eller et andet format der bruges på en anden planet.

Dem der evt. vælger at flytte på Mars kan anvende et tids system der er baseret på noget helt andet end Timer, Minutter, Dage, Måneder, og år. Det betyder at der ikke vil være nogen forvirring over hvornår der skal betales afdrag på den rumfærge man har købt på klods for at komme til Mars :-)

  • 1
  • 0
#11 Thue Kristensen

Det er da åbenlyst for enhver, at man skal sætte computerens ur til TAI. I modsætning til UTC og lokal tid, så er TAI jo lineær. Hvis man så skal vise en tid for en slutbruger, så tilføjer man skudsekunder og tidszone.

Uheldigvis så blev der ikke lige tænkt på det, da de lavede POSIX...

Problemet er nu, at vi ikke praktiskt kan konvertere alle computere i version til at bruge TAI.

Ulempen ved skudsekunder er meget stor, med uforudsete computerfejl. Ulempen ved at dagen forrykker sig en smule er ret lille; hvis forskellen bliver for stor, så kan vi jo bare skifte tidszone. Så et grimt men pragmatisk hack er at holde op med at tilføje skudsekunder.

  • 0
  • 0
#13 Niels Danielsen

Problemet er nu, at vi ikke praktiskt kan konvertere alle computere i >version til at bruge TAI.

Du har ret i at vi ikke overnight kan opdatere all computere, og specielt ikke dem der driver SCADA installationer og lign. da det somregl er et cluster fuck af ting der kun kan køre på Windows 2000 eller ældre. Men de bliver normalt opdateret med en 10-15 års mellemrum.

Man kunne jo starte med at: 1) Udvide NTP til at propagere TAI samt UTC-TAI offset. 2) Udvide operativ system API'er til at håndere TAI. 3) Definere standarder for tids formater indeholdende TAI + TZM, for over the wiere communication, XML etc. 4) Lave standard biblioteker til de udbredte sprog til at håndere dette.

Men allerede efter punkt 1, kan brugerne efter opdatering af deres NTP client vælge om de vil køre system tiden som UTC, eller hacke den til TAI. Problemet er selvfølgelig at herefter er systemet vel egentlig ikke posix længere, hvilket kan give problemer ved systemer der er programeret til at bruge/udnytte skud sekunder korrekt (meget få), eller systemer i et netværk der ved et uheld bliver konfigureret forskelligt.

  • 0
  • 0
#17 Thue Kristensen

TAI er en videnskabelig papir-tids-skala, den foreligger først nogle uger senere. Der er ingen officielle metoder (radio/gps/internet) til at få den spredt.

Det jeg mente med "I teorien" i min post ovenfor var, at sådanne ting som en standard for at distribuere TAI over NTP ikke er på plads. Plus at alt software skulle omskrives.

Min pointe var, at hvis man startede fra nul, så ville TAI være den åbenlyst rigtige tid at bygge på, da TAIs lineære tid ville give mere robuste systemer.

  • 0
  • 0
#19 Theis Blickfeldt

Man burde genoverveje definition fuldstændig. Hvor hurtigt tiden faktisk bevæger sig er helt og aldeles afhængigt af tidsvektorfeltet relativt til massekoncentration i og omkring feltet. Tiden bevæger sig hurtigere stedet hvor massekoncentrationen er lav. Fx. skal NASA indfører ca. 1ns ekstra hver dag, på satellitter som orbiterer omkring jorden, for at kompenserer for den lavere massetæthed i rummet, ved den enkelte sattelits respektive afstand til jorden. Bidraget til massetætheden på jorden, som kommer fra selve jordkloden, er nogenlunde konstant over hele overfladen. Men afstanden til solen (Som er den næstmest bidragende faktor til massetætheden på jorden) divierer meget, og derfor bør man i højere grad forsøge at opstille en matematisk model, som inkluderer massetætheden (udregnet på baggrund af afstanden til solen), til at finde den rigtige længde af hver enkelt sekund, istedet for at kompenserer med skudsekunder eller indsættelse af gummisekunder, som reelt set er det samme for tid, som interpolering er for digitale fotografier.

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