Verden kører videre: Det frygtede sekund var ikke så farligt endda

I det store hele ser det ud til, at it-verdenen havde styr på at håndtere det ekstra sekund, der blev indsat i nat efter kl. 01:59:59 dansk sommertid. Men helt glat gik det dog ikke.

Af de godt 500.000 netværk kloden over, der er forbundet med hinanden via internettets globale routing tabel, gik omkring 2.000 ned umiddelbart efter, skudsekundet blev indført.

Læs også: Natten forlænges mellem 30. juni og 1. juli

Det oplyser Doug Madory fra analysefirmaet Dyn til PC World.

Halvdelen af disse netværk havde hjemsted i Brasilien, og det kan indikere, at tjenesteudbyderne bruger samme type router, som ikke har været sat op til at håndtere skudsekundet, oplyser Doug Madory.

De fleste netværk kom dog hurtigt i drift igen, så skaden var begrænset.

Samtidig med, at de 2.000 netværk gik ned, indtraf en ekstraordinær stor aktivitet i Border Gateway Protocol (BGP), som styrer forbindelserne på internettet.

»Det kan ikke være et tilfælde,« siger Doug Madory.

Ingeniørens blogger Poul-Henning Kamp, der er ekspert i skudsekundernes betydning for internettrafikken, oplyser, at det bevirkede, at Reddit ikke kunne nås fra Danmark.

Der dog endnu ikke rapporteret om meget kritiske fejl i forbindelse med skudsekundet.

Skudsekundernes fremtid skal afgøres til november

Når skudsekundernes fremtid på ny skal diskuteres og afgøres på World Radiocommunication Conference til november, vil modstandere og fortalere for skudsekunderne uden tvivl henvise til erfaringerne med at implementere skudsekundet i år.

Fortalerne for skudsekunder vil pege på, at det jo stort set gik smertefrit. Så hvorfor ikke bevare dem, og lade tiden være styret af astronomiske hændelser, som det altid har været tilfældet?

Modstanderne vil nævne de problemer, der trods alt var, og ikke mindst det store besvær, der har været med at undgå, at problemerne blev større - og det betydningsløse i, om Solen står højest på himlen på Greenwichmedianen kl. 12:00:00 eller 12:00:01.

sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først

Det er faktisk tænkeligt at John Oliver har reddet skudsekundet.

I bund og grund har problemet altid været at folk ikke har haft opmærksomheden på det.

John Oliver har vist at det langt hen ad vejen kan lade sig gøre at få opmærksomheden rettet derhen.

En anden lille detalje er at alle dem der kører Linux med systemd muligvis har fulgt Googles "udtværede" skudsekund uden at vide det:

https://github.com/systemd/systemd/issues/437

  • 2
  • 0

"og det betydningsløse i om Solen står højest på himlen på Greenwichmedianen kl. 12:00:00 eller 12:00:01."

Jens, du burde vide bedre :-)

Det sker maksimalt fire gange om året at et givet punkt har solen i syd i det sekund der omslutter middag.

(Fire er det maksimale antal gange en ret linie kan krydse et analemmas "8-tals" kurve).

Grunden til 1-sekund tolerancen imellem jord-rotation og UTC var at skibe der navigerede efter stjernerne skulle kunne bruge tiden som proxy-mål for jordens orientering i rummet.

Derfor byggede man langbølgesenderne med tidssignaler (WWVB, DCF, Rugby osv)

Siden da er der sket en meget vigtig ting: Kvartz-styrede ure.

Først når man har været til havs uden nogen form for kommunikation i over 18 måneder bliver den akkumulerede usikkerhed så stor at man skal til at være forsigtig.

Hvis man ved at der i gennemsnit kommer et skudsekund hver 18 måneder, kan man plaske rundt i op imod 10 år før man risikerer at ramme et skær i mørket.

Og mht til hele "solen i syd til middag" argumentet, er det værd at huske at hele Kina er en enkelt tidszone hvor solen kan være op til næsten 3 timer "forkert".

Her i landet er det kun på en stort set ubeboet linie på Bornholm og kun udenfor sommertiden at solen står i syd til frokost.

  • 16
  • 0

Nu har der været ca. 25 skudsekunder siden begrebet blev indført engang i starten af 70'erne.

Hvordan kan det være, at det stadig er et problem at håndtere it-mæssigt?

Jeg mener: Hysteriet omkring Y2K kunne jeg - måske - forstå. Det var en 'once in a lifetime event'. Men en begivenhed, der indtræffer med - ok uregelmæssige - mellemrum?

