Print

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

[tommy45]

I think NS was questioning your statement that G.INP wouldn't return if you capped your line, as you wouldn't break DLM thresholds. DLM applies G.INP to all lines on Huawei cabinets no matter how the line performs, so a cap would make no difference to that.

Glad to hear it has already been reapplied to your line. DLM appears to be speeding this up as a couple of months ago it was taking weeks to return.

In the distant past (over 12mths ago) it would take up to 14 days, but that was after it had interleaved the connection it would take that long to get fast path back ,But over the past 12mths it's always been on , it changed its parameters once IIRC but's about it ,
But with regards to G.inp being enabled regardless on Huawei Dslams then you would think that after the first 24hrs if the error threshold had been breached then DLM would enable G.inp as a default option , and only if that failed to then revert to interleave or banding ?

Though looking at my stats i see that i have a small  bit of spare ds margin,  but the attainable is oddly lower than the sync  and looking back over my stats  the US margin has remained around the same value but the attainable has also dropped , though it isn't affecting the  us sync because it's capped at 20mbps as per the or product secs ,  and in the fact that every time the phone rings  it generates  a burst of 11-20 error seconds  depending on how long it rings for, even without a handset connected ,  and there are also a number of both us/ds Fec errors generated at the same time and more recently  even some us bit swaps , To me this smells of a HR fault  as there should be no interaction  between PTSN and BB ,

[tommy45]

I have been looking at the stats and i can see a similar pattern of  downstream CRC errors  when on fast path  & Downstream FEC errors ,some of the time, if you compare the graphs  from when the connection had G.inp enabled  you should see the resemblance , On G.inp they aren't as significant as far as DLM will be concerned 

And today i'm also seeing errors when i lift the handset /make a outgoing call

[tommy45]

Well activity from a neighbour (Kebab takeaway) which is located between the PCP and my home and on the same cable bundle The error threshold was breeched last night whilst i was out , so now interlagged  by the woefull dlm

Zen ran another GEA test on Friday, and the results recorded something about electrical interference , I'm determined more than ever now to get this fault sorted out  zen will be wishing that they hd left my circuit alone, I know i do

[NewtronStar]

Does sound like your pair in a joint has become degraded, while driving back home this afternoon I decided to count each BT joint from PCP cabinet to my home which = 1000 meters and there was 10 joins it's going to take a lot of OR investigation to find which one needs attention.

[tommy45]

Does sound like your pair in a joint has become degraded, while driving back home this afternoon I decided to count each BT joint from PCP cabinet to my home which = 1000 meters and there was 10 joins it's going to take a lot of OR investigation to find which one needs attention.

