Okay I promised I'd respond, but Im tired & aching and in need of a shower and food and my bed.. so it will be briefer than originally intended. Perhaps a good job I didnt have time to reply earlier today otherwise I probably would have done a lot more ranting too.
---
linkTo be clear though, the profile update only removes the automatic application of upstream interleaving, where a line does not support retransmission in the upstream. It does not disable retransmission on lines that are capable of supporting it on the upstream.
This is
FALSE. - It is not what we are seeing in reality. Line stats from our forum users and MDWS show that since 25th of May more than 20 lines which have had Mk2 G.INP rolled out they have had G.INP removed from the upstream. All these lines use compatible g.inp equipment ie HG612 modems or Billion/Zyxel own routers.
- We already knew long beforehand that the fix is to remove upstream interleaving for non-compatible modems - thats not new news
- The screen shot of the DLM profiles provided by Andy does nothing to prove what he said.
Conversely it could prove what we noticed right from the start - ie that DLM now removes g.inp from the upstream if it thinks it doesnt need it. Whether it is still using the 300MTBE as a decider or not isnt yet known The option is still there as a possibility if DLM thinks it may benefit the line, and since G.INP is now a configurable parameter then it makes sense to me that they would use the same MTBE rules as previously for triggers. - Its yet another case of someone having information which has been (mis)interpreted to prove a point that is not fact. Showing a list of available DLM parameters in itself, absolutely in no way shape or form confirms that g.inp will remain on the upstream for fully compatible g.inp modems, just that an upstream g.inp profile is available. Its the equivalent of me showing the list of old DLM parameters and saying 'All lines are interleaved' just because some of the profiles mention interleaving
- I know I keep banging on about this - but it really is important to note the distinction between Interleaving, Error Protection & Error Correction (FEC) because they aren't the same thing.
I am sick and tired of certain people dissing members of this community for daring to suggest something isn't working as it should. Let me state here and now that nothing that BlackSheep has ever said has EVER proved to be false and Im well sick to the back teeth how certain people have disregarded this community or its members though information that has either been mis-quoted elsewhere or someone has an agenda because information coming from here is not how they interpret information. Without information coming from here and using tools by our community and some of us saying this is wrong... then you'd have the likes of Andy still quoting "
It doesnt cause any degradation of the line", "
How is it affecting your performance?" [to someone syncing 10Mb less and interleaving in the 40ms] and the best one yet "
You keep going on about the modems being incompatible - they are compatible and have been tested for quite some time."
Openreach are partially to blame for this. Information has been sparse and often confusing and sometimes what they say doesn't make total sense. Some of you are aware I do have some information direct from Openreach but I have not released such information because IMHO it only muddies the water further until I get proper clarification. Note to all the nay-sayers - this doesnt come from BS, but someone very high up in Openreach who
should know what is going on. However, things are now slowly beginning to fit together and if you take what users are seeing, the information that I do have, plus the list of new profiles.
It would appear that Openreach has rejigged the available profiles. The full list isnt there, but we can see things like what appear to be what could be used in the following circumstances
[& obviously depending on line conditions]- Section 1. The open profile,
- Section 2. A sample profile for a line whose equipment doesnt support g.inp and an example of what previously happened by default if the modem was g.inp incompatible
- Section 3. This is interesting - Note how ReTX is available for upstream only - I want to see the full list of profiles before commenting further.
- Section 4. Huawei cabs - ReTX applied by default for downstream with the new available upstream profiles. Note how upstream reTX is still available. Note the absense of any interleaving. Note Error Protection off (probably not the same as Error Correction)
I suspect there will be more available profiles and why I wont comment further until Im sure, but it does appear to back up what we have suspected since the 25th of May, that interleaving has been removed from the upstream, but that DLM can also turn off g.inp if it thinks it doesnt need it... but the option is still there if the line does.
This is why I told mikelj to hold fire, because DLM
may adjust later to add it. I have seen some lines whereby they do adjust over a few days and although Ive yet to actually see one get g.inp turned back on, it looks like the possibility is still there, so I suggest leaving for a while to see what happens. Those lines where it was switched off completely and have stayed that way appear to be below the MTBE threshold so DLM may be happy to keep it like that and satisfied that there are insufficient errors to apply further DLM intervention. It will be interesting to watch what happens with mikeljs line.
---------
PS
Meant to add - G.INP isnt always a good thing and doesn't necessarily work well on all lines - could ramble on more but will let
ASSIA do the talking.
With retransmission, a line experiencing frequent noise bursts can suffer significant throughput degradation.