Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: 1 ... 3 4 [5] 6 7 ... 17

Author Topic: G.Inp on ECI Possibly Delayed  (Read 55579 times)

Bowdon

  • Content Team
  • Kitizen
  • *
  • Posts: 2395
Re: G.Inp on ECI Possibly Delayed
« Reply #60 on: February 28, 2017, 06:32:47 PM »

We're not talking about people getting 80/20 on either cabinet. We are talking about people at 400 to 500 metres away. On at ECI cabinet they might get 55Mb's while the Huawei with G.INP is getting 65Mb - 70Mb. So the ECI user is possibly getting 10 to 15Mb less because of no G.INP.

The ECI cabinet, by todays standard, is inferior. Because its not able to be upgraded (so far).

But as others have said BT won't do anything unless the gap becomes noticable to the general public, and if a big public fuss is made about it.

From what I understand by previous replies to my posts if ECI people get G.fast then they should be at an equal performance as Huawei G.fasters. If I'm wrong about this then let me know.
Logged
BT Full Fibre 500 - Smart Hub 2

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: G.Inp on ECI Possibly Delayed
« Reply #61 on: February 28, 2017, 06:47:52 PM »

Shouldn't the non-vectored Huawei end-users be complaining that they aren't getting vectoring like some other people are? It's probably just another aspect that ECI end-users will be complaining about though.

If all people are going to do with their speed is compare it to other people's, then most of them will always be unhappy, there will always be people getting a better speed on a better type of cabinet or because their phone line is of better quality or because fewer people have signed up for FTTC on their non-vectored cabinet or various other reasons. If their speed is good enough for what they want to do with it, it might not really matter whether or not someone else is getting more or less than what they're getting.
Logged

Ronski

  • Helpful
  • Kitizen
  • *
  • Posts: 4300
Re: G.Inp on ECI Possibly Delayed
« Reply #62 on: February 28, 2017, 06:59:15 PM »

If  proper fibre comes to Thanet then I will swap  :fingers: . Broadstairs used to have cable TV back in the 60's  ;)

Stuart

It was called Rediffusion, still lots of properties with the cables strung along them.

@EJS I think all Huawei cabinets should have vectoring enabled, and yes it would give us ECI end users something else to complain about  ;)
Logged
Formerly restrained by ECI and ali,  now surfing along at 390/36  ;D

ktz392837

  • Reg Member
  • ***
  • Posts: 559
Re: G.Inp on ECI Possibly Delayed
« Reply #63 on: February 28, 2017, 08:57:33 PM »

From what I understand by previous replies to my posts if ECI people get G.fast then they should be at an equal performance as Huawei G.fasters. If I'm wrong about this then let me know.
This is true but at 400-500m distance Gfast is unlikely to help me during the first rollout would need a pod closer and even if it it did I suspect a gfast connection is going to be much more expensive when a connection on FTTC using Huawei cabinet would be fine.
Logged

lee111s

  • Reg Member
  • ***
  • Posts: 139
Re: G.Inp on ECI Possibly Delayed
« Reply #64 on: February 28, 2017, 09:16:16 PM »

We're not talking about people getting 80/20 on either cabinet. We are talking about people at 400 to 500 metres away. On at ECI cabinet they might get 55Mb's while the Huawei with G.INP is getting 65Mb - 70Mb. So the ECI user is possibly getting 10 to 15Mb less because of no G.INP.

The ECI cabinet, by todays standard, is inferior. Because its not able to be upgraded (so far).

But as others have said BT won't do anything unless the gap becomes noticable to the general public, and if a big public fuss is made about it.

From what I understand by previous replies to my posts if ECI people get G.fast then they should be at an equal performance as Huawei G.fasters. If I'm wrong about this then let me know.

Current VDSL cab vendor is completely unrelated to what, if any, G.fast pod will be added to the side of the PCP.
Logged

Bowdon

  • Content Team
  • Kitizen
  • *
  • Posts: 2395
Re: G.Inp on ECI Possibly Delayed
« Reply #65 on: February 28, 2017, 09:31:36 PM »

If all people are going to do with their speed is compare it to other people's, then most of them will always be unhappy, there will always be people getting a better speed on a better type of cabinet or because their phone line is of better quality or because fewer people have signed up for FTTC on their non-vectored cabinet or various other reasons.

It's not about speed. It's about having the same chance as everyone else. If the cabinets were able to use the same technology then nobody would be complaining cabinets. There will of course be the general complaining because people always want better and faster broadband quality. But the biggest complaint of an inferior technology wouldnt be one of them.

If Huawei can get vectoring then go for it. ECI people aren't wanting to hold others back. We're just wanting our ECI cabinets to be up to date.

Maybe if Hauwei got vectoring it would cause a bigger speed difference between the 2 and the ECI public might wake up and start complaining.. so inadvertently it would help the ECI people too.

BTW, I'm not talking from an anti-BT position here. I'm just on about fairness.
Logged
BT Full Fibre 500 - Smart Hub 2

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: G.Inp on ECI Possibly Delayed
« Reply #66 on: February 28, 2017, 09:40:54 PM »

Current VDSL cab vendor is completely unrelated to what, if any, G.fast pod will be added to the side of the PCP.

My understanding is that the approved vendors for the Openreach G.Fast deployment are Huawei and Nokia-Lucent (or is it Nokia-Alcatel or just Nokia?) and, as you say, totally unrelated to the manufacturer of the local cabinet based MSAN/DSLAM.
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Ktor

  • Member
  • **
  • Posts: 37
