Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: tommy45 on November 17, 2016, 02:16:50 PM
-
Since for some reason due to being transferred from bt backhaul to Zen's llu FTTC(GEA) migration, i have lost G.inp and 8-9mbps of ds sync , but although the us snr has gained around 2db the attainable rate is lower than it was previously even before the days of G.inp it was higher , But looking at my current stats something just doesn't seem right , it's like dlm is capping the sync
But with the rate of ds errors i don't see fast path remaining for long, it better hadn't clobber me with laggy interleave , hopefully it will re-enable g.inp MDWS user is Tom34 btw for anyone wanting to have a look
-
your attainable is slightly under sync. Perhaps you are being hit by a cross talker?.. I would be keeping an eye on the attainable. If it starts falling off by a few mb then I would assume a cross talker..
But when g.inp returns I would imagine your sync will increase and errors will drop. I would leave alone until g.inp returns and then see what the stats are saying after that.
-
your attainable is slightly under sync. Perhaps you are being hit by a cross talker?.. I would be keeping an eye on the attainable. If it starts falling off by a few mb then I would assume a cross talker..
But when g.inp returns I would imagine your sync will increase and errors will drop. I would leave alone until g.inp returns and then see what the stats are saying after that.
I should not really have lost g.inp in the 1st place, as for the attainable DS being under the sync, when g.inp was on the ds snr had dropped to 5.2db but and sync from 79+mbps to 77mbps and on occasions the snr would jump up to 6db and ds attain was back at 79mbps and my last uptime was 230 days
-
still I guess you will just have to sit it out and see what happens when it comes back (g.inp that is)..
Wish I had your line stats lol... ;D
-
still I guess you will just have to sit it out and see what happens when it comes back (g.inp that is)..
Wish I had your line stats lol... ;D
Well i doubt i'll have a long wait just had a error second burst of 614 errors secs in the past hr I think it will manage to exceed the error rate threshold within the next 24hr window Why did make DLM so dumb? I someone has had G.inp for years like myself and the line was operating fine ,then why upon a resync change that? has it not got any memory apart from error rates?
Update: After the error counter getting within 900 aprox of triggering a red light of the speed dlm profile today has seen a lot lower error rate so far , So the return of G.inp delayed
-
Well i was wrong , still on fast path , just, and now when the phone rings there is a burst of ds errors as well as us errors secs, and a burst of fec's on the us too,
Due to the burst of ds errors that have been happening at or around 4pm each day since fast path was enabled due to losing G.inp, i think it will only take a day with several incoming calls to reach the 2880 error secs to trigger dlm , I'm going to report a bb fault to my ISP
As i cannot hear any noises on the line so have no fault with the voice service, But this adverse interaction between PTSN and data services should not be happening, therefore, it is a fault that Openreach should repair, I'm sure they will find it's location using the exfo or jdsu test equipment, because the remote GEA test is not helpful with this kind of fault , maybe if Zen ran the new copper test that is designed to sniff out hr dis type faults it would detect it, but there again maybe not
-
What "new copper test"?
Last I saw, the latest GEA FTTC test can return something like "suspected impaired copper joint".
-
What "new copper test"?
Last I saw, the latest GEA FTTC test can return something like "suspected impaired copper joint".
the "new" well not new anymore but the latest copper test , The GEA test doesn't pick up much tbh , plus there can be issues with the bit that runs the test at the head end, the test i was making reference to is called Copper Integrated Demand Testing(CIDT)
Anyhow facts are there is an interaction between PTSN and data and that should not be there, regardless of the tests the ISP have run or can run , because some remote test does not detect an issue doesn't mean that there isn't one , so a good isp will never become over-reliant on remote test results
-
You have a choice manually cap the DS sync on the HG612 while you wait for G.INP to come back it has only been 3 days since you lost G.INP.
-
you need to give it up to 14 days tommy.
if you think the errors are excessive then cap the speed in the mean time.
-
You have a choice manually cap the DS sync on the HG612 while you wait for G.INP to come back it has only been 3 days since you lost G.INP.
But if the errors seconds don't breach the threshold Dlm won't apply G.inp, infact it won't do anything if i artificially cap I will end up with less whilst paying more, and since zen's Gea backhaul & routeing via everything via london bs which doesn't benefit me, as i live in the north west , combined with their on-net crappy single thread throughput Give me BTW Anytime
I want this HRdis fault fixing it is the underlying reason why the sync is so low and even with a SNR of 6.9db the attainable is ultra low something is wrong with the line plant i pay each month to maintain so why should i pee about capping my sync? and if you factor into things the now passed IP snooping bill, Spy on us all, all of the time bs(With the exception of politicians connections) that the traitor of a PM wanted the internet connection is becoming rapidly less significant in my book,
And no i don't subscribe to Sky or BT amazon or any of them, who broadcast biased propaganda against the majority of the indigenous people of this country all 17.5 million of them if not more by now
-
Well Zen are being a bit awkward insisting that i change the filter and modem before they will progress the fault, and as they have already ordered migration back to WBMC they cannot raise a fault until that completes , or even run tests other than the GEA test,allegedly, knowing my luck G.inp will have been reactivated and the connection will get migrated back to wbmc and another DLM reset
-
But if the errors seconds don't breach the threshold Dlm won't apply G.inp, infact it won't do anything if i artificially cap
Not sure where you got that information from but if you can expand please do so :-\ Have seen lines go from Fastpath to G.INP without needing to be Interleaved before getting G.INP reactivated, and yes I have seen posts saying you only get G.INP if your line requires it though it would seem G.INP is applied regardless of what type of error correction is used or errored seconds count during 24 hours.
You lose G.INP during a BT OR DLM reset
You lose G.INP during a ISP transfer
-
Not sure where you got that information from but if you can expand please do so :-\ Have seen lines go from Fastpath to G.INP without needing to be Interleaved before getting G.INP reactivated, and yes I have seen posts saying you only get G.INP if your line requires it though it would seem G.INP is applied regardless of what type of error correction is used or errored seconds count during 24 hours.
You lose G.INP during a BT OR DLM reset
You lose G.INP during a ISP transfer
And it was down to being migrated from BT wholesale WBMC over to GEA (Zen's cable link) this will of been caused by the DLM reset, due to the differences in the DLM stability profiles between the 2 backhauls or that the migration between to 2 needs a resync take effect, But as to why i have lost sync speed im not sure, but the us attainable and the SNR are lower than they were
Well looks like G.inp is reactivated sync up to 76,5mbps so is now 3.5,Mbps less than it was
-
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.
-
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 ,
-
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
-
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
-
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.
-
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
-
Zen ran another GEA test on Friday, and the results recorded something about electrical interference ,
Can you post that GEA test showing electrical interference
-
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
-
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:
-
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
-
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)
-
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
-
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
-
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
-
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
-
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 ?
-
Well the engineer fixing the fault on the E side has not sorted the issue with error bursts from a certain kebab shop perhaps he couldn't be bothered to break out the step ladder and check the length of cable from the bt grey wall box to just inside my window, He was only IMO around 50 % cooperative , in that he came up with some tripe about stuff, I expected better from a BTOR engineer who claimed to be a rein engineer, But when he said that the equipment couldn't perform a basic speed test in order to test the throughput i was told it does do that well the equipment he used was an EXFO AXS-200/635 unit, and according to the product manual it has the capability to do what i enquired about , The issue lies on the D side pair
Then there is a separate issue of pish poor single threaded throughput that zen have done zero about in the past 3 weeks since they migrated my circuit over to GEA and 2 weeks later returned back onto WBMC yet the issue has followed me has to be with their side of things which they ain't accepting, bottom line in conversation with them, was i was asked what do i want?, my reply was the service that i am paying you for, is that too much to ask? still waiting for the call back on that btw and i still have the single threaded issue,
So BT or arent going to investigate a issue with throughput are they? Unless there is someone who knows differently please give us the benefit of your knowledge
-
How are you testing the single thread download - always from the same [windows] PC? If so then I would test from a different wired device if you can. Or download and burn a bootable linux CD, like Knoppix, and boot your PC from that and test download again, just to rule out anything your end.
-
How are you testing the single thread download - always from the same [windows] PC? If so then I would test from a different wired device if you can. Or download and burn a bootable linux CD, like Knoppix, and boot your PC from that and test download again, just to rule out anything your end.
1, I seriously doubt it's my PC or the ethernet connection to it, it isn't my router either
2, I don't at this present time have another working PC to test anyway Unless someone is going to reimburse me for buying one or building another ie new board and CPU then it won't be happening i am sick of this nonsense It is something zen's side or BTW's less likely the kit including the cab to the exchange cable links
UPDATE:
I think that i have through my own process of elimination testing found that this issue with single thread performance for myself at least is almost certainly not any of my equipment it's not the line either, last night after switching my LAN connection to my PC from routing via my router, to a direct link to the BT modem instead and i found that there is no issues, i had previously reverted back to the normal modem ><router><PC config, and still retained normal throughput, i did this last night , at 6.00 am dlm re-enabled G.inp and speedtests on zen's different lns gateways, were back to the rubbish single thread performance,
I have just tested directly to the modem, and 1 gateway i am getting normal ss performance and on the only other i able to hop onto The performance is poor on single stream ,
It's also odd that after the engineer had finished testing from the test jack , that i had the poor ss performance across all gateways, until connected directly and swapped gateways as it connected to the same one on the 1st attempt ,
It has to be something configured incorrectly which happened when they migrated my circuit