Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Weaver]

I have been getting occasional huge downward spikes in my downstream SNRM vs time graphs from my ADSL2-speaking modems. I’m assuming these spikes are SHINE, big noise spikes of fairly short duration. Is that correct? It looks as if that is overwhelming my PhyR and INP. I get one every few days or so, sometimes more frequently than that. Pictures below.

I don’t ever get any downstream interleaving, which imho is bad news. I’m thinking that this is because I have PhyR, and maybe the reason for the lack of interleaving is that the combination of interleaving and PhyR would both cause delays that would add up, and the software thinks that the combined delay would be too much. But I don’t care about the delay and I can’t think of any way of controlling such a max delay setting. Is any of this thinking right?

I can’t ever get downstream interleaving to turn on, as revealed by looking at the modem stats’ D parameter. I can adjust the downstream interleaving settings in AA’s server but it has no effect. I get three options for the downstream setting: "Off", "Medium" and "On", and I’m set to "On". I think that if the noise spikes are short enough then a very high interleave depth would be just what I need, but maybe there’s just some practical reason why it won’t fit in with the use of PhyR. Can anyone who is on VDSL2 and has G.INP let me know what their interleave depth setting is? That is, the D value, I don’t mean just just on/off.

         ADSL2 framing
         Bearer 0
        down      up
MSGc:   51        11
B:      18        78
M:      8         1
T:      5         1
R:      16        16
S:      1.7896    3.8191
L:      751       199
D:      1         8

A thought: It’s a shame that we can’t tell these systems “I have multiple lines, IP-bonded, with CQM”. This could mean the system could adjust its DSL-level settings accordingly, being aware of the fact that an outage on one line isn’t the end of the world, because when the CQM kicks in having detected packet loss on a line, and reassigns traffic to other lines they will then quickly handle the rest of the traffic.

On another matter, AA has turned off DLM on my lines, as per my request, and this has ended BT’s madness, pushing up downstream SNRM to crazy values, halving my data rates. Having recently done an SNR reset, right now I’m still in the 10-day training period, so does that mean that DLM-like retrains will still intervene during that time even though real DLM is supposed to be off?


Here are the SNRM vs time pictures for my lines 1 and 3:




You will see in these graphs that the downstream SNRM had gone up to crazy levels, thanks BT, before the start of the captured time period, so I reset it back down to what it should be, that’s the drop you will see later on.

Any comments, analysis would be very welcome.

[burakkucat]

Can anyone who is on VDSL2 and has G.INP let me know what their interleave depth setting is? That is, the D value, I don’t mean just just on/off.

Certainly. The VDSL2 framing section from the statistics follows --

Code: [Select]

VDSL2 framing
Bearer 0
MSGc: -6 43
B: 178 31
M: 1 1
T: 0 64
R: 12 2
S: 0.1424 0.1017
L: 10727 2675
D: 16 1
I: 191 34
N: 191 34
Q: 16 0
V: 2 0
RxQueue: 21 0
TxQueue: 7 0
G.INP Framing: 18 0
G.INP lookback: 7 0
RRC bits: 0 24
Bearer 1
MSGc: 90 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 10.6667 0.0000
L: 24 0
D: 1 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0

