2017-01-27 2 views
4

Je lis sur la différence entre CLOCK_REALTIME et CLOCK_MONOTONICQuelle est l'utilité de CLOCK_REALTIME?

Difference between CLOCK_REALTIME and CLOCK_MONOTONIC?

Le CLOCK_REALTIME a discontinuités dans le temps, peuvent sauter vers l'avant ainsi que vers l'arrière: est qu'un bug dans cette horloge? Comment une horloge qui donne un temps incohérent peut-elle être fiable?

+2

L'heure d'été est un exemple d'horloge murale qui peut sauter d'avant en arrière. Notez également que cette réponse indique clairement * c'est l'estimation du système * - et quand elle détermine qu'une supposition précédente était désactivée, elle devine à nouveau. – usr2564301

+0

Qu'est-ce que cela signifie une supposition? Le système devine le temps = détermine l'heure avec quelques ns d'erreur – Bionix1441

+1

Dépend de ce que vous en avez besoin et de ce que vous proposez de faire avec, parfois, il est utile d'avoir un horodatage (pense à la journalisation), ou peut-être que vous voulez horodatage quelques objets (création, fin de transaction etc.) Où il est utile de connaître l'heure de quelque chose. NOTE: cela ne signifie en aucun cas que l'on peut mesurer la performance ... – Nim

Répondre

9

En dépit de ses imperfections, CLOCK_REALTIME devrait être la meilleure estimation du système de l'heure UTC ou civile actuelle. C'est la base de la capacité du système à afficher le même temps que vous verriez si vous regardiez votre montre, ou une horloge sur le mur ou votre téléphone portable, ou si vous écoutiez une heure diffusée sur une station de radio, etc. affichage n'implique une conversion de l'UTC à l'heure locale, plus tard)

Mais si CLOCK_REALTIME va correspondre à l'heure UTC là-bas dans le monde réel, il y a au moins deux questions assez importantes:.

  1. Que se passe-t-il si quelqu'un d'accidentellement met l'horloge sur votre ordinateur mal? Ils vont devoir le réparer, et le correctif pourrait impliquer un saut de temps. À peu près pas moyen de contourner cela, surtout si l'erreur est grande (comme, heures ou jours).
  2. La plupart des ordinateurs n'ont malheureusement aucun moyen de représenter les secondes intercalaires. Par conséquent, quand il y a une seconde dans le monde réel, la plupart des horloges doivent sauter un peu.

Alors, quand vous avez bien lu CLOCK_REALTIME pourrait avoir des discontinuités, pourrait sauter vers l'avant, ainsi que vers l'arrière, ce n'est pas un bug, il est une caractéristique: CLOCK_REALTIME doit avoir ces possibilités, si elle est de faire face au monde réel secondes intercalaires et parfois-mauvaises horloges. Donc, si vous écrivez du code qui est censé fonctionner avec des temps correspondant à ceux du monde réel, CLOCK_REALTIME est ce que vous voulez, les verrues et tout. Idéalement, cependant, vous écrivez votre code de manière à ce qu'il se comporte raisonnablement bien (ne plante pas ou ne fasse pas quelque chose de bizarre) si, de temps en temps, l'horloge saute vers l'avant ou vers l'arrière pour une raison quelconque.

Comme vous le savez probablement de l'autre question que vous avez mentionné, CLOCK_MONOTONIC est garanti à l'étape toujours en avant exactement une seconde par seconde, sans sauts ou discontinuités, mais la valeur absolue de l'horloge ne signifie pas grand-chose. Si la valeur CLOCK_MONOTONIC est 13:05, cela ne signifie pas que c'est juste après une heure de l'après-midi, cela signifie généralement que l'ordinateur est opérationnel depuis 13 heures et 5 minutes. Donc, si tout ce qui vous intéresse est le temps relatif, CLOCK_MONOTONIC est bien. En particulier, si vous voulez chronométrer combien de temps une chose a pris, prendre deux valeurs CLOCK_MONOTONIC et les soustraire est préférable, car cela ne vous donnera pas une mauvaise réponse s'il y a eu un saut de temps (qui aurait affecté CLOCK_REALTIME) dans entre. Ou, en résumé, comme les gens l'ont dit dans le fil de commentaires, CLOCK_REALTIME est ce dont vous avez besoin pour le temps absolu, alors que CLOCK_MONOTONIC est meilleur pour le temps relatif.

Maintenant, quelques points de plus. Comme mentionné précédemment, CLOCK_REALTIME n'est pas tout à fait "l'heure du mur", car il traite réellement en UTC. Il utilise la célèbre (infâme?) Représentation Unix/Posix de secondes depuis 1970. Par exemple, une valeur CLOCK_REALTIME de 1457852399 se traduit par 06:59:59 UTC le 13 mars 2016.Où je vis, cinq heures à l'ouest de Greenwich, cela se traduit par 01:59:59 heure locale. Mais une seconde plus tard, 1457852400 se traduit par 03:00:00, parce que l'heure avancée a commencé.

J'ai suggéré que si votre horloge était erronée, un saut de temps était à peu près la seule façon de le réparer, mais ce n'est pas plutôt vrai. Si votre horloge est seulement légèrement éteinte, il est possible de la corriger en "tournant" l'heure progressivement (en changeant légèrement la fréquence d'horloge) de sorte qu'après quelques minutes ou heures elle aura dérivé à l'heure correcte sans sauter. C'est ce que NTP essaie de faire, bien que, selon sa configuration, il ne soit disposé à le faire que pour des erreurs qui sont assez petites.

J'ai dit que CLOCK_MONOTONIC était généralement le moment où l'ordinateur était opérationnel. Ce n'est pas garanti par la norme; tout ce que dit la norme est que CLOCK_MONOTONIC compte le temps écoulé depuis un point de temps arbitraire. Sur les systèmes qui implémentent CLOCK_MONOTONIC au moment où le système a été mis en place, il peut y avoir deux interprétations: est-ce le temps écoulé depuis le démarrage ou le moment où le système a été démarré ou suspendu? ? Sur de nombreux systèmes, il y a encore une autre horloge CLOCK_BOOTTIME qui compte le temps écoulé depuis le démarrage (en cours ou suspendu), alors que CLOCK_MONOTONIC ne compte que le temps pendant lequel le système était opérationnel. Enfin, si vous voulez un temps d'horloge, mais vous voulez éviter les sauts ou les discontinuités à secondes intercalaires, vous avez un problème, à cause de la mauvaise gestion des secondes intercalaires dans Unix/Linux traditionnel (et Windows, et tous autres) systèmes informatiques. Sous les noyaux Linux récents (4.x?), Il y a un CLOCK_TAI qui peut aider. Certains systèmes expérimentaux peuvent implémenter encore une autre horloge, CLOCK_UTC, qui gère correctement les secondes intercalaires. Les deux coûts ont d'autres coûts, et il faudrait vraiment savoir ce que vous faisiez pour les utiliser efficacement, du moins avec le niveau de soutien d'aujourd'hui. Voir le LEAPSECS mailing list pour plus d'informations.

+2

Superbe réponse. Couvre toutes les bases d'une manière facile à digérer. –

+0

_ "C'est ce que NTP essaie de faire, bien qu'il s'avère qu'il ne le fasse que pour des erreurs assez petites (moins d'une seconde, je pense)." _ Ceci est entièrement configurable dans votre client NTP –

+0

@LightnessRacesinOrbit Cela dépend de votre client NTP, je pense. Je l'ai en vertu de bonne autorité que l'implémentation de référence ne va flotter que si l'erreur est inférieure à 128 millisecondes, et il n'y a aucun moyen de reconfigurer cette valeur. –