Alexis Deruelle a dit : > 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... Pour moi il y a deux grandes classes de problème : 1. lié à la ligne téléphonique : - installation déficiente - perturbations (ton cas d'éclairage qui parasite...) - la météo joue (genre ligne aérienne "chahutée" lorsqu'il y a du vent) 2. lié à mauvaise prise en compte des paramètres - pour modem antérieur au E2T, utiliser les "vieux" BNM/DSPcode est un bon contournement - pour modem E2T : la bonne correction semble être d'implémenter correctement les OPTNxx voire les CMV - configuration dépendante de l'ISP (et ses DSLAM) => a priori il y a plus de sensibilité au fur et à mesure que le débit augmente Nous ne pouvons travailler que sur le 2ème cas...
