Tijd loopt sneller op server dan op andere computers?

[Gamebuster]

Ik heb een raar probleem:

Ik heb een AJAX-app die de tijd van de client bij benadering moet synchroniseren met de server. Ik ben er echter achtergekomen dat dit tijdverschil niet gelijk blijft tussen de computers, wat in theorie inhoud dat of de server's klok, of mijn computer's klok een paar milliseconden per seconde te snel/te langzaam gaat.

Wat ik op alle computers terugzie is dat de servertijd net iets sneller omhoog gaat dan de clienttijd. Consequent, over alle computers die ik probeer, lijkt de servertijd 1 milliseconde per ongeveer 4 seconden sneller toe te nemen dan die van de clients.

Hier is een live voorbeeld te zien, waarbij de servertijd en clienttijd iedere seconde vergeleken worden:
http://kutcomputers.nl/

Clientside wordt de check uitgevoerd in Javascript:

JavaScript:

        var localTime = new Date().getTime();
        self.query(["time"], function(data)
        {
            var queryTime = new Date().getTime()-localTime;
            var currentTime = localTime+Math.round(queryTime/2);
            self._timeOffset = currentTime-data.time;
            log("TimeOffset: "+(self._timeOffset/1000)
               +" ClientTime: "+(currentTime/1000)
               +" ServerTime: "+(data.time/1000)
               +" QueryTime: "+(queryTime/1000));
            if(cb)cb(self);
        });

Serverside wordt een timestamp gestuurd in JSON met de volgende 2 fragmenten aan code:

JavaScript:

//in Response-object's constructor, welke direct wordt aangemaakt bij iedere HTTP request:
this._time = new Date();

//Response.getTime():
this.getTime = function()
{
    return self._time;
}

//De code die de tijd ophaalt en toewijst aan een property in het JSON object:
response.set("time", response.getTime().getTime());
response.end();

De code is verder niet heel relevant: er is -zover ik weet- weinig vreemds aan mijn code.

Tijdens het typen van dit bericht heb ik mijn site even open gelaten, en kwam op de volgende log:
http://pastebin.com/6VxVbDph

Hierop is duidelijk te zien dat de tijd tussen mijn server en de client consequent niet gelijk blijft.

Wat ik me nou afvraag:
Is het normaal dat de tijd sneller lijkt te lopen op mijn server dan op overige computers?

Hardware specs server:
Intel i7 Xeon x3440 2.53GHz quad core
500GB samsung HDD
2GB 1333MHz ECC RAM (ga ik nog upgraden)
Intel server moederbord in 1U barebone kast
Ubuntu Server 10.04 LTS 64bit

Hardware specs testsysteem:
late 2009 15" macbook pro 2.8GHz dual core met Mac OS X 10.6

Ook getest met:
andere macbook
iPad

[ Voor 6% gewijzigd door Gamebuster op 02-01-2011 21:13 ]

[downtime]

Is het een virtuele of een fysieke server?

[Gamebuster]

downtime schreef op zondag 02 januari 2011 @ 21:12:
Is het een virtuele of een fysieke server?

fysiek

[Keiichi]

downtime schreef op zondag 02 januari 2011 @ 21:12:
Is het een virtuele of een fysieke server?

In het geval van een virtuele server, indien linux, moet je de kernel even opnieuw recompilen met de optie CONFIG_HZ=100 . Het lost het probleem dan niet geheel op, maar het maakt het wel iets beter.

[MueR]

Je hebt vast last van time dilation

[Gamebuster]

MueR schreef op zondag 02 januari 2011 @ 21:21:
Je hebt vast last van time dilation

is dit een serieus antwoord?

overigens, mijn server en mijn macbook staan nog geen 10 meter van elkaar af.

hoe dan ook, ik maak het systeem wel zo dat deze rare tijdafwijking geen probleem kan vormen door tijd tussen client en server meerdere keren te syncen, maar ik vind dit een erg vreemd probleem.

[ Voor 23% gewijzigd door Gamebuster op 02-01-2011 21:26 ]

[Vinnienerd]

MueR schreef op zondag 02 januari 2011 @ 21:21:
Je hebt vast last van time dilation

The effects detected in such experiments are extremely small, with differences being measured in nanoseconds.

