Print

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

[burakkucat]

In exchange for those two textual files, I offer you a montage of the four "snapshot" plots . . .

[mnotgninnep]

Ooh, are those generated from my logs? That's nifty, thank you.

I still have no idea what it all means... 

[j0hn]

Your line looks pretty healthy to me.

Connected to a Huawei cabinet which is good.
You have retransmission low (aka G.INP) set on the downstream

The line looks to be running with a 6dB SNRM target.
If it remains stable DLM may lower it to as low as 3dB which would give you another 10-12Mb (roughly, from looking at your current bitloading that's my educated guess).

1 thing I do note is

Code: [Select]

rtx_tx:         223190763 
I have no idea how to reset this. That figure will be from the previous owner.
Could you run adsl info --stats again after about 24 hours and upload the results.
I'd like to see the difference between the 2 rtx_tx figures (downstream retransmit).
Also 5 LEFTERS in just over an hour, seems a little high.

If you're not sure on what some of the stats mean

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

[ejs]

Code: [Select]

rtx_tx:         223190763 
I have no idea how to reset this. That figure will be from the previous owner.

It can't possibly be from the previous owner of the device, surely? Maybe the count would be retained at the DSLAM, considering that for the downstream, it'll be the DSLAM maintaining that counter of how many DTU it retransmits. Section 12 of G.998.4 also states "The counters shall be reset at power-on.".

[mnotgninnep]

Your line looks pretty healthy to me.

Connected to a Huawei cabinet which is good.
You have retransmission low (aka G.INP) set on the downstream

Good news. is exactly why I came to you guys for advice on modems having failed myself...

The line looks to be running with a 6dB SNRM target.
If it remains stable DLM may lower it to as low as 3dB which would give you another 10-12Mb (roughly, from looking at your current bitloading that's my educated guess).

1 thing I do note is

Code: [Select]

rtx_tx:         223190763 
I have no idea how to reset this. That figure will be from the previous owner.

Excellent. I would hope it would improve. When first connected, I was getting 77Mb but put the drop down to the cabinet being full. There are only 3 ports left apparently. I hope the speed does rise again. I'm already faster than I was before all this kicked off.

The rtx_tx figure is more likely from:
a) The line fault the Openreach engineer fixed, previous owner put the line under a wooden floor and it got crushed. He was surprised the number was so high and thought the line fault was to blame. I think it's Cabinet side as the number has persisted (increased) between the early Draytek readings and this.
b) The issues I had with the Draytek Vigor 130 not liking the Huawei cabinet.
c) The issues I had with the TP-Link TD-W9970 being stable but not working with 1508 MTU so data getting lost. I couldn't be bothered to reconfigure the whole network because I knew the ZyXEL was coming.

Could you run adsl info --stats again after about 24 hours and upload the results.
I'd like to see the difference between the 2 rtx_tx figures (downstream retransmit).
Also 5 LEFTERS in just over an hour, seems a little high.

If you're not sure on what some of the stats mean

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

Will do. Those were obtained not long after putting the ZyXEL in, so may be residual.

It can't possibly be from the previous owner of the device, surely? Maybe the count would be retained at the DSLAM, considering that for the downstream, it'll be the DSLAM maintaining that counter of how many DTU it retransmits. Section 12 of G.998.4 also states "The counters shall be reset at power-on.".

I'm fairly sure the number came up on the OR engineer's device. Anyone fancy arranging a local powercut?

[burakkucat]

Anyone fancy arranging a local powercut?

It would have to be for an extended period, in excess of eight hours, during which time all Openreach (or more correctly Operate (as the "fibre" cabinets are classified as exchange equipment)) technicians would have to be otherwise occupied elsewhere and so be unable to change the cabinet batteries!

[mnotgninnep]

It would have to be for an extended period, in excess of eight hours, during which time all Openreach (or more correctly Operate (as the "fibre" cabinets are classified as exchange equipment)) technicians would have to be otherwise occupied elsewhere and so be unable to change the cabinet batteries!

Haha, I forgot that. Before I moved house, I was with Virgin and they weren't required to have backup power so every time there was a power issue, the phones and everything went out with it.

Could you run adsl info --stats again after about 24 hours and upload the results.

Here you go.

Code: [Select]

> adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason:    1
Last initialization procedure status:   0
Max:    Upstream rate = 24468 Kbps, Downstream rate = 65839 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 65216 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(0x0)
Trellis:                U:ON /D:ON
Line Status:            No Defect
Training Status:        Showtime
                Down            Up
SNR (dB):        6.4             15.3
Attn(dB):        13.4            0.0
Pwr(dBm):        13.7            3.3

                        VDSL2 framing
                        Bearer 0
MSGc:           -6              26
B:              243             237
M:              1               1
T:              0               42
R:              10              16
S:              0.0000          0.3781
L:              17056           5374
D:              8               1
I:              254             127
N:              254             254
Q:              8               0
V:              0               0
RxQueue:                51              0
TxQueue:                17              0
G.INP Framing:          18              0
G.INP lookback:         17              0
RRC bits:               0               24
                        Bearer 1