(I'll send a copy of the complete snapshot log, captured on April 1st, to you by e-mail.)

[Weaver]

So much for my idea then. Here we see Burakkucat’s downstream interleave depth of a magnificent 16 and he has downstream G.INP too on his VDSL2 circuit. So that proves that systems don’t feel they always have to have no interleaving if ReTX is in use.

I’m sure I’ve asked the question before, but I can’t remember. I’m aware that PhyR is a Broadcom-proprietary term. Is there any difference between G.INP on ADSL2 and PhyR ?

I’m not used to reading G.INP stats since I never get shown any PhyR-related parameters from my modem when it is in ADSL2 mode - for some reason. @Burrakucat and everyone: is there no upstream G.INP on Burakkucat’s VDSL2 line shown here?

Why is that, does anyone know ? Is it something that Huawei (?) DSLAMs can’t handle (but I thought those systems were just using Broadcom kit anyway?)  I’m assuming that Burrakucat’s modem can potentially handle upstream G.INP when in VDSL2 mode, given permission to go for it. Is it that the DSLAM doesn’t agree in initialisation negotiations ? Or is it BT, for some really weird reason?

I see non-zero ReTX-related parameters on the upstream side in Burakkucat’s stats section, but is that just the presence of the RRC?

I can’t have upstream PhyR for some reason as the G.992.3 +G.998.4 standards forbids upstream G.INP for ADSL2 and I’m assuming that that’s the same for PhyR. I don’t know why that’s the case. It can be bidirectional in VDSL2, so what’s the problem? Would need an amended or additional subsection in G.998.4 where it talks about operation of G.INP with ADSL2.

I could really do with upstream ReTX, assuming an update to the G.998.4 standard relating to ADSL2. Or else just let it be a  Broadcom-only proprietary capability until they submit such a new ADSL2/ADSL2+ capability change for standardisation. In the past, I have sometimes had periods where upstream ADSL2 with no ReTX available at 6 dB SNRM is not good enough to prevent errors. For some reason the only upstream target SNRM options offered to me with ADSL2 are 6 dB or 9 dB. No 3 dB for some reason, not that it would work properly for me without ReTX, but with ReTX the fantasy upstream performance would be spectacular. Does anyone know why the settings are so limited? I have briefly tried 9 dB in times of trouble and it really hurts performance, as you would put:
(i) sorting out downstream interleaving capability with PhyR for me,
(ii) upstream ReTX for ADSL2,
(iii) PTM for my ADSL2 !!
(iv) a Broadcom/ZyXEL fix for the stats listing on my modem in ADSL2 mode so that I get PhyR-related framing parameters and better ReTX-related event counters in the stats too. I don’t understand those counters at all, so fixing the UI would be essential, or maybe ripping out that code and reorganising it so that the results make sense and are informative.

(Since we have the modem code from ZyXEL, maybe we could find where the relevant PhyR parameters live, perhaps getting inspiration by looking at the G.INP code for the VDSL2 case and also then reusing the reporting code that is there to printf the stats in the VDSL2 case too. I hate trying to find this stuff though - I just loathe trying to read other people’s code.)

How I do long for PTM. Thinking about it over-simplistically, it might give me nearly 10% extra speed, and it is indeed a true free lunch. Working out the actual speed improvement figure for my systems is not possible just now because I don’t get any stats on PhyR from my modems for who knows what reason, so I can’t evaluate exactly how much protocol-bloat/overhead there is in PhyR currently and how that might be affected with a change of ReTX-related framing parameters due to the switchover from ATM to PTM with different DTUs, and maybe other factors. All things being equal, I would get back 1-48/53 = 9.4 % less encoding expansion, for large packets, from losing the ATM per-cell bloat, and I’d lose some of my current one-off header overhead of 32 bytes. But I don’t have enough information to evaluate the one-off PTM overhead or the 64/65 framing/encoding expansion, but the latter must be 2-3% or more given what Kitz has said about bloat/expansion with VDSL2, which uses PTM. In that scenario though there are other (possibly useless) protocol headers involved that are related to VDSL2, or its use-cases, not to PTM. So a very dodgy guess, there might be a gain of very approximately ~6% speed completely for free. I’d like to know more about the overheads of VDSL2 with and without G.INP if anyone out there is up for helping me with info.

I chose not to think too much about the case of small packets and ATM. Given the highly variable, length-dependent expansion bloat of ATM, which becomes absolutely massive with short packets, one cell can turn into two worst case, each times 53 bytes waste per partly filled cell. Also my fairly typical 32-byte one-off all-DSL-related protocols combined overhead including one-off ATM AAL5 overhead, that 32 bytes can also push things over a size boundary so that an extra cell is required, doubling the size of the short message. I’m assuming that sending a great lot of short messages is not a common situation, is that right? What about use-cases such as VoIP? I have no idea how big the IP packets are in typical VoIP conversations.

[burakkucat]

I’m sure I’ve asked the question before, but I can’t remember. I’m aware that PhyR is a Broadcom-proprietary term. Is there any difference between G.INP on ADSL2 and PhyR ?

I believe that Kitz has mentioned, in the past, that there are differences between G.Inp and PhyR but I can't put a paw on the relevant post.

Looking at the little snippet, above, have you noticed that there is a Bearer 0 and a Bearer 1? If I am remembering correctly, Bearer 0 carries the (normal) data whilst Bearer 1 only carries those data packets which need to be resent.

In my particular case, the VDSL2 link is between a Huawei MA5603T (the cabinet based DSLAM) and a Huawei HG612 (in The Cattery). (The latter device is the G.993.2 end-point, the PTM end-point and a VLAN (tagged 101) end-point. It just passes Ethernet frames to/from the router.)

@Burrakucat and everyone: is there no upstream G.INP on Burakkucat’s VDSL2 line shown here?

Correct. That is the Openreach / BT default. G.Inp can be turned on by the DLM process; if it is considered to be necessary.

Why is that, does anyone know ? Is it something that Huawei (?) DSLAMs can’t handle (but I thought those systems were just using Broadcom kit anyway?)  I’m assuming that Burrakucat’s modem can potentially handle upstream G.INP when in VDSL2 mode, given permission to go for it. Is it that the DSLAM doesn’t agree in initialisation negotiations ? Or is it BT, for some really weird reason?.

See my previous comment.

[Weaver]

Now you mention it I do remember reading something about the use of bearer 1, but I would need to re-read G.998.4 ti refresh my shockingly bad memory. The RRC carries the retx requests I think, 24 bits in each message to the DSLAM, but again my memory is bad and so that could be totally wrong. I think that the RRC is in the bearer 0 upstream possibly, from the look of the stats. I think that probably retransmissions are triggered by receipt of a positive NACK, a retransmit-request, not by a timeout, because it needs to be triggered very quickly, unlike transport layers where non-receipt and timeout triggers a retransmission. (They have no choice, because they never normally see corrupt packets as they would get dropped in L3. That was how the transport layer that I once designed worked, by timeout, not positive NACK.)

The business of co-opting another bearer in G.INP is interesting, if we’ve got that right. It means they’re assuming that no one ever uses the other bearers really, because G.INP is eating one up. Or at least an application cannot use the same total number if bearers any more. Perhaps it’s a feature that has being loudly ignored by users and systems designers? IPTV would be one application though, no? But I am pretty sure that IPTV needs L2ReTX as that’s mentioned in some PhyR documents that I’ve read as being a use-case that drove the creating of PhyR/G.INP - the need for ultra high reliability without ruining the speed with an enormously high target SNRM for errors that may rarely happen but would be unacceptable to IPTV users. So that means that some of what I’ve written doesn’t sound right.

Note to self - just re-read G.998 properly and cease writing nonsense

Is the lack of upstream G.INP in VDSL2 something due to BT ? Or the particular DSLAMs?

I wonder if anyone uses the ethernet facility with VDSL2? Perhaps someone finds the VLAN tagging facility useful for non-IP applications, or for things targeting different endpoints within a demultiplexing router, one that say has some kind of IPTV support with different requirements? Or more like, a separate output for VoIP audio or something to do with VoIP IP going onto a LAN. But otherwise, the ethernet MAC headers would be just more unnecessary bloat, unless carriers find it useful to use ethernet switches internally. I seem to remember that, Kitz, was it, amongst others, wrote something about the use of BT TV in maybe BT-specific wireless routers (which their marketing people keep calling hubs, because they can’t just use existing standard terminology, for some reason. Just like IBM, in the ‘70s, and NASA in the 60s.)

[burakkucat]

Is the lack of upstream G.INP in VDSL2 something due to BT ? Or the particular DSLAMs?

For a UK VDSL2 service, using the Openreach infrastructure, the DLM process will enable G.Inp on the upstream . . . if it is deemed necessary or beneficial. By default, G.Inp on the upstream is disabled.

So to answer your question, ". . . due to BT ?", we need to consider who defined the current algorithm of the DLM process.

[kitz]

Tried to answer yesterday, had to abandon.

>>  AA has turned off DLM on my lines
>> I can’t ever get downstream interleaving to turn on

I'm confused. Interleaving needs participation of the MSAN & modem.   It won't work if the DLM is turned off.
However, interleaving and DLM are sometimes used interchangeabily, in that an ISP may say DLM is off when in reality its interleaving that has been disabled on the DSLAM.

>>  three options for the downstream setting: "Off", "Medium" and "On", and I’m set to "On"

1) Permanently Off
2) Controlled by DLM. (as it sees fit depending upon the state your line)
3) Permanently On.

Differences re g.inp, transmission etc on main site.   

Interleaving doesnt work well with SHINE.   Overheads.  ( known phrase from bcm -  "it steals your bandwidth").  I wouldnt recommend after seeing amount of your dip.

Openreach DLM config options:

    Downstream:
    [Speed band], Error Protection Off, ReTx Low, ReTx High, Interleaving Low, Interleaving High.
    Upstream:
    [Speed band], Error Protection Off, ReTx Low, ReTx High, Interleaving On.

You wanted some VDSL stats.
My line is currently sick hence 60Mbps banding again.

Code: [Select]

xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason:    0
Last initialization procedure status:   0
Max:    Upstream rate = 30719 Kbps, Downstream rate = 81753 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 60000 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State:       L0
Mode:                   VDSL2 Annex B
VDSL2 Profile:          Profile 17a
TPS-TC:                 PTM Mode
Trellis:                U:ON /D:ON
Line Status:            No Defect
Training Status:        Showtime
                Down            Up
SNR (dB):        11.4            12.5
Attn(dB):        0.0             0.0
Pwr(dBm):        5.4             5.4

                        VDSL2 framing
                        Bearer 0
MSGc:           -6              150
B:              122             236
M:              1               1
T:              0               5
R:              8               16
S:              0.0647          0.3771
L:              16186           5410
D:              1               1
I:              131             255
N:              131             255
Q:              8               0
V:              7               0
RxQueue:                136             0
TxQueue:                34              0
G.INP Framing:          18              0
G.INP lookback:         31              0
RRC bits:               0               24
                        Bearer 1