Burde det ikke bare være 'just another day at work'? Eller er det et tegn på manglende rettidig omhu?

  • 6
  • 1

Samtidig med, at de 2.000 netværk gik ned, indtraf en ekstraordinær stor aktivitet i Border Gateway Protocol (BGP), som styrer forbindelserne på internettet.

»Det kan ikke være et tilfælde,« siger Doug Madory.

Det håber jeg da ikke det var, hele pointen i BGP er at den skal være selvhelende i sådan en situation :)

  • 0
  • 0

Hvordan kan det være, at det stadig er et problem at håndtere it-mæssigt?

Indtil internettet var tidssynkronisering ikke noget man brugte.

I en mainframe installation bestemte mainframen hvad klokken var og så var man færdig med den detalje.

Desværre exploderede internettet ud over verden i netop den periode hvor der ingen skudsekunder var, 1998-2005 og da IT branchen samtidig blev hen ved 1000 gange større, og ingen af disse ny folk havde nogen faglig baggrund, var der ingen der tænkte proaktivt på skudsekunder.

  • 10
  • 0

Indtil internettet var tidssynkronisering ikke noget man brugte.

I en mainframe installation bestemte mainframen hvad klokken var og så var man færdig med den detalje.

Desværre exploderede internettet ud over verden i netop den periode hvor der ingen skudsekunder var, 1998-2005 og da IT branchen samtidig blev hen ved 1000 gange større, og ingen af disse ny folk havde nogen faglig baggrund, var der ingen der tænkte proaktivt på skudsekunder.

Til forskel for det nævnte y2k og det kommende år 2038 problem, så skal der dertil lægges at det er med relativt kort varsel (seks måneder) at skudsekunderne annonceres.

Så en funktion som localtime(3) skal enten opdateres inden for det givne varsel, hvilket man nok ikke har lyst til særligt mange steder - eller have forbindelse til en server den er nødt til at stole på for at få kendskab især kommende skudsekunder.

(3) https://en.wikipedia.org/w/index.php?title...

  • 0
  • 0

Sommertid er nemt, det er bare et tidszone skift.

Problemet med skudsekunder er at man ikke lige kan se om forskellen mellem kl. 23:30:00 og 00:30:00 er 3600 eller 3601 sekunder uden at konsultere en ekstern, manuelt opdateret database og så regne på om man ramte hen over skudsekundet.

  • 1
  • 0

Men hvad mener du med "måske" kunne forstå, angående Y2K

Det jeg mente var, at Y2K problemet var uprøvet land, og at man måske derfor kunne være bekymret.

Jeg havde selv 'fornøjelsen' af at stå for ledelsen af en tværorganisatorisk arbejdsgruppe i en større dansk/europæisk service- og industrivirksomhed, hvor opgaven var, at sikre virksomheden mod problemer med Y2K.

Min mavefornemmelse dengang var: Tjek alle 'mission critical' installationer, sørg for at vagttelefonerne er bemandede - og glem så alle de andre installationer. Der sker sg* nok ikke noget alvorligt. Virksomhedens jurister var ikke helt tilfredse med den anbefaling. De tænkte allerede i erstatningssager osv.

Men ok, omkostningerne ved at gå alle installationer igennem til mindste detalje kontra omkostningerne ved eventuelle fejl, overbeviste dem dog.

Men som sagt: Y2K var en en-gangs ting - i hvert fald lige indtil 2038, men her er der dog 'fair warning'. Men efter ca. 25 skudsekunder fordelt over de sidste ca. 30 år burde systemerne og procedurerne vel være på plads? Hvilket artiklen her vel også stort set bekræfter.

  • 2
  • 0

Men ellers synes jeg da, det lyder mest fornuftigt at droppe hele systemet. Behold den tidsstandard der er baseret på et eller andet atoms svingninger, og så bare 'kør der uud a'. Jordens rotation om sig selv er en alt for unøjagtig tidsreference, når vi skal ned på en præcision på sekund-basis.

Hvornår solen står højest over Aakirkeby plus/minus et minut eller to betyder nok ikke noget i den store sammenhæng, og så kan man slippe for et pseudo-problem.

PS: Det er i øvrigt sjovt nok, når PHK skriver, at det først er med internettets udbredelse at problemet opstod. Det svarer lidt til, at det var ved jernbanens indførsel, at de enkelte stationsbyer mistede deres lokale tid som defineret ved det lokale kirketårnsur.

  • 5
  • 0

Navigatører og videnskabsfolk har altid regnet med korrektioner. De tror ikke på absolutte værdier - og er derfor glade for pålidelige korrektioner, som giver dem den ønskede, nødvendige, nøjagtighed.

