Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[boogy]

hi

It's Kitz University time. Or more likely Kitz playschool for me.

Saw this information:

http://www.kitz.co.uk/adsl/adsl_technology.htm#vdsl_tones

and thought I would see if I can calculate my download speed from the tones.

I'm running dslstats 5.5.4 with my billion 8800axl and the bitloading graph is attached and is also available on mydslwebstats.

I matched the tones to the huwei (broadcom) pattern and looked at D1, D2 & D3 then calc'd:

   start tone   end tone   tones   avg bits per tone   bits
D1             33          859     826                    8    6608
D2          1216         1961     745                    5    3725
D3          2793         3385     592                    2    1184
               
                                                                      11517

Looking at D3 on the dslstats graph, the highest tone was 3385 vs 3970 in the spec. I haven't added one on for the inclusive tones.

I looked at the graph for the average bits per tone for each tone group.

I'm obviously doing something wrong as I'm not getting 40000 kb/sec.

I wonder if this is dynamic and changes to reflect the load, or is static...

[burakkucat]

I wonder if this is dynamic and changes to reflect the load, or is static...

Assuming you have not disabled bit swapping in the modem's configuration then the initial segment of your above "wonder" contains the explanation. Bit swapping is a dynamic process and the sum total of bits used (the total bit loading) can vary with time. 

[boogy]

Thanks burakkucat.

I haven't disabled bit swapping, and I haven't seen anywhere where I can do that. So if I understand my reflected wonder, my calculations are roughly correct for the example, and if I were to capture a bit loading at full whack the numbers should roughly tally.

One thing I realised going through this exercise is that SNRM is no longer a single number but is there for each tone, and the SNRM reported looks like the lowest number for all tones.

Also, running on a capped 40/10 line which is reported as being capable of running at nearly double that looks like a good safety margin overall.

[burakkucat]

b*cat nods in acknowledgement (whilst thinking about his (overdue) evening meal . . .) 

[boogy]

For this calculation I have the full range of tones for D1-3, max bits per tone for all 3, and when they're added up I get 41k so this can't be right....

Code: [Select]

start tone end tone tones max bits per tone       bits
D1 33         859         827              15               12405
D2 1216         1961         746              15               11190
D3 2793         3970         1178              15               17670

                                     41265



[ejs]

Can the sum total of the bit allocation change with just bit swapping? I thought it would have to stay the same for the speed to stay the same (without Seamless Rate Adaption).

The sum total of bit allocations won't be the line rate, it's more complicated than that, the linked page touches on the symbol rate, and gave a approx. figure of 4kbps for each allocated bit, although that was probably for ADSL.

[burakkucat]

I think Kitz will be the person to provide the necessary clarification. 

[kitz]

ejs is correct.  Confusion has occured because of the use of the term 'bit' in bit loading.   The bits that are allocated to the bins don't equal 1 bit of speed (or even 1kbps as per calculations above)

The process of conversion to speed is a lot more complicated and why I say on the main site that it is 'beyond the scope of this tutorial.   If anyone is interested theres a paper here:  BIT RATE MAXIMIZING WINDOW AND EQUALIZER DESIGN FOR DMT-SYSTEMS.

The exact process involves Time & Frequency Domain Equalisers (TEQ & FEQ) & QAM , If you look on page 3 you will see the algorithms soon become eye watering.

In its very simplest form DMT is basically a load of 56k modems running in tandem.  Think of each tone as a single 56/60k modem and you can see that each tone has more capacity than 15 'bits' of speed.  In its simplest form then DMT can transmit 60kbps per tone, but DSL also has a lot of redundancy which is reserved for 'overhead' and its why you sometimes see on some papers with ADSL there is scope for more than 8Mbps.   The algorithms then can make a difference to the bit loading.   It was with ADSL2 (not 2+) a more efficient algorithm decreased overheads and increased the 8Mbps to 12Mbps of sync.   

TBH this isnt an area Ive looked for years - since the days of ADSL - but for ADSL at least a rough approximation using the figure of 4kbps of speed per 'bit loaded' works out about right.     

[boogy]

It's such a difficult job to explain complicated stuff without having to give everyone a brain transplant.

And, as if to prove that, I was just doing some more layman back of the beer mat calculations:

If we have an 80 Mbit/sec rated downstream line and we add up the downstream tones we get 2751 for Huawei.

