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

Login with username, password and session length
Advanced search  

News:

Pages: [1] 2

Author Topic: SNR Margin & G.fast  (Read 1077 times)

Bowdon

  • Content Team
  • Kitizen
  • *
  • Posts: 1098
SNR Margin & G.fast
« on: March 15, 2017, 02:26:26 PM »

If the target SNR margin is reduced to 3dB would this increase the speed & reach of G.fast?

I'm kinda assuming that when people talk about the distance reach of G.fast that its all based on the SNR margin being 6dB.
Logged
BT Infinity 2 - HG612 & Asus RT-N66U - ECI Cab

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 18790
  • Over the Rainbow
    • The ELRepo Project
Re: SNR Margin & G.fast
« Reply #1 on: March 15, 2017, 07:20:18 PM »

G.Fast is ITU-T specifications G.9700 and G.9701.

I have not given any consideration to target SNRM, only the duplex method (time division). Perhaps you could research the information given in the above links?  :-\
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.

Bowdon

  • Content Team
  • Kitizen
  • *
  • Posts: 1098
Re: SNR Margin & G.fast
« Reply #2 on: March 20, 2017, 06:11:46 PM »

That's way over my head :)

I let the cats kitz and wombats to figure that stuff out. I'm just the dopey dog always asking questions  ;D

I was wondering, seen as G.fast has vectoring built in, if I was to sign up for G.fast I wonder if my line would become vectored, so that in itself might make it more stable. I'm not sure about the G.INP and SNR margin as they would come from the cabinet, as far as I know.
Logged
BT Infinity 2 - HG612 & Asus RT-N66U - ECI Cab

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 18790
  • Over the Rainbow
    • The ELRepo Project
Re: SNR Margin & G.fast
« Reply #3 on: March 20, 2017, 07:14:32 PM »

I was wondering, seen as G.fast has vectoring built in, . . .

Vectoring is mandatory for G.Fast.

Quote
. . . if I was to sign up for G.fast I wonder if my line would become vectored, . . .

Vectoring would be applied to the circuit.

Quote
so that in itself might make it more stable.

Can one equate the minimisation of cross-talk with stability?  :-\  That is a good question.

Quote
I'm not sure about the G.INP and SNR margin as they would come from the cabinet, as far as I know.

Let us assume that you are provided with a service which makes use of the G.Fast process. It would be provided from a "side-pod", attached to the PCP through which your circuit is routed. Unlike the case where one migrates from a G.992.5 to a G.993.2 service, which relies upon a low-pass filter in the "fibre" cabinet in stopping the exchange based G.992.5 service in reaching the end-user's CPE, I would expect the G.993.2 service to be explicitly terminated and disconnected from the circuit. All features of the G.Fast circuit's mode of operation would be controlled by the electronics in the PCP "side-pod".
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.

PhilipD

  • Reg Member
  • ***
  • Posts: 320
Re: SNR Margin & G.fast
« Reply #4 on: March 21, 2017, 07:48:33 AM »

Hi

I would think the low pass filter is also in the G.Fast pod as you don't want the signal travelling back towards the exchange.  How they connect up will work in the same way as FTTC except G.Fast is just that much closer to the PCP.  Having the pod on the PCP will also reduce distance for many people, at my old address the PCP was a good 20 metres away from the FTTC cabinet, so adding 20 metres of distance, at my new address it's around 10 metres.  With G.Fast being more distance dependent than anything they've hacked across decades old telephone cable before, saving just a few metres of distance will make a considerable difference.  Presumably why they've gone for attaching the POD on the PCP rather than extending the FTTC cabinet, which would be easier as the power and fibre is already there.

Regards

Phil
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 18790
  • Over the Rainbow
    • The ELRepo Project
Re: SNR Margin & G.fast
« Reply #5 on: March 21, 2017, 06:09:00 PM »

Thank you for your thoughts Phil.

There is something else that came to mind, earlier today, whilst I was doing a routine task that did not require any great mental supervisory effort . . .

G.9700/G.9701 (G.Fast) uses time division duplex (TDD) and not frequency division duplex (FDD) like the current (common) xDSL services (G.992.{1|3|5}/G.993.2). To me, usage of TDD suggests that a G.Fast service should be capable of supporting symmetric synchronisation speeds. I.e. Equal DS and US synchronisation speeds.
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.

lee111s

  • Member
  • **
  • Posts: 30
Re: SNR Margin & G.fast
« Reply #6 on: March 21, 2017, 06:45:38 PM »

Thank you for your thoughts Phil.

There is something else that came to mind, earlier today, whilst I was doing a routine task that did not require any great mental supervisory effort . . .

G.9700/G.9701 (G.Fast) uses time division duplex (TDD) and not frequency division duplex (FDD) like the current (common) xDSL services (G.992.{1|3|5}/G.993.2). To me, usage of TDD suggests that a G.Fast service should be capable of supporting symmetric synchronisation speeds. I.e. Equal DS and US synchronisation speeds.

Correct. I believe it is actually mandatory to offer ratios of between 90/10 to 50/50, but 50/50 to 10/90 is discrentionary.
Logged

Weaver

  • Kitizen
  • ****
  • Posts: 4004
  • Retd sw dev; A&A; 3 7km ADSL2; IPv6; Firebrick
Re: SNR Margin & G.fast
« Reply #7 on: March 21, 2017, 07:00:06 PM »

Presumably TDD makes it more spectrum-efficient? But I haven't taken the Fourier transform of the time-sliced combined signals to have a look at what that combining process does to you.
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 18790
  • Over the Rainbow
    • The ELRepo Project
Re: SNR Margin & G.fast
« Reply #8 on: March 21, 2017, 07:22:23 PM »

Presumably TDD makes it more spectrum-efficient?

The way I view it is as two alternating "time-share" simplex transmissions, each of which has the full circuit bandwidth available to use.
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.

PhilipD

  • Reg Member
  • ***
  • Posts: 320
Re: SNR Margin & G.fast
« Reply #9 on: March 22, 2017, 07:59:35 AM »

Hi

The way I view it is as two alternating "time-share" simplex transmissions, each of which has the full circuit bandwidth available to use.

G.Fast because of time division multiplexing also adds some latency but shouldn't be noticeable, however the other benefit of time division multiplexing is because it's on/off constantly in each direction, it's much easier to add power saving options, for example, skipping some of the time slots is easy to implement until a transmit buffer is full to burst it across in one go.  G.Fast will have these sorts of power saving features, and if they do enable them then latency is likely to be all over the place.  Not sure if BT have said if they will implement these sorts of power saving options, but gamers will not like it. 

Regards

Phil
Logged

ejs

  • Kitizen
  • ****
  • Posts: 1232
Re: SNR Margin & G.fast
« Reply #10 on: March 22, 2017, 08:09:27 AM »

Or the time slots will be so short it will be completely unnoticeable, but gamers will still probably not like it once they know they are there.
Logged

Chrysalis

  • Content Team
  • Kitizen
  • *
  • Posts: 4359
Re: SNR Margin & G.fast
« Reply #11 on: March 22, 2017, 08:46:27 AM »

I would guess the power saving stuff will be disabled as it carries risk of problems, problems = money expenditure.
Logged
Sky Fiber Pro - Billion 8800NL bridge & PFSense BOX running PFSense 2.4 - ECI Cab

ejs

  • Kitizen
  • ****
  • Posts: 1232
Re: SNR Margin & G.fast
« Reply #12 on: March 22, 2017, 08:57:04 AM »

I thought I'd better skim through the ITU-T G.9701 document, from which I gather a typical time for one "TDD frame", which comprises both downstream and upstream, is 0.75ms.
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 18790
  • Over the Rainbow
    • The ELRepo Project
Re: SNR Margin & G.fast
« Reply #13 on: March 22, 2017, 09:40:22 PM »

I thought I'd better skim through the ITU-T G.9701 document, from which I gather a typical time for one "TDD frame", which comprises both downstream and upstream, is 0.75ms.

Thank you.

Reading either/or/and G.9700/G.9701 was not currently something that I wanted to do.
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.

Ignitionnet

  • Reg Member
  • ***
  • Posts: 493
Re: SNR Margin & G.fast
« Reply #14 on: March 23, 2017, 09:00:21 AM »

If the target SNR margin is reduced to 3dB would this increase the speed & reach of G.fast?

Yes.

You're welcome.
Logged
Pages: [1] 2
 

anything