Quelle est la précision du python du temps.sleep()?

Je peux donner des nombres à virgule flottante, comme

time.sleep(0.5)

mais quelle est la précision? Si je vous le donne

time.sleep(0.05)

va vraiment dormir environ 50 ms?

InformationsquelleAutor Claudiu | 2009-07-15

67

La précision de l'heure.fonction de sommeil dépend de votre OS sous-jacent de sommeil précision. Pour les non-OS temps réel est comme un stock de Windows le plus petit intervalle, vous pouvez dormir pendant environ 10-13ms. J'ai vu précis dort dans plusieurs millisecondes de temps quand au-dessus du minimum de 10 13ms.

Mise à jour:
Comme mentionné dans les documents cités ci-dessous, il est commun de faire de la veille dans une boucle qui fera en sorte d'aller de nouveau au sommeil si elle vous réveille tôt.

Je dois aussi mentionner que si vous utilisez Ubuntu, vous pouvez essayer un pseudo-noyau temps-réel (avec le RT_PREEMPT jeu de patch) par l'installation de la rt paquet de noyau (au moins dans Ubuntu 10.04 LTS).

EDIT: Correction de la non-temps réel noyaux Linux ont un minimum de sommeil intervalle beaucoup plus proche de 1ms puis 10ms, mais il varie dans un non-déterministe manière.
- En fait, le noyau Linux a manqué à une hausse de la tique taux pour un certain temps, de sorte que le "minimum" le sommeil est beaucoup plus proche de 1 ms de 10ms. Il n'est pas garanti -, d'autres de l'activité du système peut rendre le noyau impossible de planifier votre processus dès que vous le souhaitez, même sans contention du PROCESSEUR. C'est ce que le temps réel, les grains sont d'essayer de les corriger, je pense. Mais, à moins que vous vraiment besoin en temps réel le comportement, simplement en utilisant une haute tique taux (noyau HZ réglage) vous obtiendrez non-garantis-mais-haute résolution dort sous Linux sans l'aide de quelque chose de spécial.
- Oui, vous avez raison, j'ai essayé avec Linux 2.6.24-24 et a été en mesure d'obtenir à peu près à 1000 Hz taux de mise à jour. À l'époque, je faisais cela, j'ai été également à l'exécution du code sur Mac et Windows, donc j'ai sans doute confondu. Je sais que windows XP au moins a une tique taux d'environ 10ms.
- Sur Windows 8 je reçois peu moins de 2ms
- Aussi la précision n'est pas seulement tributaire de l'OS, mais ce que l'OS est en train de faire à la fois sur Windows et Linux, si ils sont occupés à faire quelque chose de plus important sleep() de la docs "la période de suspension peut être plus longue que ce qui est demandé par une quantité arbitraire à cause de la tenue d'une autre activité dans le système".
InformationsquelleAutor Joseph Lisee
49

Les gens sont tout à fait raison sur les différences entre les systèmes d'exploitation et des noyaux, mais je ne vois pas de granularité dans Ubuntu, et je vois un 1 ms granularité dans MS7. Ce qui suggère une mise en œuvre différente de temps.sommeil, pas juste une autre tique taux. Une inspection plus minutieuse suggère un 1µs granularité dans Ubuntu par le sens, mais qui est due à la fois.le temps de la fonction que j'utilise pour la mesure de la précision.
- Il est intéressant de voir comment Linux a choisi de toujours dormir un peu plus longtemps que ce qui est demandé, alors que Microsoft ont choisi l'approche opposée.
- le linux démarche fait sens pour moi: le sommeil est vraiment un communiqué de la priorité d'exécution pour un montant de temps après lequel vous encore une fois de vous soumettre à la volonté de l'ordonnanceur (qui peut ou peut ne pas vous programmer pour l'exécution tout de suite).
- Très vrai.
- Sur Windows 8, je ne vois pas Windows dormir pour moins que le temps demandé aussi, je suis capable de dormir pour moins de 1ms, mais n'importe où en dessous de 1 ms je obtenir 0.00009 ms! (c'est peut-être pas dormir du tout)
- J'ai donné une autre réponse à cette question à partir d'OS X Yosemite. Comportement complètement différent à partir de Windows ou de Linux.
- comment avez-vous les résultats? Peut fournir le code source? Le graphique ressemble à un artefact de l'utilisation de différentes minuteries pour mesurer le temps et le sommeil (En principe, vous pourriez même l'utilisation de la dérive entre les compteurs à zéro en tant que source de l'aléatoire).
- Sebastian - La fonction que j'ai utilisé est en socsci.ru.nl/wilberth/computer/sleepAccuracy.html . Le troisième graphique, il montre un effet similaire à ce que vous voyez, mais de seulement 1‰.
- sur Windows peut être pire que sur Linux. Votre essayé de l'exécuter à l'aide de timeit.default_timer à la place?
- Sebastian je utiliser le temps.clock() sur windows
- Disponible time.sleep() utilise millisecondes sur Windows, ce qui explique l'absence de sous-ordre de la milliseconde dort.
InformationsquelleAutor Wilbert
25

