|
|
Anyone about who can look at these and see if I'm getting all I can?
I believe my copper line distance is 500m, probably 600m given where the FTTC cab was installed :-/
http://i612.photobucket.com/albums/tt201/MisterReder...
James BT Infinity 2 - 19/9/2012 - Install-sync: 52/12 - Test: 50/10 - Est: 44.6/6.5 Mbps
13 years of broadband - ntl:(512k/1M)/BTbusiness(2M)/Metronet(2M)/Bulldog(8M/16M)/BE(16M)/BT FTTC(50M)
|
|
|
Look fair to me. Downstream interleaving is on.
I'm almost exactly 600m away as well. Just done these.
Very clean D-side here.
My broadband basic info/help site - www.robertos.me.uk
Domains,website and mail hosting - Tsohost. Connection - Plusnet Extra Fibre (FTTC). Sync ~ 56.0/13.9Mbps @ 600m.
"Where talent is a dwarf, self-esteem is a giant." - Jean-Antoine Petit-Senn.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allergy information: This post was manufactured in an environment where nuts are present. It may include traces of understatement, litotes and humour.
|
|
|
Look fair to me. Downstream interleaving is on.
I suspected as much. I went to a friends on the weekend, Sat when I left the downloads were peaking at 49/50 megabit in various testers, and when I came back there was a LOT of standing water and more coming down, and I was maxing out at 47/48. I didn't check profile after install, but that's when I decided to hack and get stats.
I'm almost exactly 600m away as well.
Hee, that's interesting. When I had the SFI visit in 2010 he showed me the line plant diagram on his toughbook which showed where the cables ran; and I know they're dead straight down my road turn left, and halfway down there hit the PCP!
The PCP is according to google maps 500m from my building, so add easily another 50m or so to get into my 2nd floor flat (no poles here) then another 50 (twice) to get to the FTTC cab and back - could be 650 or more.
Very clean D-side here.
Amazing, you get pretty close to theoretical max - I'm getting 10meg less. Although its good, I was only predicted 44 / 6 so anything higher than those is good.
Thanks!
James BT Infinity 2 - 19/9/2012 - Install-sync: 52/12 - Test: 50/10 - Est: 44.6/6.5 Mbps
13 years of broadband - ntl:(512k/1M)/BTbusiness(2M)/Metronet(2M)/Bulldog(8M/16M)/BE(16M)/BT FTTC(50M)
|
|
Register (or login) on our website and you will not see this ad.
|
|
|
then another 50 (twice) to get to the FTTC cab and back
You only need to count it once - getting to the modem in the FTTC cabinet. The cable back will only carry the voice component....
|
|
|
then another 50 (twice) to get to the FTTC cab and back
You only need to count it once - getting to the modem in the FTTC cabinet. The cable back will only carry the voice component....
Eh?
PSTN from exchange >> PCP
FTTC from (an) exchange >> FTTC cab (DSLAM)
Voice goes PCP >> DSLAM< signals merged
Merged goes DSLAM >> PCP >> Premises.
Ah, yes you're right, just the way you put it confused me. By talking about the voice going upstream from the premises, rather than the VDSL2 downstream to the premises.
My broadband basic info/help site - www.robertos.me.uk
Domains,website and mail hosting - Tsohost. Connection - Plusnet Extra Fibre (FTTC). Sync ~ 56.0/13.9Mbps @ 600m.
"Where talent is a dwarf, self-esteem is a giant." - Jean-Antoine Petit-Senn.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allergy information: This post was manufactured in an environment where nuts are present. It may include traces of understatement, litotes and humour.
|
|
|
Look fair to me. Downstream interleaving is on.
I suspected as much. I went to a friends on the weekend, Sat when I left the downloads were peaking at 49/50 megabit in various testers, and when I came back there was a LOT of standing water and more coming down, and I was maxing out at 47/48. I didn't check profile after install, but that's when I decided to hack and get stats.
The stats say that downstream is running at 63/80 (79%) for end-user throughput, and 17/80 (21%) as the overhead for the parity bits used by the forward-error-correction process that is turned on alongside interleaving.
That would account for the difference in scale between the max & actual speeds quite well. It also sounds pretty high to me - about the highest I've seen (though I've seen it choose smaller RS block sizes than 80).
|
|
|
Well your both doing better than me, and I'm only 450 - 500 meters at the most.
Attainable: Upstream 10035Kbps Downstream 51636 Kbps
Sync Rate: Upstream 9995Kbps Dwonstream 44596 Kbps
All my graphs can be found here on Dropbox, although the last day or so has not yet been uploaded.
|
|
|
According to my Fritz!Box 7390 I'm 1352ft (approximately 412m) from the cabinet, although walking distance is roughly 100m.
My stats, though attainable seems to be hard to figure out as I am getting some different values...
| Text | 1
23
45
67
89
1011
1213
1415
1617
1819
2021
| cpe> 11
Downstream line rate: 90136 kbpsUpstream line rate: 19832 kbps
Bearer0 Downstream payload rate: 0 kbpsBearer1 Downstream payload rate: 66968 kbps
Bearer0 Upstream payload rate: 0 kbpsBearer1 Upstream payload rate: 17000 kbps
Downstream attainable payload rate: 66968 kbpsDownstream attainable line rate: 97176 kbps
Downstream Training Margin: 6.0 dBDownstream Line Protection (Bearer1 Path): 2.0 DMT Symbols
Upstream Line Protection (Bearer1 Path): 0.0 DMT SymbolsDownstream delay: 7.5 ms
Upstream delay: 0.0 msTx total power 6.5 dbm
FE Tx total power 12.0 dbmVDSL Estimated Loop Length : 1352 ft
G.Hs Estimated Near End Loop Length : 3512 ftG.Hs Estimated Far End Loop Length :0 ft
No. of Upstream Bands...: 3No. of Downstream Bands.: 3 |
| Text | 1
23
45
67
89
1011
1213
1415
1617
1819
2021
2223
2425
| cpe> 13
SNR Margin: 4.8 dBAttenuation: 14.7 dB
Avg SNR Margin: 6.0 dBAvg SNR: 32.0 dB
SNR Margin (SNRMpb-0): 6.0 dB
SNR Margin (SNRMpb-1): 5.9 dBSNR Margin (SNRMpb-2): 6.1 dB
SNR Margin (SNRMpb-3): 0.0 dBSNR Margin (SNRMpb-4): 0.0 dB
Line Attenuation (LATNpb-0): 9.4 dB
Line Attenuation (LATNpb-1): 27.7 dBLine Attenuation (LATNpb-2): 43.7 dB
Line Attenuation (LATNpb-3): 0.0 dBLine Attenuation (LATNpb-4): 0.0 dB
Signal Attenuation (SATNpb-0): 9.8 dB
Signal Attenuation (SATNpb-1): 27.4 dBSignal Attenuation (SATNpb-2): 44.4 dB
Signal Attenuation (SATNpb-3): 0.0 dBSignal Attenuation (SATNpb-4): 0.0 dB
Downstream attainable Line rate : 90608 kbps Downstream attainable payload rate : 67584 kbps |
I imagine the correct downstream attinable rate is '90608 kbps' (without interleaving delay/impulse noise protection).
|
|
|
With those figures, I'd say the 100 meters is most likely correct.
If it really was 412 meters I think I'd rush out and get a Fritz! box
Edited by R0NSKI (Wed 26-Sep-12 12:57:21)
|
|
|
|
I'd agree on that kind of distance that the Fritzbox is estimating - at least if it is standard copper.
My current line is around 400 metres too, and can't really be any shorter or longer. The Huawei shows downstream signal attenuation figures of 11, 28 and 43 dB - almost identical to yours. We get an actual 80/20 speed, with a max of 82/25. No interleaving, and very few errors.
I had FTTC at a previous property, which *did* get errors (and DLM selected an interleaved profile that sync'ed st s reduced rate of around 36/10) on the original 8c profile (ie 8MHz). When BT changed to the 17a profile, the modem could sustain a full 40/10 sync - the interleaving was still present, but the extra frequencies helped hide the additional bandwidth used by the parity data. (The 80/20 wasn't available to trial at the time we were in that property).
The old line was about 550 metres. The signal attenuation figures there were 14, 34 and 53dB. The Huawei there reported a max of 61/16, while sustaining 40/10, and was given high interleaving with 23% overhead - so probably would only end up sustaining about 50/15 on a new 80/20 product.
Of course, the Fritzbox may be estimating the distance based on the attenuation (rather than, say, reflection timing), so it wouldn't be a surprise to get that result. If you are fed by aluminium, say, then the attenuation would be lower for the same distance, and any consequent distance estimates would be equally off.
|
|
|
I've just been conparing my current stats to the op's and notice that in the bit loading graph and the SNR graph my graphs have the blocks missing above 2750Khz, why is this and I presume this is why my DS rates are a lot lower even though I'm about 450 meters, where as he estimates 600 meters?
I presume from the bit loading graph that my connection is not using the highest band at all?
Also his first and second red blocks both look stronger.
My graphs
|
|
|
|
Your graph shows that your bit loading stops at tone 2750 (about 12 MHz, I think), though that's the end of the upstream. The last downstream tone is around 1950. So indeed - you aren't using any of the D3 block.
The sync process has chosen not to use the tones above 2750 because it doesn't think it can carry any data on there. That comes about from the SNR measurements at each tone. But you can't see any information about the SNR values in D3, so i think the next-best place to look is the HLog graph.
On the whole, the OP's line seems to start getting iffy around tone 3300, and stops at tone 3500. At HLog graph is showing values of around -62 or -63dB at these tones. The SNR graph looks to be in the 6-7dB region at this point.
On your HLog graph, D3 starts (tone 2750) around -62dB, suggesting that there isn't quite the margin needed to carry data (but only just).
I do notice that your QLN graph is not as smooth in D3 as the OP's. I'm not sure what we can infer with that though.
|
|
|
I've just been conparing my current stats to the op's and notice that in the bit loading graph and the SNR graph my graphs have the blocks missing above 2750Khz, why is this and I presume this is why my DS rates are a lot lower even though I'm about 450 meters, where as he estimates 600 meters?
I wonder if your line has more "junction" points than mine? Or there is some aluminium in your line?
My line had to be repaired the morning of the install - luckily the FTTC installing OR engineer found the fault early and raised a fault call and a separate OR engineer turned up at my door at noon to test the line - as he thought he'd fixed the issue (and he had). The issue was apparently "battery" and caused by poor / very old joints in the BT network but physically within my block of flats. (ie, all our lines travel through various meter cupboards, one of them has a junction box and for some reason two lines were slightly touching).
I also know from my SFI visit in 2010 that the jelly crimps in the street installed in the 70s when the block of flats was built were replaced on my line due to the fault in three manhole covers - but nobody else's. The SFI visit was arranged by BE because I was getting constant disconnections on a line that had been good (did get 18meg in 2008, then dropped to 14meg by 2012).
My FTTC speeds are lower today than on installation (50/10), but they've stabilised around 46/10 - that's on speed testers.
James BT Infinity 2 - 19/9/2012 - Install-sync: 52/12 - Test: 50/10 - Est: 44.6/6.5 Mbps
13 years of broadband - ntl:(512k/1M)/BTbusiness(2M)/Metronet(2M)/Bulldog(8M/16M)/BE(16M)/BT FTTC(50M)
|
|
|
Thanks for the input wwwombat & jchamier.
As far as I know we are on copper lines, this is what the engineer said, but he was not from our area, so could only go on what was coming into the house.
Is it unusual for the D3 block to be unused on a 450 meter line length?
|
|
|
I've just come back, and looked at this one:
I'm almost exactly 600m away as well. Just done these.
Very clean D-side here.
On topic comment:
Your D3 QLN bounces around a little. I wonder if this indicates something about your line.
Off topic comment:
The bit-loading graph shows a problem that I come across sometimes... which is mostly visible in D1, but actually is a problem in the tones up to 1023: All the values seem to be lower than you'd expect.
I get this sometimes, more often than I'd like, but it seems to be a problem with the statistics data presented by the modem rather than the actual state of the line. I can get the 2 different sets of data at different times, even with no sync inbetween - and no difference in the headline speed. You'd expect, if there really was a huge reduction in bit-loading in this area, that there'd be a corresponding drop in speed.
|