Svenska ElektronikForumet

Läste denna artikel:
ACM: The One-Second War av Poul-Henning Kamp 2011

Artikeln visar de problem som användandet av skottsekunder orsakar. Mycket just för att planetrörelser och sekunder inte går jämnt upp. Samt att många program antar att en minut är 60 sekunder lång inte 59, 60, 61 beroende på när den inträffar.
Sådant kan vara problematiskt för flygplan som rör sig 300 m/s i tätt packade luftkorridorer eller produktionslinor där robotar måste jobba synkront.

Fundering: Är detta något som du själv stött på som ett problem? klarar ditt program av att epochklockan ändrar sig under körning?

Nej, det har inte varit ett problem för mig ännu.

Jag skummade genom artickeln och förstod vad han försökte säga. Men jag förstod inte de exempel han drog upp.

När han pratar om flygplan som färdas 300m/s och att man gör anti-kollistionstester flera gånger per sekund så spelar väl inte en skott-sekund någon roll? Om man har sin time_t räknare eller egenhändigt hackade räknare och skickar sin signal 1 eller 10ggr/ sekund så struntar väl både flygplanet och kontrolltornet om denna sekund kallas 1a jan eller 10 maj?

Det andra exemplet om att thoshibas fabrik krachade pga en 70msek långt spänningsfall har väl inte med skottsekunden att göra? klart att alla system måste startas om, synkas med varandra etc efter att strömmen gått. Men när systemet väl är uppe, är det ett problem då?

Oftast när jag jobbat med syncade microkontrollers brukar det i första hand vara mycket kortare perioder än 1sek. Dessutom brukar jag använda mig av en räknare som räknar sekunder som man därefter omvandlar till minuter, timmar dagar mm för att läsa av när saker och ting hände (time_t precis som nämnts i artickeln)
Det är väl ofast människan som behöver ha koll på dag, år, timme sekund. medan maskinen vet att det gått t.ex 104631 sekunder sedan 1970. Omvandlingen som sker brukar oftast användas för att visa oss människor när något hänt eller ge en tidsstämpel i en fil.
Om man skulle gjort tvärtom, hållit koll på timmar, dagar mm och därefter räknat ut vilken sekund det är och försökt synka mot denna skulle jag kunna förstå att det blir fel.

Men jag kanske missat något i mitt resonemang?

Nej, jag tror nog att du har rätt, man brukar inte synka utrustning enskilt, man har naturligtvis en master som man synkar mot.
Dessutom är det sällan man synkar mot realtiden, utan mot interna räknare.
Realtiden som sådan är för det mesta rätt ointressant, utan används för det mesta för tidsstämpling.

Detta med flygplanen är faktisk ett fullt seriöst scenario! Det experimenteras sedan ett tag med att låta bli att ha flygkorridorer med tighta scheman och istället skapa ett system där flygplanen beräknar deras position en bit fram och sedan meddelar andra flygplan om detta. Om två (eller fler) flygplan understiger den säkerhetsavstånd som ska finnas ska systemet se till att de styr fri av varandra och de kan sedan stega tillbaka i deras planerade rutt och finputsa lite så det blir bra och "mjukt". Systemet är i övrigt uppfunnit av Håkan Lans efter vad jag minns.

Och då kan ett sekund här eller där ha en viss betydelse!

Men det jag roar mig lite över är just den mentalitet jag ser här: "men det är väl inget problem?"
Svaret är: "oftast inte!"

Men vad OM ett skottsekund kan vara av stor betydelse?
Har vi analyserat systemet bra nog för att veta OM et skottsekund kan bli ett problem?
Har vi skrivit mjukvaran till att, på ett stabilt och säkert sätt, kunde acceptera ett skottsekund?

Det är i grunden det samma som "millenumbuggen": ingen betydelse alls för långt störste delen av alla system - men i vissa system kan det bli oväntade händelser (dela med noll eller annat skit) och om dessa system är vitala - vad händer då?

Det var ju väldigt många unix-servrar som dog av skottsekunden i år.
Har för mig det berodde på någon bugg i ntp-paketet.

Den typen av utrustning finns redan på alla större flygplan. Jag är ganska säker på att den går på GPS tid. Det är en egen tidbas.

Icecap skrev: Och då kan ett sekund här eller där ha en viss betydelse!

Visst, men skottsekund innebär inte att en dators sekundräknare plötsligt tar ett kliv på 2 sekunder istället för en sekund. Det innebär att om sekundvärdet n motsvarar tidpunkten 14:35:12 så motsvarar sekundvärdet n+1 14:35:14.

Inte riktigt samma typ av leap-seconds, men men.

På mitt förra konsultuppdrag fick vi problem med att GPS-tiden plötsligt hade glidit 16 sekunder.
Hur kom det sig när det fungerat stabilt i så många år?