well my line is 349mtrs from the cab according to the GEA FTTC test , and all is UG & the majority is probably in ducts ,ie the run from cab from frame boxes to the dp and from there  not in ducting  under the footway outside my home there is at least 20mtrs of cable coiled up directly underneath the paving slabs that have since been covered with a token gesture thickness of tarmac and spray and pray liquid bitumen that is used by councils to dodge out of doing real & lasting repairs (How do i know about OR's coiled cable, well several years ago some drainage co , severed an incoming 240v supply cable  to a neighbouring property and that took out my elec supply too,)and whilst the engineers where tracing my elec cable  to the main cable in the road they uncovered this coil of copper bt cable  lay there in the sand , nothing has changed since, maybe it needs shortening , i'm sure i could hire the tools needed,lol

[NewtronStar]

Zen ran another GEA test on Friday, and the results recorded something about electrical interference ,

Can you post that GEA test showing electrical interference

[tommy45]

Can you post that GEA test showing electrical interference

Unfortunately i can't as Zen didn't supply it, only verbally, But  iirc there is a Field for it  from earlier GEA tests, it's probably a simple yes/no
Just had a look at other GEA service test results , and if this is the same Test that they ran, it doesn't have a field for electrical interference, but does have one for REIN , so maybe it was this he meant

My PTSN provider  has ran the TAM test  and it came back clear, no fault, so?? My ISP have booked an engineer for Wednesday and i'm still able to demonstrate the interaction between PSTN and BB services that shouldn't be present,  ie, Burts of thousands of FEC errors DS and a small amount of US FEC errors too,  as well as  20 us error secs /CRC's or more depending on how long the phone is left to ring for, I also see some us bit swapping during the period the phone is ringing
If i dial 175 from the landline and clear down, it rings for several mins , quite a bit longer than when i call from my mobile

Then there is the unrelated fault with the single thread that Zen appear to be doing Zero about here's how much it is impacting on the single thread , the multi-thread works as normal , and i inherited this crap after being migrated to their GEA , so it has to be down to whatever they are supposed to of done whilst i was on GEA to fix the problem , that still persists now i'm back on WBMC  http://www.dslreports.com/speedtest/6927662

I have a burning question  could a HR type fault be an underlying cause  of REIN , in that the poor connection is making rein type interference  more likely to cause a degraded service more (errors) in my case and or a lower than normal sync rate?

I asked Zen to provide me a copy of this test  which shows info about  interference , and they are unable to find it, the one they did provide shows no faults, but my line length estimate is 339mtrs, discount the coil under the footpath it probably a bit shorter

[Sheepie]

As you know, I was migrated to GEA not long after you, and 1 week later I am still on interleave up and down, in fact it has been increasng interleave every single day and it is now:

DS= INT:    1894    INP:    7.00    DLY:    10
US= INT:   427    INP:   4.00  DLY:   4

Downstream sync has gone from a very stable 80mbps to 44mbps in just over a month.

I can see possible RIEN on the D1 band but although I get a lot of FEC errors there has never been any ES errors. I have replaced the modem, faceplate and cables

So what I am confused about after all I read on this forum is
1. Why is DLM putting loads of interleave in place, more every day, when apparently it doesn't take FEC errors into account (they are corrected as they should be)  and I have had no ES errors and less than the allowed retrains?
2. Why is the DLM not putting me on G-INP, it is supported by my cab and my modem and was quite happily using G-INP before they went and migrated me to GEA?



$ adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason:    0
Last initialization procedure status:   0
Max:    Upstream rate = 27438 Kbps, Downstream rate = 76140 Kbps
Bearer: 0, Upstream rate = 15000 Kbps, Downstream rate = 44275 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):        8.8             8.0
Attn(dB):        12.6            0.0
Pwr(dBm):        12.7            3.9

                        VDSL2 framing
                        Bearer 0
MSGc:           14              29
B:              28              19
M:              1               1
T:              64              64
R:              16              16
S:              0.0208          0.0423
L:              17280           6803
D:              1894            427
I:              45              36
N:              45              36

                        Counters
                        Bearer 0
OHF:            18339953                2936149
OHFErr:         0               0
RS:             1573628480              626872
RSCorr:         22657           13850
RSUnCorr:       0               0

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

ES:             0               0
SES:            0               0
UAS:            1608            1608
AS:             30690

                        Bearer 0
INP:            7.00            4.00
INPRein:        0.00            0.00
delay:          10              4
PER:            1.67            4.75
OR:             95.62           58.82
AgR:            44370.67        15058.95

Bitswap:        1862/1868               248/248

Total time = 8 hours 58 min 18 sec
FEC:            22657           13850
CRC:            0               0
ES:             0               0
SES:            0               0
UAS:            1608            1608
LOS:            0               0
LOF:            0               0
LOM:            0               0
Retr:           0
Latest 15 minutes time = 13 min 18 sec
FEC:            555             1
CRC:            0               0
ES:             0               0
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
Retr:           0
Previous 15 minutes time = 15 min 0 sec
FEC:            203             896
CRC:            0               0
ES:             0               0
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
Retr:           N/A
Latest 1 day time = 8 hours 58 min 18 sec
FEC:            22657           13850
CRC:            0               0
ES:             0               0
SES:            0               0
UAS:            1608            1608
LOS:            0               0
LOF:            0               0
LOM:            0               0
Retr:           0
Previous 1 day time = 0 sec
FEC:            0               0
CRC:            0               0
ES:             0               0
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
Retr:           0
Since Link time = 8 hours 31 min 29 sec
FEC:            22657           13850
CRC:            0               0
ES:             0               0
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
Retr:       

[tommy45]

As you know, I was migrated to GEA not long after you, and 1 week later I am still on interleave up and down, in fact it has been increasng interleave every single day and it is now:

DS= INT:    1894    INP:    7.00    DLY:    10
US= INT:   427    INP:   4.00  DLY:   4

Downstream sync has gone from a very stable 80mbps to 44mbps in just over a month.

I can see possible RIEN on the D1 band but although I get a lot of FEC errors there has never been any ES errors. I have replaced the modem, faceplate and cables

So what I am confused about after all I read on this forum is
1. Why is DLM putting loads of interleave in place, more every day, when apparently it doesn't take FEC errors into account (they are corrected as they should be)  and I have had no ES errors and less than the allowed retrains?
2. Why is the DLM not putting me on G-INP, it is supported by my cab and my modem and was quite happily using G-INP before they went and migrated me to GEA?

1st i would ask Zen support to check and confirm that your circuit is on the Speed DLM stability profile, as there are 3 available and it's possible that you have been put on one of the other 2  DLM stability options , if you are on the speed  then that is out of the equation
DLM usually only takes action if the error rate threshold is breached or the number of re sync events exceeds the allowed quota  Mine is currently interlagged  due to the high amount of errors on Saturday night which exceeded the 2880 in at least 1 hr out of the 24hr period  a certain local Kebab takeaway i suspect is the source of the interference being injected into my copper pair as it's in between me and the cab and near to me, it will probably remain like this  for the usual 14 days or could be less or longer , unless the engineer resets it, i will be asking  for a dlm reset

[Sheepie]

yeah but for the first 24 hours after I had DLM reset I was on fastpath and even the "stable" profile was at amber which is what I would expect given I am ~271m from the street cab accordnig to Zen's line test (with no kabab takeaway in sight!).

The DLM is killing me and I don't know why, it has got to be taking something else into account as well as ES/Retrains!

At one point not that long ago these were my stats
Attainable DS=100113 (but speed capped @ 66000 with SNRm of 15.5dB)
Attainable US=32858 (but speed capped @ 14000 with SNRm of 19.2dB)

MDWS=Sheepie (large gaps today due to me turing off various ring mains in attempt to find rein - and using AM radio found very noisy CCTV transformer but removing it has not made any difference)

[tommy45]

yeah but for the first 24 hours after I had DLM reset I was on fastpath and even the "stable" profile was at amber which is what I would expect given I am ~271m from the street cab accordnig to Zen's line test (with no kabab takeaway in sight!).

The DLM is killing me and I don't know why, it has got to be taking something else into account as well as ES/Retrains!

At one point not that long ago these were my stats
Attainable DS=100113 (but speed capped @ 66000 with SNRm of 15.5dB)
Attainable US=32858 (but speed capped @ 14000 with SNRm of 19.2dB)

MDWS=Sheepie (large gaps today due to me turing off various ring mains in attempt to find rein - and using AM radio found very noisy CCTV transformer but removing it has not made any difference)

Maybe it doesn't like you capping the sync rates? or a faulty line card or other parts inside the FTTC cab My previous dlm reset was 4 -5 days of fast path then G.inp
On today's error graph the two bursts of us errors on my line where when i had the phone ringing /incoming call

[tommy45]

Looks like dlm put me back on fastpath , why not straight to G.inp?

Well just for curiosities sake i tested direct to the modem  http://www.thinkbroadband.com/speedtest/button/148104067001040226036.png

Yup as i thought the single threaded issue still evident , Zen tell me that it's one of the reasons that they are sending an  OR engineer, Crap single threaded ds throughput  i don't think is something the engineer will be looking at

[tommy45]

Well BT OR engineer attended today and the exfo results were borderline  (within spec) PQT but by 0.1 so potential HR fault, the tdr detected  2 areas, one at 4mtrs. so nte5 or first joint at the window where out side and inside cable joined , and one further away. So engineer gone to test at the pcp  will update later,
Meanwhile the single threaded issue has re-emerged and nothing has changed, prior to engineer unplugging modem to test , This has to be something on zen's side or VDSL cab issue

[Sheepie]

Have you changed MTU at all? Might be the reason for your single threaded download speed if packets are too big and it's requesting fragmentation.... you never know

[tommy45]

Have you changed MTU at all? Might be the reason for your single threaded download speed if packets are too big and it's requesting fragmentation.... you never know

No no changes made, And i did test with the modem directly connected to my pc  same issue,  Well BT or Changed the Eside pair as that's where he said the fault was, But  when i ring the phone i still get the errors he has reset dlm too thankfully


Well reading this AAISP thread over on TBB it seems that BTW are having single thread issues too http://forums.thinkbroadband.com/aaisp/f/4516449-single-thread-congestion.html

http://www.thinkbroadband.com/speedtest/button/148120617563699926122-mini.png How is this considered acceptable by BTW ?