MSGc:           122             -6
B:              0               0
M:              2               0
T:              2               0
R:              16              0
S:              8.0000          0.0000
L:              32              0
D:              1               0
I:              32              0
N:              32              0
Q:              0               0
V:              0               0
RxQueue:                0               0
TxQueue:                0               0
G.INP Framing:          0               0
G.INP lookback:         0               0
RRC bits:               0               0

                        Counters
                        Bearer 0
OHF:            0               589272
OHFErr:         0               0
RS:             221968440               3924074
RSCorr:         2               3
RSUnCorr:       0               0
                        Bearer 1
OHF:            224622          0
OHFErr:         0               0
RS:             1796482         0
RSCorr:         1               0
RSUnCorr:       0               0

                        Retransmit Counters
rtx_tx:         23              0
rtx_c:          6               0
rtx_uc:         0               0

                        G.INP Counters
LEFTRS:         0               0
minEFTR:        59985           0
errFreeBits:    3301318         0

                        Bearer 0
HEC:            0               0
OCD:            0               0
LCD:            0               0
Total Cells:    416305602               0
Data Cells:     2924027         0
Drop Cells:     0
Bit Errors:     0               0

                        Bearer 1
HEC:            0               0
OCD:            0               0
LCD:            0               0
Total Cells:    0               0
Data Cells:     0               0
Drop Cells:     0
Bit Errors:     0               0

ES:             0               0
SES:            0               0
UAS:            27              27
AS:             3610

                        Bearer 0
INP:            52.00           0.00
INPRein:        1.00            0.00
delay:          0               0
PER:            0.00            6.15
OR:             0.01            202.87
AgR:            60553.63        20203.27

                        Bearer 1
INP:            2.00            0.00
INPRein:        2.00            0.00
delay:          0               0
PER:            16.06           0.01
OR:             63.75           0.01
AgR:            63.75   0.01

Bitswap:        3/3             0/0


 >

As you can see it keeps dropping, but Im feeling too poorly to have to deal with the prospect an Openreach visit.
No matter what the DLM does, it doesnt do anything to help the SHINE that I usually get on a daily basis.  What its doing now is different to the usual morning burst. But as you can see, despite banding from what should be 80Mbps down to 60Mb.   If it were standard bg noise or even a small amount of REIN, thats when interleaving is more useful.

Code: [Select]

