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 [2]

Author Topic: Openreach Plan Self Install G.fast Broadband ISP Trial for Late 2018  (Read 4652 times)

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Openreach Plan Self Install G.fast Broadband ISP Trial for Late 2018
« Reply #15 on: June 04, 2018, 09:10:12 PM »

I think it's 48 (later 96) total ports per G.fast pod, not per line card.

Hmm . . . Remember there are two different Huawei units, the cabinet version (as the image above) and the hermetically sealed, environmentally hardened, unit initially trialled in foot-way joint boxes and at pole tops. The latter unit (whose model number I cannot recall) was the port limited version.
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.

Browni

  • Reg Member
  • ***
  • Posts: 137
Re: Openreach Plan Self Install G.fast Broadband ISP Trial for Late 2018
« Reply #16 on: June 04, 2018, 09:20:26 PM »

Has that been approved, by Openreach, for use on its G.9700/G.9701 service? Have you been authorised to use it in place of the Huawei MT992? If either answer is "no", then expect the SFI engineering report to state that the problem is self-inflicted and your ISP to be charged for the visit.

The specifications can be seen in the relevant ITU-T documents: G.9700 and G.9701
The last engineer didn't bat an eyelid at it as I was using the Huawei modem when he arrived,
he simply said "Oh, you didn't need the modem then" and then replaced the dropwire which he suspected may be the problem.

He said he was getting 290Mb at the pole but only 220 at the master socket...

To give an idea of distance, if the pole fell the wrong way, it would come through my living room window.


j0hn

  • Kitizen
  • ****
  • Posts: 4093
Re: Openreach Plan Self Install G.fast Broadband ISP Trial for Late 2018
« Reply #17 on: June 04, 2018, 11:36:38 PM »

It's 48 ports per pod at the moment, with an aim for 96.

You won't get a result from the vectoring command, that's for VDSL2 only.

Vectoring and G.INP are mandatory with G.Fast.
Logged
Talktalk FTTP 550/75 - Speedtest - BQM

Browni

  • Reg Member
  • ***
  • Posts: 137
Re: Openreach Plan Self Install G.fast Broadband ISP Trial for Late 2018
« Reply #18 on: June 05, 2018, 01:25:40 AM »

Vectoring and G.INP are mandatory with G.Fast.
I beleve so.
How do I confirm they are active?

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Openreach Plan Self Install G.fast Broadband ISP Trial for Late 2018
« Reply #19 on: June 05, 2018, 05:56:47 AM »

@Browni from my reading, if I remember correctly, vectoring is part of the actual standards document. I don't believe it is an option for the service provider to either include the feature or not. Perhaps someone who actually knows what they are talking about will be able to help here. I will need to re-read the standards document. I assume that there is no chance if it even working, at those frequencies, without vectoring. The crosstalk is, I assume, very bad. And not correcting for it, with the marvel of the vectoring mathematics, is not an option.

As I understand it, and I have read the chapter on the subject in Golden, Dedieu and Jacobsen vol 2, which is a good bit too early, the vectoring system here can actually be regarded as having the same mathematical basis as MIMO in advanced wireless networks. You have multiple paths from a source to various destinations, and in rf networks the destinations are various antennae and the source is also a group of one or more antennae too. That all actually boosts performance, a lot. It is a positive thing, not a difficulty. I am wondering if vectoring in DSL may be further developed to the level where it does not merely correct for crosstalk up to a level of 100% performance restoration, but could go on to give you much more than 100% bandwidth, and the more crosstalk and more lines the better. I know it sounds stupid, the idea that crosstalk could ever be a good thing, but in rf networks it is something - called multipath - which used to be a bad problem and has now been turned into a huge asset. Perhaps someone could confirm that this comparison is valid? Or not. The situation in DSL is only like a MIMO setup where there are multiple antenna at the source end and one antenna at the receiving end. In rf networks it is usually a case of 1, more likely several, antennae at the sending end and several at the receiving end, which means n × m paths, and the more paths the better. So I believe anyway. I am hoping someone will point out any errors.
Logged

Bowdon

  • Content Team
  • Kitizen
  • *
  • Posts: 2395
Re: Openreach Plan Self Install G.fast Broadband ISP Trial for Late 2018
« Reply #20 on: June 05, 2018, 11:29:51 AM »

Can anyone confirm that 1 port = 1 customer?
Logged
BT Full Fibre 500 - Smart Hub 2

niemand

  • Kitizen
  • ****
  • Posts: 1836
Re: Openreach Plan Self Install G.fast Broadband ISP Trial for Late 2018
« Reply #21 on: June 05, 2018, 12:22:18 PM »

Yes, exactly the same as other DSL technologies, point to point between modem and DSLAM.
Logged

niemand

  • Kitizen
  • ****
  • Posts: 1836
Re: Openreach Plan Self Install G.fast Broadband ISP Trial for Late 2018
« Reply #22 on: June 05, 2018, 12:33:40 PM »

Regarding vectoring, there is the concept of a phantom virtual channel, however MIMO requires separate transmit and receive antenna so the best that can be done is using multiple pairs between DSLAM and modem and adding phantoms.

However, the increase in processing required isn't great. The reason there are so few ports on line cards right now is the heat and processing required. Needs better ASICs produced with a smaller feature size to allow for more ports per card.