[Pascal]

ah nette ping toch 33ms
TimeOffset: -33.654

[ Voor 12% gewijzigd door Pascal op 02-01-2011 21:46 ]

[Gamebuster]

Pascal schreef op zondag 02 januari 2011 @ 21:29:
ah nette ping toch 33ms
TimeOffset: -33.654

ten eerste, dat is seconden, geen milliseconden.
ten tweede is dat geen ping, maar het gemeten tijdverschil tussen server en client
QueryTime komt daar meer in de buurt: tijd dat de AJAX request duurde.

[Xesxen]

TimeOffset: -36.554 ClientTime: 1294000424.556 ServerTime: 1294000461.11 QueryTime: 0.26

Ik denk niet dat de clienttime en de servertime in ms worden gemeten

[Hardware Junk]

De server is een kloon en de clients zijn allemaal Appels?

Dan zal ik toch eens aan een Appel moeten, immers is de tijd van de kloon PC sneller voorbij.

[Gamebuster]

Xesxen schreef op zondag 02 januari 2011 @ 21:34:
TimeOffset: -36.554 ClientTime: 1294000424.556 ServerTime: 1294000461.11 QueryTime: 0.26

Ik denk niet dat de clienttime en de servertime in ms worden gemeten

JavaScript:

        var localTime = new Date().getTime(); 
        self.query(["time"], function(data) 
        { 
            var queryTime = new Date().getTime()-localTime; 
            var currentTime = localTime+Math.round(queryTime/2); 
            self._timeOffset = currentTime-data.time; 
            log("TimeOffset: "+(self._timeOffset/1000) 
               +" ClientTime: "+(currentTime/1000) 
               +" ServerTime: "+(data.time/1000) 
               +" QueryTime: "+(queryTime/1000)); 
            if(cb)cb(self); 
        });

Wel, zover je kunt vertrouwen op Javascript's new Date().

Serverside gebruik ik overigens NodeJS, clientside Safari.

Zelfs zonder milliseconde-precisie zie je gewoon dat het verschil consequent toeneemt

Hardware Junk schreef op zondag 02 januari 2011 @ 21:36:
De server is een kloon en de clients zijn allemaal Appels?

Dan zal ik toch eens aan een Appel moeten, immers is de tijd van de kloon PC sneller voorbij.

wut? een kloon?

[ Voor 16% gewijzigd door Gamebuster op 02-01-2011 21:43 ]

[CyBeR]

Je server loopt inderdaad voor. Ongeveer 34 seconden. Als je elke zoveel tijd de tijd gelijk zet, houdt dat inderdaad in dat die server een klok heeft die iets te snel loopt. Dat kan, en is normaal. Installeer ntpd, die zorgt dat de klok gelijk gaat lopen.

[ Voor 4% gewijzigd door CyBeR op 02-01-2011 21:47 ]

[Gamebuster]

sudo apt-get install openntpd

Moet ik me nu inbeelden dat de tijd opeens weer "goed gezet" wordt, eens om de zoveel tijd? Ik betwijfel of mijn app dit leuk gaat vinden, omdat die sterk afhankelijk is van de klok. Als de tijd opeens 10 seconden terugspringt krijg je rare gezichten van mijn bezoekers.

[ Voor 123% gewijzigd door Gamebuster op 02-01-2011 21:55 ]

[Onbekend]

Ik denk dat het te maken heeft met de ping. Oftewel, soms komt een pakketje iets later aan dan de andere keer, en daarmee kan je dus niet exact bepalen wat het het tijdsverschil is.

[CoolGamer]

De klokken die in computers zitten zijn niet bedoeld om als atoomklok te functioneren, dus extreem accuraat zullen ze niet gemaakt worden. Er zijn maar weinig toepassingen waar een zeer accurate klok voor nodig is.

Zelf sync ik mijn klok in Windows met de servers van ntp.org. Daar zit soms een afwijking in van een paar seconden. Afwijkingen kunnen worden teruggekeken in het Windows-logboek. Dus hier een voorbeeld dat de ene klok sneller loopt dan de ander.

