Print

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

[mrk26]

Is there anyone who is on this trial on eci cabinets and using lantiq based chipset modem?

[j0hn]

Yes.

https://forum.kitz.co.uk/index.php/topic,24403.msg412216.html#msg412216

A few Plusnet Hub Ones on the Plusnet forums also.

https://community.plus.net/t5/Fibre-Broadband/ECI-Cabinets/td-p/1708051

[kitz]

My daily dose of SHINE got stuck again yesterday.  Total Err Secs for the day = 1483
I had a forced resync this morning at 03:48 and it looks like the DLM may have banded me at 67Mbps.


I've just tried another resync and still at 67Mbps

Code: [Select]

Max:    Upstream rate = 24881 Kbps, Downstream rate = 68700 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 66999 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
Trellis:                U:ON /D:ON
Line Status:            No Defect
Training Status:        Showtime
                Down            Up
SNR (dB):        6.5             9.4
Attn(dB):        0.0             0.0
Pwr(dBm):        6.8             6.8
The INP value has also increased to 52.   
Notice also for the first time since being on G.INP my max sync is now more than my actual.   I'd commented just the other day about my max value being less since re-tx had been applied on my line.

Code: [Select]

                        Bearer 0
INP:            52.00           0.00
INPRein:        1.00            0.00
delay:          0               0
PER:            0.00            6.15
OR:             0.01            202.87
AgR:            67092.23        20203.27

                        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


G.INP doesn't cope well with my daily bursts of SHINE 

The reason I say doesn't cope well, is that when the bouts of SHINE stick, then whilst on G.INP absolutely no data can be sent or received on my connection.   
Prior to G.INP at least some data was able to get through and I would get DSLstat alerts informing me there was a problem.   

Each time it happens now, then I get loads and loads of these errors in my DSLstats event log, thus it may be some time before I notice there is a problem with my connection - making it too late to manually intervene like I used to be able to.

12 Apr 2020 08:50:35   Email alert failed (unable to login to SMTP server)
12 Apr 2020 08:51:13   Email alert failed (unable to login to SMTP server)
12 Apr 2020 08:52:14   Email alert failed (unable to login to SMTP server)
etc etc etc


It's annoying because that daily SHINE is usually only for a minute or so per day and the rest of the day its fine.    No amount of Interleaving or G.INP is ever going to be able to correct what happens during that SHINE burst.     Since being on G.INP those daily SHINE bursts have stuck far more frequently than they usually do.
Not quite sure what will happen next, because if the SHINE bursts continue to get stuck and I'm not getting email notifications then DLM I guess will just keep continuing to take further action with the banding?

[tiffy]

With your somewhat unusual line characteristics and the very successful work around you pioneered it's a very unfortunate bi-product in your case of the very long awaited re-application of G.Inp to ECI cabinets.

Still, I'am sure you will manage to formulate a new solution/work around, good luck, will follow with interest.

[ejs]

Or the behaviour of kitz's line will get G.INP on ECI banished again.

[Chrysalis]

well kiz i prefer the new g.inp dlm, you been dlmd twice now and still no interleaving banding > interleaving

[kitz]

Or the behaviour of kitz's line will get G.INP on ECI banished again.

Hope not..  it works really well aside from my daily error burst each morning.      It's well known that retransmission doesn't work well with shine and types of rein.

Thing is DLM on the ECIs is cutting in at low level Err/secs - way below what there were.    This isn't anything to do with g.inp, but has been happening for a while now and its not unique to my line.   Chrys has just had it happen to him too.   

If it were still the 'old' parameters then I would not have had DLM action a couple of days ago as I spotted that myself as I was on the forum and everything just stopped working, so I was able to correct it quite quickly.   It's like the transmission queue buffer cant cope with the amount of errors and just backs up until no data at all gets through.  Webpages wont load, email doesn't contact the host etc.   Pre g.inp everything would slow down but at least a good portion of data would still be transmitted. 

well kiz i prefer the new g.inp dlm, you been dlmd twice now and still no interleaving banding > interleaving

Aye - I'm on re-tx high so my throughput speed is probably not so great as it could be due to the IProfile - in turn due to additional overheads...  and the banding is still at a figure that I'm ok with.    Still in a better than it would be if I was interleaved.

[j0hn]

I think I might have suggested this before although I can't remember if it was to yourself or someone else.

I know it won't help much when you're getting so many ES that DslStats struggles to send an email, but you could try automate the process of taking your line down instead of having to react when you receive the DslStats email.

Something like IFTTT can do this.

Connect Zyxel modem to your TP-Link power socket (if you have a spare 1).
When X amount of ES occurs in a set time period have DslStats email IFTTT with a chosen #hashtag.
Have IFTTT turn off your TP-Link WiFi power socket when the above email is sent, immediately stopping the ES burst.

This would mean instead of you having to react to resync your line as quickly as possible you would only have to manually power the modem back on.

I have a similar IFTTT email trigger set up and it works perfect every time.

https://imgur.com/a/UftVkWU

As your line now has G.INP instead of just fastpath you should be able to set the ES trigger in Dslstats much lower than you had it before.

[Weaver]

That IFTTT stuff is very clever, I’ve seen the iOS app. Got any urls for reading matter?

[kitz]

Hi J0hn.    I hadnt realised that IFTTT had an email address so thanks for that.   

I do already have the modem plugged into the TPlink HS100 so I can remotely manage it even if out.
   
What I normally do upon receiving the email notification is 
1) Set up a new instruction to automatically power on the HS100 to power on in 5 mins time
2) Then Switch off the HS100.


I shall have to have a look and see if I can do something on IFTTT to get it to bring it back up again too, because once it's down then I have no remote control at all. 

I also have it currently set to alert on CRCs as opposed to Err Secs.  From past experience if I get 3 emails in a row saying the CRCs have gone above a certain amount then its more likely to be a stuck.   I did originally have it set up for Err Secs and cant exactly remember why now, but the CRCs seemed to give a better indication and sooner if it was stuck rather than the Err Secs did.   
From memory I think it was because the ErrSecs count was per hour...  by which time it was often too late.   3 or 4 consecutive emails each min alerts me much sooner that there is a problem.   I sometimes have to do a judgement call based on the CRCs..  ie if say they are at 800 on mail 1, 1200 on mail 2, and 500 on mail 3 then its usually ok...  but if its say 800, 1200, 1200, 1200 I know its stuck.

Although I get a dose of SHINE practically every morning - its never at the same time (can be between 8am and 11am) nor did it ever cause the same amount of CRCs/Err secs.    Since G.INP it does seem to cause a full 60 err secs per min..  yet when on INP it would be more varied and not always the full 60 err secs. 

[Chrysalis]

Talking about profiles, we know FEC is used without delay on the US, and some also may remember back when I had a pair swap a few years back, my DS was synced at around 50mbit, I had FEC "without" delay on my DS also that day,  but I have never ever seen that profile on anyone's line since.  It would be nice on non g.inp line's if FEC with no delay was used instead of FEC+delay.

I have now massively reduced the ES threshold on my dslstats email config given all the changes that have been happening.

[mrk26]

There is a FEC on downstream and upstream on eci cabinet if you using modem with lantiq chipset. They are present on mine and I'm on fastpath and no delays, unfortunately no g.inp on my line.

[j0hn]

As it appears things are working does anyone want to guess when the trial will be expanded as I feel I am missing out now

I should have posted in the Plusnet thread to get on the trial but didn't want to risk problems with my connection at this time but as things seem positive I wish I risked it now.

Seems they are taking requests from ISP's to have G.INP enabled.

https://www.ispreview.co.uk/index.php/2020/06/openreach-extend-g-inp-to-more-eci-fttc-broadband-lines.html

The recent trial, which is still on pause, was an attempt to deploy ReTx to all ECI lines in a more strategic way. However a new briefing from Openreach (here) claims it will offer ISPs “the chance to deploy ReTransmission to more of their VDSL lines.” The focus of this, we’re told, seems to be on a large volume of in-life ECI lines.

Openreach estimates that around 17% of ECI lines could benefit from ReTx and so they’ve agreed, upon request from an ISP, to deploy the upgrade to in-life ECI FTTC lines over the next six weeks or so. Apparently providers will be able to opt-in to this between now and 9th July 2020. We don’t know exactly how many lines will benefit but it looks like a significant proportion of their estate.

[broadstairs]

I woke up this morning to find G.INP enabled on my ECI line this morning and now on fast path running at 67000kbps down. I'm with TalkTalk btw.

Stuart

[ktz392837]

Openreach Extend G.INP to More ECI FTTC Broadband Lines

https://www.ispreview.co.uk/index.php/2020/06/openreach-extend-g-inp-to-more-eci-fttc-broadband-lines.html