Nøjagtig tidsmåling, eller egentlig en tidsmåling som blev nøjagtig ved anvendelse af en kendt korrektion, startede til søs for at kunne beregne positioner. Strengt taget er det ligegyldigt hvad uret viser OG om set vinder eller taber - bare jeg kender korrektionen (som også har en tidsfaktor: urets "gang", dvs. uret vinder / taber x sekunder per døgn.

Jernbanetog, som følger er køreplan, stiller krav om synkroniserede ure - på afgangsstedet. Sådan startede det i USA. Hvad uret viser er mere en konvention end et krav. Men, i modsætning til navigatøren som er vandt til korrektioner, så vil andre nok foretrække en fælles konvention og synkrone ure (med en acceptabel variation i forhold til formålet).

I moderne tid begynder meget nøjagtige ure pludselig at få betydning - vores moderne elektroniske infrastruktur, videnskabeligt til måling af forskellige fænomener (jordskælv for eksempel). Men det har intet at gøre med solen kulmination eller lignende.

Så den verdensomspændende korrektion i nat er mere bekvemmelighed og vane. De som virkelig er afhængig tiden kunne sagtens bruge en korrektion. Og navigatøren, som vi startede med, han får aligevel nye tabeller hvert år, så de skal bare udlægges efter den vedtagne tid.

P.S.: jeg kiggede på min GPS i aftes (ganske vist gammel), men den talte lystigt :58, :59, :00, :01 ....... Se DET er et interessant problem. Men da jeg ikke har en sekundær, absolut, reference, så ved jeg ikke hvor mit skudsekund er henne ...... Måske ER tiden rigtig, nu, efter sluk-i-nat, tændt igen .... (Note, for at imødegå smarte bemærkninger: tiden på en GPS er beregnet i apparatet; den er IKKE sendt fra satelliterne. Tiden, og bredde, længde og højde er de 4 løsninger på GPS-beregninger - forudsat mindst 4 satellitter er synlige).

  • 2
  • 0

Men ellers synes jeg da, det lyder mest fornuftigt at droppe hele systemet. Behold den tidsstandard der er baseret på et eller andet atoms svingninger, og så bare 'kør der uud a'. Jordens rotation om sig selv er en alt for unøjagtig tidsreference, når vi skal ned på en præcision på sekund-basis.

Behøver vi ikke et tidsbegreb, der ikke påvirkes af skudsekunder?

Hvordan skal vi trække to tidspunkter fra hinanden, hvis der er indsat et skudsekund? Og hvad er resultatet?

Hvis skudsekunder påvirker selveste tiden, må vores fysiske regler ikke gælde i skudsekund øjeblikket.

  • 3
  • 1

PS: Det er i øvrigt sjovt nok, når PHK skriver, at det først er med internettets udbredelse at problemet opstod. Det svarer lidt til, at det var ved jernbanens indførsel, at de enkelte stationsbyer mistede deres lokale tid som defineret ved det lokale kirketårnsur.

Analogien er ikke helt ved siden af, men heller ikke helt lige i øjet.

Riskoen ved skudsekunder skulle i givet fald svare til at man i den ene by havde husket at skifte til sommertid, mens den anden ende af den enkeltsporede jernbane havde glemt det.

  • 2
  • 0

Desværre exploderede internettet ud over verden i netop den periode hvor der ingen skudsekunder var, 1998-2005 og da IT branchen samtidig blev hen ved 1000 gange større, og ingen af disse ny folk havde nogen faglig baggrund, var der ingen der tænkte proaktivt på skudsekunder.

OK. I 1998-2005 var der ingen skudsekunder. Det antyder, at der i perioden 2005-2015 har været andre skudsekunder end det i nat.

Og så er vi jo tilbage ved Rolf Andersens spørgsmål: Hvordan har disse andre skudsekunder været håndteret, og hvorfor forventede man, at skudsekundet i nat skulle udgøre et større problem?

  • 1
  • 0

En anden lille detalje er at alle dem der kører Linux med systemd muligvis har fulgt Googles "udtværede" skudsekund uden at vide det:

https://github.com/systemd/systemd/issues/437

Det er ikke helt rigtigt.

Hvis du læser lidt længere ned i den bugreport, så vil du se at systemd-udviklerne står meget fast på at brugen af Google's tidsservere kun er til intern systemd-test, og at alle brugere (e.g. distributioner) skal rette den setting til at bruge deres egne tidsservere (e.g. arch.pool.ntp.org). Og sådan er det også sat op på min Arch-desktop.

  • 0
  • 0
Bidrag med din viden – log ind og deltag i debatten