Comme le protocole NTP tente de mesurer et de compenser la latence du réseau et d'autres retards, il est très précis même lors de l'utilisation de serveurs horaires publics.

RTC est utilisé pour maintenir l'heure du système lorsque l'alimentation est coupée, et il n'est même pas nécessairement précis, une fois que votre raspberry PI a démarré et reçu l'heure de NTP il continuera à compter le temps sans RTC même si le réseau est déconnecté.

Lorsque vous utilisez NTP , vous ne synchronisez pas en permanence avec le réseau, l'heure du système est maintenue avec une minuterie basée sur l'horloge du processeur.

Lorsqu'il est exécuté avec un serveur de temps de réseau local, NTP peut atteindre une précision de <1ms.

Lorsqu'il est exécuté sur l'Internet public, le routage dynamique et potentiellement asymétrique des paquets contribue à une estimation plus médiocre des retards du réseau. Cependant, vous pouvez vous attendre à une précision bien inférieure à 1s , la plupart des documents affirmant une précision de 100 ms sur l'Internet public.

Si vous avez besoin d'une meilleure synchronisation, sans une meilleure précision, vous pouvez envisager d'exécuter un serveur NTP local pour synchroniser plusieurs raspberry pi les uns par rapport aux autres avec une synchronisation meilleure que 1ms (bon pour aligner les données du capteur).

Si vous avez besoin à la fois de précision et de synchronisation, vous pouvez exécuter un serveur NTP Stratum 1 en utilisant le GPS comme source de temps.

Selon wikipedia, le Network Time Protocol utilisé par défaut sur Raspbian et des millions d'autres appareils et ordinateurs en réseau:

est destiné à synchroniser tous les ordinateurs participants avec en quelques millisecondes

En fait, NTP est utilisé sur les systèmes (serveurs, PC, etc.) qui ont un RTC afin de corriger la dérive des horloges informatiques. Cela signifie que si vous ajoutiez un RTC, il resterait précis en utilisant exactement les mêmes mécanismes de réseau que ceux déjà utilisés pour régler l'horloge «logicielle» du système d'exploitation (qui, de manière réaliste, est liée à la fréquence du processeur, c'est-à-dire qu'il y a du cristal dedans quelque part qui garde effectivement l'heure lorsque le système est allumé).

La présence ou l'absence de RTC n'a rien à voir avec la précision du chronométrage. Il s'agit simplement de pouvoir conserver (une mauvaise approximation de) l'heure actuelle pendant que l'appareil est éteint afin que l'heure système soit correcte avant d'afficher le périphérique réseau et ntpd.

Notez que si vous voulez une source d'horloge distante sécurisée plutôt que ntp simple, vous aurez besoin de connaître une idée approximative de l'heure actuelle (précise à l'échelle du mois) afin de valider les certificats; c'est probablement le principal objectif moderne d'un RTC sur les appareils connectés à Internet.

Après avoir fait des expériences avec C ++ sur mon RPI3 (Stretch) en utilisant la fonction sys / time.h gettimeofday (**) et l'API de câblagePi, puis en mesurant par rapport à un champ d'application, les applications rationalisées peuvent obtenir une résolution et une précision inférieures à la milliseconde.

Maintenant, si vous utilisez d'autres langues sur le RPI, vous ne pourrez peut-être pas obtenir ces vitesses.

Nous obtenons une précision meilleure qu'une seconde sur plusieurs unités en utilisant un serveur NTP public de l'autre côté d'un réseau complexe et chargé. Nous n'avons également besoin que d'une précision de l'ordre de 1s (que l'horloge système peut maintenir pendant des jours lorsqu'elle est sous tension).

Consultez la page de manuel ntpd, mais après avoir configuré un serveur , vous assurer que ntpd -g s'exécute au démarrage devrait être tout ce dont vous avez besoin. Le -g vous ramène au temps réel si l'horloge est sortie, par exemple après une panne de courant.