07 Apr 2023 01:30:38 No DSL connection
07 Apr 2023 01:31:38 DSL connection restored. SNRMup = 12.7 dB, SNRMdown = 11.4 dB
07 Apr 2023 02:57:36 No DSL connection
07 Apr 2023 02:58:36 No DSL connection
07 Apr 2023 02:59:38 DSL connection restored. SNRMup = 12.8 dB, SNRMdown = 11.9 dB
07 Apr 2023 07:47:36 No DSL connection
07 Apr 2023 07:48:36 No DSL connection
07 Apr 2023 07:49:36 Unable to collect stats 3 or more times in succession
07 Apr 2023 07:49:36 No DSL connection
07 Apr 2023 07:50:38 DSL connection restored. SNRMup = 12.8 dB, SNRMdown = 12.0 dB
07 Apr 2023 17:17:35 No DSL connection
07 Apr 2023 17:18:36 No DSL connection
07 Apr 2023 17:19:36 Unable to collect stats 3 or more times in succession
07 Apr 2023 17:19:36 No DSL connection
07 Apr 2023 17:20:38 DSL connection restored. SNRMup = 12.6 dB, SNRMdown = 12.1 dB
07 Apr 2023 19:26:36 No DSL connection
07 Apr 2023 19:27:36 No DSL connection
07 Apr 2023 19:28:38 DSL connection restored. SNRMup = 12.8 dB, SNRMdown = 11.9 dB
07 Apr 2023 21:24:36 No DSL connection
07 Apr 2023 21:25:36 No DSL connection
07 Apr 2023 21:26:36 Unable to collect stats 3 or more times in succession
07 Apr 2023 21:26:36 No DSL connection
07 Apr 2023 21:27:38 DSL connection restored. SNRMup = 12.7 dB, SNRMdown = 11.9 dB
07 Apr 2023 23:20:36 No DSL connection
07 Apr 2023 23:21:35 No DSL connection
07 Apr 2023 23:22:36 Unable to collect stats 3 or more times in succession
07 Apr 2023 23:22:36 No DSL connection
07 Apr 2023 23:23:38 DSL connection restored. SNRMup = 12.8 dB, SNRMdown = 11.9 dB
07 Apr 2023 23:25:38 Unable to login to modem/router
08 Apr 2023 00:06:39 Auto snapshots taken
08 Apr 2023 01:26:36 No DSL connection
08 Apr 2023 01:27:36 No DSL connection
08 Apr 2023 01:28:35 Unable to collect stats 3 or more times in succession
08 Apr 2023 01:28:36 No DSL connection
08 Apr 2023 01:29:40 DSL connection restored. SNRMup = 12.7 dB, SNRMdown = 11.9 dB
08 Apr 2023 02:06:39 Auto snapshots taken
08 Apr 2023 02:57:36 No DSL connection
08 Apr 2023 02:58:36 No DSL connection
08 Apr 2023 02:59:38 Unable to collect stats 3 or more times in succession
08 Apr 2023 02:59:38 Unable to login to modem/router
08 Apr 2023 03:00:38 DSL connection restored. SNRMup = 12.7 dB, SNRMdown = 12.1 dB
09 Apr 2023 05:51:36 No DSL connection
09 Apr 2023 05:52:36 No DSL connection
09 Apr 2023 05:53:38 DSL connection restored. SNRMup = 12.8 dB, SNRMdown = 12.0 dB
09 Apr 2023 15:21:36 No DSL connection
09 Apr 2023 15:22:36 No DSL connection
09 Apr 2023 15:23:36 Unable to collect stats 3 or more times in succession
09 Apr 2023 15:23:36 No DSL connection
09 Apr 2023 15:24:38 DSL connection restored. SNRMup = 12.8 dB, SNRMdown = 12.1 dB
09 Apr 2023 17:17:36 No DSL connection
09 Apr 2023 17:18:35 No DSL connection
09 Apr 2023 17:19:36 Unable to collect stats 3 or more times in succession
09 Apr 2023 17:19:36 No DSL connection
09 Apr 2023 17:20:41 DSL connection restored. SNRMup = 12.7 dB, SNRMdown = 12.2 dB
09 Apr 2023 22:20:39 No DSL connection
09 Apr 2023 22:21:38 No DSL connection
09 Apr 2023 22:22:41 DSL connection restored. SNRMup = 13.0 dB, SNRMdown = 11.9 dB
10 Apr 2023 00:16:39 No DSL connection
10 Apr 2023 00:17:41 Unable to login to modem/router
10 Apr 2023 00:18:41 Unable to collect stats 3 or more times in succession
10 Apr 2023 00:18:41 Unable to login to modem/router
10 Apr 2023 00:19:42 DSL connection restored. SNRMup = 12.8 dB, SNRMdown = 11.9 dB

