Kitz Forum
Broadband Related => Broadband Technology => Topic started by: Weaver on September 20, 2021, 10:24:29 AM
-
Being on 21CN ADSL2 Andrews and Arnold gives me a three- or four-option parameter for downstream interleave control: off, on, ‘medium’ and a button marked ‘auto’ which I suspect is a toggle: auto vs off. I am wondering whether ‘on’ is higher than ‘medium’ ?
My downstream ADSL2 framing parameter D for downstream is set to 1, so does this mean ‘no interleave’? Is that correct? Why is that happening? Sounds as if the setting is currently actually ‘auto’ and some system has decided I don’t need d/s interleave. Very occasionally I get a sizeable d/s CRC spike, of 50 CRCs in one time quantum (a minute?). For me, since I don’t care about higher latency, not being a gamer, there’s no downside to having higher interleave depth, so I would like to force d/s interleave to be high in order to give me extra robustness and protect against these occasional errors especially while using Zoom. Is there anything I should be doing to take control of interleave state and depth?
-
I remember reading about the logic of the interleave settings available for A&A ADSL2(+) users and, to me, it wasn't all that logical. :-X
If you want to have permanent interleaving I believe you need to ignore the "auto" setting and just take the "on" option.
-
Agreed. I should have mentioned that it is currently set to ‘on’ for downstream, yet the D parameter is still 1.
-
From my experience interleave at “on” will give D=1 if the DLM thinks it doesn’t need it on ADSL2. You would think auto would do that, but it doesn’t seem so. I had that with Plusnet and Zen on ADSL2.
-
So the question is, will Medium force it on?
-
It seems a bit strange as ‘on’ seems the same as ‘auto’.
I set line 2 downstream interleave to ‘medium’ and now downstream D = 2 whereas it is 1 for other lines. So ‘medium’ works, as predicted. It does force interleave on, but only at a very pathetic level.
The upstream D = 8 for that link, and I’d like to have the same for the downstream.
Correction. The ‘medium’ trick doesn’t work reliably. I tried it with another line and there the downstream D remained at 1. And yes, I did remember to force a resync, and I remembered to hit the ‘Apply’ button in clueless.
I have sent AA an email asking them if they know what’s what.
AA came back to me telling me that it’s supposed to work the way I/we expected it works.
Wild speculation: I wonder if ADSL2 PhyR (L2 ReTX - proprietary G.INP) has some connection with this. I did once manage to get downstream D = 2 so it can’t be the case that PhyR completely disables interleave. Since there’s no upstream PhyR on my links and on upstream D = 8, it does make me wonder though. Perhaps some system somewhere decides that if you have L2 retransmissions then you don’t need interleave as well, but that makes no sense to me as apart from the latency there’s no downside to having interleave, surely?
-
One of the main complaints we see about Interleaving is that it reduces the attainable sync speed. In reality its the RS overheads from the Error Correction that is switched on at the same time as interleaving which is reducing the data rate.
I think you mentioned bearer channels in another thread. Not all modems shows all the info about the different bearers but both adsl and vdsl has an AOC/VOC used to carry such things as overheads, Re-tx config, bitswap info, line config info etc. Its pretty obvious to say that the more bandwidth required by the 'hidden' bearer channel will reduce the available bit rate for [Bearer 0] your user data.
On a standard line turning on error protection/correction (aka "Interleaving") can substantially reduce the maximum sync speed - which is the real reason why the likes of Max hates 'interleaving' & DLM. I can't recall exact figures, but I think the error correction costs me about 7Mbps of sync speed on vdsl and somewhere around 3Mbps when on adsl2+.
Re-tx muddies the waters somewhat it uses a different coding for overheads. I'm struggling today and can't recall the actual term (which I damn well know and why Im having to go around the houses), but basically its more efficient algorithm and doesnt cause as many overheads needed for the AOC and thus less noticeable loss of available sync as far as the user is concerned. I'm about at the end of my limit for typing today and beginning to waffle but retx coding efficiency is better when compared to adsl than vdsl*
Damn, so sorry, and so frustrated because words are muddling despite me knowing in my head what I want to type in reply to your final paragraph. My last para has took >40mins despite having to take more morphine for pain. Im trying to say retx coding is more efficient on adsl than vdsl AND still the words wont come out right. retx coding algorithm is better than vdsl coding which is better than adsl, so ummm ok.. retx coding algorithm more efficient so may not see as much loss of sync speed when used with adsl compared to vdsl. Hoping someone can join the dots. I've reached the wall and know from experience that Im not going to be able to break through it today. :/
-
When A&A were tuning our DSL to fend off the electric fence interference, they told me they can only set interleave on or off, not control the depth. I asked the question because when DLM had its way it set some very deep interleaving that seemed to clear all the errors. Unfortunately it only applied this after setting target NM through the roof so it actually performed worse than running full speed and putting up with 72 CRC per minute. Ideally it would have been good if A&A could have locked the line to the 6dB target which still applying that interleaving.
-
I have always been annoyed by the latency hit more than the sync speed hit.
As kitz says though interleaving itself adds delay not sync speed overhead.
Openreach enable the error correction on VDSL upstream "without" interleaving so it gets error correction without a latency hit.
About 5 or so years back (maybe more) when I was on plusnet I posted on here once with the same config on my downstream (error correction with no interleaving) was totally bizarre as I have never seen that on any other openreach VDSL line ever, was that time I had a sync speed of about 50mbit.
-
The practical reason I wish to get some interleave depth is because just once per day or even less frequently I see a big spike of CRC errors (n errors in 1 minute, I think that’s the time resolution/quantum used by the johnson ‘easy-stats’ graphing [as I have christened it] ?) Something is completely overwhelming the CRC error-correction anyway.
-
some interleave depth is because just once per day or even less frequently I see a big spike of CRC errors (n errors in 1 minute,
Is Interleaving sufficient to correct this type of burst errors? Quite often retx and interleaving doesnt work too well with single bursts of SHINE. If it lasts for a few seconds then even RS may not help either. I have single daily bursts of SHINE that lasts for about a second which no amount of Interleaving, FEC or Re-tx can correct.
The annoying thing is that DLM see's it, tries to correct it and keeps doing so increasing the amount of Re-Tx, Interleaving, FEC and even starts banding. Yet aside from that single burst lasting <1sec the line is perfectly fine for the rest of the day. I've now been banded several times, I've got high retx and high Interleave and practically every single day I still get breakthrough noise.
Nothing the DLM does seems to stop it, yet DLM has quite severely limited my line. TBH I wish it would leave it alone as for 99.99% of the day it works fine and I dont even notice the noise burst because its over and done with so fast. This morning it caused >10k FEC and usually causes just 1 ErrSec.
It's my opinion that sometimes you just may as well accept that for a few seconds per day the line is going to error. I wish I could turn DLM off, as all its doing is restricting what the line is fully capable of doing for the rest of the day.
-
Damn, so sorry, and so frustrated because words are muddling despite me knowing in my head what I want to type in reply to your final paragraph.
Apols for yesterday, its a known side effect of MS. I know quite clearly in my head what I want to say, but the words just wont come out either verbally or written. The harder I try, the more words jumble and I end up typing not quite what I meant to. It is frustrating because unlike with other diseases, I'm fully aware that it's happening but I can't seem to break through the wall - even if the word Im looking for is simple or common.
The word I was looking for was "coding efficiency". Ironically I could say coding and I could say efficient, but couldnt string the 2 together. :/
What I was trying (and failing miserably) to say, is that the code used by various types of dsl technology has become more efficient and carries less overheads. Less overheads in the AOC/VOC (eg bearer 1) means more available bandwidth for what we think of as the sync speed (eg data carried in bearer 0). One of the largest improvements was adsl > adsl2 which effectively doubled the available sync speed.
Usually the addition of Error Correction such as RS encoding causes a reduction in the sync speed. However, because Re-Tx is more efficient than the more traditional overheads, it is possible that Re-tx may not cause noticeable loss of available sync speed.. and may even improve some adsl1/2 lines.
I'm not 100% certain, but I do strongly suspect the reason we see the known anomaly with max sync speed displayed by the router when a line is interleaved has an awful lot to do with the fact the modem is calculating the max sync using the more efficient coding algorithm being used with error correction, as opposed to the standard overheads on adsl/vdsl.
-
> Is Interleaving sufficient to correct this type of burst errors? Quite often retx and interleaving doesnt work too well with single bursts of SHINE. If it lasts for a few seconds then even RS may not help either.
Understood. I don’t know how long the error burst is other than it’s less than n secs. Maybe n=60, can’t remember, yet again forgotten. We had an opinion in a post some while back; Burakkucat will probably know
-
Maybe n=60, can’t remember, yet again forgotten. We had an opinion in a post some while back; Burakkucat will probably know
The sampling frequency? Once a minute. (I.e. 0.016666667 Hz)
-
Agreed, that’s what I thought.
If you experience an error-burst of a certain duration in which all data is corrupted irrecoverably, then that becomes a SES under certain conditions which Kitz has given on the site, but SES counters can’t tell you the length of such a burst nor whether or not it is an all-data-100%-corrupt period. So I presume SES counters are not much help for assessing this?
I wanted to work out whether or not interleave of a certain depth can protect you from such a problem.
-
Is Interleaving sufficient to correct this type of burst errors? Quite often retx and interleaving doesnt work too well with single bursts of SHINE. If it lasts for a few seconds then even RS may not help either. I have single daily bursts of SHINE that lasts for about a second which no amount of Interleaving, FEC or Re-tx can correct.
The annoying thing is that DLM see's it, tries to correct it and keeps doing so increasing the amount of Re-Tx, Interleaving, FEC and even starts banding. Yet aside from that single burst lasting <1sec the line is perfectly fine for the rest of the day. I've now been banded several times, I've got high retx and high Interleave and practically every single day I still get breakthrough noise.
Nothing the DLM does seems to stop it, yet DLM has quite severely limited my line. TBH I wish it would leave it alone as for 99.99% of the day it works fine and I dont even notice the noise burst because its over and done with so fast. This morning it caused >10k FEC and usually causes just 1 ErrSec.
It's my opinion that sometimes you just may as well accept that for a few seconds per day the line is going to error. I wish I could turn DLM off, as all its doing is restricting what the line is fully capable of doing for the rest of the day.
Thats basically DLM's achilles heel, the worst care scenario for it, occasional very short bursts of noise, that are just about frequent enough to keep it triggered.
-
It all depends entirely what you’re doing. If all you ever do is use TCP, then who cares about noise bursts? On the other hand if you use non -retransmitting L4 protocols then you might care a lot, eg VoIP, IPTV and so forth.
-
Thats true weaver, its a tough one, IPTV probably ok if the burst isnt powerful enough to trigger any SES, but I do remember when that fault I had happened a couple of months back, and my discord calls were a little shaky.
-
Since I’ve worked a lot on dramatically cutting the rate of CRCs and ES’s, the problem I had with audio garbling in Zoom has almost entirely (touch wood) been fixed.