6
votes

Pourquoi les intervalles de GettimeOfday sont-ils occasionnellement négatifs?

J'ai une bibliothèque expérimentale dont la performance que j'essaie de mesurer. Pour ce faire, j'ai écrit ce qui suit: xxx

occasionnellement, mes résultats incluent des horaires négatifs, dont certains sont absorbants. Par exemple: xxx

Qu'est-ce qui se passe?


3 commentaires

Vous obtenez des négatifs car TIMEVAL est une structure multi-composants. en bref composé de deuxième et d'usecondes. Si vous diffusez naïvement les composants communs dans la 2e TV au 1er téléviseur, vous obtiendrez des négatifs. Par exemple, considérons TV1 comme étant 1sec 3Usec d'Epoch et TV2 étant 4sec et 1usec de Epoch. Comme vous pouvez vous constater, vous obtenez maintenant une valeur négative dans la différence entre les composants USEC.


Vous avez 4 réponses à cette question, pas l'une d'entre elles n'est même arrivée à fournir une réponse correcte pourtant, vous avez toujours sélectionné le plus non pertinent que la réponse finale.


Ajout intéressant, mais uniquement pertinent lors de l'utilisation d'un seul des composants, comme je le faisais (uniquement à l'aide des composants TV_USEC, pas les TV_SEC).


5 Réponses :


6
votes

Vous avez une faute de frappe. Correction dernière ligne (notez le nombre de 0): xxx

BTW, TIMERSUB est une méthode intégrée pour faire la différence entre deux Timevals. < / p>


4 commentaires

Putain, c'est embarrassant. :)


Pourquoi cela est-il considéré comme la réponse? Ce n'est pas correct, cela fixe simplement un petit bug dans la présentation du temps. Cela ne traite pas du problème fondamental de pourquoi les temps négatifs se présentent. Readers NOTE - Ce n'est pas une réponse valide!


@Zenikoder Oui, il fait. Ordinairement, la valeur absolue du Minuend (secondes * 1000000) serait plus grande que la sous-trahend, de sorte que même si vous avez enveloppé une seconde, vous ne seriez pas négatif. Dans ce cas, le minuend a toujours été trop petit (zéro manquant, facteur de 10), de sorte que les deuxièmes enveloppements ont fait des nombres négatifs relativement importants dans le sous-traitant.


Donc, fondamentalement, vous devez appliquer un cerveau à l'erreur pour la comprendre profondément, mais à peu près ... il répond toujours à la question. :)



3
votes

std :: COUT << "Heure:" << 100000 * (fin.tv_sec - begin.tv_sec) + (fin.tv_usec - begin.tv_usec) << STD :: endl;

Comme indiqué, il y a 1000000 USEC dans une seconde, pas 100000.

Plus généralement, vous devrez peut-être être conscient de l'instabilité du timing sur les ordinateurs. Des processus tels que NTPD peuvent changer les temps d'horloge, ce qui entraîne des temps de Delta incorrects. Vous pourriez être intéressé par des installations de POSIX telles que Timer_Create .


1 commentaires

Et la chose insidieuse à propos de NTPD est que cela le fait en petites étapes étalées dans le temps, il est donc plus difficile de remarquer.



-1
votes

faire

$ TIME ./proxy-application

la prochaine fois


1 commentaires

Cela ne me laisse pas le temps d'expérimenter lui-même. Toutes les participants à l'allocator de mémoire, la construction d'objets statiques et le chargement du programme sont inclus. De plus, ce n'est qu'à des secondes de granularité.



4
votes

Les bibliothèques Posix Realtime sont mieux adaptées à la mesure des intervalles de précision élevés. Vous ne voulez vraiment pas connaître l'heure actuelle. Vous voulez juste savoir combien de temps cela a été entre deux points. C'est ce que l'horloge monotone est pour. xxx

Lorsque vous vous trouvez, vous devez ajouter -lrt .

Utilisation de l'horloge monotone a plusieurs Avantages. Il utilise souvent les minuteries matérielles (cristal Hz ou autre), il s'agit donc souvent d'un appel plus rapide que GettimeOdday () . De plus, les minuteries monotoniques sont garanties de ne jamais revenir en arrière, même si NTPD ou un utilisateur greoting avec le temps système.


1 commentaires

J'ai oublié ce genre de choses! Mac OS n'applique pas les bibliothèques Posix Realtime. Vous êtes totalement juste, cependant.



3
votes

Vous avez pris soin de la valeur négative, mais cela n'est toujours pas correct. La différence entre les variables millisecondes est erronée, disons que nous avons des moments de départ et de fin sous les 1,100 et 2,051. Par la réponse acceptée, ce serait une période écoulée de 1,049, ce qui est incorrect.

Le code ci-dessous prend en charge les cas où il n'ya qu'une différence de millisecondes mais non secondes et le cas où la valeur de millisecondes déborde. xxx


0 commentaires