Betaalbare NTP appliance

[Wido]

Hallo,

Het wordt vaak onderschat, maar vooral in distributed systemen zoals Ceph is het hebben van de exacte tijd érg belangrijk.

Het is dus zaak dat je alle servers voorziet van een NTP daemon om clock drifts tegen te gaan.

Nu ben ik met een best grote deployment bezig en wil ik daarmee niet op de publieke NTP servers gaan hameren, maar ook is de tijd daarvan nog niet accuraat genoeg. Door latency e.d. kan je in een groot cluster van met achines toch nog steeds verschillen krijgen van 0.1 seconde, wat te veel is.

Het liefste zou ik een NTP appliance hebben die heel accuraat is, alleen zijn die krengen belachelijk duur. Zo betaal je rustig $5000,00 voor zo'n appliance en dat vind ik iets te veel.

Rond zoekende op het internet kom je ook mensen tegen die met een Soekris 4501 een eigen NTP server hebben gebouwd. Nu wil ik dat solderen graag voorkomen en ergens een betaalbaar systeem vandaan halen wat een GPS klok gebruikt.

Een GPS receiver op een serieële poort kan ook nog, maar wat voor een server hang je daar voor?

Welke moderne CPU heeft het minste last van clock drifting?

Ik zoek een manier om een simpele NTP appliance te maken, het liefste gewoon een Plug&Play apparaat, maar ik ben bang dat die allemaal nogal duur gaan zijn.

Suggesties?

[systemdeveloper]

Het belangrijkste is dat je dezelfde tijd hebt en of dat 0,1s van de real life tijd afwijkt zou niet echt boeiend moeten zijn. Is een arduino met een rtc shield (of een pi) niet voldoende? Eventueel kun je er nog een antenne aan hangen en syncen met de atoomtijd. Of een ntp deamon op een gewone bak runnen en je cluster laten syncen met die bak binnen je netwerk. Latency ben je dan waarschijnlijk ver kwijt.

[Tim.Bracquez]

Je hebt ook zo'n devices: http://www.amazon.com/TM1000A-GPS-Ne.../dp/B002RC3Q4Q

Opzich zolang je tijd gelijk is (interne NTP met UTC time)... of die er naast zit maakt dit toch niet zoveel uit?

[Wido]

Het belangrijkste is dat je dezelfde tijd hebt en of dat 0,1s van de real life tijd afwijkt zou niet echt boeiend moeten zijn. Is een arduino met een rtc shield (of een pi) niet voldoende? Eventueel kun je er nog een antenne aan hangen en syncen met de atoomtijd. Of een ntp deamon op een gewone bak runnen en je cluster laten syncen met die bak binnen je netwerk. Latency ben je dan waarschijnlijk ver kwijt.

Een bak in het netwerk waar iedereen mee synced was inderdaad al een eerste idee.

Ik vond het echter wel zo leuk om het direct goed te doen met een hele accurate NTP server.

Je hebt ook zo'n devices: http://www.amazon.com/TM1000A-GPS-Ne.../dp/B002RC3Q4Q

Opzich zolang je tijd gelijk is (interne NTP met UTC time)... of die er naast zit maakt dit toch niet zoveel uit?

Alle machines in het cluster moeten inderdaad exact de zelfde tijd hebben, anders komt het cluster in de problemen. Updates van verschillende nodes die volgens de ene node in het verleden waren, terwijl ze eigenlijk in de toekomst waren, etc, etc.

$299 valt inderdaad wel mee, wellicht is dat wel wat.

[visser]

Hallo,

Het wordt vaak onderschat, maar vooral in distributed systemen zoals Ceph is het hebben van de exacte tijd érg belangrijk.

Het is dus zaak dat je alle servers voorziet van een NTP daemon om clock drifts tegen te gaan.

Nu ben ik met een best grote deployment bezig en wil ik daarmee niet op de publieke NTP servers gaan hameren, maar ook is de tijd daarvan nog niet accuraat genoeg. Door latency e.d. kan je in een groot cluster van met achines toch nog steeds verschillen krijgen van 0.1 seconde, wat te veel is.

Dat zou echt niet moeten, voor NTP die in sync is en een behoorlijk stabiele lokale klok heeft.

Het liefste zou ik een NTP appliance hebben die heel accuraat is, alleen zijn die krengen belachelijk duur. Zo betaal je rustig $5000,00 voor zo'n appliance en dat vind ik iets te veel.

Ik zie ze op Ebay ook voor 500 dollar.
(zoek op ntp server in 'Computers/Tablets' ).
Bedenk wel dat ontvangst (GPS, of ook DCF77) in een typisch DC erg lastig kan zijn .

Zoals systemdeveloper ook zei, dat je cluster _onderling_ echt dezelfde tijd moet hebben kan ik wel begrijpen, het belang dat dat binnen weinig milliseconden van "de buitentijd" zit snap ik iets minder.

Dan moet je ze vooral met elkaar en een lokale ntp server laten syncen; Als die lokale ntp server toevallig ook een stratum 1 is vanwege een GPS is dat mooi, maar m.i. kun je die ook wel met een paar publieke ntp servers syncen.
Een (constante) latency is niet zo heel erg erg, het is jitter (variatie in latency) die de nauwkeurigheid aantast.

Rond zoekende op het internet kom je ook mensen tegen die met een Soekris 4501 een eigen NTP server hebben gebouwd. Nu wil ik dat solderen graag voorkomen en ergens een betaalbaar systeem vandaan halen wat een GPS klok gebruikt.

Een GPS receiver op een serieële poort kan ook nog, maar wat voor een server hang je daar voor?

Welke moderne CPU heeft het minste last van clock drifting?

