Alexis Deruelle a dit : >> >> 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 > > Dans quelle mesure les différents BNM pourraient être distribués avec le > driver et selectionnés à l'install à partir d'une matrice FAI/Type de > Modem ? c'est du contournement : autant s'attaquer au bon problème dont la résolution est de prendre la dernière version des BNM/DSPcode (backward compatible avec les différents types de modem) ET prendre en compte l'envoi des bons paramètres (via OPTNxx dans eagle-usb.conf - rapide - ou mieux par CMV - sera à tester)
>> - pour modem E2T : la bonne correction semble être d'implémenter >> correctement les OPTNxx voire les CMV > > Que sait-on précisemment à ce sujet sur les valeurs à utiliser ? - Liste de valeurs par pays fournie, les soucis avec OPTN1 (Free dégroupé/débit ralenti et maintenant Cegetel) montrent soit un pb d'OPTNxx, soit que c'est par ISP qu'il faut gérer et non par pays - pas d'information sur la signification de chaque option (c'est nos demandes LT002 et LT003 de la page http://dev.eagle-usb.org/wakka.php?wiki=RequirementsEagleUsbGPL ). Nous y allons à l'aveuglette sans connaissance des impacts potentiels. > Une quetions concernant le driver : est-ce que l'on peut imaginer de > régler ces valeur "on the fly" avec eaglectrl ou à l'aide de fichier > dans /proc ? Si il y a besoin de main d'oeuvre, je suis prêt. Régler les valeurs par un programme préalable : sans doute possible (fait pour d'autres pilotes) et déjà suggéré. Après tout reste à faire : ce serait plutôt dans le dialogue modem / DSLAM qu'il faudrait l'implémenter, sans connaissance du protocole, ni des commandes accessibles/disponibles c'est tout de suite plus dur (d'où la demande LT004). L'idée ce serait plutôt d'avoir un programme initial de configuration qui identifie et fixe les paramètres au départ (après ça change pas tous les 4 matins...). Cela pourrait éventuellement permettre d'étendre les capacités de diagnostics en fonction des informations disponibles. >> - 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 > > Quelqu'un a des infos plus précises là dessus ? Est-ce que les anomalies > côté modem sont visibles au niveau des DSLAM ? Dans ce cas est-ce > qu'ils regardent leur "logs" proactivement ou faut-il les "avertir" ? hum, disons qu'il est permis de rêver :-)) Quand bien même il y aurait des anos tracées dans les DSLAM, je ne pense pas que c'est un niveau à remonter à l'utilisateur : chacun son métier ;-) En revanche si le DSLAM sait les envoyer à l'utilisateur ou au moins des codes d'erreur (donc sans coût humain côté ISP), il y a tout intérêt à l'implémenter pour fournir un diagnostic plus pertinent et contribuer à résoudre les problèmes plus rapidement (c'est couvert par notre demande #LT004 et correspond à un avantage induit de l'obtenir). Il y a peut-être des docs dispos sur les DSLAM et leurs protocoles (peut-être regarder du côté du DSLForum, je n'ai que rarement pris le temps...) @++ Ben'. aka baud123
