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 <ssc...@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.blumensti...@googlemail.com> wrote:
On Tue, Jun 2, 2015 at 1:54 AM, Aleksander Wałęski <olewa...@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.blumensti...@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@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
