En effet, je n’ai plus de problème de freeze de ping, ceux-ci se font bien toutes les minutes et les status sont rafraichis à chaque fois.
Cependant je constate que très souvent, le status tombe à zéro pendant 1, 2, régulièrement 5 minutes voire plus.
J’ai lu que sur les tel récents, le wifi pouvait en quelque sorte se mettre veille parfois et que le ping ne se fasse pas.
J’ai implémenté via scénario un temps de confirmation de 5 minutes sur les passages de status à zéro mais j’ai quand même voulu regarder les latences de ping pour voir ce que ça donnait :
Voici le graph qui montre sur une journée la latence de 3 téléphones :
Je constate qu’il n’est pas rare que la latence se rapproche de 1seconde.
Or j’ai lu que le timeout sur le plugin network était réglé à 1seconde.
Je fais donc l’hypothèse que parfois le téléphone est en veille et possiblement il veut bien répondre au ping mais sans trop se presser !
Et que donc, pour les téléphones, ce serait possiblement plus efficace de rallonger le timeout, quitte à réduire le nombre d’essai pour limiter la durée de l’update.
tu parles de ping => as-tu configuré en « ping » ou « arp » ? une requete arp ce n’est pas vraiment un ping, question de mot mais c’est important et une requête arp donnera probablement de meilleur résultat sur les devices mobiles
si tu augmentes le nombre de tentatives, c’est quasi comme si tu augmentais le timeout du nombre de secondes correspondantes si le timeout d’une tentative = 1 seconde (plus quelques nanoseconde d’overhead pour l’execution de la commande que je considère comme négligeable) => augmentes le nombre de tentatives
Hello !
Pardon mauvais choix de mot : pour les téléphone je suis bien en ARP.
A ce jour j’ai mis 3 tentatives.
Ma crainte : si à chaque tentative la latence met plus de 1sec, toutes les requêtes de ping/arp sont perdues et le status passe à 0.
Mais si je comprends ce que tu dis : si on a deux tentatives : alors le retour de requête ARP, s’il met 1.5sec, alors il sera capturé par la deuxième tentative et alors le status restera à 1 ?
Ca reste un mystère pour moi, si je pouvais simplement je testerais avec 2sec de timeout pour constater ou non si j’ai moins de perte de status je le ferais.
Avec arp, selon mon expérience, c’est effectivement un « temps de réveil » du mobile.
Effectivement ca arrive qu’il faille 4 ou 5 tentatives avant qu’un mobile réponde mais ensuite pendant les x minutes qui suivent ca répond toujours immédiatement (jusqu’à la prochaine veille je suppose, je n’ai pas testé en détail)
Je vais voir ce qu’il existe niveau timeout et si possible d’ajouter une config; pas ce soir, peut-être demain si j’ai le temps sinon semaine prochaine.
Je vois quand même une nette amélioration sur la fréquence des coupures en passant à 3secondes. Il reste encore des coupure de status de temps en temps mais avec un filtre de 5secondes ça passe bien.
Le seul inconvénient c’est que pendant les longues périodes dans la journée où personne n’est à la maison, alors toutes les minutes l’update met le temps maximal (nb essai x timeout).
J’ai donc un suggestion pour réduire les ressources, je reconnais que c’est possiblement du pinaillage, mais c’est pour en discuter et pourquoi pas ajouter la fonctionnalité de filtre des pertes de ping en ARP :
Quand un téléphone borne depuis plus de 5 (TBC) minutes (status 1), on pourrait par exemple avec un timeout de 1sec, et seulement si le premier essai est négatif, on augmente le timeout pour les suivants
En revanche lorsque le téléphone ne borne plus depuis 5 (TBC) minutes, je pense qu’on pourrait mettre par défaut un timeout de 1sec avec 1 seul essai, comme ça on ne surcharge pas le update pendant toutes la durée de l’absence. Et quand le téléphone rebornera au wifi, il sera réactif au moins sur le premier ping.
Ceci pour dire qu’il serait utile pour les utilisateurs que le temps de confirmation à la perte du ping (moi j’ai mis 5 minutes) pourrait être intégré au plugin.
c’est trop de logique à intégrer au plugin, selon moi ca dépasse son rôle et sa responsabilité.
en plus ca me parait fort complexe à implémenter pour un gain très faible.
on vient quand même d’un truc ou il y avait 3 * 10 essais en dur (donc 30s par device) à un système complétement configurable y compris le timeout; à chacun maintenant de trouver l’équilibre qui lui convient sachant que dans la plupart des cas les paramètres par défaut vont être satisfaisant.
C’est vrai qu’on a fait du chemin ! Je comprends ta position.
Je ne sais pas dire si la fonction update consomme bcp de ressource. Je sais que chez moi la fonction est en cours environ 30sec toutes les minutes quand personne n’est à la maison.
Quant à la confirmation de 5 minutes pour éviter les pertes intempestives de statut, on peut se le faire chez nous !
