G.Fast Estimated Speed by BTw Checker Live

Here is live g.fast estmated by BT Checker:

50 to 100m away from the cabinet:
https://s30.postimg.org/ojhw2p0fl/G.Fast_50m_to_100m...

100 to 150m away from the cabinet:
https://s30.postimg.org/kxc2q1u29/G.Fast_100_to_150m...

150 to 200m away from the cabinet:
https://s30.postimg.org/e85ja18q9/G.Fast_150_to_200m...

Edited by adslmax (Mon 21-Aug-17 13:18:24)

no wonder they want to enable vdsl2 range for g.fast those figures look painful, the 50m line not even getting estimated max speed for upstream or downstream, and at 150m upstream slower than vdsl2.

Is this after BT had their way with the amendments to g.fast spec?

Vectored vdsl2 30mhz, is not far away at over 100m and would have benefited everyone on a cabinet not just those next door to it. So g.fast at this stage simply seems to be about marketing gains as its peak speed allows them to keep up with VM.

It's been on there for months but thanks, I guess.

Yeah, it's pretty disappointing. Only those fairly close to the cabinet will benefit greatly from this, hopefully in the not too far distant future there will be more premises further away who can benefit from this. Unless of course it's like ECI DSLAM's all over again (no G.INP *yet, if ever*, no vectoring, little hope of improvement).

In reply to a post by Ixel:

Yeah, it's pretty disappointing. Only those fairly close to the cabinet will benefit greatly from this, hopefully in the not too far distant future there will be more premises further away who can benefit from this. Unless of course it's like ECI DSLAM's all over again (no G.INP *yet, if ever*, no vectoring, little hope of improvement).

So given vectoring and retransmission are required for G.fast, and G.INP will reappear on ECI in the not too distant, there's definitely some future prospects for G.fast as the standard evolves.

If BT would be allowed to use pair bonding that would help a ton.

Just thinking aloud about ECI and Huawei cabs: You're fundamentally very correct of course; but as time goes by the ECI cabinets will fill up possibly even if they get an extension pod, and as they don't install ECI cabs any more OR will plonk a Huawei one next to it for you to be connected up to. I suppose that even when one cab fills up and another is installed because of continued demand, there would still be no absolute guarantee that you'd get connected to the newer cabinet; i.e., you may be really unlucky if a few people move house and/or cancel their service, leaving spaces on the old ECI one.

Speculation, there.

It's a shame Huawei's 288+ cabinets have to be about twice the size of ECI's 128/256 (they're externally identical) cabinets. If Huawei's 96-line cabinets support vectoring and G.INP then it's nothing to do with requiring more space (not that I thought that anyway, I think the Huawei 288+ cabinets are comically large to be honest). And it's simply because ECI have shown that it can be done in a much more compact way, unfortunately in an inferior manner. I wouldn't really care, but massive green cabinets everywhere might lead to more complaints than small(er) ones.

Edited by deleted (Mon 21-Aug-17 23:08:00)

My exact situation. Was connected to ECI cab for over a year. The cab filled, had a waiting list, and they installed a 288 Huawei. I ceased my line on the ECI cab before the Huawei went live to allow the port to get taken. I ordered a new line the day the Huawei started taking orders and was connected a week later.

On the same D-Side the syncs were 55/6.8 on the ECI and 55/10.5 on the Huawei. Crosstalk has since knocked me down to 40/8. DLM has still not applied G.INP, no vectoring on my cab. The Huawei DSLAM have me considerably better upload sync though.

And it's simply because ECI have shown that it can be done in a much more compact way, unfortunately in an inferior manner

At thst is a problem as ECI are knoen to be significantly more troublesome particularly when it comes to cooling

Are these estimates based on the old (amendment 1) hardware, or the new (amendment 2) hardware?

The newer hardware should have the higher power rating, and the higher number of bits-per-tone. Those give higher speeds and/or higher range, so it is important to know.

No idea if it come with new or old hardware. How to tell it?

Right now? The best answer is through external knowledge of the line, chatting to Openreach engineers, or watching for how the estimate has changed over time. Tying the estimate to actual sync speed would help, alongside monitoring of the history of the sync speed and error rates.

The same information for a number of lines would help improve guesswork into solidity.

Rather like VDSL2, to be honest, and the way we figured things out 6-7 years ago.

I wouldn't put too much emphasis on the checker at this stage.

There are less than 500 people on G.fast at the moment, so there's not enough live data to give realistic scenarios for speed in the checker.

I fully expect our table to get some regular tweaks as the year progresses, difference in 2017 compared to 2009 for VDSL2 is people are now expecting all the answers on day 1

I notice you've updated the "cumulative percentages" covered by different distances for VDSL2, which has fed into that table for G.Fast.

