none
Stabilité de System.Timers.Timer RRS feed

  • Question

  • Bonjour,

    J'ai associé ce type de timer à un WindowsForm dans l'idée d'en vérifier la régularité. Le programme calcule simplement le temps de relaxation et l'affiche dans un label. Le comportement du timer (en AutoReset) est curieux avec une durée stable mais variant par paliers. Voici quelques résultats.

    Interval = 33 à 46 ms, mesure = 46 ms

    Interval = 47 à 62 ms, mesure = 62 ms

    A partir de la valeur par défaut de 100 ms, je mesure 110 pour 100, 117 pour 110, 125 pour 120, ce qui semble plus satisfaisant, mais 140 aussi bien pour Interval fixé à 130 qu'à 140.

    J'aimerais connaître votre avis.

    Cordialement.

    vendredi 28 septembre 2012 13:34

Réponses

  • Bonjour,

    Pouvez-vous faire le test avec ce genre de projet :

    http://www.codeproject.com/Articles/98346/Microsecond-and-Millisecond-NET-Timer

     

    Cordialement


    Merci de valider par "Proposer comme réponse" si celle-ci répond à votre demande !

    • Proposé comme réponse Papy Normand dimanche 28 octobre 2012 15:56
    • Marqué comme réponse Tirfon mercredi 31 octobre 2012 08:16
    mardi 23 octobre 2012 13:02
  • Bonjour,

    Pour System.Timers, MSDN vante la régularité de la période mais se garde de parler de l'irrégularité de la progression. Quand j'ai mesuré 62 ms pour un Interval de 62, je passe à 78 pour un Interval de 63, une aberration. Avec une erreur parfois nulle, parfois d'une quinzaine de ms selon la valeur d'Interval, ce timer est inutilisable pour régler une fréquence. J'essaierai System.Threading en espérant que les ingénieurs ont compté au-delà de 15 Hz.
    Cela n'est pas une aberration mais dépend du Scheduler de Windows et des processus en cours d'exécution qui s'exécute sur votre ordinateur.
    En effet, en programmant un Timer toutes les x ms, Windows ne garanti pas que votre processus sera appelé toutes les x ms (et encore heureux !)... Si d'autres processus sont prioritaires, Windows les exécutera et votre application sera exécuté plustard... C'est ce qui explique ce retard...

    Au passage le Scheduler de Windows a été amélioré depuis Vista, vous aurez certainement des différences sur un XP ou un Vista (et versions ultérieures).

    Le Timer System.Threading est le Timer le plus bas niveau du .NET Framework. Le Timer System.Timers est une version orienté "Component" de System.Threading. Vous obtiendrez donc quasiment les mêmes performances.

    Cordialement


    Gilles TOURREAU - MVP C#
    Architecte logiciel/Consultant/Formateur Freelance
    Blog : http://gilles.tourreau.fr
    - MCPD : Enterprise Developper / Windows Developper 3.5 / ASP .NET 3.5/4.0
    - MCITP : SQL Server 2008 Developper
    - MCTS : ADO .NET 3.5 / SQL Server 2008 Developper / Windows Forms 3.5 / ASP .NET 3.5/4.0

    • Marqué comme réponse Aurel Bera lundi 1 octobre 2012 07:41
    dimanche 30 septembre 2012 21:23
    Modérateur