If you're having to throw a DSP monster into each home to boost performance over copper, alongside expensive line cards, it gets cheaper to dig fibre fairly quickly.

I would imagine Openreach will be almost entirely an FTTP shop once this wave of Gfast is over. It is good for MDUs, especially if you can run it over coaxial, but after this cabinet based deployment the sums don't work to place nodes deeper into the access network.

DSL is on its last big deployment before an inevitable, gradual decline.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Openreach Plan Self Install G.fast Broadband ISP Trial for Late 2018
« Reply #23 on: June 05, 2018, 04:41:37 PM »

@Ignitionnet - thanks, I didn't know that about MIMO.

Regarding the dsp monster, Moore's law isn't quite dead yet, and silicon is so cheap now, with small feature sizes and more parallelism that processor power is crazy, especially if a problem is parallel-friendly, so I assume that the cost of CPUs is not such a big deal. What do you think?

(After all, it seems the likes of Intel don't even know what to do with all the acreage of silicon space that they have available to them nowadays. All they can think of is to put dozens of processors on it, rather than radically better individual ones - and vector instruction sets don't fully count as they do not help some algorithms. A single much faster processor would be very nice as you often have old code that isn't going to get rewritten or an algorithm that doesn't lend itself to an expensive parallel multi-cpu rewrite or use of vector instructions anyway. But it doesn't seem as if a single 100GHz Von Neumann CPU is going to come around soon. Not an electronic one anyway.)
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7382
  • VM Gig1 - AAISP L2TP
Re: Openreach Plan Self Install G.fast Broadband ISP Trial for Late 2018
« Reply #24 on: June 05, 2018, 07:56:01 PM »

oh dear there is already rogue asus modems on the g.fast network, this isnt going to end well.

why oh why openreach do you not enforce a modem whitelist. *shakes head*.
Logged

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: Openreach Plan Self Install G.fast Broadband ISP Trial for Late 2018
« Reply #25 on: June 05, 2018, 08:02:58 PM »

I don't think vectoring actually has to be used with G.fast in general, for fibre-to-the-pole type situations providing G.fast to a single line. For Openreach's cabinet based G.fast deployment, with each G.fast pod serving dozens of G.fast lines, of course vectoring is pretty much essential.
Logged

niemand

  • Kitizen
  • ****
  • Posts: 1836
Re: Openreach Plan Self Install G.fast Broadband ISP Trial for Late 2018
« Reply #26 on: June 05, 2018, 09:27:10 PM »

Weaver, the CPU manufacturers are throwing more cores at everything as single core performance increases tail off. Have a look at the clock speed of x86 CPUs and how slowly it has progressed recently despite smaller feature sizes. We're also closing in on feature sizes at which point quantum effects become an issue for classical computing: so few electrons and atoms involved in deciding 1 from 0 that spontaneous quantum fluctuations interfere.

Vectoring has to be done in real time so as the symbol rate goes up the processing has to match. That's a big increase between VDSL and G.fast and will double and more again when extended spectrum comes into play.

Another thought regarding vectoring is that it's not a general purpose task so relies on raw horsepower once the ASIC has been built, it's not like x86 where you add some SIMD extensions or AES instructions to boost performance on some tasks, once you've crossed from FPGA to ASIC you're about done and a new, optimised ASIC is needed each time an extension to the standard is made.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Openreach Plan Self Install G.fast Broadband ISP Trial for Late 2018
« Reply #27 on: June 05, 2018, 11:12:29 PM »

@ignitionnet so you would say that a lot of it is done by asics, not just the low level stuff, rather than by CPUs and normal software? There is a chapter on silicon exactly this subject, in Golden, Dedieu eg al vol 2 but that was written ten years ago, although it does mention vectoring theory so they did very well, but anyway, it cannot describe 2018 hardware. From what I read about G.INP, having looked at the standards doc, I would myself have done it in software, given a decent CPU, but then that's what software people do who don't speak hardware. To a farmer everything looks like a cow, what is it they say?

I kind of assumed that more could be taken on by CPUs nowadays if vector instructions are a useful aid as they have got wider and more capable in some CPUs but possibly not in the low power cheap cores that eg Broadcom might use in a modem. But otherwise CPUs have not got any faster in the last few years. The odd program that Inhave written recently do x64 has got dramatically faster on a post 2012 Intel CPU because of the arrival of certain new special instructions which were wisely picked to plug a hole, a common performance nightmare idiom. Things like POPCNT and LZCNT or whatever they’re called and the new instruction to pack sparse group of bits together, gone blank. Some years back the number of instructions that can be scheduled in parallel with out-of-order has improved a bit further. But more recently, unless you hit one of those special situations where one of those special-case instructions gives a massive boost in an inner loop in a leaf function then you don't see any big improvement over the last few years, not unless you actually can exploit multiple cores, which is a pain, dangerous, not always applicable and so on.

But anyway, the modem developers perhaps really do not want the cost and power consumption of some beast like a modern x86 CPU, what with its instruction set translation to micro ops and out-of-order and all that stuff which eats power, while some of it is only there because backwards compatibility with a 1985, or even 1977, old instruction set.

Quite agree with you about the tail off. They can only maintain that Moore's law is holding up if they count in the multiple cores and maybe also the parallelism of SIMD vector instructions too.
Logged
Pages: 1 [2]
 

anything