Some of the changes seem huge to me. For example, the 100m distance has increased by around 6%, but the 400m distance has changed from 45% to 68%.

The first change seems plausible, but the second one is huge. Just that raw number would suggest that 23% of lines have been affected by infill!

Has it really improved that much?

Or have you audited the baseline figures too? They were based on the Sagentia/Ofcom report from 2008, right?

+1

Baseline was the 2008 report, and now its our figures, since things have changed so much using decade old figures makes no sense

In places like Glasgow and Edinburgh there have been a LOT of EO areas gaining cabinets where lots of people are on top of the cabinet, and the practice of often doing 1 new cabinet outside the exchange in Scottish villages is making an impact too

If the entirety of Scotland was EO, and all converted to cabinet-based, and be complete, it would still affect less than 10% of lines!

I need to think of some sanity checks here. 23% feels too high a number.

is that a table for g.fast (I know it's estimates). Intrigued as I'm around 450m from cab - was getting about 35/7 sync on VDSL2 + HG612 but I jumped to virgin (200/20, could go higher).Good to consider what options may be around in the next few years, I'm guessing a doubling or so on fttc, but nothing like the close distance speeds

I doubt you will get any faster with g.fast than you did on VDSL. Current G.fast plans are going to be a big disappointment for a lot of people

In reply to a post by witchunt:

I doubt you will get any faster with g.fast than you did on VDSL. Current G.fast plans are going to be a big disappointment for a lot of people

People certainly need to be pragmatic. If you aren't getting full 80Mb sync due to loss you aren't going to get anything better out of technology that runs at higher frequencies.

I thought the table was pretty clear about the sharp drop on G.fast....or is comprehension of distance so bad I need to list it in football pitches

In reply to a post by Ignitionnet:

If you aren't getting full 80Mb sync due to loss you aren't going to get anything better out of technology that runs at higher frequencies.

Right now, this looks like a decent rule-of-thumb.

Better range is available out of a "raw" G.Fast line, but that would need to reuse the frequencies that VDSL2 is using. That won't be possible in the near future; BT seem to be looking at how to better deal with this. That might turn into something or nothing ... but it is likely to be a way off.

Is it accurate though?

On fttc I'm 175m from my cabinet as the crow flies, 283m as reported by a GEA test and my router reports 11.6dB attenuation.

Your 2nd table indicates a line length of 500m for an 11dB attenuation with a downstream speed of 38Mbs.

You're not even on the ballpark with that figure!

Edited by IanBB (Sat 26-Aug-17 21:25:10)

It is probably best to assume that attenuation figures aren't consistent.

I had one line with an attenuation of 16.5dB, of around 375-400m. Fairly consistent with your figure.

My current line is 8.6dB, and about 100m. I think this one is thinner 0.4mm copper.

I am at 400m get 79 sync at 19.9 attenuation. How does that stack up?

The answers aren't so black and white, as ever it's a shade of grey in between, due to all the variables.

NTE to DSLAM for my line is 220m spot on, I see 9db attenuation ...

There is an easy answer delete the table

In reply to a post by MrSaffron:

I thought the table was pretty clear about the sharp drop on G.fast....or is comprehension of distance so bad I need to list it in football pitches

Try flashing banners per intrusive banner ads.

Ah yes, must say we do not have anywhere near enough compared to the majority of sites that claim to be news sites

How do you get from the values reported by pbparams to a single figure?

VDSL Band Status	U0	U1	U2	U3	U4	D1	D2	D3
  Line Attenuation(dB):	2.3	14.1	22.5	N/A	N/A	7.6	18.5	29.4
Signal Attenuation(dB):	2.3	13.3	21.8	N/A	N/A	10.8	18.3	29.4

I didn't the attenuation figures were taken some years ago from what people were posting on forums and then averaged out, now removed seen as people 'feel' they are wrong

In reply to a post by BatBoy:

How do you get from the values reported by pbparams to a single figure?

The VDSL2 specification has a definition of "electrical length" that is:

electrical length: An estimate of the loop attenuation, assuming that all sections of a loop obey a sqroot(f) attenuation characteristic. Specifically, the electrical length is the attenuation, in dB at 1 MHz, of an equivalent hypothetical loop with a perfect sqroot(f) attenuation characteristic.

NOTE � The attenuation caused by bridged taps does not follow a sqroot(f) characteristic, and thus the effects of bridged taps may not be accurately represented in the estimate.

Later on, the specification requires a modem to estimate its electrical length, and allows it to use one of two methods.

In essence, though, the modem needs to calculate, for any frequency f, the value loss(f)/sqroot(f). The electrical length is then given from the minimum value of these, for all frequencies from 1MHz upwards, of all workable frequencies.

That definition works for across the whole spectrum. Presumably the pbparams output just tells you the "min" value for subsets of the spectrum.