"Interleaving causes DELAY - ie increase in latency/ping times. Interleaving does NOT cause loss of sync speed."
I will change that to add 'alone'. I had tried to clarify the difference between the two, but perhaps the addition of the word 'alone' in there it will make it clearer?
For every non-G.INP VDSL2 connection that I have seen stats for since 2011, a switch from fastpath to Interleaved has ALWAYS coincided with an increase in attainable rate & definitely a decrease in sync speed.
When fastpath and/or reduced Interleaving depth have been restored, attainable rate has reduced again & sync speed has increased.
Do you have an explanation for this?
Based on what you say, my suspicion (but that's all it is) is that sync speed has been reduced by DLM to provide more stability, alongside Interleaving/delay etc.
From the limited detailed stats I have seen from G.INP active connections to date, it appears that a reduction in Bearer 0 Interleaving depth etc. has actually resulted in slightly LOWER sync speeds.
For pre G.INP, it will be INP that decreases the sync speed.
There are a couple of things I dont understand
[1] Why max attainable rate always seems to go skewy when Interleaving and Error Correction is turned on.
[2] Why /how FEC alone affects sync. We've known for several months that BT had been dabbling with FEC without INP or Interleaving on the upstream but I could never fully understand what was happening there and if you recall in the early days I had started beginning to wonder about PhyR.
I still see occasional FEC on my own lines upstream yet there is no INP or Interleaving. Yet for FEC to occur then there must be some very low level redundancy somewhere. Perhaps because so many lines can reach their upstream target easier and because Interleaving isnt applied we havent been looking closely enough as to why this could be and if its possible that BT by default is applying Error Correction and weve never noticed the loss in attainable upstream sync... and we never seem to pay much attention to upstream like we do for downstream.
Ermmm actually further to the above - Ive just looked more closely at my stats.
VDSL2 framing
Bearer 0
MSGc: 18 150
B: 239 236
M: 1 1
T: 23 5
R: 0 16
There you go - the
R value proves that BT is using a low level of upstream Error Correction by default on their DSLAMs, that isnt anything to do with the usual DLM settings. One mystery [#2] solved.