Print

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

[Oranged]

Having read Kitz's section on bitloading, I am puzzled (or I haven't quite grasped how it works) by the bitloading graph of my connection.

I'm on a Target SNR of 9dB which between 8am and 5pm produces an SNRM of 8dB to 9dB. Attenuation is 37.5dB.

From 5pm through to 7am the SNRM can lose up to 5dB (which is why there is a Target of 9dB) and sometimes does drop to 4dB without disconnecting.

The Routerstats graph showing Bits/Tone shows a higher loading (15 bits) over more of the tones between 33 - 100 after 5pm than between 8am - 5pm. Currently (11.20am) only tones 36 to 64 are at 15 bits with SNRM at a very steady 8.5dB.

This is what puzzles me because from Kitz's explanation I thought that there would be a lower loading at night when noise is worse......or have I totally misunderstood ?

[roseway]

Some routers are more aggressive than others when first negotiating the connection - some go for the highest speed they can, and others leave a bit in reserve to cope better with changes in line conditions, to make the connection more stable. This is pure guesswork on my part, but it may be that your router is one of the more conservative ones, and when conditions worsen at night it makes use of tones which were kept in reserve in order to maintain a good connection.

I'm happy for this theory to be shot down in flames though.

[Oranged]

That does sound very logical.........but......the last sync (9+ days ago) was during the morning to achieve the best speed rather than best stability.

I'm using the O2 wirelessbox II (TG585v7) which isn't renowned for its ability "to cope better with changes in line conditions".

So it would seem that I have correctly understood Kitz's explanation of the "hows" of bitloading but that's resulted in my not fully understanding the "whys" perhaps  .......and it seemed such a precise science !!

[jeffbb]

Hi

Basically when the negotiation takes place during the synch process a bit allocation table is created. That is how many bits can be used .
Now if all were used up then of course there would be NO chance for bit swapping when the line gets noisy.so some spare room  must be available .As Roseway said some routers may be more aggressive in their bit loading . That probably would equate to less tolerance to noise.

quote :This is what puzzles me because from Kitz's explanation I thought that there would be a lower loading at night when noise is worse......or have I totally misunderstood ?

Remember that the bit allocation table is generated during the synch process. Changes to the table are made as noise occurs where a tone or a number of tones snr margins are to low . The requirement to  swap is determined at each tones SNR margin ,not by the general SNR margin.

The table at any one time reflects all the changes that have been made  because of the noise the line has experienced since synch. As long as the Tone SNR margin does NOT drop to low then there will be NO change .

see latest routerstats   showing SNR margin/tone
     

Regards Jeff

edit link

[waltergmw]

@ Roseway & Oranged,

No shooters or any flames !

I'm using the 2Wire 2700HGV diagnostics page rather than Routerstats.
I'd also be surprised if the firmware implementations of bit loading logic didn't vary with at least the modem chipset if not the modem manufacturer as well.
The 2Wire seems to show the same bit loading unless the modem re-syncs, ergo the time of day is not directly concerned.

As it's a lovely dry and cold day in sunny Surrey I thought I'd test the theory by re-booting just for Oranged.

For my pains the modem took 19 attempts between 13:42:38 and 13:46:13 before it managed to synchronise.
The synchronisation rate was down one notch at 192 and the total bits loaded were 79 instead of the previous 92

The three BT speedtests I did this morning were:-
10:32, 76 kbps @ 224 kbps sync speed
13:38, 102 kbps @ 224 kbps sync speed
14:06 97 kbps @ 192 kbps sync speed (after remote re-boot).

Given that these are such atrocious figures I believe we can discount contention and latency problems.
If so, the actual thoughput must be directly related to the real state of each tone, rather than the bit loading or even the synchronisation speed recorded.

Kind regards,
Walter

(Sorry I was typing this as jeffbb was also.
I think my experiment demonstrates jeffbb's statements.)

[jeffbb]

Hi
 The bit allocation table shows all the bits . That is those used and those available .

so as an example when I checked my downstream bit loading   (using routerstats)
I had  a total of   2081  my synch speed was 7328  based on 4Kbps per data bit = 1832 used . So it looks as if 249 (~12%)are available to swap .

@ walter
79 instead of the previous 92 Is that just the total Downstream data bits ?

14:06 97 kbps @ 192 kbps sync speed (after remote re-boot).  ~= to 48 data bits  actually used ,31 available  (39%) seems a lot spare , but I suppose with a poor line its just as well.

224 kbps sync speed~= 56 data bits actually used  ,36 available (39%)

regards Jeff

[waltergmw]

Hi Jeff,

Yes it's only the download bits. The upstream is quite resonable so it shows the higher frequencies are just being blown into the quagmire of noise.

Kind regards,
Walter

[attachment deleted by admin]

[kitz]

The initial bit allocation (BAT) is what determines the sync speed. 
As mentioned there is an inbuilt allowance to allow for any bit swapping.  What the allowance is I dont know.

Its the 'real' SNR at each tone that determines the amount of bits loaded and it should roughly equate to 1 bit per 3dB of real SNR  less the unknown reserve quantity.  There may well be an equation that determines this, but its not anything Ive ever looked into, other than I know its there.

>> If so, the actual thoughput must be directly related to the real state of each tone,

Not quite that simple Im afraid.

Dont forget to add an allowance for any errors in there as well.  LOts of CRCs are definitely going to affect the throughput speed.

The bits should be available... or not...  or they will be swapped.   If theres insufficient to cover bit swapping then the line will drop.
Once the SNR goes down... theres insufficient tones to be able to carry the data....  plus gain can be adjusted by the router/dsalm.  This shows up in the 'power output'..   from my own observations a line would generally run at about 18 dBm during sync..  but can go up to around 20dBm.
Increasing the output power gives a the SNR a lil bit more of a boost.

[waltergmw]

@ Kitz,

Thanks for the detailed explanation. I note the bad line I'm monitoring has power values which vary slightly but are well down on yours.

Up varies between 12.2 to 12.5 and down from 13.1 to 13.6.

Kind regards,
Walter

[Chrysalis]

here is my explanation based on personal past experience.

when I was on ipstream and used the speedtouch 585v6 with DMT, the tones would usually not sync up at 15 bitloading, typically would be 13-14 on the strongest tones.

When night time comes the higher weaker tones are then unable to keep providing a signal without errors, so they get bits removed from them or turned off by the router, but the bits have to be allocated somewhere.

Usually this means the stronger tones then get higher bitloading and is why on weak lines this can happen.  Also the stronger tones at least on my line tend to have no variance at all between night and day, so they can withstand that bitloading quite well.