Poor sync speed on profile 17a at 300m? :: Fibre Broadband

General Discussion
>> Fibre Broadband

Pages in this thread: 1 | 2 | [3] | 4 | (show all)

Print Thread

deleted
(deleted) Mon 06-Feb-12 16:16:55

Re: Poor sync speed on profile 17a at 300m?

[re: deleted] [link to this post]

In reply to a post by WWWombat:
When I fiddled to adjust the size (and going direct to PNG rather than via PBM), I get far better definition.

This gets considerably finer detail, but I haven't worked out the perfect width yet.

Well, when you have spent hours & hours experimenting & sussing it out, just let me know & I'll include the relevant code in my scripts & claim all the credit for it smile

deleted
(deleted) Tue 07-Feb-12 12:18:39

Re: Poor sync speed on profile 17a at 300m?

[re: deleted] [link to this post]

The change to the graphs ends up being quite simple, but it certainly makes the graphs very wide. They are great for getting a detailed view, but perhaps not so good for an overview, and really no good in the montages. Anyway, try it for yourself, and see what you think...

The basic change is, for each graph you want to widen, to alter this line (in Linux shell script):

echo "set terminal pbm color"

into

echo "set terminal png size 4372,480"
echo "set lmargin 7"
echo "set rmargin 4"

The difference is to tell GnuPlot to use an output device of a PNG image (rather than PBM) and to set a definite size of 4372x480 (instead of the default 640x480usd by PBM). The margin sizes control the space used left & right - which magically leaves 4096 pixels for the graph itself, or 1 pixel per tone.

The bit-loading graphs come out looking like this: Original Line and New line.

deleted
(deleted) Tue 07-Feb-12 16:32:16

Re: Poor sync speed on profile 17a at 300m?

[re: deleted] [link to this post]

In reply to a post by WWWombat:
The change to the graphs ends up being quite simple, but it certainly makes the graphs very wide. They are great for getting a detailed view, but perhaps not so good for an overview, and really no good in the montages. Anyway, try it for yourself, and see what you think...

Or This - Bits only and This - Montage

echo set terminal png font "arial, 53" size 4372,3279
echo set lmargin 7
echo set rmargin 4

The colours are more vivid, with a lot more colour choices (256 insteaad of 10 - I think), but the resulting file sizes do increase substantially.

deleted
(deleted) Tue 07-Feb-12 18:30:18

Re: Poor sync speed on profile 17a at 300m?

[re: deleted] [link to this post]

Incidentally, from the bit-loading data, I totted-up how many bits were allocated on each line (both of which were synced at 40/10 at the time). I am still wondering why there was such a big difference in the number of bits being used.

Old line: 18173 bits
New line: 11371 bits

As each bit is supposed to represent 4kbps on the line, this implies that the modem is set up to transfer:

Old line: 72.7Mbps
New line: 45.5Mbps

I can understand the old line being larger - perhaps interleaving, and the use of the forward-error correction checksums really does end up using 50% extra on the line.

However, the new line doesn't even manage to add up to the amount of data it is synced at (40/10, totalling 50). Bizarre... so perhaps I'll try to get a new set of data later

deleted
(deleted) Tue 07-Feb-12 18:40:54

Re: Poor sync speed on profile 17a at 300m?

[re: deleted] [link to this post]

In reply to a post by Bald_Eagle1:
Or This - Bits only and This - Montage

I think Photobucket stole most of the resolution there - the images I see are 1024x768 vand 693x1024.

but the resulting file sizes do increase substantially.

echo set terminal png font "arial, 53" size 4372,3279

The vertical dimenstion of 3279 keeps the graph square, but it will be contributing to the huge increase in file size. In mine, the wide PNG image is 30KB, while the original PBM is 6KB.

The colours are more vivid, with a lot more colour choices (256 insteaad of 10 - I think),

Agree on that. I like how you've got the extra colours in there for up/down. I'm not sure that there should be anything in the gaps between the up/down bands coloured blue - I'm thinking of the one around tone 850 in your bits-only image. Surely those higher gaps shouldn't be shared?

deleted
(deleted) Tue 07-Feb-12 19:32:17

Re: Poor sync speed on profile 17a at 300m?

[re: deleted] [link to this post]

In reply to a post by WWWombat:
I think Photobucket stole most of the resolution there - the images I see are 1024x768 vand 693x1024.

Yes it did. I might look for a site that keeps full resolution.

The vertical dimenstion of 3279 keeps the graph square, but it will be contributing to the huge increase in file size. In mine, the wide PNG image is 30KB, while the original PBM is 6KB.

The bits.png image is now 137KB on its own.

The colours are more vivid, with a lot more colour choices (256 insteaad of 10 - I think),

Agree on that. I like how you've got the extra colours in there for up/down. I'm not sure that there should be anything in the gaps between the up/down bands coloured blue - I'm thinking of the one around tone 850 in your bits-only image. Surely those higher gaps shouldn't be shared?

Perhaps "Shared" is the wrong word as it is supposed to be a gap in the band plans.
However, bits are loaded so I thought I would show them, calling them "Shared" for now:-

