Le samedi 06 novembre 2004 à 19:36 +0100, Gilles Espinasse a écrit : > I have made sync tests in various conditions with Sagem800 Vendor=1110 > ProdID=900f Rev=40.0b and with: > dsp_code_pots.bin (win2.031 or eagleIII DTAG 44E2EA17), > CMVep.txt from win sagem 2.031 or eagle-usb 2.0.0rc3
Thanks Gilles for bringing us such tests that make me understand better how the modem and ADSL work, or at least makes me work on it. > My first test was a loop > for i in `seq 1 20`; do /etc/rc.d/rc.eagleusbadsl start; > /etc/rc.d/rc.eagleusbadsl cleanup; /bin/sleep 5; done > It basically load the module, try to sync with 90s of time limit and unload > the module > > Result does not vary significantly with dsp_code or CMV change. > win2.031 dspcode, CMVep from win sagem2.031 : 9 failures to sync in 19 > attempts > eagleIII dspcode, CMVep from win sagem2.031 : 10 failures to sync in 20 > attempts > eagleIII dspcode, CMVep from eagleIII 44E2EA17 : 5 failures to sync in 15 > attempts > > Time to sync in case of success was between 30 to 45 s and mostly 35 s this time is related to : - time to send dsp_code to modem (that depends on size of dsp_code and rate of USB) - + time to handshake with the DSLAM ? > I next try with a modified loop > for i in `seq 1 20`; do resetusb; /etc/rc.d/rc.eagleusbadsl start; > /etc/rc.d/rc.eagleusbadsl cleanup; /bin/sleep 5; done > resetusb is a script wich remove the usb controller module :usb-uhci in my > case (and so unpower the modem) > eagleIII dspcode, CMVep from eagleIII 44E2EA17 : 0 failures to sync in 20 > attempts > > So the conclusion I found from those tests are : you are quite fast, could you elaborate : see below my comments / reflexions / questions > - the problem to sync should be related to the way the reset order is taken > or not by the modem, how do you guess this ? having the source code would really be easier to identify this rather than try to guess how it works ;-) maybe ADI can confirm that they changed this part ? Is this dsp_code related or only driver related ? (I would say dsp_code related from your test ?) > - test if the modem is in operational state if you can avoid to try to sync > actually. Even if operational, we can resync if necessary (I see VPI / VCI as well ?). You can sync even if VPI / VCI are bad (but pppd will not get connected of course). > This is still a problem because if Encapsulation value is changed, > modem need to be initialised again to take the new Encapsulation. Encapsulation is not displayed by eaglestat ? why ? > I next try to activate some debug messages but when -x 0xFFFF is added to > the same line where eaglectrl -d -o, every attempt to sync fail. and ? bug ? or you think debugging puts a delay that prevents sync ? My conclusion from your test would be more matter of fact (or there are some points I have not followed) : - latest dsp_code seems better to get synchronized - reinit of usb causes modem alimentation to cease (hence it reinits the firmware/dsp_code from memory) and this is better for synchronization afterwards. I would only conclude that a synchronized modem does not accept very well to be resynchronized... (maybe a bug or a limitation of the current dsp_code... if we had the source code, maybe someone could analyze it more completely ;-) currently we can only infer behaviour from external tests. In the past, I've always been more efficient in driving developments and identifying impacts on specific problems with the source code available (that's rarely needed, but when needed having it is a real plus ;-) anyway developments would still be asked from original developers or if we can provide a patch, I would not be implemented as it is usually preferred to have a validation from the original developer). The problem I see for implementation of newest dsp_code in 2.0.0 is that it requires to use CMVs which have to be determined precisely : I still do not believe that it's country-only related, I think it's DSLAM related which is more problematic as we have no way of telling easily which DSLAM version is used. I may be in error, information welcome to put me on the right track => I see this as a regression from a user-oriented point of view (either it works all the time, whatever the config, as was the case before E2L/E2T and new dsp_code, or it does not work : we need to have the good parameters available to make it work depending on user's configuration). For me 2.0.0 is the end of the 1.9.x series that work for existing modems. Newest modems may be taken into account with latest dsp_code and - beginning with 2.0.1 - we can work on it ASAP. @++ Ben'. aka baud123