[Moderator: Minor edit to the format.]

[kitz]

>> The business of co-opting another bearer in G.INP is interesting,

I know this stuff, but sorry I not well enough to be able to regurgitate it concisely and my brain saying no whilst trying to read your post.
What you talk about isnt g.inp/re-transmission specific, its DSL transmission fundamentals.

Perhaps the following may be a more user friendly refresher... rather than having to take in the whole G.998 documentation and piece together how it works.

https://kitz.co.uk/adsl/retransmission.htm

I think it covers most of your questions - it even covers the usage of bearer channels with retransmission and interleaving.
Then theres this page that details the more BT/Openreach specifics.

https://kitz.co.uk/adsl/ginp-retransmission.htm

One more thing that possibly isnt covered.  DSL isnt limited to just 2 bearers... and bearers aren't the only type of channels. 
For example you have the FAST channel and Interleaved channel. Then to top it off, you can have "Interleaved=1" which is data being sent over the interleaved channel but not actually interleaved


So you could have

# Bearer 0
   *FAST {Being used for IPTV}
   *INTERLEAVED {Being used for normal data either interleaved or not interleavead}
# Bearer 1
   *FAST
    *INTERLEAVED {retransmission overheads}

Its possible to apply different levels of error protection to interleaved Bearer 1 than that on Interleaved Bearer 0

[kitz]

>> Is the lack of upstream G.INP in VDSL2 something due to BT ? Or the particular DSLAMs?

I think b*cat already covered that in that it is in use on the Huawei MSANs, but not on the ECI's.   
Having spent a considerable amount of time researching the topic several years ago, I could not see a reason why the ECI M41's when using VTU-C64P line cards could not support it.  IMO it looked more like some sort of conflict with certain modems.

I cant recall why its not compatible with ADSL possibly something to do with the framing?

[Weaver]

Many thank Kitz

[Weaver]

Recently I’ve been getting SHINE on the upstream, and it has been much more on one of my lines. I have now put the upstream target SNRM up to 9 dB on that line, which knocked the upstream sync rate down from ~730 kbps to ~530 kbps, which is a shame. So what’s that, about 27% down compared with what it was. Mind you, it’s only the one line, so in total it’s not as bad as it sounds. Surprisingly I do very occasionally get a spike breaking through, even at this level of error correction on the upstream, without PhyR, so that proves that I really need PhyR. It’s almost like the difference between 3 dB and 8-9 dB of extra SNRM. From this result, it is surprising to me that there are no BT-provided upstream target SNRM values higher than 9 dB. I would have thought that someone somewhere might need 12 dB, even though the speed would be pretty awful, but they might have an application that has an L4 protocol with no retransmissions.

[tonygibbs16]

Hello Weaver,

If you would like some more VDSL stats as a comparison, here are mine:

============================================================================
    VDSL Training Status:   Showtime
                    Mode:   VDSL2 Annex B
            VDSL Profile:   Profile 17a
                G.Vector:   Disable
            Traffic Type:   PTM Mode
             Link Uptime:   5 days: 19 hours: 20 minutes
============================================================================
       VDSL Port Details       Upstream         Downstream
               Line Rate:     20.063 Mbps       79.998 Mbps
    Actual Net Data Rate:     19.999 Mbps       79.999 Mbps
          Trellis Coding:         ON                ON
              SNR Margin:       15.2 dB            8.7 dB
            Actual Delay:          0 ms              0 ms
          Transmit Power:      -10.7 dBm          13.5 dBm
           Receive Power:      -19.5 dBm           4.8 dBm
              Actual INP:        0.0 symbols      48.0 symbols
       Total Attenuation:        8.8 dB            8.6 dB
Attainable Net Data Rate:     28.977 Mbps       93.099 Mbps
============================================================================
      VDSL Band Status    U0      U1      U2      U3      D1      D2      D3
  Line Attenuation(dB):  1.9    13.0    10.3     N/A     4.6    17.7    16.6   
Signal Attenuation(dB):  1.9    11.9     9.6     N/A     5.9    18.2    16.6   
        SNR Margin(dB): 15.1    15.2    15.3     N/A     8.8     8.7     8.6   
   Transmit Power(dBm):-24.6   -31.7   -10.9     N/A    10.4     7.9     7.0   