Re: G.Inp on ECI Possibly Delayed
« Reply #67 on: March 01, 2017, 02:20:07 AM »

The only business case for g.inp is that it can reduce fault reports as the technology is quite good at masking issues on lines.

Errm. Seems fairly obvious to me the business case for G.INP was to get more speed/reliability out of crappy connections to increase the number of customers they can flog TV services to.
Logged

lee111s

  • Reg Member
  • ***
  • Posts: 139
Re: G.Inp on ECI Possibly Delayed
« Reply #68 on: March 01, 2017, 09:33:13 AM »

Errm. Seems fairly obvious to me the business case for G.INP was to get more speed/reliability out of crappy connections to increase the number of customers they can flog TV services to.

Openreach don't sell TV services.
Logged

broadstairs

  • Kitizen
  • ****
  • Posts: 3697
Re: G.Inp on ECI Possibly Delayed
« Reply #69 on: March 01, 2017, 09:37:00 AM »

Openreach don't sell TV services.

No but BT do and that's the issue with OR being part of BT, this crossover potential for BT to pressure OR to do things which help the overall group. OR should have a remit to do things because they are effective for all not just the BT group and no matter how much they (OR) say that's what they do while they are part of the same group people will not believe it actually works that way.

Stuart
Logged
ISP:Vodafone Router:Vodafone Wi-Fi hub FTTP

PhilipD

  • Reg Member
  • ***
  • Posts: 591
Re: G.Inp on ECI Possibly Delayed
« Reply #70 on: March 01, 2017, 10:55:19 AM »

Hi

G.INP does two things:

1) Corrects errors on UDP packets that otherwise would be lost if noise on the VDSL line caused the packet to be corrupted.  This is important for voice/video services that use UDP.  UDP is a light weight protocol and there is no way to re-request a UDP packet if one is missing due to an error, and if there was a way, by the time the request has gone all the way back to the originating server and been resent, in real time applications that means it arrives back two late and is of no use anyway.  Interleaving of course helps here anyway by adding error correction, but packets can still be lost if the error can't be corrected.  G.INP is simply a buffer at the VDSL cabinet modem that holds on to frames for a short while after they have been sent, and a low latency data exchange between the modems is able to signal back to the cabinet and say "this frame is corrupt, send again", and its sent with very low latency from the buffer so can work with real time applications.

2) For all other data exchanges using TCP/IP then corrupted packets aren't lost, as there is a mechanism to request the packet again, this would go back to the originating server which then re-transmits the packet.  The packets are reassembled in the correct order when received even if arriving out of sync.  This is why web pages and downloads are not corrupt even though our modem stats are showing errors.  The problem with this is, over millions of connections re-transmitting errors adds up to a lot of extra bandwidth and overheads.  By using G.INP, the frame containing the corrupt packet is re-requested from the cabinet modems buffer and the network stack never sees the error, so doesn't have to send a re-transmit request back to the originating server, so removing those overheads of re-sending data from source to recipient. 

For 2, this is why interleaving is turned on even when the errors aren't particularly noticeable or causing a problem for the end user, as it helps remove the extra overheads by reducing the errors as much as possible.  As G.INP does the same thing but better is the reason why the DSLAM is allowed to turn interleaving off when G.INP is available.  The same error rate exists whether G.INP is on or off, but as G.INP stops those errors causing overheads on the network, BT are quite happy disabling interleaving when G.INP is available unless things are so bad both are required.

Regards

Phil



Logged

g3uiss

  • Kitizen
  • ****
  • Posts: 1151
  • You never too old to learn but soon I may be
    • Midas Solutions
Re: G.Inp on ECI Possibly Delayed
« Reply #71 on: March 01, 2017, 05:26:06 PM »

I started the thread or one of them. I see the topic has crept somewhat. Have we any confirmation that the retransmission is postponed ?

All agreed it's just good to have, or it least was for me on a long AL line

Tony
Logged
Cerebus FTTP 500/70 Draytec 2927 VOXI 4G fallback.

NewtronStar

  • Kitizen
  • ****
  • Posts: 4898
Re: G.Inp on ECI Possibly Delayed
« Reply #73 on: March 01, 2017, 09:02:28 PM »

Definitely agree it helps long lines that would normally be stuck on high interleaving levels which causes high latency, why anyone would try to deny access to G.INP just because they can''t have it sounds like throw your toys out of the pram to me.
Logged

DMZ

  • Member
  • **
  • Posts: 63
Re: G.Inp on ECI Possibly Delayed
« Reply #74 on: March 02, 2017, 11:25:52 AM »

Hey guys,
I'm not adding much to this conversation but it's something to give you all a chuckle.

I was passing my ECI cabinet today and me being me, I gave it a quick kick. Then someone said "I don't blame you, these cabinets have gone to the dogs really." It was an Openreach fella parked in the alley around the corner from it. I did question this; Anymore ECI cabinets? Since this one is at full capacity. Openreach fella: "Nah definitely a Huawei cabinet next."

I walked away with a smile and a wave knowing I got away with teaching my ECI cabinet a thing or two. And the fact this Openreach guy doesn't think much of them either. Getting a new Huawei cabinet installed too. May say a lot or little.  ;D

Sorry for the not so serious post but it was something I wanted to share. Plus in actuality I don't mind being on an ECI cabinet it works, I can do everything I need to without an issue. Even when it's as full as a gun so...Yup. I'm just immature I HAD to kick it today.  :cool:
Logged
Pages: 1 ... 3 4 [5] 6 7 ... 17
 

anything