Combien de timer gérés par XP

Bonjour,

Je cherche désespérément une information concernant le nombre de timer disponible dans Windows (XP principalement, mais les autres versions aussi).
Que ce soit le nombre de timer disponibles globalement dans le système ou par process ou même par thread.

Le constat que j'ai pu faire est celui-ci :

• - timeSetEvent : max = 16 :( par process et très précis (250 ms tenu sur les 16 sans problème)
  
• - CreateTimerQueueTimer : pas trouvé le max (cela fonctionne avec 34 timers :lol:, chacun dans un thread différent) mais cela perd rapidement de la précision (paramétré à 250 ms, obtenu = 270 ms :( ) quelque soit la valeur fixée pour le dernier paramètre de la fonction.
  
• - Waitable timer : pas trouvé le max et aussi précis que le timeSetEvent (250 ms tenu avec 34 timers :lol:, chacun dans un thread différent).

J'ai bien entendu parcouru ce tutoriel indispensable : http://www.codeproject.com/kb/system/timers_intro.aspx mais on y parle plus de précision que de quantité. J'ai également fouillé les pages de ce forum et du msdn, etc. sans trouvé une info détaillée et claire sur le sujet.

La raison pour laquelle j'ai besoin de cette info est simple : mon application permet de relever des mesures sur X détecteurs (peu importe le bus de communication) toutes les 250 ms (sinon perte d'une mesure) et je dois annoncer quelle est la limite max de détecteur "surveillable" en clair quelle est la valeur max de X. Et la seule limite que j'ai trouvée - pour le moment Cf. remarque sur le timeSetEvent ;) -était liée au nombre de timers lancés en parallèle.

Donc je vous remercie pour toutes les infos que vous pourrez m'apporter sur ce sujet.

Tu veux dire que tu as un thread par équipement à surveiller ?

Et pourquoi pas un thread pour plusieurs équipements (10 par exemple ?)

Merci pour ta réponse.

Tu as raison, cela pourrait être une alternative. :ccool:

Mais ce que je n'ai pas dit, c'est qu'en fait d'application, le produit est une DLL d'interface avec les détecteurs, que nous proposons, pour pouvoir implémenter des applications à la demande. Ce qui signifie que nous ne savons pas à l'avance quelle sera la configuration utilisée. :roll:

L'information supplémentaire, c'est qu'il existe une 15 de détecteurs possibles différents avec des caractéristiques et des temps d'interrogation qui peuvent être également différents et de plus des modes d'interrogation différents aussi, sans parler de bus de communication très variés également. :lol:

Donc nous avons choisi - mais peut-être n'est-ce pas forcément la meilleure architecture - de dédié un thread à chaque détecteur. :calim2:

D'où mon interrogation sur le nombre de timers, puisque le nombre de timers sera égal au nombre de détecteurs "supervisables".

Je ne suis pas sûr qu'il y ait une limite au nombre de timer.

Si on prend le Waitable timer par exemple, j'ai l'impression que chaque thread vient avec son pool de Waitable timer et donc tant que tu peux créer des threads, tu auras tes timers.

Je pense plutôt que la limite sera sur le nombre de threads que tu peux créer (ce sont des ressources couteuses tout de même). Et après, même si tu peux en créer beaucoup, est ce que l'ordonnencement de tout cela ne va pas être couteux et ralentir le système.

Un thread réveillé toutes les 250ms, pas de problèmes mais 100 thread réveillés toutes les 250ms, je ne sais pas ce que cela va donner. Fait un essai.

Il faudrait aussi connaitre la limite que tu te donnes en termes de nombre d'équipements manageables par ton appli et par poste (100, 1 000, 10 000...). Cette limite est à la fois technique (puissance du poste, RAM, CPU) mais probablement aussi commerciale (license).

Une nouvelle fois merci pour ta réponse.

Je suis d'accord avec toi sur le nombre de thread, si la limite n'est pas le nombre de timers, alors ce sera cela ma limite.

Ta dernière remarque est tout à fait juste, et c'est même le cœur de mon interrogation : quelle est la limite d'équipement que je peux manager par poste ?
Avant d'avoir une limite "marketing/commerciale" il faut que je connaisse la limite technique.

Et aujourd'hui, après être tombé dans le trou des 16 timeSetEvent max :(, je ne dispose pas de suffisamment d'équipements disponibles (flux tendu + cout de fab... :cry:) en même temps pour la déterminer pas l'expérience, il me faut des données théoriques pour étayer mon argument. Nous sommes actuellement à 34 équipements, raisonnablement, je pense pouvoir annoncer 50 (ce qui est déjà beaucoup pour ce type d'application) mais comment le garantir sans faire de véritables essais ? 8O

Au delà de 50, ce sera sûrement un autre poste.

Si tu ne peux pas avoir une 100 d'équipements, tu peux peut voir à les simuler.

Lancer 100 (ou 1000) threads qui font une attente de 250 ms et qui font quelque chose qui modélisera le fonctionnement de ton équipement :

• même durée durée de traitement
• chargeant la CPU identique
• sollicitation de la mémoire similaire
• accès disque similaire
• ...

Déjà, tu verras bien comment réagit ton appli avec 100 threads qui travaillent toutes les 250ms. Si cela marche, tu augmentes les valeurs de manière à connaitre les limites théoriques.

Autre chose, pout t'aider à calculer le nombre d'équipements théoriques maximal, peut être que le bon sens suffit. Est ce que cela à un sens d'avoir 100 équipements.

Si on imagine que tes équipements sont des thermomètres, et que le PC gère la maison, est ce que cela à un sens de pouvoir gérer 100 sondes thermiques. Personnellement, je pense qu'avec 20 (dans cet exemple), on atteint les limites du bon sens raisonnable.

OK pour la simulation, même si cela reste une simulation, c'est vrai qu'elle peut apporter des éléments d'information sur le nombre de thread simultanés possibles. :)

Pour le bon sens, je te rejoins, c'est pour cela que j'indiquais que 50 détecteurs me semblait un chiffre raisonnable. :)

Après tu connais sûrement des gens du marketing pour qui il est important d'annoncer des chiffres ronflants :zoubi: (comme les vitesses max pour les voitures ! :lol:) et bien nous en avons aussi. :mrgreen: qui

Il me faut donc des arguments techniques solides pour formuler ma réponse face à eux qui n'ont qu'une spec : "le plus sera le mieux !" comme règle marketing. :cry: