Print

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

[NewtronStar]

Just a bit concerned that all lines will see a stable fasthpath once G.INP is removed some lines may have to many errored seconds to remain on fastpath and the DLM will send them back to interleaving.

Once G.INP is removed it goes into interleaving then to fastpath if the errored seconds counts have gone above 2880 Speed and 1440 Standard profile the DLM may introduce interleaving

That was always the case even before G.INP

[Ronski]

My works line stayed interleaved (it always has been generally), my home line did go on to fast path but is back interleaved, which it often used to be.

[WildBill]

Once G.INP is removed it goes into interleaving then to fastpath if the errored seconds counts have gone above 2880 Speed and 1440 Standard profile the DLM may introduce interleaving

Hey there,

Are those the errored seconds values per 24hr DLM period?
Where did you get those values from?

Cheers

[skyeci]

I get 400-600 ds es per 24 hour.still on fast path

[Ktor]

I currently have 2 US and 2 DS CRC errors in 65 hours of up time. The session before had 1 US CRC error in 101 hours which is why I am not impressed with this ECI G.INP fiasco forcing at least downstream interleave on my connection for 8 weeks and counting.

[kitz]

DLM uses MTBE to calculate acceptable errors.

So if you are on speed profile and have a full days uptime

MTBE red = 86400/30 = 2880
MTBE green = 86400/300 = 288
Anything in between is amber and considered OK.

[MikeZ]

DLM uses MTBE to calculate acceptable errors.

So if you are on speed profile and have a full days uptime

MTBE red = 86400/30 = 2880
MTBE green = 86400/300 = 288
Anything in between is amber and considered OK.

Do we know for sure that DLM uses a 24 hour period and doesn't look at the number of ES/SES over smaller intervals, too? I had a big spike this morning (268 ES between 9 and 10am) and one SES. No resync, though. My MTBE is 106s over 24 hours.

[Chrysalis]

I think its 24 hours, last week when I had that very nasty 2-3 hour spell, I was way over the MTBE threshold during that short period but over 24 hours I was ok.

[MikeZ]

I think its 24 hours, last week when I had that very nasty 2-3 hour spell, I was way over the MTBE threshold during that short period but over 24 hours I was ok.

Thanks - I guess I'll find out soon enough

[Mark07]

It's a bit frustrating they decided to remove it from *ALL* ECI lines, at my parents' they gained about 6meg with it on, and now it's been removed they've lost about 8meg from it (I suspect extra noise since it last resynced)

[skyeci]

Well thats not strictly correct as 3 users on mydslstats still have g.inp on eci lines. The reason why it remains on these lines does not appear to be totally clear.
Fingers crossed they may sort it, hopefully not abandon it..

[kitz]

Openreach are under the impression that the only lines with g.inp remaining are those with multicast.
That was just last last week and supposedly they still havent made a final decision for removal from multicast lines. 

The multicast info was originally included in the original statement made 30th April.   However I removed the IPTV info as npr had said despite him having BT-TV,  g.inp had been rolled back for him and therefore assumed that had made a decision.

If your line has been reset indications are that it wont come back on... and therefore I doubt purchasing BT-TV would now cause it to kick back in again.

[kitz]

btw.   Has anyone else notice that since they've rolled back it takes ages to get re-connected and get a new PPP session.

I was fine before.. this has only started tonight...  but then again tonight is the first time Ive had to resync since g.inp was rolled back plus I cant recall having to do a manual resync since g.inp was enabled.

[WWWombat]

The BT Wholesale ISP Forum document (from 12th May) has a little to say about the subject of Retransmission on ECI:
- Openreach were removing retransmission on ECI
- The decision affects 260k lines
- Does not include multicast; decision due on those lines on 13th May
- The reason given: "we are experiencing a much higher than average fault rate for these lines"
- "Openreach working with its supplier"
- If I read it correctly, one item that BTW fed back to BTOR was: "ECI retransmission - why wasn’t it trialled more thoroughly?"

260,000 lines doesn't seem like a lot. Either there are a lot using multicast, or the rollout hadn't gone very far.

To check, I looked back at the cabinet composition data we got in Autumn 2014, as part of the application for unmetered power supplies. That data provided a snapshot for 34,000 cabinets (out of perhaps 55,000 that were installed at the time), of which 15,000 cabinets were ECI ones. The breakdown of ports in use suggested there were perhaps 750k lines on those 15,000 ECI cabinets at the time.

I would guess there has to be over a million lines in use now - even if most of the rollout since then has been Huawei.

[kitz]

@wombat

That info sounds like it may be old - its basically what I reported on the 30th of April and before they made the decision to roll back on all lines except multicast. 

The reason I removed the multi-cast info on May 1st was that npr who had BT-TV said that he had been rolled back, so I assumed that Openreach had already made the decision (which from the info I got ) was due by mid-May.   However it does appear that those few remaining MDWS lines still on ECI G.INP do have IPTV services.