Print

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

[tommy45]

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

[skyeci]

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.

[tommy45]

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

[skyeci]

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...

[tommy45]

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...

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 

[tommy45]

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

[ejs]

What "new copper test"?

Last I saw, the latest GEA FTTC test can return something like "suspected impaired copper joint".

[tommy45]

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

[NewtronStar]

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.

[Chrysalis]

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.

[tommy45]

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

[tommy45]

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

[NewtronStar]

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

[tommy45]

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

[j0hn]

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.