Toutes les réponses

  • Et oui personne n'est parfait :)

    je crois que c'est dépendant du tickrate système. J'avais aussi constaté ce genre de problème mais comme le timer est basé sur le ms pas micro-sec. Je crois qu'en utilisant le timer dans le namespace system.threading ou mediadispatcher a voir.


    Merci de valider par "Proposer comme réponse" si celle-ci répond à votre demande !

    vendredi 28 septembre 2012 16:16
  • Pour System.Timers, MSDN vante la régularité de la période mais se garde de parler de l'irrégularité de la progression. Quand j'ai mesuré 62 ms pour un Interval de 62, je passe à 78 pour un Interval de 63, une aberration. Avec une erreur parfois nulle, parfois d'une quinzaine de ms selon la valeur d'Interval, ce timer est inutilisable pour régler une fréquence. J'essaierai System.Threading en espérant que les ingénieurs ont compté au-delà de 15 Hz.
    vendredi 28 septembre 2012 17:28
  • Bonjour,

    Pour System.Timers, MSDN vante la régularité de la période mais se garde de parler de l'irrégularité de la progression. Quand j'ai mesuré 62 ms pour un Interval de 62, je passe à 78 pour un Interval de 63, une aberration. Avec une erreur parfois nulle, parfois d'une quinzaine de ms selon la valeur d'Interval, ce timer est inutilisable pour régler une fréquence. J'essaierai System.Threading en espérant que les ingénieurs ont compté au-delà de 15 Hz.
    Cela n'est pas une aberration mais dépend du Scheduler de Windows et des processus en cours d'exécution qui s'exécute sur votre ordinateur.
    En effet, en programmant un Timer toutes les x ms, Windows ne garanti pas que votre processus sera appelé toutes les x ms (et encore heureux !)... Si d'autres processus sont prioritaires, Windows les exécutera et votre application sera exécuté plustard... C'est ce qui explique ce retard...

    Au passage le Scheduler de Windows a été amélioré depuis Vista, vous aurez certainement des différences sur un XP ou un Vista (et versions ultérieures).

    Le Timer System.Threading est le Timer le plus bas niveau du .NET Framework. Le Timer System.Timers est une version orienté "Component" de System.Threading. Vous obtiendrez donc quasiment les mêmes performances.

    Cordialement


    Gilles TOURREAU - MVP C#
    Architecte logiciel/Consultant/Formateur Freelance
    Blog : http://gilles.tourreau.fr
    - MCPD : Enterprise Developper / Windows Developper 3.5 / ASP .NET 3.5/4.0
    - MCITP : SQL Server 2008 Developper
    - MCTS : ADO .NET 3.5 / SQL Server 2008 Developper / Windows Forms 3.5 / ASP .NET 3.5/4.0

    • Marqué comme réponse Aurel Bera lundi 1 octobre 2012 07:41
    dimanche 30 septembre 2012 21:23
    Modérateur
  • Bonjour,

    Pouvons-nous considérer que vous avez résolu votre problème avec les scénarios proposés ? Dans l'affirmative, pourriez-vous partager avec nous la solution, afin que d'autres personnes avec le même problème puissent profiter de cette solution ?

    Désormais, nous marquons les solutions proposées. N'hésitez pas à revenir et supprimer la réponse marquée si la solution n’est pas correcte. Merci !

    Cordialement,

    Aurel


    Aurel BERA, Microsoft
    Microsoft propose ce service gratuitement, dans le but d'aider les utilisateurs et d'élargir les connaissances générales liées aux produits et technologies Microsoft. Ce contenu est fourni "tel quel" et il n'implique aucune responsabilité de la part de Microsoft.

    lundi 1 octobre 2012 07:42
  • Résolu, pas vraiment, mais je n'ai pas le choix puisque System.Timers dériverait de System.Threading. Il n'y aurait donc aucun progrès en matière de régularité, ce qui n'explique d'ailleurs pas pourquoi certaines valeurs faibles, toujours les mêmes (15 ms par ex., moins de 70 Hz, à peine mieux que la fréquence du secteur), sont curieusement beaucoup plus stables.  Je contournerai le problème en calant Interval par programme sur la plus basse d'entre-elles.

    Cordialement.

    lundi 15 octobre 2012 16:12
  • Bonjour,

    C'est tout simplement la résolution de ce timer (16 ms de mémoire) qui provoque cet effet de pallier. Après tout dépend de l'usage.

    Il existe des timers avec une précision plus haute (pour le multimédia et il faut sans doute utiliser l'API Windows) mais à la base Windows n'est pas un OS temps réel (et est-ce vraiment un timer dont on a besoin ou veut on mesurer des durées ?).


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".

    dimanche 21 octobre 2012 10:15
    Modérateur
  • Bonjour à tous,

    Si tu veux avoir de meilleur performance je t'invite à créer ton propre Timer avec des perfcounter :) et surtout de ne pas utiliser des event comme callback de fin de timer car ces appels peuvent peuvent prendre beaucoup de temps.

    J'ai du programmer un Timer avec une haute performance car celui de Windows était trop aléatoire pour ce que je fais, et avec les perfCounter je tombe a une précision de 4ms en moyenne...

    mardi 23 octobre 2012 11:58
  • Bonjour,

    Pouvez-vous faire le test avec ce genre de projet :

    http://www.codeproject.com/Articles/98346/Microsecond-and-Millisecond-NET-Timer

     

    Cordialement


    Merci de valider par "Proposer comme réponse" si celle-ci répond à votre demande !

    • Proposé comme réponse Papy Normand dimanche 28 octobre 2012 15:56
    • Marqué comme réponse Tirfon mercredi 31 octobre 2012 08:16
    mardi 23 octobre 2012 13:02