Divide 80,000,000 by 2751 comes to 29,080 bits per second per tone.

On my capped 40 Mbit/sec service that would be 14,540 bits per second per tone assuming all available tones are in use.

As I only appear to be using 2163 tones that last calc would yield 18,493 bits per second per tone.

So this I think lies well within the capability of over 2000 56K modems.

Time to stand back in wonderment.

Imagine a system where we take a message, share it out amongst over 2000 poodles and then each poodle shares it out again amongst about 20,000 chihuahuas who each carry a bit each and run off down the maze to meet at the other end.

It's a wonder it ever works.

I'll never take it for granted again - thanks!

[WWWombat]

Kitz is perfectly right with her explanation, but I'll add one more element in... the symbol rate, which helps tie the "sum of the bit-loading" to the final throughput.

In a DMT system, all those parallel modems are actually transmitting 4,000 symbols per second. Every single modem (for its individual tone) transmits one symbol every 0.25 msecs.

What is a symbol?

In analogue terms, it is simply a 0.25ms-long waveform, with a specific phase and amplitude. The DSL modem's job is to transmit or detect this waveform.

In digital terms, that analogue waveform gets translated to/from a number of bits - the exact number being determined by the "bit loading" of the tone. One analogue symbol will map to 1-15 bits, depending on the bit-loading of that tone.

For tones where there is a lot of signal and little noise (high SNR), the receiving modem can detect finer-grained differences between the phase & amplitude values of the waveforms ... so is capable of transferrining more bits, and the "bit loading" can be higher. When SNR is low, receiver has a harder job distinguishing differences, so the bit loading must be kept low.