============================================================================

            VDSL Counters

           Downstream        Upstream
Since Link time = 20 min 55 sec
FEC:      102872      799
CRC:      0      18
ES:      0      12
SES:      0      0
UAS:      0      0
LOS:      0      0
LOF:      0      0
LOM:      0      0
Retr:      0
HostInitRetr:   0
FailedRetr:   0
Latest 15 minutes time = 7 min 41 sec
FEC:      153      0
CRC:      0      0
ES:      0      0
SES:      0      0
UAS:      0      0
LOS:      0      0
LOF:      0      0
LOM:      0      0
Retr:      0
HostInitRetr:   0
FailedRetr:   0

Cheers,
     Tony

[Edinburgh_lad]

Recently I’ve been getting SHINE on the upstream, and it has been much more on one of my lines. I have now put the upstream target SNRM up to 9 dB on that line, which knocked the upstream sync rate down from ~730 kbps to ~530 kbps, which is a shame. So what’s that, about 27% down compared with what it was. Mind you, it’s only the one line, so in total it’s not as bad as it sounds. Surprisingly I do very occasionally get a spike breaking through, even at this level of error correction on the upstream, without PhyR, so that proves that I really need PhyR. It’s almost like the difference between 3 dB and 8-9 dB of extra SNRM. From this result, it is surprising to me that there are no BT-provided upstream target SNRM values higher than 9 dB. I would have thought that someone somewhere might need 12 dB, even though the speed would be pretty awful, but they might have an application that has an L4 protocol with no retransmissions.

How can you tell the difference between SHINE and congestion?

[Weaver]

Easy, because I have detailed statistics of CRC errors collected in 30 s buckets all the time, thanks to our very own Mr johnson who wrote the custom software for various ZyXEL modems which gives direct access to pretty graphs of stats vs time, graphs of various values vs a modem’s DMT tones and raw numerical data from the modems. All this is accessible via http. I have written some large programs for my iPad that allow me to get summaries of the state of my lines and their health with diagnosis and warning capabilities and these apps use Mr Johnson’s "easy stats" protocol (I made that name up, as I had to have something to call the protocols and the service).

I see these occasional large spikes of fairly short duration, the durations may be a lot shorter than the collection bucket duration of 30 s, I can’t really tell, but sometimes there is evidence of the burst being slightly longer than 30 s, but that could just be an occasion where a burst straddles the boundary between two buckets, part being in each, but the total duration might even in that case be fairly small.

Having read a fair chunk of the standards documents such as G.992.3, G.998.4 etc, this is the definition of REIN, the following being taken from G.998.4, see the intro at the start giving definitions of all known terms:

3.9  repetitive electrical impulse noise (REIN): This is a type of electrical noise encountered on digital subscriber lines. It is evident as a continuous and periodic stream of short impulse noise events. Individual REIN impulses commonly have durations of less than 1 millisecond. REIN is commonly coupled from electrical power cable appliances drawing power from the AC electrical power network, having a repetition rate of twice the AC power frequency (100 or 120 Hz).

Presumably the second harmonic mentioned is to do with it being power vs time, not potential difference (aka ‘voltage’) vs time, so the V² gives us 1/2 + cos( 2f ) and there’s the frequency-doubling, if I remember all the good stuff from 45 years ago. I’m very lucky not to have any REIN at all because there are no houses or humans near my copper lines for the last 4.5 miles of the length, and it’s only in the stretch < 1 mile or so long nearest to the exchange that the lines are near buildings and their mains. Presumably in that stretch, RF isn’t such a concern for downstream at least because it is there that my signals are the strongest still little-attenuated, so the signal voltage there is high giving us a high SNR if measured at that location. Upstream is the reverse: RF produced from buildings would be where we least want it as the upstream is maximally attenuated there.

To sum up: I can see SHINE in the graphs from the modems anyway.

I wish I knew what was producing it, and where it might be coming from. Does anyone have any suggestions, likely candidates / typical culprits ? Do you suffer from SHINE ?

[XGS_Is_On]

How can you tell the difference between SHINE and congestion?

SHINE will show in the DSL stats, congestion won't. It's basically the same way you can tell the difference between a problem with routing and pulling the Ethernet cable out of your PC.

https://en.wikipedia.org/wiki/OSI_model