MSGc:           154             -6
B:              0               0
M:              2               0
T:              2               0
R:              16              0
S:              6.4000          0.0000
L:              40              0
D:              3               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               1621124
OHFErr:         57              899
RS:             776004888               713393
RSCorr:         70982           16106
RSUnCorr:       0               0
                        Bearer 1
OHF:            1444606         0
OHFErr:         5               0
RS:             14445447                0
RSCorr:         121             0
RSUnCorr:       18              0

                        Retransmit Counters
rtx_tx:         7469            0
rtx_c:          7111            0
rtx_uc:         40694           0

                        G.INP Counters
LEFTRS:         120             0
minEFTR:        65218           0
errFreeBits:    183374826               0

                        Bearer 0
HEC:            0               0
OCD:            0               0
LCD:            0               0
Total Cells:    2909878671              0
Data Cells:     39268053                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:             25              359
SES:            10              2
UAS:            113             103
AS:             23212

                        Bearer 0
INP:            47.00           0.00
INPRein:        0.00            0.00
delay:          0               0
PER:            0.00            3.98
OR:             0.01            64.22
AgR:            65283.00        20063.54

                        Bearer 1
INP:            4.50            0.00
INPRein:        4.50            0.00
delay:          3               0
PER:            16.06           0.01
OR:             79.68           0.01
AgR:            79.68   0.01

Bitswap:        1195/1195               1474/1475

Total time = 1 days 4 hours 43 min 13 sec
FEC:            164418          29401
CRC:            618             1245
ES:             25              359
SES:            10              2
UAS:            113             103
LOS:            1               0
LOF:            8               0
LOM:            0               0
Latest 15 minutes time = 13 min 13 sec
FEC:            0               15
CRC:            0               1
ES:             0               1
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
Previous 15 minutes time = 15 min 0 sec
FEC:            446             14
CRC:            0               8
ES:             0               5
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
Latest 1 day time = 4 hours 43 min 13 sec
FEC:            6761            11227
CRC:            1               52
ES:             1               47
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
Previous 1 day time = 24 hours 0 sec
FEC:            157657          18174
CRC:            617             1193
ES:             24              312
SES:            10              2
UAS:            113             103
LOS:            1               0
LOF:            8               0
LOM:            0               0
Since Link time = 6 hours 26 min 51 sec
FEC:            70982           16106
CRC:            57              899
ES:             12              115
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0

[highpriest]

The Vigor 130 didn't like my line/huawei cabinet at all. I was getting tons of dropped packets/line syncs. My line rate compared with the Plusnet HubOne (BT HH5) dropped from 65Mb down to 48Mb over a week. I've since found lots of posts online of people having issues with the Vigor 130, Plusnet and/or Huawei cabs. Being a Lantiq chipset, it would be better suited to an ECI cab. I've also seem something somewhere about G.INP/Vectoring being a last minute addition to the firmware and apparently disabling it in the web interface fixes stuff.  Of course there's also the possibility I was unlucky and got a faulty unit, but by that point I'd fallen out with it and was running out of time to return it for a full refund. With the TP-Link, everything became stable, but as you can see, I've just found that it doesn't support baby jumbo frames.

Not just you. I had exactly the same experience with a Vigor 130. After syncing for years at 80/20, I lost 6 Mbps in just 3 days with the Vigor. And it never recovered until I eventually switched ISPs (and my line underwent a full reset). There's something about that chipset that really upsets the DLM on Huawei cabinets.

I wish they did a Broadcom version of that modem.

[Weaver]

For ADSL1/2/2+ users, I loved the fact that the Vigor modems do PPPoEoE on the LAN side to RFC2364 aka PPPoA protocol conversion, and allowing IP 1500 MTU on the DSL side of things. So I am surprised that they do not offer MTU 1508 with VDSL given that they are already handling PPP MTU 1508 with PPPoEoE on the LAN side in the ADSL case.

I take it that it is not a problem with a router not speaking RFC 4638 ie supporting ethernet baby jumbo frames with a 1508byte oversized L2 payload.

[mnotgninnep]

For ADSL1/2/2+ users, I loved the fact that the Vigor modems do PPPoEoE on the LAN side to RFC2364 aka PPPoA protocol conversion, and allowing IP 1500 MTU on the DSL side of things. So I am surprised that they do not offer MTU 1508 with VDSL given that they are already handling PPP MTU 1508 with PPPoEoE on the LAN side in the ADSL case.

I take it that it is not a problem with a router not speaking RFC 4638 ie supporting ethernet baby jumbo frames with a 1508byte oversized L2 payload.

The Draytek did 1508 MTU fine. It just wasn't keeping the line in good sync.
It was the need for a broadcom based modem that did it that was the tricky part.