You've made me think about it now but my speeds are ok, my pings to bt is 10ms, snr 8.8 down and dlm hasn't kicked in to my knowledge as my disconnects last on average over 7 days...
Last edited:
Anyone Using an Asus DSL-AC68U
- Thread starter Socrates470BC
- Start date
You've made me think about it now but my speeds are ok, my pings to bt is 10ms, snr 8.8 down and dlm hasn't kicked in to my knowledge as my disconnects last on average over 7 days...
as you say at least with mine (adsl) is fine
Yes indeed something happens and start increasing errors
At Advanced settings > wireless > professional > Reducing USB 3.0 interference > Disable it ... and check if errors increasing at random times again but i don't have vdsl to test, so vdsl users test & report
as you say at least with mine (adsl) is fine
Yes indeed something happens and start increasing errors
At Advanced settings > wireless > professional > Reducing USB 3.0 interference > Disable it ... and check if errors increasing at random times again but i don't have vdsl to test, so vdsl users test & report
I'll give it a try, though I'm not anticipating much difference as I've disabled all wireless on the device as I use another router for that purpose. I wonder if there's anything else that might be worth considering if it's internal noise causing this problem (on a frequency potentially higher than 2.2MHz~, since this is common among VDSL2 users). Of course, another thing worth an attempt might be to see what would happen on a connection with only using tones up to 2.2MHz and disabling any tones above that frequency, but I doubt I'll try that as I don't want to encourage DLM into banding my connection any further than 49Mbps downstream (even though I can override this while using this device). Not sure if I could even sync at such a setup anyway, though presumably US0 would give me some upstream. I wonder if it would be reasonably safe to try for a few hours in the early hours of the morning? I bet the problem wouldn't occur.
I don't even use the USB port so perhaps there's some way I can disable/power it down?
Last edited:
EDIT
well if you did disable all wifi may not make change for vdsl users ... but the line may be more stable? even if are few errors ... i did test (adsl) the TBB monitor is more clear, have less ping ... i have one more reason to say this which i have reported to asus
The only i am aware to disable usb it may be at usb application > usb 3G/4G & disable "enable usb modem" maybe this in combination with reduced usb 3.0 at wifi
Then 2 combinations i am getting better results, so worth to try both
also maybe worth try & media player (Media Services and Servers) disable media server
well if you did disable all wifi may not make change for vdsl users ... but the line may be more stable? even if are few errors ... i did test (adsl) the TBB monitor is more clear, have less ping ... i have one more reason to say this which i have reported to asus
The only i am aware to disable usb it may be at usb application > usb 3G/4G & disable "enable usb modem" maybe this in combination with reduced usb 3.0 at wifi
Then 2 combinations i am getting better results, so worth to try both
also maybe worth try & media player (Media Services and Servers) disable media server
Last edited:
I see, I'll look into that now. I'll disable the setting for reducing USB interference as well.
Since I don't get a problem with the upstream I could potentially try disabling all DS tones above 2.2MHz~ so I run the equivalent of an ADSL2+ connection with a much higher upstream (or so I believe anyway?). I'm very much expecting there to be no abnormal FEC or CRC errors if I ran that setup for a few hours. If I did try that and found no abnormalities then it means something is happening on the DS2 or DS3 band. In one of my past experiments I've disabled half of the tones in DS1 and for another experiment all of the tones in DS3, so that mainly leaves the second half of DS1 and all of DS2.
Changing the above recommendations didn't help. However, so far blocking all tones above DS1 has (sadly I can't just block all tones in DS2 only, rx_blackout doesn't seem to have any effect
). I will post an update in the morning, hopefully a positive one. I've removed INP (INP=0, was 1) and kept a delay of 8ms. Target SNRM is 6.0dB with a max sync rate of 80Mbps.Without INP I usually suffer CRC errors so we'll see. I'm more interested to see whether the FEC errors go out of control.
Finally here's a common thing I see on my bitloading graphs on this device, which makes me wonder if it's linked to the problem, see below screenshot.
I'll provide an update in the morning. I wonder what could be causing interference on those tones.
Last edited:
for the broken bit swap ... if you had the reduced usb off and 3g/4g modem, my guess with out them (turned off) must pick up noise so may need reduced usb more agressive mode
Unless the broken bit swap tones are due to bad weather in your area yesterday
Unless the broken bit swap tones are due to bad weather in your area yesterday
Last edited:
I see, well that would've been for the last few weeks (weather) but sadly weather hasn't been bad for all of that time so it can't be the cause.
I can't be sure if the test was a success or not as I stupidly forgot to change 'Rx AGC Gain Adjustment' to 'Stable' (was on 'High Performance'), so might have encouraged CRC errors. For the last few weeks I've been using TC and manually setting AGC and other settings that way, anyway DLM's kicked in and set a very high interleaving level so I'll suspend further testing until the interleaving level is reduced (currently INP 7, delay 16ms), hopefully won't be much more than 14 days. What I also find interesting so far, this morning, is that the FEC isn't wildly high even after nearly 4 hours of uptime so far, perhaps the high INP is stopping that.
Code:
near-end path0 fec: 165565(165565)
near-end path0 crc: 0(0)
near-end fec sec: 233(233)
near-end err sec: 0(0)
near-end ses sec: 0(0)
near-end los sec: 0(0)
near-end ua sec: 0(0)
far-end path0 fec: 1679(362803)
far-end path0 crc: 0(1828)
far-end fec sec: 29(6958)
far-end err sec: 0(1443)
far-end ses sec: 0(0)
far-end los sec: 0(570)
far-end ua sec: 0(25920)
outDiscards=321
inDiscards=0
outBytes=310499827
inBytes=645809617
outPkts=852416
inPkts=646669
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=12.2 dB
AttenDown=10.4 dB
SNRMarginUp=6.8 dB
AttenUp=0.1 dB
DataRateDown=42125 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=165565
FECUp=1679
CRCDown=0
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 3:51, 58 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=10.9 dbm
PowerUp=4.7 dbm
AttainUp=26051
AttainDown=93640
ShowtimeStart=18
TotalStart=18
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1819
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus
Last edited:
With that ping I'd say you're fastpath.
-If i am not mistaken from your previous posts long time, didn't you tried INP 7/16ms before? or close to them?
-Is this less fec errors with 3g/4g & reduced usb 3.0 off or on?
Thanks
I've not tried an INP of 7 with a delay of 16ms before. DLM set my downstream to this, early this morning. It's almost the highest level of error correction that DLM will apply (maximum I've read is INP 8 with a delay of 16ms).
I've tried reduced usb 3.0 and 3g/4g both off, no difference before DLM set me to this. I'll give it a bit of time to settle and allow DLM to improve the downstream before I attempt any further.
Code:
near-end path0 fec: 272352(272352)
near-end path0 crc: 0(0)
near-end fec sec: 1035(1035)
near-end err sec: 0(0)
near-end ses sec: 0(0)
near-end los sec: 0(0)
near-end ua sec: 0(0)
far-end path0 fec: 4790(365914)
far-end path0 crc: 0(1828)
far-end fec sec: 94(7023)
far-end err sec: 0(1443)
far-end ses sec: 0(0)
far-end los sec: 0(570)
far-end ua sec: 0(25920)
outDiscards=389
inDiscards=45
outBytes=2005938490
inBytes=1416637897
outPkts=5098122
inPkts=4993138
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=12.2 dB
AttenDown=10.4 dB
SNRMarginUp=6.7 dB
AttenUp=0.1 dB
DataRateDown=42125 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=272352
FECUp=4790
CRCDown=0
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=10:35, 27 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=10.9 dbm
PowerUp=4.7 dbm
AttainUp=25955
AttainDown=93608
ShowtimeStart=18
TotalStart=18
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1819
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplusEither the settings didn't take effect properly before, or the high INP/delay combination is keeping the FEC under control.
Last edited:
Thanks, but doesn't my high FEC count then debunk the FEC theory? Latest stats:
ASUSWRT DSL-AC68U_3.0.0.4 Tue Dec 2
admin@DSL-AC68U:/tmp/home/root# cat
outDiscards=1264
inDiscards=117
outBytes=891872352
inBytes=1788343969
outPkts=6243100
inPkts=10493165
fwVer= FwVer:5.5.1.126_B_A60901 HwVe
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.8 dB
AttenDown=14.4 dB
SNRMarginUp=12.6 dB
AttenUp=0.1 dB
DataRateDown=39993 kbps
DataRateUp=9994 kbps
WanListMode=1
FECDown=508366016
FECUp=33
CRCDown=216
CRCUp=1
HECDown=0
HECUp=0
ADSLUpTime=3 days, 3:59, 19 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=13.6 dbm
PowerUp=6.5 dbm
ATURID=26005443434e0000
ATUCID=b5004946544eb204
AttainUp=19715
AttainDown=76872
ShowtimeStart=19
TotalStart=39
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=2313
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)
FEC theory?
Looking at that paste it seems you have a depth of greater than 1, and plenty of FEC on the downstream, so that ping appears to be misleading and you are indeed on interleaving for downstream. What ping do you get when pinging bbc.co.uk?
Oh I see. FEC's shouldn't cause disconnects as they are corrected errors. I see, yeah you're definitely interleaved then, delay 8ms most likely (no idea on the INP).
Mmm, I guess then I'll have to wait until the dlm resets itself, how long will that be? It's shame because I only had two or three disconnects caused by the modem and that was very early on, the rest have been caused by firmware updates and before the last one three days ago the modem had been up for over 10 days. Perhaps I should stop doing them but then that's the penalty for being an early adopter...
Last edited: