Il est temps de laisser la seconde intercalaire dans le passé

Le concept de seconde intercalaire a été introduit pour la première fois en 1972 par le Service international de la rotation terrestre et des systèmes de référence (IERS) dans le but de mettre à jour périodiquement Temps universel coordonné (UTC) en raison d’une inexactitude temps solaire observé (UT1) et à long terme ralentissement de la rotation de la Terre. Cet ajustement périodique profite principalement aux scientifiques et aux astronomes, car ils peuvent observer les corps célestes en utilisant l’UTC dans la plupart des cas. S’il n’y avait pas de correction UTC, des ajustements devraient être apportés à l’équipement et aux logiciels obsolètes qui se synchronisent à l’UTC pour les observations astronomiques.

À ce jour, depuis l’introduction de la seconde intercalaire, UTC a été mis à jour 27 fois.

Alors que la seconde intercalaire était peut-être une solution acceptable en 1972, alors qu’elle plaisait à la fois à la communauté scientifique et à l’industrie des télécommunications, l’UTC est aujourd’hui tout aussi néfaste pour les applications numériques que pour les scientifiques, qui choisissent souvent TAI ou UT1 à la place.

Chez Meta, nous soutenons un effort de l’industrie pour arrêter les futures introductions de secondes intercalaires et rester au niveau actuel de 27. L’introduction de nouvelles secondes intercalaires est une pratique risquée qui fait plus de mal que de bien, et nous pensons qu’il est temps que de nouvelles technologies la remplacent.

acte de foi

L’un des nombreux facteurs qui contribuent aux irrégularités de la rotation de la Terre est la fonte et le regel constants des calottes glaciaires sur les plus hautes montagnes du monde. Ce phénomène peut être facilement visualisé en pensant à un patineur artistique en rotation, contrôlant la vitesse angulaire en contrôlant ses bras et ses mains. Au fur et à mesure qu’ils écartent les bras, la vitesse angulaire diminue, préservant l’élan du patineur. Une fois que le patineur rétracte ses bras, la vitesse angulaire augmente.

Pensez à un patineur artistique en rotation pour visualiser le changement de vitesse angulaire.

Jusqu’à présent, seules des secondes intercalaires positives ont été ajoutées. Au début, cela se faisait simplement en ajoutant une seconde supplémentaire, ce qui entraînait un horodatage inhabituel :

23:59:59 -> 23:59:60 -> 00:00:00

Au mieux, un tel saut dans le temps faisait planter des programmes ou même des données corrompues, en raison d’horodatages étranges dans le magasin de données.

Avec le changement du schéma de rotation de la Terre, il est très probable que nous aurons une seconde intercalaire négative à un moment donné dans le futur. L’horodatage ressemblerait alors à ceci :

23:59:58 -> 00:00:00

L’impact d’une seconde intercalaire négative n’a jamais été largement testé ; cela peut avoir un effet dévastateur sur les logiciels qui reposent sur des minuteries ou des planificateurs.

Dans tous les cas, chaque seconde intercalaire est une source majeure de douleur pour les personnes qui gèrent les infrastructures matérielles.

diffamer

Plus récemment, il est devenu courant de “salir” une seconde intercalaire en ralentissant ou en accélérant simplement l’horloge. Il n’y a pas de moyen universel de le faire, mais chez Meta, nous maculons la seconde intercalaire pendant 17 heures à partir de 00:00:00 UTC basé sur le contenu du paquet de données de fuseau horaire (tzdata).

seconde intercalaire
A sauté le deuxième frottis à Meta.

Décomposons un peu cela.

Nous avons opté pour une durée de 17 heures, principalement parce qu’il y a un maculage sur la strate 2, où des centaines NTP graisser les serveurs en même temps. Pour que la différence entre les deux soit acceptable, les étapes doivent être minimales. Si les étapes de lubrification sont trop importantes, les clients NTP peuvent considérer certains appareils comme défectueux et les exclure du quorum, entraînant une panne.

Le point de départ à 00:00:00 UTC n’est pas non plus standardisé et de nombreuses options sont possibles. Par exemple, certaines entreprises commencent le graissage à 12:00:00 UTC la veille et pendant 24 heures ; certains le font deux heures avant l’événement, et d’autres en périphérie.

Il existe également plusieurs algorithmes sur la lubrification elle-même. Il y a une correction par deuxième intercalaire du noyau, un maculage linéaire (lorsque des étapes égales sont appliquées), un cosinus et un quadratique (qui utilise Meta). Les algorithmes sont basés sur différents modèles mathématiques et produisent différents graphiques de décalage :