Text
1 23 45 67 89	Tone number Bit Allocation 860 6 861 6 862 6 863 6 864 6 865 6 866 6 867 4

deleted
(deleted) Tue 07-Feb-12 23:40:47

Re: Poor sync speed on profile 17a at 300m?

[re: deleted] [link to this post]

In reply to a post by Bald_Eagle1:
Perhaps "Shared" is the wrong word as it is supposed to be a gap in the band plans.
However, bits are loaded so I thought I would show them, calling them "Shared" for now:-

I've hit a conundrum with the bit loading data, but I think it is best on a separate thread. I'll start it off in a bit....

deleted
(deleted) Wed 08-Feb-12 02:18:24

Re: Poor sync speed on profile 17a at 300m?

[re: deleted] [link to this post]

In reply to a post by Bald_Eagle1:
Due to attenuation/distance from the cabinet, my connection is unable to make use of the higher frequency tone band plans & you will see high bit-loading in the lower band plan.

Having seen quite a few connection stats now,

Paul,

While trying to make sense of the bit-loading issues I saw, I started trying to work out how much data needed to be sent by the modem for FEC to work. Obviously FEC (as part of interleaving) only works by sending extra parity bits - and DLM is in charge of the configuration of this - butthose parity bits must be sent "invisibly" to the Sync speed, but "visibly" to the bit-loading graphs.

By that I mean that the parity data must be sent in buckets that are viable for carrying data, but an increase in parity size does not increase the sync size.

As a conclusion, the space used by FEC can therefore decrease your sync speed, if the "capability" of the line is close to the caps.

According to an article on FEC, the parameters N and R are important: N being the number of bytes in a codeword, and R being the number of parity bytes in that codeword - therefore (N-R) bytes are real user data.

The important bit that the (N-R) bytes go within the sync speed, and the R bytes go on top.

In one of your old posts where speed was 27Mbps, N was 44 and R was 12. For every 32 bytes of data you sent (inside the 27Mbps), another 12 bytes of parity data was being sent outside it - or about 37%. On a perfect line without interleaving, that would be another 10Mbps.

In the data kept within the graphing scripts, some more recent stats showed a speed of 28Mbps, N of 80 and R of 16. For every 64 bytes of data, 16 bytes of parity data ae being sent - or about 25%. That would be another 7Mbps.

So it could be that you are suffering a double-edged blow from noise. The noise level is lowering SNR, which means you get less Bits to play with; and then a good proportion of those bits are being stolen to carry FEC parity data. But again, we don't have the "before" figures to tell quite so easily.

I wonder if I am reading the N and R values correctly from the stats...

deleted
(deleted) Wed 08-Feb-12 18:41:33

Re: Poor sync speed on profile 17a at 300m?

[re: Anonymous] [link to this post]

In reply to a post by Anonymous:
There is an issue with your line / setup. Problem is BT say 15meg sync is acceptable so unlikely to get someone out to look - also NGA has dedicated teams who are given 2 weeks training, a van and a screw driver and are let loose on these.
Only the overflow jobs go to the real engineers and so why you were left with low speeds.
At 362M copper from cab on provision (3rd sub) I got full speed with attainable of around 140Md/s 54Mu/s - checked it a few days ago with tester and still sync 40/10 but SNR has shot up to 22db (from 6) and attainable rate is now 98Md/s 38u/s. I know the line is perfect - this just crosstalk from other subs.
One thing to check is whether he installed it correctly in your house. Do you have more than one NTE5? did he fit a proper filter plate or did he simply unplug the adsl modem and put the OR modem in its place?
You would be surprised at some of the awful setups I come across after these guys - often worse than if they had just allowed a self install. But hey - low quality = high productivity = bosses get bonuses - got to keep these things in perspective.

Well my original NTE was behind the door in my living room, immediately where the cable comes is from the outside. But since my comms equipment was under the stairs using one of the spur sockets he said he converted that one to be the master socket with the filtering NTE on it and then all others becoming the spurs.

deleted
(deleted) Wed 08-Feb-12 19:49:46

Re: Poor sync speed on profile 17a at 300m?

[re: deleted] [link to this post]

Right, I've taken the face plate of the original master socket to see what has been done by the OR engineer. It looks like he's taken the white & blue wire from the main drop cable and used some kind of clear cable crimp on them connecting it to a pair in an extension wire that feeds the socket under the stairs. He installed a new NTE under the stairs connected to the extension wires (about 3-4 metres away). He has then chosen a different wire pair in the extension cable to feed back from the new NTE under the stairs making the original master socket and spur instead.

So it looks like there is at least a 3 metre run from where the drop comes into the house that is going over telephone wire carrying the VDSL2 signal before entering the NTE and then into the modem. Is this 3 metre run inside the house likely to cause a lower than expected sync rate?

Thanks.

Edited by deleted (Wed 08-Feb-12 19:56:58)

Pages in this thread: 1 | 2 | [3] | 4 | (show all)

Print Thread

Jump to