Je zal misschien een langere meting kunnen doen of het niet een meetfout is of dat het ergens anders door komt. Maar een afwijking is eigenlijk wel te verwachten, al is deze afwijking misschien wel groot. 1ms/4s levert een afwijking van ~11 seconden per dag op. Is wel veel.

[ Voor 4% gewijzigd door CoolGamer op 02-01-2011 21:54 ]

[CyBeR]

Gamebuster schreef op zondag 02 januari 2011 @ 21:50:
sudo apt-get install openntpd

Moet ik me nu inbeelden dat de tijd opeens weer "goed gezet" wordt, eens om de zoveel tijd? Ik betwijfel of mijn app dit leuk gaat vinden, omdat die sterk afhankelijk is van de klok. Als de tijd opeens 10 seconden terugspringt krijg je rare gezichten van mijn bezoekers.

Eh, hoe openntpd werkt weet ik niet want ik had het over de normale ntpd. Maar hoe de normale ntpd werkt is door de snelheid van de klok aan te passen. (In de praktijk voeren de meeste startup scripts daarvoor eerst even 'ntpdate' uit om dat proces wat te versnellen). Daardoor is na een tijdje de snelheid van je klok zelf aangepast, zodat 'ie gewoon op de goede tijd draait ipv elke zoveel tijd voor- of achteruit gezet te moeten worden.

Onbekend schreef op zondag 02 januari 2011 @ 21:51:
Ik denk dat het te maken heeft met de ping. Oftewel, soms komt een pakketje iets later aan dan de andere keer, en daarmee kan je dus niet exact bepalen wat het het tijdsverschil is.

Dat fenomeen heet niet 'ping' (niets heet zo, behalve het commando om roundtrip latency te meten), dat heet jitter.

[ Voor 19% gewijzigd door CyBeR op 02-01-2011 21:58 ]

[Gamebuster]

Hee, er gebeurt wat.

http://pastebin.com/sUPv3Jjc

Hij ging heel langzaam van 33.8 naar 33.9 naar 34.0. Rond deze tijd installeerde ik dat ntpd en nu loopt het weer terug naar 33.9

Hopelijk komt dit inderdaad door ntpd; dan ben ik ruim tevreden met dit gedrag; dan is dat probleem in ieder geval opgelost. Was al bang dat de tijd opeens zou verspringen, maar dat doet-ie gelukkig niet.

[ Voor 11% gewijzigd door Gamebuster op 02-01-2011 22:00 ]

[Nielson]

Je RTC overklokken is nooit handig Je zou eens kunnen kijken of je Linux kernel gebruik maakt van de normale timer of de theoretisch veel preciezere HPET.

[CoolGamer]

ntpd is misschien wel geïnstalleerd, hij heeft nog niet gesynct. De afwijking is nog steeds meer dan 30 seconden. Staat hij wel geïnstalleerd als daemon en is er een server ingesteld?

[Gamebuster]

Nielson schreef op zondag 02 januari 2011 @ 22:00:
Je RTC overklokken is nooit handig Je zou eens kunnen kijken of je Linux kernel gebruik maakt van de normale timer of de theoretisch veel preciezere HPET.

Zegt me weinig, ben prima tevreden met de werking van ntpd.

[CyBeR]

TheCoolGamer schreef op zondag 02 januari 2011 @ 22:07:
ntpd is misschien wel geïnstalleerd, hij heeft nog niet gesynct. De afwijking is nog steeds meer dan 30 seconden. Staat hij wel geïnstalleerd als daemon en is er een server ingesteld?

Dat klopt ook, want ntpd zal nooit zomaar je klok verzetten.

[Gamebuster]

TheCoolGamer schreef op zondag 02 januari 2011 @ 22:07:
ntpd is misschien wel geïnstalleerd, hij heeft nog niet gesynct. De afwijking is nog steeds meer dan 30 seconden. Staat hij wel geïnstalleerd als daemon en is er een server ingesteld?

verschil loopt weer terug, hij werkt. Na installatie liep tijd weer langzamer. Ik ben prima tevreden met de werking van ntpd. Zit nu weer op -33.6 en voor de installatie had ik bijna de -34.1 bereikt.

[CyBeR]

Gamebuster schreef op zondag 02 januari 2011 @ 22:10:
[...]

