Kitz Forum
Broadband Related => Broadband Technology => Topic started by: Weaver on March 28, 2019, 02:26:36 AM
-
Can I ask if any kitizens have L2 retransmission protocol technologies on upstream or downstream or both?
This term covers either the standard G.INP (https://kitz.co.uk/adsl/retransmission.htm) protocol or else the Broadcom-proprietary ‘PhyR’ (https://forum.kitz.co.uk/index.php/topic,15188.msg282331.html#msg282331) in ADSL2/2+ )
I have the PhyR form of L2 retx protocol but only on downstream, not on the upstream for some reason. This is really really annoying, as my upstream is painfully slow and experience from the downstream shows that L2 retx can get me a good bit more speed because the substantial gain in extra reliability achieved by the use of L2 retx can if desired be traded back for yet more speed instead, and I could really do with using L2 retx to speed up the upstream too.
-
On my line G.INP is enabled in both directions but I don't know how I could help you.
-
iirc the ITU-T standard for G.INP doesn't support upstream retransmission on adsl2/2+
-
@kitz - so perhaps that’s related to why I have no proprietary PhyR on upstream for my ADSL2 then? I wish I understood it.
-
Yup that will be the reason.
-
I'm not convinced that that is the reason. There appear to be ADSL only modems that have independent PhyR on/off settings for the upstream and downstream.
-
A possible disincentive might be, in order to support retransmission, the modem needs to be able to store the data that might need to be retransmitted. That might increase manufacturing cost (ram requirements), which might be seen as hard to justify, in cost-conscious consumer appuratus.
The amount of ram needed would be a function of the time it must be retained, pending acknowledgement, and the rate at which it is sent.
Just guessing though. :)
-
I think G.INP was originally based around using the amount of memory that would have otherwise used for interleaving. Interleaving also needs to store the delay's worth of data in order to re-arrange it.
-
Please excuse my confusion. The line that I mentioned is running on vdsl2.
-
It is an absolutely superb feature. It gives me very very roughly the equivalent of another 3dB of SNRM and about another 5% downstream sync speed. The reliability improvement is absolutely spectacular, looking at the ratio of FEC error count to bad CRCs count when running at 3dB downstream target SNRM and drooping down to about 2dB during part of the day.
—
I will do some number crunching for all the lines when I am a bit less tired, but here are some numbers for my line 1:
Since Link / Up-time = 5 days 6 min 23 sec = 432383 s
FEC downstream: 178704 CRC downstream : 15
FEC upstream: 46825 CRC upstream: 330
Downstream CRC / FEC = 8.3937684663E-05 = 1 / 11913.6
Upstream CRC / FEC = 7.0475174E-03 = 1 / 141.8939393939
This is with an upstream target SNRM of 6dB and target downstream of 3dB. The effectiveness of the combined error correction systems is spectacular, as too is the difference in effectiveness between downstream and upstream, especially given that the target SNRM difference is in the ‘opposite’ direction.
A question: can I work out how busy the line has been ? How much data has been going through it in both directions?
I thought about looking at the error counts per hour, but then I thought that a busy line and an idle line should not be placed side by side where counts are concerned.
For ADSL2 with ATM, can I take the modem’s reported "data cells" ATM stats figure and multiply by 53 bytes times 8 bits? There are several cell counters: there is that figure and a total ATM cells figure.
-
CRC and FEC counts will be completely unaffected by the amount of traffic going over your Internet connection.
-
Just so I understand, that is because there are idle cells screaming through all the time?
I need to have a proper picture of what is going on with ATM here when things are idle. And I also need to understand what it is that a CRC is the CRC of? What does it cover? (And what when there’s no user data.) my ignorance here is shameful. :-[ :( ???
-
Just so I understand, that is because there are idle cells screaming through all the time?
Basically yes.
I get the similar FEC/ES/rtx_tx when I'm downloading at 40Mb/s over a 6 hour period as I do with just the modem synced (No router/PPP).
-
I clearly need to read up on ATM properly.
-
See Improved impulse noise protection for digital subscriber line (DSL) transceivers (https://www.itu.int/rec/T-REC-G.998.4)
Annex A specifies Support of ITU-T G.998.4 with ITU-T G.992.3 (ADSL2)
Annex B specifies Support of ITU-T G.998.4 with ITU-T G.992.5 (ADSL2+)
A.1 Specific requirements
For [ITU-T G.992.3], retransmission is defined only for the downstream direction (i.e., DTUs are transmitted only in the downstream direction and the RRC is transmitted only in the upstream direction).
B.1 Specific requirements
For [ITU-T G.992.5], retransmission is defined only for the downstream direction (i.e., DTUs are transmitted only in the downstream direction and the RRC is transmitted only in the upstream direction).
A lot of the constraints do appear to be related to memory, which are far more defined when used with ITU-T G.993.2 (VDSL2) - See Annex C
C.1 Specific requirements
C.1.1 Memory
The following definitions shall apply:
delay_octetDS,0 = (DDS,0 – 1) × (IDS,0 – 1)
delay_octetUS,0 = (DUS,0 – 1) × (IUS,0 – 1).
If retransmission is enabled in the downstream direction,
then delay_octetDS,1 = 2×Qtx,DS×QDS×HDS
otherwise delay_octetDS,1 = (DDS,1 – 1) × (IDS,1 – 1)
If retransmission is enabled in the upstream direction,
then delay_octetUS,1 = 2×Qtx,US×QUS×HUS
otherwise delay_octetDS,1 = (DUS,1 – 1) × (IUS,1 – 1)
...etc...
-
PhyR and G.INP are not the same though.
I assume that the capability for upstream PhyR is enabled on Weaver's modems. The Openreach HG612 has PhyR enabled on the downstream but disabled on the upstream by default, so perhaps other Broadcom modems have similar PhyR default settings.
-
Agreed.... but PhyR was the basis for G.998.4
Broadcom's PhyR impulse noise protection and retransmission technology is currently being considered for DSL standardization.
I can't find any other SP who has used retransmission with adsl2/2+ that enabled it on the upstream.
The question was availability of upstream Retx being available for Weavers line. That answer would be no because he's on adsl2/2+.
-
Apparently G.998.4 was the amalgamation of two different vendor retransmission schemes (according to the Ikanos pdf here (https://forum.kitz.co.uk/index.php/topic,15188.msg282331.html#msg282331)). The absence of upstream retransmission for ADSL2/2+ in G.998.4 could be from limitations of one scheme, or the other, or how they were combined, or some other reason.
Because PhyR is not G.998.4, the non-existence of G.998.4 for ADSL2/2+ upstream does not imply the non-existence of PhyR for the ADSL2/2+ upstream.
-
The stats give the impression that Broadcom or ZyXEL’s designers were expecting upstream PhyR to be a possibility, because they show stats relating to PhyR for upstream, which are all zero of course.
-
Is upstream PhyR enabled on your modems? You can check with: xdslctl profile --show
-
As expected, enabled by the look of it ?
VMG1312-B10A
Login: admin
Password:
> xdslctl profile --show
Modulations:
G.Dmt Disabled
G.lite Disabled
T1.413 Disabled
ADSL2 Enabled
AnnexL Enabled
ADSL2+ Disabled
AnnexM Disabled
VDSL2 Disabled
Phone line pair:
Inner pair
Capability:
bitswap On
sra On
trellis On
sesdrop Off
CoMinMgn Off
24k Off
phyReXmt(Us/Ds) On/On
TpsTc AvPvAa
monitorTone: On
dynamicD: On
dynamicF: On
SOS: On
Training Margin(Q4 in dB): -1(DEFAULT)
>
-
Yes it's enabled in both directions.
I don't think 24k bytes of interleaving memory needs to be disabled, although I think that's only applicable to ADSL2+ (where modems can use either 16k or 24k bytes of interleaving memory).
-
That is an interesting comment regarding the 24k bytes of interleaving memory. I've just taken a look at the configuration of my VMG1312-B10A and see that the 24k capability is "on".
> xdslctl profile --show
Modulations:
G.Dmt Disabled
G.lite Disabled
T1.413 Disabled
ADSL2 Enabled
AnnexL Disabled
ADSL2+ Disabled
AnnexM Disabled
VDSL2 Enabled
VDSL2 profiles:
8a Disabled
8b Disabled
8c Disabled
8d Disabled
12a Disabled
12b Disabled
17a Enabled
30a Disabled
US0 Disabled
Phone line pair:
Inner pair
Capability:
bitswap On
sra On
trellis On
sesdrop Off
CoMinMgn Off
24k On
phyReXmt(Us/Ds) On/On
TpsTc AvPvAa
monitorTone: On
dynamicD: On
dynamicF: On
SOS: On
Training Margin(Q4 in dB): -1(DEFAULT)
>
-
I don’t understand that 24k entry. It isn’t something that I have every seen in the UI anywhere, so it isn’t a choice that I made intentionally when configuring the thing.
Is there a chance that that option, however it has got set the way it has, is restricting the device’s ability to choose the highest interleave depths ?
I could do with some help understanding the other entries in that list, but that topic deserves a thread in its own.
-
The only comment I can make is that my device was configured entirely from the GUI and not by editing a pre-saved configuration file which was then subsequently restored.
-
The 24k option is only applicable to ADSL2+.
ADSL2 only has 16002 bytes available for interleaving. Opting for ADSL2 only removes the possibility of using 24000 bytes for interleaving.
-
I robotically edited the config file by using a program that applies regex-based search-replace operations on the XML to change things like IPv4 addresses per modem, and n-th modem index numbers 1,2,3,4 where needed to make them correct per-modem, that kind of thing. I then checked the output by diff-ing the output against the original, so as to make sure that the program had not only done the right thing where it was supposed to but had also not gone ‘rogue’ and applied any changes anywhere else where it shouldn’t due to a false accidental match. The edit operations used complex ‘context’ regexes to strictly limit edit sites down to where they are supposed be, only in the right XML context. So I was quite paranoid about the likelihood of bugs.
The modems refer to per-modem addresses 192.168.n.1 and 192.168.n.254, where n is 1…4, and .n.1 is the modem’s admin interface looking towards the Firebrick and .n.254 is the Firebrick’s modem-facing interface. That is one example of a systematic change that is straightforward.
-
The 24k option is only applicable to ADSL2+.
ADSL2 only has 16002 bytes available for interleaving. Opting for ADSL2 only removes the possibility of using 24000 bytes for interleaving.
That is another interesting fact I have just learned.
The service I receive is deployed from the TalkTalk MSAN in ADSL2+ (ITU-T G.992.5) mode. I restrict the circuit to operate in ADSL2 (ITU-T G.992.3) mode by appropriate configuration of the CPE. Hence the former, I presume, is why the 24k option is seen enabled within my VMG1312-B10A.
However that has me slightly puzzled by what we now know about the four services deployed from the Broadford exchange to the Heasta "Weaving Shed". :-\
-
The 24k option means 24k * 1k = 24 Mbps? = G.992.5?
-
The 24k option means 24k * 1k = 24 Mbps? = G.992.5?
Looking at the words of our own expert, earlier, above --
I don't think 24k bytes of interleaving memory needs to be disabled, although I think that's only applicable to ADSL2+ (where modems can use either 16k or 24k bytes of interleaving memory).
-- I think you have misinterpreted the meaning of that option!
-
I am absolutely full of morphine, a double shot tonight and that on top of various other drugs. So it was all a bit blurry trying to read the earlier thread. :-[ ??? :no:
-
Bearing in mind that Kitz drew our attention to the forbidding of upstream G.998.4 in the case of G.992.3 https://forum.kitz.co.uk/index.php/topic,23280.msg395111.html#msg395111 although ejs also reminds us that PhyR is not G.998.4, I still don’t understand why the standards for G.992.3 or the practical choices in PhyR don’t support upstream L2ReTX in G.992.3?
You have to write the code anyway don’t you, for the other case, G.993.2 surely, so why not use it for G.992.3 as well ? For PhyR you can make your own modem models look better than the competitors’ by an even greater margin?
-
I never found anything definitive that states upstream PhyR does not exist for ADSL2/2+. Perhaps it is just not enabled for your line.
I can speculate about the reasons why the designers didn't do upstream retransmission for ADSL2/2+:
- The primary motivation for retransmission was for the delivery of IPTV, a downstream only service.
- The ADSL2/2+ upstream uses lower frequencies than the downstream, which have lower attenuation and maybe suffers less from interference anyway. This is unlike the VDSL2 upstream, where most of the upstream bandwidth comes from high frequency bands.
-
Thank you for your insight