Ik zoek een manier om een simpele NTP appliance te maken, het liefste gewoon een Plug&Play apparaat, maar ik ben bang dat die allemaal nogal duur gaan zijn.

Suggesties?

Ebay. En kijk ook goed naar je server(instellingen).
Het principe van NTP is dat een systeem een behoorlijk stabiele _lokale_ tijd/frequentiebron heeft, die geijkt en voorzichtig bijgestuurd wordt door externe tijdsbronnen.

Als NTP een tijd gedraaid heeft (en dan de drift van de lokale bron goed kent) moet het ook vrij lang nauwkeurig blijven zonder externe input.
Als die aanname van een stabiele lokale bron niet klopt kan ntp heel wat minder bereiken dan wat men normaal verwacht .

Kortom :
1: ntp lager stratum 'dichtbij' , de tijdsbron (gps of publieke servers) is minder relevant
2: goed inlezen dat je op de servers zelf niet meer verliest dan er te winnen valt met ntp.

Met een rondje googlen zie ik dat het iets met geduld is, want de kleinere effecten zie je met een periode van uren tot dagen. Ik vind wachten op de sync al lang duren....
('even proberen of deze instelling beter werkt' is dus niet 'even' ). Frequente start/stops van ntp zijn zo te zien behoorlijk erger voor nauwkeurigheid dan cpu drift, oscillator temperatuur (ja, meetbaar als je je best doet) e.d.

Met de natte vinger denk ik/meen ik op te maken uit mijn google ronde dat je een stel 'lokale' systemen die op hardware draaien (vm's is een ramp) vrij goed binnen een milliseconde van elkaar moet kunnen houden, en dat sub-milliseconde mogelijk is maar dat het dan echt werk wordt.

[t.bloo]

Ik heb hier Ceph monitors op VM's draaien en die vinden inderdaad altijd dat ze voor of achter lopen, ook al sync je ze tegen een externe publieke NTP server. Iets lokaals lijkt me een goede oplossing, maar Ceph zou ook best eens naar z'n algoritme kunnen kijken want het staat blijkbaar wel heel erg strak afgesteld.

[IT-worX]

Gewoon kijken naar stratum 1 servers niet genoeg dan?
Bvb ntp1.belnet.be en ntp1.oma.be?

[visser]

Gewoon kijken naar stratum 1 servers niet genoeg dan?
Bvb ntp1.belnet.be en ntp1.oma.be?

Dat is niet waar het probleem (cq onnauwkeurigheid) zit.
stratum 1 'ver weg' is absoluut niet beter dan 'stratum 2' dicht bij, in tegendeel.

[IT-worX]

Het is ook niet mijn bedoeling om dit te beweren hoor, verre van!
Maar "ver weg" lijkt me brussel niet (gerekend in latency).
Maar als je een stratum 1 zoekt in NL : http://support.ntp.org/bin/view/Serv...OneTimeServers

[visser]

Het is ook niet mijn bedoeling om dit te beweren hoor, verre van!
Maar "ver weg" lijkt me brussel niet (gerekend in latency).
Maar als je een stratum 1 zoekt in NL : http://support.ntp.org/bin/view/Serv...OneTimeServers

?
Je posting leek mij toch echt te beweren dat Wido's 0.1 sec onderling verschil probleem opgelost zou zijn als hij maar een stratum 1 op internet zou nemen.
Dat was tenslotte zijn probleem, en jouw aanbeveling.

Nogmaals : het stratum is geen één op één met 'lager is altijd de beste keus' , en een stratum 1 op internet nemen hoeft al helemaal geen oplossing te zijn waarmee je een cluster strak _bij elkaar_ houdt.

Ik heb wel een beetje tijd gestoken in mijn posting, en er is een hoop meer over NTP te zeggen dan 'laagste stratum in de lijst nemen'.
Een heel internet pad met ietwat variabele latency naar een stratum 1, of over een lan switch naar een stratum 2 of 3 bron syncen, dan is de lokale server een veel betere keuze om je cluster _bij elkaar_ te houden.
Als je lokale server een stabiele bron is, kun je die nog aan een publieke NTP server binnen een goede grens van de 'werkelijke' buitentijd houden.
Een publieke stratum2 server die goed gesynced (en gelinked) is aan een (evt niet-publieke) stratum 1 bron is nog steeds heel erg nauwkeurig. En afhankelijk van de kwaliteit van het pad, en met name variatie in latency, mogelijk een betere bron dan 'rechtstreeks' aan een stratum 1 syncen.

[Paulewk]

Hoi Wido. Als tijd zo belangrijk voor je is, waarom zou je hier dan op besparen. Is goedkoper ook net zo goed, of beter?

[Wido]

Hoi Wido. Als tijd zo belangrijk voor je is, waarom zou je hier dan op besparen. Is goedkoper ook net zo goed, of beter?

Nou, het is meer dat ik 5k voor een NTP appliance een beetje te veel vind.

Het gaat er bij Ceph om dat de interne tijd inderdaad goed loopt. Of dit 0.1 seconde met de daadwerkelijke tijd verschilt maakt niet veel uit, maar het gehele cluster moet op tijd lopen.

Een lokale NTP wil je dus vanwege lag/jitter op het internet, ookal anticiperen de NTP daemons daar zelf ook op.

[systemdeveloper]

Nou, het is meer dat ik 5k voor een NTP appliance een beetje te veel vind.

Het gaat er bij Ceph om dat de interne tijd inderdaad goed loopt. Of dit 0.1 seconde met de daadwerkelijke tijd verschilt maakt niet veel uit, maar het gehele cluster moet op tijd lopen.

Een lokale NTP wil je dus vanwege lag/jitter op het internet, ookal anticiperen de NTP daemons daar zelf ook op.

Oh, voor 3k heb ik ook wel een bakje voor je met een stikker 'Local NTP daemon'