verschil loopt weer terug, hij werkt. Na installatie liep tijd weer langzamer. Ik ben prima tevreden met de werking van ntpd. Zit nu weer op -33.6 en voor de installatie had ik bijna de -34.1 bereikt.

Je zult 'm na een tijdje rond de 0 hebben staan. Jouw testsysteem is namelijk standaard voorzien van een correct ingestelde ntpd. OSX komt namelijk standaard met ntpd ingesteld op (heel netjes trouwens) Apple's eigen GPS-based time servers.

[ Voor 10% gewijzigd door CyBeR op 02-01-2011 22:12 ]

[Gamebuster]

iPads overigens niet. Die heeft afwijking van +96.241 op dit moment. Macbook zit op -33.505 nu.

[Keiichi]

Je kunt het best even een 'ntpdate pool.ntp.org' uitvoeren voordat je ntp start. Dan staat je tijd wat sneller goed

[Gamebuster]

code:

toby@ubuntu:~$ sudo ntpdate pool.ntp.org
[sudo] password for toby: 
 2 Jan 22:33:27 ntpdate[5269]: step time server 85.234.224.216 offset -33.469764 sec

hee hij versprong direct

[ Voor 8% gewijzigd door Gamebuster op 02-01-2011 22:34 ]

[Keiichi]

Gamebuster schreef op zondag 02 januari 2011 @ 22:33:

code:

toby@ubuntu:~$ sudo ntpdate pool.ntp.org
[sudo] password for toby: 
 2 Jan 22:33:27 ntpdate[5269]: step time server 85.234.224.216 offset -33.469764 sec

hee hij versprong direct

ntpdate zorgt daar idd voor, die pakt de tijd van de ntp server en synct gelijk. De ntp daemon zorgt ervoor dat die tijd op tijd blijft.

-edit-

Volgens mij blijft de clock nu wel redelijk in sync? Zit heel de tijd rond -0.100s timediff wat zeker qua latency niet slecht is.

[ Voor 13% gewijzigd door Keiichi op 02-01-2011 22:37 ]

[Gamebuster]

Hij is van +0.022 (+0.022 begon-ie mee na update) naar -0.067 gegaan bij mij. Ik hou het in de gaten, maar vertrouw erop dat het goed komt. Laat 'm hele nacht doorgaan, ik zie wel waar-ie morgen op staat.

[ Voor 53% gewijzigd door Gamebuster op 02-01-2011 22:49 ]

[CyBeR]

Keiichi schreef op zondag 02 januari 2011 @ 22:26:
Je kunt het best even een 'ntpdate pool.ntp.org' uitvoeren voordat je ntp start. Dan staat je tijd wat sneller goed

Ja, dat zet de tijd dus achteruit en dat wilde 'ie juist niet

Overigens loopt 'ie nu weer op-- staat ntpd uit nudat je ntpdate hebt gedaan?

[ Voor 11% gewijzigd door CyBeR op 02-01-2011 22:55 ]

[Keiichi]

CyBeR schreef op zondag 02 januari 2011 @ 22:53:
[...]
Ja, dat zet de tijd dus achteruit en dat wilde 'ie juist niet

1x mag de tijd toch nog verspringen. Ik denk dat de site nog alleen nog maar ter test is. Zodra de tijd gewoon synced blijft is er verder geen probleem meer.

[Patriot]

CyBeR schreef op zondag 02 januari 2011 @ 22:53:
[...]


Ja, dat zet de tijd dus achteruit en dat wilde 'ie juist niet

Overigens loopt 'ie nu weer op-- staat ntpd uit nudat je ntpdate hebt gedaan?

Hij wilde dat niet constant, nu tijdens het ontwikkelproces lijkt me dat geen probleem

[Gamebuster]

CyBeR schreef op zondag 02 januari 2011 @ 22:53:
[...]


Ja, dat zet de tijd dus achteruit en dat wilde 'ie juist niet

Overigens loopt 'ie nu weer op-- staat ntpd uit nudat je ntpdate hebt gedaan?

nu is het niet erg, eenmalig. Maar als de site live is kan ik dat absoluut niet hebben. Als het echt zou moeten zou ik het wel snachts kunnen doen.

Tijd gaat nu wel nog een beetje raar:
+0.022 naar -0.310 naar -0.290 naar -0.320