seconde intercalaire
Graisser le noyau saut en seconde avec NTPD

La source de l’indicateur de saut diffère selon les constellations GNSS (par exemple GPS, GLONASS, Galileo et BeiDou). Dans certains cas, elle est diffusée par satellite plusieurs heures à l’avance. Dans d’autres cas, l’heure est propagée en UTC avec le saut déjà appliqué. Dans différentes constellations, la valeur de la seconde intercalaire diffère selon le moment où elle a été lancée.

seconde intercalaire
Différence de valeurs de seconde intercalaire entre les constellations GNSS.

Tout cela nécessite la logique de conversion non triviale dans les sources temporelles, y compris la nôtre Dispositif de temps. La perte d’un signal GNSS pendant une période aussi sensible peut entraîner la perte d’un indicateur de saut et une situation de cerveau divisé, ce qui peut entraîner un dysfonctionnement.

L’événement Leap sera également distribué des mois à l’avance via le package tzdata et pour les fans de ntpd via un saut deuxième fichier distribué via le site Web de l’Internet Engineering Taskforce (IETF). Ne pas avoir une nouvelle copie du fichier peut vous faire oublier une seconde intercalaire et provoquer un dysfonctionnement.

Comme mentionné, le maculage est un moment très sensible. Si le serveur NTP est redémarré pendant ce temps, nous nous retrouverons probablement avec “l’ancienne” ou la “nouvelle” heure, qui peut se propager aux clients et entraîner une panne.

En raison de telles ambiguïtés, les pools NTP publics ne font pas de maculage et transmettent parfois un indicateur de saut aux clients pour résoudre ce problème. Les clients SNTP règlent généralement l’horloge et gèrent les conséquences décrites précédemment. Les clients plus intelligents peuvent choisir une stratégie standard pour étendre le saut localement. Dans l’ensemble, cela signifie que les grands acteurs comme Meta, qui salissent les services publics, ne peuvent pas rejoindre les piscines publiques.

Et même après le saut, les choses sont toujours en danger. Le logiciel NTP doit constamment appliquer un décalage par rapport à la source de temps qu’il utilise (GNSS, TAI ou horloge atomique), et le logiciel PTP doit diffuser un drapeau dit de décalage UTC dans les messages d’annonce.

L’impact négatif des secondes intercalaires

La seconde intercalaire et la compensation qu’elle crée causent des problèmes dans l’ensemble de l’industrie. L’un des moyens les plus simples de provoquer une panne est de penser que le temps avance toujours. Supposons que nous ayons un code comme celui-ci :

start := time.Now()

// faire quelque chose

dépensé := time.Now().Sub(start)

Selon comment Publié est utilisé, nous pouvons nous retrouver dans une situation où nous comptons sur une valeur négative lors d’un événement intercalaire. De telles hypothèses ont conduit à de nombreux échecs et de nombreux articles décrivent ces cas.

En 2012, Reddit expérimenté une énorme perturbation d’une seconde intercalaire ; le site a été inaccessible pendant 30 à 40 minutes. Cela s’est produit lorsque le changement d’heure a chamboulé le timer haute résolution (hrtimer), provoquant une hyperactivité sur les serveurs, bloquant les CPU des machines.

En 2017, Cloudflare a publié un très article détaillé sur l’impact d’une seconde intercalaire sur le DNS public de l’entreprise. La cause première du bogue qui a affecté leur service DNS était la conviction que le temps ne peut pas revenir en arrière. Le code a pris les valeurs de temps en amont et les a transmises à la fonction rand.Int63n() de Go. La fonction rand.Int63n() a immédiatement paniqué car l’argument était négatif, provoquant l’échec du serveur DNS.

Au-delà de la seconde intercalaire

Les événements intercalaires ont créé des problèmes dans l’ensemble de l’industrie et continuent de poser de nombreux risques. En tant qu’industrie, nous rencontrons des problèmes lorsqu’une seconde intercalaire est introduite. Et parce que c’est un événement si rare, il dévaste la communauté à chaque fois qu’il se produit. Avec une demande croissante de précision d’horloge dans toutes les industries, la seconde intercalaire fait maintenant plus de dégâts que de bien, entraînant des pannes et des pannes.

En tant qu’ingénieurs chez Meta, nous soutenons une communauté plus large pour arrêter l’introduction future des secondes intercalaires et rester au niveau actuel de 27, ce qui, selon nous, sera suffisant pour le prochain millénaire.

Leave a Reply

Your email address will not be published.