The best way I have seen to picture the translation between an analogue symbol and the number of bits is through two-dimensional graphs known as constellations. These give a translation between an N-bit number and the corresponding phase-angle+modulation.
The picture in this section of wikipedia gives a simple example of a 4-bit constellation (don't worry about the text, just look at the animated image).
https://en.wikipedia.org/wiki/Quadrature_amplitude_modulation#Quantized_QAM

Here's a picture showing a few different constellations for bit-loads of 1-5. Look at figure 4:
https://www.osapublishing.org/oe/fulltext.cfm?uri=oe-19-26-B486&id=224908
It actually shows results applicable to fibre, rather than DSL, but the principle is the same.

Figure 6 this page gives a few more examples:
http://140.98.202.196/xpls/icp.jsp?arnumber=6479217&pgName=figures

So ... the answer to your quandary about bit-loading is that you needed to calculate the sum of bits, as you did, which tells you how many bits are transferred per symbol (ie every 0.25ms). Multiplying this by 4,000 gives you the number of bits per second.

That still doesn't help you entirely, because other line-coding details get in the way, such as trellis encoding, and FEC, and framing. But it gets you closer.

[boogy]

Thank you that is much clearer. I've just spent a couple of hours working my way through it, which is a reflection of my own reduced bit loading!

Following up your references, I came up with two follow ons:

https://en.wikipedia.org/wiki/Very-high-bit-rate_digital_subscriber_line_2

http://www.chronos.co.uk/files/pdfs/itsf/2010/Day3/07-Nw_Timing_Ref_for_Freq_Sync_in_xDSL_based_Access_Networks.pdf

from which I have extracted two attachments, the profile definitions and another quadrature picture, which shows the pattern for odd numbers of bits.

It took me some time to take my original numbers and crunch them using your explanation but I think I'm there.

The key driver is the 4000 symbols per second as that is an absolute.

My equation in english reads:

Code: [Select]

4000 symbols/second

times

(sum of

(active carrier tones in bands d1,d2,d3

times

average bits per tone in bands d1,d2,d3)
)


Using my data from the start of this post, that becomes:

Code: [Select]

4000 symbols per second * ((826 tones * 8 bits per tone) + (745 tones * 5 bits per tone) + (592 tones * 2 bits per tone)

and that comes to 4000 * 11517 = 46,068,000 bits per second

which is the gross version of my net capped speed of 40Mbits per second.

I recognise my profile (17A) in the attachment, can multiply 4096 carriers * 4.3125 kHz bandwidth to get 17.664 MHz total bandwidth, and I can see how profile 30A can reach 200 Mbits/second (4000 * 3470 * 15).

My billion 8800axl shows in its xDSL statistics a number that I now understand - it reports downstream 10727 bits transmitted in each data symbol which is remarkably close to my estimate of 11517.

Profile 17A has a max aggregate downsteam transmit power of 14.5 dBm and my stats report 12.4 dBm so presumably this is what arrives after line attenuation etc.

I'll take a breather and then I will look at Framing, FEC, Trellis Encoding, Vectoring and G.INP...

It is stunning to think of the constellation diagram that has 32,768 distinct combinations of phase and amplitude when 15 bits are being represented in a symbol.

Go VDSL2!

[ejs]

Profile 17A has a max aggregate downsteam transmit power of 14.5 dBm and my stats report 12.4 dBm so presumably this is what arrives after line attenuation etc.

12.4 dBm will be the output power transmitted from the cabinet, the power level of the signal that arrives at your end will be a tiny fraction of what was originally transmitted.

[WWWombat]

You got the hang of that quite well, then 

http://www.chronos.co.uk/files/pdfs/itsf/2010/Day3/07-Nw_Timing_Ref_for_Freq_Sync_in_xDSL_based_Access_Networks.pdf

from which I have extracted two attachments, the profile definitions and another quadrature picture, which shows the pattern for odd numbers of bits.

That's a really good find for a picture of constellations, including the 15-bit one on the next page. Bizarre to find the best example in something that highlights the need for a good timing reference.

Timing is one of those critical elements that almost no-one outside telecomms realises. In my early days on GSM, the timing unit in the bases stations was one of the biggest physical elements, and took a long time to stabilise.

My billion 8800axl shows in its xDSL statistics a number that I now understand - it reports downstream 10727 bits transmitted in each data symbol which is remarkably close to my estimate of 11517.

When I've done calculations in the past, I always get close ... but never quite close enough. Bits are being used elsewhere ... and bitswapping over time seems to make the calculations worse!

Profile 17A has a max aggregate downsteam transmit power of 14.5 dBm and my stats report 12.4 dBm so presumably this is what arrives after line attenuation etc.

As ejs says, that will be the transmit level.

IIRC, each 3dB of attenuation means the received power has halved, and each 6dB of attenuation means the received amplitude (ie voltage) has halved. With that, you can calculate the received power in the three bands from the --pbParams output.

Your modem knows the original transmit power because it is told this as one (of many) parameters transferred between the two modems, carried outside the end-user data flow, and carried within the "framing overheads".

It is stunning to think of the constellation diagram that has 32,768 distinct combinations of phase and amplitude when 15 bits are being represented in a symbol.

Isn't it just. And the receiver sensitivity that has to be able to detect the difference between those combinations.

And BT believes that, for G.fast mk.II, they can use improvements in the quality of receiver hardware to increase the number of bits they can carry in each tone.

I'll take a breather and then I will look at Framing, FEC, Trellis Encoding, Vectoring and G.INP...

As an aside, on the vectoring front...

Note that the customer's modem's role in vectoring is to measure the error (in phase & magnitude) between the actual received point in the constellation, and the expected point.

That means the receiver has to be sensitive enough to not just quantise the result, but to be able to tell how far off the proper result it was!

[boogy]

Hi

What would be the best order to tackle the vdsl2 topic list:

Current/In progress: Framing, FEC, Trellis Encoding, G.INP,
Near Future: Vectoring
Future: G.fast (are there others?)

and how best to go about this.

One obvious way is for me to take say Framing, do some research and try to summarise. There will obviously be some great information on the site, but there's definitely better learning for me to relate it to my own stats and info from my own kit. Reading back through the calculations it would be possible for someone else to go through and do their own calculations but it isn't in step 1, 2, 3... format.

Thanks!

[WWWombat]

What would be the best order to tackle the vdsl2 topic list:

Current/In progress: Framing, FEC, Trellis Encoding, G.INP,
Near Future: Vectoring
Future: G.fast (are there others?)

and how best to go about this.

It depends what you want to get out of it.

To understand Framing, FEC and Trellis encoding, you may be better looking at these within the context of ADSL, as there is a wealth of information out there (including Kitz' main site).

Learning how it applies to VDSL2 is a little harder, as there is less out there. The ITU specifications are available though.

Vectoring is different, and can be researched online as a standalone item - probably because it was standardised as a standalone affair. ITU specifications are available, but there are plenty of other documents. Broadband Forum's MR-257 is a starter.