De la la documentation:

D'autre part, la précision de
time() et sleep() est mieux que
leurs équivalents Unix: les temps sont
exprimé en nombres à virgule flottante,
time() renvoie la plus précise
disponible (en utilisant Unix gettimeofday
lorsqu'ils sont disponibles), et sleep() va
accepter un temps avec une fraction non nulle
(Unix select est utilisé pour mettre en œuvre
ce, le cas échéant).

Et plus précisément w.r.t. sleep():

Suspendre l'exécution pour le nombre donné
de secondes. L'argument peut être un
nombre à virgule flottante à indiquer un
plus précise du temps de sommeil. Le réel
le temps de suspension de peut-être moins que
demandé parce que tout pris signal
mettra fin à l' sleep() suivants
l'exécution de ce signal de l'attraper
de routine. Aussi, le temps de suspension peut
être plus que ce qui est demandé par un
quantité arbitraire en raison de la
la planification d'une autre activité dans le
système d'.
- Quelqu'un peut-il expliquer le "parce que tout pris signal de résilier le sleep() à la suite de l'exécution de ce signal de capture de routine"? Les signaux qui est-il référence? Merci!
- Les signaux sont comme les notifications que l'OS gère (en.wikipedia.org/wiki/Unix_signal), cela signifie que si le système d'exploitation pris un signal, le sleep() est terminée après le traitement de ce signal.
InformationsquelleAutor Stephan202
17

Voici mon suivi de Wilbert réponse: la même chose pour Mac OS X Yosemite, puisqu'il n'est pas mentionné encore beaucoup.

Ressemble beaucoup à du temps il dort environ 1,25 fois l'heure de la demande et dort parfois entre 1 et 1,25 fois le temps de votre demande. Presque jamais (~deux fois sur 1000 échantillons) dort beaucoup plus que 1,25 fois le temps de votre demande.

Aussi (pas indiqué explicitement) de 1,25 relation semble tenir plutôt bien jusqu'à ce que vous obtenez en dessous d'environ 0,2 ms, après quoi il commence à avoir un peu floue. En outre, le temps semble s'installer à environ 5 ms de plus que vous demande après le laps de temps requis obtient au-dessus de 20 ms.

Encore une fois, il semble être un de complètement différent de la mise en œuvre de sleep() sous OS X que sous Windows ou n'importe quel Linux kernel Wilbert était de l'utiliser.
- Pourriez-vous télécharger le code source de la référence à github/bitbucket?
- Oui, le code est ici.
- J'ai essayé il sur ma machine. Le résultat est similaire à @Wilbert réponse.
InformationsquelleAutor Tim Supinie
15

Pourquoi ne pas vous trouver:
```
from datetime import datetime
import time

def check_sleep(amount):
    start = datetime.now()
    time.sleep(amount)
    end = datetime.now()
    delta = end-start
    return delta.seconds + delta.microseconds/1000000.

error = sum(abs(check_sleep(0.050)-0.050) for i in xrange(100))*10
print "Average error is %0.2fms" % error
```
Pour l'enregistrement, je reçois l'ordre de 0,1 ms erreur sur mon HTPC et 2ms sur mon ordinateur portable, les deux machines linux.
- Les tests empiriques va vous donner un point de vue étroit. Il y a beaucoup de noyaux de systèmes d'exploitation et des configurations qui l'influencent. Anciens noyaux Linux par défaut à une diminution de l'tique de taux, d'où une plus grande granularité. Dans l'implémentation Unix, un signal externe pendant le sommeil va l'annuler à tout moment, et d'autres implémentations pourraient en avoir des interruptions.
- Bien sûr, l'observation empirique n'est pas transférable. Outre les systèmes d'exploitation et des noyaux, il y a beaucoup de questions transitoires qui l'influencent. Si dur en temps réel, des garanties sont requises, puis l'ensemble de la conception du système à partir de matériel doit être pris en considération. Je viens de trouver les résultats les plus pertinents compte tenu des déclarations que les 10ms est le minimum de précision. Je ne suis pas à la maison dans le monde Windows, mais la plupart des distributions linux ont été en cours d'exécution tickless noyaux pour un certain temps maintenant. Avec multicores désormais très répandue, il est assez probable pour obtenir programmée vraiment proche de l'expiration du délai.
- +1 pour la belle empiriques code
InformationsquelleAutor Ants Aasma
4

Une petite correction, plusieurs personnes mentionnent que le sommeil peut être terminé au début par un signal. Dans le 3.6 docs il dit,

Changé dans la version 3.5: La fonction dort maintenant au moins secs, même si
le sommeil est interrompu par un signal, sauf si le gestionnaire de signal
lève une exception (voir PEP 475 pour le raisonnement).

InformationsquelleAutor user405
2

Vous ne pouvez pas vraiment quoi que ce soit garantie sur sleep(), sauf qu'il va au moins faire un meilleur effort de dormir aussi longtemps que vous lui avez dit (signaux peuvent tuer votre sommeil avant le temps est écoulé, et beaucoup plus de choses peuvent faire courir de long).

Pour assurer le minimum que vous pouvez obtenir sur un ordinateur de bureau standard du système d'exploitation va être autour de 16ms (minuterie de granularité plus le temps de changement de contexte), mais les chances sont que le % de l'écart à partir de l'argument fourni est importante quand vous êtes à essayer de dormir pendant 10s de millisecondes.

Signaux, les autres threads tenue de la GIL, d'ordonnancement du noyau de plaisir, un processeur de vitesse pas à pas, etc. peuvent jouer des ravages avec la durée de votre thread/processus dort.
- La documentation dit le contraire: > La période de suspension peut être inférieure à celle demandée, car tout pris signal de résilier le sleep() à la suite de l'exécution de ce signal de capture de routine.
- Ah juste point, fixe le post, bien que de plus en plus longues dort() est beaucoup plus susceptibles que les plus courts.
- Deux ans et demi plus tard ... la documentation se trouve encore. Sur Windows, les signaux de ne pas mettre fin à sleep(). Testé sur Python 3.2, WinXP SP3.
- Oui, mais les signaux préjuger de sommeil est insolites, par exemple, de TUER, de la documentation dit aussi: "en outre, la période de suspension peut être plus longue que ce qui est demandé par une quantité arbitraire à cause de la tenue d'une autre activité dans le système." qui est plus typique.
- Singnals et Windows est tout simplement ridicule. Sous Windows, le Python de temps.sleep() attend une ConsoleEvent pour capturer des trucs comme Ctrl-C.
- href="https://docs.python.org/3/library/time.html#time.sleep" >Python 3.5: "La fonction dort maintenant au moins secs, même si le sommeil est interrompu par un signal, sauf si le gestionnaire de signal soulève une exception"
InformationsquelleAutor Nick Bastin
0

Testé récemment sur Python 3.7 sur Windows 10. La précision a été autour de 1ms.

InformationsquelleAutor Aleksandar Kiridžić
0
```
def start(self):
    sec_arg = 10.0
    cptr = 0
    time_start = time.time()
    time_init = time.time()
    while True:
        cptr += 1
        time_start = time.time()
        time.sleep(((time_init + (sec_arg * cptr)) - time_start ))

        # AND YOUR CODE .......
        t00 = threading.Thread(name='thread_request', target=self.send_request, args=([]))
        t00.start()
```
Ne pas utiliser une variable pour passer l'argument de sleep (), vous devez insérer le calcul directement dans le sommeil ()

Et le retour de mon terminal

1 ───── 17:20:16.891 ───────────────────

2 ───── 17:20:18.891 ───────────────────

3 ───── 17:20:20.891 ───────────────────

4 ───── 17:20:22.891 ───────────────────

5 ───── 17:20:24.891 ───────────────────

....

689 ─── 17:43:12.891 ────────────────────

690 ─── 17:43:14.890 ────────────────────

691 ─── 17:43:16.891 ────────────────────

692 ─── 17:43:18.890 ────────────────────

693 ─── 17:43:20.891 ────────────────────

...

727 ─── 17:44:28.891 ────────────────────

728 ─── 17:44:30.891 ────────────────────

729 ─── 17:44:32.891 ────────────────────

730 ─── 17:44:34.890 ────────────────────

731 ─── 17:44:36.891 ────────────────────

InformationsquelleAutor forrest

Vous devez vous connecter pour publier un commentaire.