hoe kan ik controleren of die ntpd draait?

edit:
+0.022 naar -0.310 naar -0.290 naar -0.320 naar -0.270

Lijkt te werken. Zo lekker slapen, zie morgen wel waar de tijd op staat. Laat mijn site hele nacht open, kan ik meteen kijken of mijn NodeJS dingetjes na een nacht ook nog prima draait.

edit2:

code:

TimeOffset: -0.416 ClientTime: 1294007844.786 ServerTime: 1294007845.202 QueryTime: 0.006
TimeOffset: -0.416 ClientTime: 1294007843.786 ServerTime: 1294007844.202 QueryTime: 0.006
TimeOffset: -0.201 ClientTime: 1294007842.787 ServerTime: 1294007842.988 QueryTime: 0.008
TimeOffset: -0.200 ClientTime: 1294007841.786 ServerTime: 1294007841.986 QueryTime: 0.006
TimeOffset: -0.200 ClientTime: 1294007840.786 ServerTime: 1294007840.986 QueryTime: 0.006

verspringt even 200ms? apart. Ach ja, ik zie morgen wel waar-ie op staat.

[ Voor 80% gewijzigd door Gamebuster op 02-01-2011 23:41 ]

[Matis]

Het is alsof de duvel er mee speelt

TimeOffset: -0.666 ClientTime: 1294038412.86 ServerTime: 1294038413.526 QueryTime: 0.023

Daar blijft hij nu rond schommelen. Draait op zowel je server als op je client ntpd?

[Gamebuster]

Afgelopen nacht heeft-ie geschommeld tussen 0.100 en -0.400. Ben ik tevreden mee; probleem opgelost.

Ik ga zo weer verder werken eraan, site kan komende tijd raar gaan doen.

[ Voor 39% gewijzigd door Gamebuster op 03-01-2011 11:15 ]

[Ventieldopje]

code:

TimeOffset: -0.075 ClientTime: 1294050630.823 ServerTime: 1294050630.898 QueryTime: 0.058
TimeOffset: -0.082 ClientTime: 1294050629.816 ServerTime: 1294050629.898 QueryTime: 0.044
TimeOffset: -0.083 ClientTime: 1294050628.813 ServerTime: 1294050628.896 QueryTime: 0.042
TimeOffset: -0.083 ClientTime: 1294050627.81 ServerTime: 1294050627.893 QueryTime: 0.041

Zeer netjes toch

[ACM]

Gamebuster schreef op zondag 02 januari 2011 @ 23:24:
nu is het niet erg, eenmalig. Maar als de site live is kan ik dat absoluut niet hebben. Als het echt zou moeten zou ik het wel snachts kunnen doen.

Ntpd probeert ervoor te zorgen dat e.e.a. vaak genoeg geupdate wordt, zodanig dat de tijdsverschillen klein blijven. Het zou best kunnen dat ie uiteindelijk elk uur ofzo even update zodat de tijden maximaal X tijd verkeerd lopen. Hij past, vziw, niet de 'snelheid van je klok' aan oid, maar de snelheid waarmee ie updates uitvoert om je klok opnieuw gelijk te zetten. En als je dat maar vaak genoeg doet zie je vanzelf bijna geen verschillen meer.

Overigens is dat niet iets wat enkel 'servers' hebben, windows desktops doen het net zo goed fout. Wat dan ook waarschijnlijk de reden is geweest dat men de ntp-service is gaan inbouwen bij Windows XP. Ik heb vervolgens later zelf nog de synchronisatie-intervallen fors verkleind omdat mijn systeem steeds een minuut ofzo achterliep aan het eind van de weekinterval...

verspringt even 200ms? apart. Ach ja, ik zie morgen wel waar-ie op staat.

Ntpd zette de tijd dan wellicht even goed.

[CyBeR]

ACM schreef op maandag 03 januari 2011 @ 12:13:
[...]

Ntpd probeert ervoor te zorgen dat e.e.a. vaak genoeg geupdate wordt, zodanig dat de tijdsverschillen klein blijven. Het zou best kunnen dat ie uiteindelijk elk uur ofzo even update zodat de tijden maximaal X tijd verkeerd lopen. Hij past, vziw, niet de 'snelheid van je klok' aan oid, maar de snelheid waarmee ie updates uitvoert om je klok opnieuw gelijk te zetten. En als je dat maar vaak genoeg doet zie je vanzelf bijna geen verschillen meer.

Dat ligt aan de omstandigheden: http://www.ntp.org/ntpfaq/NTP-s-algo.htm#Q-CLOCK-DISCIPLINE

5.1.6.1. How will NTP discipline my Clock?

In order to keep the right time, xntpd must make adjustments to the system clock. Different operating systems provide different means, but the most popular ones are listed below.

Basically there are four mechanisms (system calls) an NTP implementation can use to discipline the system clock (For details see the different RFCs found in Table 4):

settimeofday(2) to step (set) the time. This method is used if the time if off by more than 128ms.

adjtime(2) to slew (gradually change) the time. Slewing the time means to change the virtual frequency of the software clock to make the clock go faster or slower until the requested correction is achieved. Slewing the clock for a larger amount of time may require some time, too. For example standard Linux adjusts the time with a rate of 0.5ms per second.

ntp_adjtime(2) to control several parameters of the software clock (also known as kernel discipline). Among these parameters are:

Adjust the offset of the software clock, possibly correcting the virtual frequency as well

Adjust the virtual frequency of the software clock directly

Enable or disable PPS event processing

Control processing of leap seconds

Read and set some related characteristic values of the clock

[H!GHGuY]

Nielson schreef op zondag 02 januari 2011 @ 22:00:
Je RTC overklokken is nooit handig Je zou eens kunnen kijken of je Linux kernel gebruik maakt van de normale timer of de theoretisch veel preciezere HPET.

Wat een geblaat komt hier toch voorbij.

HPET is een event timer die enkel gebruikt wordt voor high-precision timing.
De tijd wordt in de kernel nog altijd bijgehouden met de normale timer tick die afhankelijk van de configuratie eens elke 10ms tot 1ms af gaat. HPET heeft geen invloed op time keeping. Use the source, Luke.

Daarenboven hebben alle RTC devices een afwijking. Die is afhankelijk van het gebruikte (quartz-)kristal, van de temperatuur en vermoedelijk van nog wel wat zaken. Normaal wordt een afwijking tot 500ppm als normaal aanzien voor de meeste toepassingen, maw 500s per 1M seconden afwijking.

CyBeR schreef op zondag 02 januari 2011 @ 21:57:
[...]
Eh, hoe openntpd werkt weet ik niet want ik had het over de normale ntpd. Maar hoe de normale ntpd werkt is door de snelheid van de klok aan te passen. (In de praktijk voeren de meeste startup scripts daarvoor eerst even 'ntpdate' uit om dat proces wat te versnellen). Daardoor is na een tijdje de snelheid van je klok zelf aangepast, zodat 'ie gewoon op de goede tijd draait ipv elke zoveel tijd voor- of achteruit gezet te moeten worden.

ntpdate voert een eenmalige synchronisatie uit en je krijgt hiermee dan ook een sprong in de tijd.

ntpd zal, waar mogelijk, altijd de tijd vertragen of versnellen om tot de correcte tijd te komen. Dit gebeurt door elke zoveel ticks van de HW-timer een kleine correctie op de klok uit te voeren. ntpd zal ook altijd proberen om de tijd enkel vooruit te laten lopen.
Ook zal ntpd luid genoeg klagen (door ermee op te houden) als de drift van je klok te groot is. Als de offset bij starten van ntpd te groot is zal ook ntpd een sprong maken in de tijd.

[TJHeuvel]

Wat je kan overwegen om dit hele probleem te vermijden is bij het laden van de website de server tijd meegeven, en relatief van die tijd rekenen. Of het verschil van beide tijden meerekenen.

[Gamebuster]

CyCloneNL schreef op woensdag 05 januari 2011 @ 13:39:
Wat je kan overwegen om dit hele probleem te vermijden is bij het laden van de website de server tijd meegeven, en relatief van die tijd rekenen. Of het verschil van beide tijden meerekenen.

Dat doe ik ook, zo kwam ik er juist achter. Dat moet sowieso wel; het kan ook voorkomen dat een client's tijd niet goed staat of te snel/te langzaam gaat.