GuiGui's Show

Quelques documentations pour comprendre comment les secondes intercalaires peuvent être digérées par nos systèmes informatiques :

• https://access.redhat.com/articles/15145
  
  
• https://developers.redhat.com/blog/2015/06/01/five-different-ways-handle-leap-seconds-ntp/
  
  
• https://www.meinbergglobal.com/english/info/leap-second.htm#os

Voici un gros résumé.

La méthode POSIX standard, c'est d'incrémenter le temps, de revenir en arrière d'une seconde et de continuer à incrémenter. On rejoue donc une même seconde. C'est la méthode « step back ». Cette méthode peut être mise en œuvre par le noyau ou par le démon NTP (disable kernel avec ntpd). La deuxième méthode permet de se prémunir d'un bug dans le noyau et de maintenir à l'heure un système dont le noyau ne propose pas d'API pour lui indiquer l'imminence de la seconde intercalaire. Linux dispose d'un bout de code permettant le traitement des secondes intercalaires. L'ennui avec la méthode step back dans son ensemble, c'est que le temps revient en arrière, il n'est plus continu. Cela peut mettre la grouille sur les systèmes qui dépendent fortement de l'ordre des événements pour fonctionner comme les gestionnaires de bases de données ou les clusters de stockage distribués (lors de la seconde intercalaire de 2005, Google a constaté que certains de ses serveurs de stockage étaient out).

La méthode NTP standard, en interne des implémentations des serveurs NTP est de stopper/maintenir le temps durant la seconde intercalaire. C'est la méthode « hold ». Ainsi, le temps reste continu. Voir : https://www.eecis.udel.edu/~mills/leap.html

Une autre méthode est d'augmenter très progressivement le temps pour compenser la seconde intercalaire.

• On peut le faire côté serveur NTP avant que la seconde intercalaire intervienne afin que les clients (les serveurs, desktop, ordiphone, etc.) soient en avance avant la seconde intercalaire et pile à l'heure au moment de la seconde intercalaire. C'est la méthode « leap smear » / « server slew » proposée par Google sur son service de serveurs NTP public : https://developers.google.com/time/ .
  
  
• On peut le faire côté client NTP durant la seconde intercalaire. C'est la méthode « client slew ».

On peut aussi choisir d'ignorer la seconde intercalaire et de la traiter après coup comme un problème standard de dérive du temps.

Évidemment, chaque façon de faire a ses avantages et inconvénients en fonction des usages :

• Step back : l'horloge est en dérive pendant une seule seconde, la fréquence de l'horloge n'est pas affectée, mais le temps n'est plus continu, ce qui casse certaines applications.
  
  
• Smear / server slew : la fréquence de l'horloge est faiblement affectée, le temps est continu, mais l'horloge est en dérive (avance) durant plusieurs heures avant la seconde intercalaire. De plus, il faut utiliser un pool NTP dédié.
  
  
• Client slew : le temps est continu, l'horloge est en dérive (retard) durant quelques dizaines de secondes voire minutes, mais la fréquence de l'horloge est fortement affectée donc les intervalles de temps mesurés par l'horloge durant la correction sont faux car plus longs.
  
  
• Ignorer la seconde intercalaire : le temps est continu, la fréquence de l'horloge est faiblement affectée, mais l'horloge est en dérive (retard) pendant environ 2 jours après la seconde intercalaire.

Perso, je retiens que le comportement par défaut, step back, suffit pour mes usages. Si besoin que le temps s'écoule de manière continue, utiliser les méthodes « slew » ou, si la dérive de l'horloge n'est pas un problème, ignorer la seconde intercalaire.

Notons que les paquets NTP disposent d'un drapeau « Leap Indicator » qui permet d'indiquer la seconde intercalaire durant les 24 heures précédant son application. Ce flag, qui est positionné par le serveur de strate 1 (celui directement raccordé à un appareil de mesure du temps genre GPS ou horloge atomique) ou par n'importe quel serveur de n'importe quelle strate, se transmet de serveurs NTP en serveur NTP et permet aux clients et serveurs NTP d'informer le noyau de l'imminence d'une seconde intercalaire. Le noyau stocke l'information et fera le changement à l'heure convenue universellement (23h59m59 UTC). Un reboot de la machine nécessite d'informer à nouveau le noyau, bien évidemment.

Comment un serveur de temps positionne-t-il le flag LI ? Soit parce que sa référence de temps le lui a appris, soit parce qu'il utilise un fichier publié par le NIST qui contient les secondes intercalaires passées et celles à venir, voir : http://support.ntp.org/bin/view/Support/ConfiguringNTP#Section_6.14 . Il faut évidemment garder ce fichier à jour (2 fois par an max).

Regardons ce flag avec tshark :

Network Time Protocol (NTP Version 4, server)
    Flags: 0x64
        01.. .... = Leap Indicator: last minute of the day has 61 seconds (1)
        ..10 0... = Version number: NTP Version 4 (4)
        .... .100 = Mode: server (4)
    Peer Clock Stratum: secondary reference (2)
    Peer Polling Interval: invalid (3)
    Peer Clock Precision: 0,000000 sec
    Root Delay:    0,0076 sec
    Root Dispersion:    0,0387 sec
    Reference ID: 145.238.203.14
    Reference Timestamp: Dec 31, 2016 12:46:39.884128000 UTC
    Origin Timestamp: Dec 31, 2016 13:02:54.234703000 UTC
    Receive Timestamp: Dec 31, 2016 13:02:54.341816000 UTC
    Transmit Timestamp: Dec 31, 2016 13:02:54.341864000 UTC

En temps normal :

Network Time Protocol (NTP Version 4, server)
    Flags: 0x24
        00.. .... = Leap Indicator: no warning (0)
        ..10 0... = Version number: NTP Version 4 (4)
        .... .100 = Mode: server (4)
    Peer Clock Stratum: secondary reference (2)
    Peer Polling Interval: invalid (3)
    Peer Clock Precision: 0,000000 sec
    Root Delay:    0,0076 sec
    Root Dispersion:    0,0500 sec
    Reference ID: 145.238.203.14
    Reference Timestamp: Apr  2, 2017 10:13:49.572752000 UTC
    Origin Timestamp: Apr  2, 2017 10:26:29.182950000 UTC
    Receive Timestamp: Apr  2, 2017 10:26:29.350805000 UTC
    Transmit Timestamp: Apr  2, 2017 10:26:29.350865000 UTC

Note "fun" : encore en 2017, il semblerait que des bugs surviennent dans le traitement informatique de la seconde intercalaire. « Amazingly there are also 4 servers that are off by a second in the wrong direction (like they applied the leap second twice). ». Source : https://community.ntppool.org/t/leap-second-2017-status/59 .