[OpenWrt-Devel] lantiq DSL drivers / firmware info

[Sylwester Petela]

W dniu 2015-06-06 o 14:18, Aleksander Wałęski pisze:
> Interesting. Have you made a note of which parameter made such a
> difference? I guess disabling ReTx could potentially cause lower sync
> speeds because DSLAM needs to compensate for lack of retransmissions.
> It may be enabled/disabled in autoboot script as it is in latest
> TP-LINK firmware.
> Vectroring needs firmware to have it enabled, but its VDSL2-only
> feature anyway so it shouldn't cause issues for you. Bonding does not
> seem to be supported by the driver (yet).
>
> Router's performance change with time worries me a bit. Are you sure
> it is DSL part that is slowing it down? I have 9 days uptime at this
> point and have not noticed any slowdowns yet.

As for speed, yes only DSL is affected. LAN -> WLAN and overall (USB/3G) 
performance is same, bit higher CPU usage but cannot trace it by top, 
ram a bit but that because driver is bit bigger.

ReTx on ADSL isn't used so I don't know if driver tries to do something 
that it can't do.

What intriges me is that only two options (except low-level init) are 
different VDSL / ADSL related in init scripts delivered with original 
driver package:


          if [ "$wanphy_phymode" = "0" -o "$wanphy_phymode" = "3" ]; then
             # If BitSwap is disabled, or Retransmission is enabled
             # then set the DSL Parameters accordingly
             if [ "$BS_ENA" != "1" ]; then
                dir="0 1"
                for j in $dir ; do
                   LFCG_VALS=`${BIN_DIR}/dsl_cpe_pipe.sh lfcg $j`
                   if [ "$?" = "0" ]; then
                      for i in $LFCG_VALS; do eval $i 2>/dev/null; done
                      ${BIN_DIR}/dsl_cpe_pipe.sh lfcs $nDirection \
                         $bTrellisEnable $BS_ENA $RETX_ENA 
$bVirtualNoiseSupport \
                         $b20BitSupport >/dev/null
                   else
                      if [ "$j" = "0" ]; then
                         ${BIN_DIR}/dsl_cpe_pipe.sh lfcs $j 1 $BS_ENA 
$RETX_ENA \
                            0 -1 >/dev/null
                      else
                         ${BIN_DIR}/dsl_cpe_pipe.sh lfcs $j 1 $BS_ENA 
$RETX_ENA \
                            0 0 >/dev/null
                      fi
                   fi
                done

After 9 days and bit of performance drop I reverted back to stripped out 
init script and also lowered debug level to default so I can track what 
is causing these issues.

> On Fri, Jun 5, 2015 at 9:27 AM, Sylwester Petela <sscapi at gmail.com> wrote:
>>
>> W dniu 2015-06-05 o 04:56, Aleksander Wałęski pisze:
>>> Try playing with /etc/init.d/dsl_control when you'll have a moment to
>>> spare to see if all parameters it passes to control application are
>>> necessary. Selecting between ADSL and VDSL may be necessary but
>>> firmware for ADSL seems to be annex-specific and I think that each
>>> step we can make towards simplifying configuration will be welcomed.
>>
>> There are more parameters required then only dsl_control passes, low_level
>> config, ReTx, Bonding, Vectoring.
>>
>> Getting rid of these gave me two things:
>>
>> 1. slower 1 synch (full_init -> exception -> full_init)
>> 2. after couple of days (8d 0h 9m 30s) router is less responsive then at the
>> beginning, d/u speed is also affected.
>>
>> Tested on Annex A line ATM, compared to normal dsl_control with only higher
>> debug level (it consumes bit more RAM then lower debug level).
>>
>> Conclusion: maybe on VDSL line these values have margin usage but ReTx or
>> Vectoring on Annex A ADSL line is bit to much to driver.
>>
>>> On Thu, Jun 4, 2015 at 10:30 PM, Martin Blumenstingl
>>> <martin.blumenstingl at googlemail.com> wrote:
>>>> On Tue, Jun 2, 2015 at 1:54 AM, Aleksander Wałęski <olewales at gmail.com>
>>>> wrote:
>>>>> Extraction procedure is exactly the same as for regular TD-W9980.
>>>> Thanks, I have it that this afternoon.
>>>>
>>>>> I was expecting only Annex difference, but this firmware
>>>>> may be specifically tweaked for Germany ("# for DT/Germany market" in
>>>>> vdsl.scr). I guess ADSL over ISDN is not very popular elsewhere.
>>>> Yes, Germany is a bit special regarding this...
>>>>
>>>>
>>>>> On Mon, Jun 1, 2015 at 11:32 PM, Martin Blumenstingl
>>>>> <martin.blumenstingl at googlemail.com> wrote:
>>>>>> I can test it this weekend on an Annex B ADSL connection. So I will
>>>>>> test with firmware 1e472dad0eda88281af7c00cd3f49fcc29d4fa83 or
>>>>>> 186b5406e6511c97d997b48f5e0ec5ad3f62600d (see [1]).
>>>> I was able to test those two today: both are working fine on my ADSL2+
>>>> Annex B connection - I did not notice any difference between them.
>>>>
>>>> I have also updated my patch once again: [0].
>>>> It does not spam my dmesg, device is still responsive. However, I
>>>> cannot say anything regarding stability yet. Let's wait a few days...
>>>>
>>>>
>>>> Regards,
>>>> Martin
>>>>
>>>>
>>>> [0] https://gist.github.com/xdarklight/2986587133d97892a4b3
>>
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel