Omdat het NTP -protocol probeert netwerklatentie en andere vertragingen te meten en te compenseren, is het zelfs bij gebruik van openbare tijdservers zeer nauwkeurig.

RTC wordt gebruikt om de systeemtijd bij te houden wanneer de stroom is uitgeschakeld, en het is niet noodzakelijk zelfs nauwkeurig, nadat uw Raspberry PI is opgestart en de tijd heeft ontvangen van NTP het zal doorgaan met het tellen van de tijd zonder een RTC , zelfs als de verbinding met het netwerk is verbroken.

Bij gebruik van NTP ben je niet continu aan het synchroniseren met het netwerk, de systeemtijd wordt bijgehouden met een timer gebaseerd op de cpu-klok.

Wanneer het wordt uitgevoerd met een lokale netwerktijdserver, kan NTP een nauwkeurigheid bereiken van <1ms.

Bij overlopen het openbare internet, dynamische en mogelijk asymmetrische routering van pakketten draagt ​​bij aan een slechtere inschatting van netwerkvertragingen. U kunt echter een nauwkeurigheid verwachten van ruim onder 1s , waarbij de meeste documentatie een nauwkeurigheid van 100ms claimt via het openbare internet.

Als u een betere synchronisatie nodig heeft, zonder betere nauwkeurigheid, kunt u overwegen om een ​​lokale NTP-server te draaien om meerdere Raspberry Pi ten opzichte van elkaar te synchroniseren met een betere synchronisatie dan 1ms (goed voor het uitlijnen van sensorgegevens).

Als u zowel nauwkeurigheid als synchronisatie nodig heeft, kunt u een Stratum 1 NTP-server gebruiken met GPS als tijdbron.

Volgens Wikipedia is het Network Time Protocol dat standaard wordt gebruikt op Raspbian en miljoenen andere netwerkapparaten en computers:

bedoeld om alle deelnemende computers te synchroniseren met binnen een paar milliseconden

In feite wordt NTP gebruikt op systemen (servers, pc's, enz.) die een RTC hebben om te corrigeren voor de afwijkende computerklokken. Dit betekent dat als je een RTC hebt toegevoegd, deze nauwkeurig zou worden gehouden door exact dezelfde netwerkmechanismen te gebruiken die worden gebruikt om de 'softwareklok' van het besturingssysteem al in te stellen (die realistisch gezien is gekoppeld aan de processorfrequentie, dat wil zeggen dat er kristal in zit ergens dat effectief de tijd bijhoudt terwijl het systeem aan staat).

Aanwezigheid of afwezigheid van RTC heeft niets te maken met de precisie van de tijdregistratie. Het is puur een kwestie van het kunnen houden van (een slechte benadering van) de huidige tijd terwijl het apparaat is uitgeschakeld, zodat de systeemtijd correct is voordat u het netwerkapparaat en ntpd opent.

Merk op dat als u wilt een veilige externe klokbron in plaats van een gewone ntp, u moet een globaal idee hebben van de huidige tijd (nauwkeurig binnen de maandschaal) om certificaten te valideren; dit is waarschijnlijk het belangrijkste moderne doel van een RTC op apparaten met internetverbinding.

Na experimenten te hebben gedaan met C ++ op mijn RPI3 (Stretch) met behulp van de sys / time.h-functie gettimeofday (**) en de bedradingPi API en vervolgens te meten tegen een bereik, kunnen gestroomlijnde applicaties een resolutie van minder dan een milliseconde en een nauwkeurigheid van timing verkrijgen.

Als u nu andere talen op de RPI gebruikt, kunt u die snelheden mogelijk niet verkrijgen.

We krijgen een nauwkeurigheid van beter dan een seconde op verschillende eenheden met behulp van een openbare NTP-server aan de andere kant van een complex en druk netwerk. We hebben ook alleen een nauwkeurigheid nodig in de orde van 1s (die de systeemklok dagenlang kan vasthouden terwijl deze is ingeschakeld).

Bekijk de ntpd-manpagina, maar na het configureren van een server , ervoor zorgen dat ntpd -g tijdens het opstarten draait, zou alles moeten zijn wat je nodig hebt. De -g brengt u terug naar de realtime als de klok ver weg is, zoals na stroomuitval.