Print

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

[NewtronStar]

Those stats look more healthier than my own so I see no reason why it should not at least hit the 35 Mbps mark, don't see any G.INP yet on that line yet it is on the huawei cabinet.

[burakkucat]

I think it is important to remember that G.Inp does not necessarily have to be active on a circuit.

If the hardware (DSLAM & modem) supports its activity, then G.Inp will be enabled if the DLM decides that it will be beneficial.

[WWWombat]

In a Pratchettian world, I can picture all those G.imps running retransmission through the clacks to ensure perfect communication.

[NewtronStar]

I think it is important to remember that G.Inp does not necessarily have to be active on a circuit.

If we take MDWS as a small snapshot on what is happening around the rest of the UK with huawei cabinets then it shows 99.7% of lines the DLM has decided it is beneficial to apply G.INP 

[burakkucat]

In a Pratchettian world, I can picture all those G.imps running retransmission through the clacks to ensure perfect communication.

Indeed! 

My excuse: I was hungry and needed to check in my food bowl. As a result there was paw-slippage, in my haste! 

[WWWombat]

then it shows 99.7% of lines the DLM has decided it is beneficial to apply G.INP 

And as to how beneficial it is, we can only look at the stats.

My line has currently been up for 87 days. In that time, I have had zero ES's downstream. Not one single error has slipped past the combination of interleaving, FEC and re-transmission, even though all three have been called into play.

BT's own report on the effectiveness of G.INP retransmission comes from the graph below. I must be one the "66% error-free" after re-transmission, so I guess I am far from alone.

[waltergmw]

Gentlefolk,

Sadly DLM seems to have gone into doze mode !

Retrain Reason:   1
Last initialization procedure status:   0
Max:   Upstream rate = 7744 Kbps, Downstream rate = 39752 Kbps
Bearer:   0, Upstream rate = 6000 Kbps, Downstream rate = 27398 Kbps

Link Power State:   L0
Mode:         VDSL2 Annex B
VDSL2 Profile:      Profile 17a
TPS-TC:         PTM Mode(0x0)
Trellis:      U:ON /D:ON
Line Status:      No Defect
Training Status:   Showtime
      Down      Up
SNR (dB):    15.3       15.0
Attn(dB):    25.4       0.0
Pwr(dBm):    11.2       2.4
         VDSL2 framing
         Bearer 0
MSGc:      22      118
B:      237      174
M:      1      1
T:      64      18
R:      16      16
S:      0.2764      0.9259
L:      7352      1659
D:      1      1
I:      254      96
N:      254      192
         Counters
         Bearer 0
OHF:      89562672      704572
OHFErr:      632      85
RS:      1437029335      4013532
RSCorr:      4270      499
RSUnCorr:   3843      0

         Bearer 0
HEC:      3789      0
OCD:      247      0
LCD:      247      0
Total Cells:   3765416465      0
Data Cells:   16840522      0
Drop Cells:   0
Bit Errors:   0      0

ES:      884      107
SES:      42      0
UAS:      172      130
AS:      397617

         Bearer 0
INP:      0.00      0.00
INPRein:   0.00      0.00
delay:      0      0
PER:      4.43      16.73
OR:      50.45      59.29
AgR:      27448.30   6059.33

Bitswap:   279037/279037      27/27

Total time = 1 days 6 hours 50 min 14 sec
FEC:      6430      42927
CRC:      10704      133
ES:      884      107
SES:      42      0
UAS:      172      130
LOS:      4      0
LOF:      35      0
LOM:      0      0

[WWWombat]

Hi Walter,

Can you collect more stats over time, but taking care to include the full batch that looks like the last 9 lines?

900-odd ESs in 30 hours isn't intolerable, and wouldn't trigger DLM intervention, but it might be enough to stop DLM de-intervention. SES of 42 isn't that good either. Nor are UAS of 172, LOS of 4, or LOF of 35. They're all pointers that something still isn't quite right.

[Bald_Eagle1]

FWIW, I am remotely monitoring this connection with Walter & I have the ongoing & snapshot raw data auto-emailed to me every morning.

For graphical reference purposes, I have attached a montage of the ongoing stats graphs for the latest 10 days as obtained by 06:00 this morning, along with the snapshot montage using data from 06:01.

[NewtronStar]

Still the D2 band line attenuation & signal attenuation is to high at 56dB to get close to 30Mbps that would need to change to 51 or 52dB

[Bald_Eagle1]

Sorry, NS.

That's not the case.

See the montage from my own connection from when the intermittent fault was repaired back in 2012 (well before I started seeing any crosstalk effects).

Line & Signal Attenuation in the D2 band both at 64.8 dB.

[NewtronStar]

Well that is not the way you taught me 2 years ago the lower the dB on each band = a higher sync rate see my stats

[Bald_Eagle1]

Yes, but SNR/SNRM also has an effect.

At only 51.9 dB attenuation, your SNRM was only 6.6 dB.
No doubt the result of poorer QLN.

At 56 dB or so, the other user has a better QLN & thus SNRM of 15.3 dB, so plenty of scope for more speed to come.

[NewtronStar]

Cheers BE1 as always you have made it very understandable 

[WWWombat]

Thanks BE

If I read those graphs right, the final set of stats in Walter's post really applies to 10 days, not 1 day 6 hours, and includes 5 resyncs.

I've fallen foul of one of the bugs in the output from the HG612, haven't I?

That makes all of those stats firmly "ordinary".