Den 30 juni i år behövde man lägga till ytterligare en sekund till GPS-tiden, vilket är nu totalt 16 sekunder.
Har man då bara tillägnat fyra bitar för detta så slår det plötsligt runt..

Icecap, sjävlklart är det viktigt att alla flygplan är syncade med varandra men vart finns kopplingen till skott-sekunden?
Menar du att det system som beräknar flygplanens possition använder sig av tid på formatet timmar, dagar, minuter och sekunder som tidbas? Det är som sagt mest funderingar från min sida eftersom jag inte är helt insatt i exakt hur tids-synkroniseringen sker. Det hela verkar väldigt ologiskt.

Jag är kritisk till inställningen att alarmera om saker som kanske är ett problem där man själv inte är helt insatt i systemet.
Ska man sitta och gissa vilka buggar som finns i alla kritiska system och alarmera hela välden om att det kanske är ett problem? Om man ska göra detta skulle jag gärna vilja ha en koppling med en ev lösning till problemet.

Jag har i ett SW projekt varit tvungen att sortera data som i princip kunde ha 3 olika tidbaser; windows tid (vad nu det var, minns inte), GPS tid samt en proprietär bas som startade år 2000. Det var inte lätt med alla dessa skottdagar, skottsekunder och whatnot! Iofs inget "mission critical" kod det var fråga om, men det skulle ju fungera korrekt.

Oj, en hel sekund!
Jag fixade ett "fel" i förra veckan i ett produktionssystem
där *hela 2013* saknades i en intern kalender...

På tal om... på ett tidigare jobb...
En stor kund frågade om vår produkt var y2k kompatibel... "Visst, absolut." sa vi självsäkert, koden använder ju knappt någon tidsfunktion. Väl tillbaka på officet testade vi, ingen hade ju brytt sig om att testa nåt sånt tidigare. Visade sig att y2k inte fungerade, faktiskt gick det fel vid varje årsbyte, eller rättare sagt, problemet var att varje månadsbyte gick det fel. Doh!
Test ansågs inte så viktigt då ännu på firman.

Jag lärde mig mycket på den firman, men primärt lärde jag mig hur man *inte* utvecklar mjukvara.

dangraf: skottsekunden som sådan ser jag inte som något större fel eller problem men om man använder en fel formel i någon beräkning och någon gång behöver att räkna med 12:34:60, vad händer då?

"Faran" är inte ett sekund hit eller dit, om alla bara är överens om när klockan är vad, det besvärliga är om man räknar fel. Tar man flygningen med "självplanerande rutter" kan det betyda att en uträkning på när ett flyg befinner sig på en viss plats fram i tiden kan bli helt jävla fel om detta extra sekund t.ex. ger ett negativt värde eller liknande.

Själv skulle jag vara intensivt likgiltig om min dator hickar till och flyttas 1 sekund i tid, jag skulle med extrem sannolikhet inte ens märka det men hade jag en uträkning som utgick från att ett dygn består av ett fast antal sekunder kan jag tänka mig att vissa uträkningar kan gå fel.

Och det de skriver i artikeln är: tänk fram, planera efter om det kan behövas i det projekt man håller på med, behövs det är det bra att kunde reagera rätt.

mri skrev:Jag lärde mig mycket på den firman, men primärt lärde jag mig hur man *inte* utvecklar mjukvara.

Vilka andra lärdomar fick du?

Icecap skrev:dangraf: skottsekunden som sådan ser jag inte som något större fel eller problem men om man använder en fel formel i någon beräkning och någon gång behöver att räkna med 12:34:60, vad händer då?

"Faran" är inte ett sekund hit eller dit, om alla bara är överens om när klockan är vad, det besvärliga är om man räknar fel. Tar man flygningen med "självplanerande rutter" kan det betyda att en uträkning på när ett flyg befinner sig på en viss plats fram i tiden kan bli helt jävla fel om detta extra sekund t.ex. ger ett negativt värde eller liknande.

Inom flyget har man alltid minst dubbla oberoende system, så av ett så enkelt fel händer där inget, i den här situationen hade radarkollisionssytemet varnat i god tid.

De säkraste flygplanen som har funnits i historien är Airbus och Boeings helt mjukvarustyrda fly-by-wire (A330, A340, Being 777), ungfär 20 år var de modellerna i tjänst innan första dödsfallet, planet från Brasilien som störtade i Atlanten. Och det berodde inte på för mycket dator utan snarare på för lite, hade inte styrsystemet varit programmerat för att överlåta kontrollen åt piloterna vid undantaget att alla pitotrören är ur funktion så hade det antagligen gått bra eftersom att instruktionerna i manualen är väldigt enkla vid den här typen av situation: typ 70% gas och nos 5% uppåt tills dess att fartinformationen återkommer.