Tekst: Per André Horpen
Enkelte synkroniseringsmetoder er gratis, men da skorter det på nøyaktigheten.
Les også: Klokkesynkronisering med eksterne tidsservere
Enkelt med NTP
Andre løsninger har en høyere investeringskost, men det gir økt presisjon.
Vi starter med NTP (Network Time Protocol), en standard måte å synkronisere klokker på. Den spiller både på intranett og internett. Løsningen har enkelt oppsett, og NTP-klientsoftware er inkludert i de fleste operativsystemer. NTP kan kjøre på to forskjellige måter.
Les også: Slik perfeksjonerer du påliteligheten i industrielle nettverk
Beregner offset
Den mest brukte og mest nøyaktige måten går ut på at NTP-klienten regelmessig forespør serveren om tid, for å holde seg synkronisert. Klienten spør en eller flere servere om korrekt tid (t1), se figur. Serveren får forespørselen (t2) og sender klokkeslettet tilbake til klienten (t3), som klienten så mottar (t4).
Den tiden det tar fra klienten spør om korrekt tid, til den mottar svar fra serveren, er tiden det tar for dataene å reise frem og tilbake mellom klient og server. Klienten beregner så sin offset ifra serveren, ved å bruke følgende algoritme:
O = ((t2-t1)+(t3-t4))/2
Les også: Slik øker du påliteligheten i industrielle nettverk med funksjonaliteten i switchene
Kompenserer for reisetid
Kort forklart tar klienten den totale reisetiden til og fra serveren og deler den på to, hvilket gir datapakkens reisetid, én vei. Klienten tar reisetiden, legger til det klokkeslettet som serveren sendte, og bruker dette som korrekt tid. For å gi et eksempel: Dersom reisetiden var to sekunder frem og tilbake, så beregner klienten at reisetid én vei var på ett sekund.
Om avviket mellom klientens interne klokke og serverens klokke er liten, vil klienten øke eller senke sin interne klokkehastighet for å justere seg mot korrekt tid.
Pass på loggehull
Men dersom avviket er stort vil skuddsekund (leap second) inntreffe. Klienten vil, i en stor jafs, forskyve sin interne klokke til servertiden for å oppnå synkronitet. Dette vil forårsake enten hull i logger, eller doble oppføringer på samme klokkeslett, og er selvsagt ikke å anbefale.
Noen NTP-klienter kan konfigureres med flere, redundante servere. Vi skraper litt i overflaten på det omfattende temaet.
NTP-redundans
Klienten lager et vektet gjennomsnitt av alle de forskjellige klokkeslettene den mottar fra serverne, og bruker dette som sin interne klokke. Om alle serverne er innenfor det den anser som rimelig samlet, blir alle tatt med i det vektede gjennomsnittet.
Hvis derimot en eller flere avviker fra den samlede serverflokken, blir den eller de utelukket fra snittberegningen. Dette er en form for kvalitetssikring.
Uønsket drift
Desto mindre nøyaktige serverne er, desto mer vil de drifte fra hverandre. I verste fall kan du da (sett fra klientens ståsted) ende opp med kun én server som blir ansett som pålitelig. Idet klienten fjerner den eller de upålitelige serverne fra snittberegningen, kan man få skuddsekunder.
Det er derfor viktig at alle NTP-serverne er synkronisert mot en felles kilde for å unngå at de ”vingler rundt”. Selv om en server bare drifter noen få sekunder, vil det ta lenger tid enn et par sekunder å lese loggfiler med hull og dobbeltoppføringer.
Les også: Slik kontrollerer du industrielle nettverk med virtuelle løsninger og multicast-teknologi
Interne, offline NTP
Interne, offline NTP-servere er en av de mest brukte løsningene som brukes for å synkronisere lokalnettet (intranettet). Man bruker for eksempel en pc eller en filserver (en hvilken som helst node som kan være NTP-server), og så konfigurerer man alle de andre nodene til å bruke disse enhetene som NTP-servere.
Da oppnår pc-er, PLS-er, HMI-er, og alt annet som måtte befinne seg på nettverket, korrekt tid på en enkel og rimelig måte. Skjønt, i dette eksempelet er uttrykket «korrekt tid» en stor overdrivelse.
Unøyaktige oscillatorer
Servere, pc-er og alt annet nettverksutstyr er laget for å prosessere og presentere data. Oscillatorene som sitter i utstyret er veldig kjappe, men langt fra nøyaktige. Disse oscillatorene blir lett påvirket av både temperatursvingninger og vibrasjoner, og man ser fort at tiden drifter en god slump sekunder – hver eneste dag.
Sett fra NTP-klientens ståsted vil ikke denne driftingen spille noen rolle, for klientene vil drifte i takt med serveren, og alle lever lykkelig uvitende. Men den dagen tiden på serveren blir korrigert, vil man kunne se effekten av det, i form av skuddsekunder på samtlige klienter.
Uansett om behovet er absolutt eller relativ tid, er dette ingen god løsning. I hvert fall ikke om man har et ørlite ønske om nøyaktighet, eller et håp om å kunne bruke klokken når det kommer til feilsøking. Dersom en bruker redundante NTP-servere er denne løsningen ikke å anbefale.
Les også: Slik synkroniserer du tiden i industrielle nettverk
NTP-poolservere
NTP-gruppeservere (pool servere) er nok en gratis måte å synkronisere klokker på. En stor fordel er at de er synkronisert mot UTC (Coordinated Universal Time), ofte via GPS. Mest sannsynlig er alle Stratum 1-servere.
Stratum 1 forteller at serveren er synkronisert mot for eksempel GPS, DCF77, eller en annen offisiell klokkekilde, og at de er dertil nøyaktige.
Last kontra nøyaktighet
Noen ganger blir Stratum 1-serverne brukt til å synkronisere andre klokkeservere i samme gruppe, og disse blir da referert til som Stratum 2-servere. Har man et knippe Stratum 1-servere, vil lasten på disse øke i takt ettersom flere bruker gruppen til å synkronisere klokkene sine.
Lastdeling kan for eksempel gjøres ved å sette opp flere Stratum 2-servere, som synkroniseres mot Stratum 1-serverne, for så å bruke Stratum 2-serverne for å dele klokketid med klientene. Det er bra med tanke på lastdelingen, men for hvert ledd NTP-pakkene skal gå via, degraderes nøyaktigheten.
Varierende reisetid
Som vi alle vet, er dette med redundans et meget relevant tema i industrien. Sånn sett er en NTP-pool noe å vurdere, da det er mange servere som står for å drifte en pool, kontra det å ha et par interne pc-er eller servere som NTP-servere. Men, på den annen side, så får man ikke redundans ved å bruke en NTP-server dersom man kun har en link ut mot internett.
En annen viktig ting å tenke på, som er en nøkkelfaktor for nøyaktighet og NTP-poolservere: Datatrafikk som sendes over internett går gjennom en stor mengde routere. En NTP-klients forespørsel tar en rute når den blir sendt til serveren, men svaret fra serveren kan ta en helt annen rute, som kan være lengre eller kortere. Dette gjør at klientens algoritme for å beregne reisetid for pakken, blir unøyaktig.
Les også: Klokkesynkronisering med eksterne tidsservere
