Le Mercredi 05 Janvier 2005 10:16, Alexis Bunel a écrit : > On Tue, 4 Jan 2005 23:34:27 +0100, Benoît Audouard <[EMAIL PROTECTED]> wrote: > > c'est quoi vos messages dans /var/log/messages au moment où ça coupe ? > > Je l'avais posté il y a quelque temps sur la ML : > > Ca y est j'ai un beau log : > > Sep 23 07:33:13 lezard kernel: [EAGLE-USB] CRC count treshold reached. > > Rebooting > > > Sep 23 07:33:45 lezard kernel: [eagle-usb] Modem operational > > Et gilles avait répondu : > > "Cela veut dire que le modem a atteint un seuil d'erreur CRC dans les > trames ATM auquel il considère que la solution la meilleure est de rebooter > (en interne) l'OS du modem. Cela fait le plus souvent tomber la connexion > PPP (je ne sais pas si c'est tout le temps). > C'est probablement lié à l'adaptation du modem à la ligne CMV / OPTN et > touti-quanti mais peut aussi être un problème pur de ligne dans son > environnement. > Par exemple en ce moment, je perd la connexion tous les matins quand > l'éclairage public s'éteint à cause des parasites émis à ce moment que l'on > entend même à la radio." >
Je confirme que j'observe le même type de problèmes avec mon E2T / Cegetel Max, erreurs CRC extrêmement aléatoires, au départ j'avais des reboots du modem toutes les 10 minutes de façon assez précise (je garde la connexion la plus part du temps) Alors j'ai augmenté les seuils de reboot (+1 dans les #define de Sm.c) Depuis, j'observe des reboot un peu moins fréquents (enfin ça dépend des moments) mais quand ça tient ça peut durer plusieurs heures sans problèmes ! Je me demande même si le taux d'humidité n'a pas une influence ! Bon, il faut dire que je suis en ligne aérienne dans mon quartier et j'imagine que ça doit avoir un impact sur le parasitage. Pour en revenir à la gestion des CRC, le driver commence parfois à calculer le taux d'erreur (nombre de packets OK / nombre de packets en erreur) : si 97 % d'erreur pendant 6 sec -> reboot (97th CRC error threshold) si 90 % d'erreur pendant 20 sec -> reboot (90th CRC error threshold) Bon, ça semble être des palier déjà bien élevés, mais comme je disait hier à baud123 et a sleeper, je m'interroge un peu sur la gestion du message DIAG.54 : c'est le message qui déclenche le calcul du taux d'erreur. A explorer... > _______________________________________________ > Eagleusb-dev mailing list > [email protected] > https://mail.gna.org/listinfo/eagleusb-dev -- Alexis Deruelle <[EMAIL PROTECTED]>
