Print

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

[fbnts]

Hi,

My FTTC has slowly reduced the attainable rate over the past few months. (I have a flashed HG612 so can see the line stats).

I have been using rs-w which shows a graph of the bit loading. One interesting thing I see is that the loading for the lower tones (100 to 900 ish ) almost half every few minute and then restore after a few seconds.

Would this indicate a fault?

Attached are two images of the bit loading.


Tom

[ColinS]

Would this indicate a fault?
Tom

Well, it certainly doesn't look like normal behaviour!    The reduction in bit-loading appears to have been caused by an accompanying increase in the SNR margin in the D1 band, but why it should oscillate on a minute-by-minute basis like that is beyond me at this point.     Perhaps the DSLAM line-card has left the cabinet! 

Wiser heads will join the debate soon I expect.

[fbnts]

Some months ago I actually had a callout with BT as the line was synced higher than the modem's stated attainable rate.

The engineer that came out found a fault in the junction box where the line is attached to the house, just wonder if there's another fault somewhere?

I have just taken a snapshot of the SNR and CRC screens as well.

What is D1 band?  What is the blue sections on the bit loading?

Tom

[ColinS]

Some months ago I actually had a callout with BT as the line was synced higher than the modem's stated attainable rate.

The engineer that came out found a fault in the junction box where the line is attached to the house, just wonder if there's another fault somewhere?

I have just taken a snapshot of the SNR and CRC screens as well.

What is D1 band?  What is the blue sections on the bit loading?

Tom

Well, I think that it is very possible that you have another fault.  As I thought, your SNR graphs show it oscillating wildly at one point, which is definately 'not normal'.

D1 is the first (red) Downstream band on your bitloading graphs; it includes the ADSL2+ range (up to ~tone 450).  The fact that this D1 band is affected most, while the higher frequency bands seem (to me) to be unaffected, does suggest to me that there may well be a fault somewhere between you and the cabinet. The blue tones are 'shared', that is can be allocated either to the upstream or the downstream as necessary during bitswapping (or at least that's my rough understanding of it).

[fbnts]

Now I just need to try and convince BT there's a fault and proving it to them without them getting arsey that I have a flashed modem which enables me to get these stats!

It all started when I upgraded from 40/10 to 80/20 and didn't notice any change.  According to the telnet data I am correctly on 17a:

Code: [Select]

xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 10809 Kbps, Downstream rate = 34548 Kbps
Path: 0, Upstream rate = 10932 Kbps, Downstream rate = 35875 Kbps

Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 5.3 6.2
Attn(dB): 0.0 0.0
Pwr(dBm): 11.4 6.8


[ColinS]

Well, well, well! Thinking about your problem Tom, made me go and have a look at my own bit-loadings on rsw.

And guess what  , I am also getting some 'oscilation' of the bit-loadings in the lower tones of D1, albeit not as frequently as yours.  Unfortunately, for some reason I will need to investigate I can't seem to get rsw snapshots working at the moment, or I would post the graphs. 

However, sometimes I am getting additional shared (blue) tones in the 30-90 tone range and these are allowing these bins to be loaded as high as 14 bits for a time; then (because of errors I guess) they get first reduced in number, then removed and the loadings fall to 4-6 bits per bin.  I think this is just part of the 'normal' error correction on my line, trying to utilise unused bins to carry bits from others with errors, only to find that they are (presumably) worse!  It's a very dynamic thing.

I don't remember seeing these before (although I just may not have been looking closely enough until your post) but the DSLAM did force a resync on me earlier this evening, and I don't recall having shared tones in these lower bins before that.

Perhaps somebody wiser will now be able to explain this to both of us.  I don't seem to have the wild SNR oscillation you posted, it just appears like that on mine if you were to take 2 snapshots, one with the shared tones on and higher bin loadings and then later when they are removed again and the loadings fall.

/correction. The DSLAM did not force a resynch on me, it was just a data harvesting hiccup .correction/

[krypton]

I think the random changes in bitloading data values is a bug. I noticed the same behaviour on my Broadcom 6368 based device.

I noticed another strange thing. The SNR and bitloading data doesn't always fit together.

The first picture was taken directly after a resync, the second a bit later:

[burakkucat]

I think the random changes in bitloading data values is a bug.

One quick query. You think it is a bug. A bug in the device's firmware or in the code of Eric's utility? 

[ColinS]

I think the random changes in bitloading data values is a bug.

One quick query. You think it is a bug. A bug in the device's firmware or in the code of Eric's utility? 

I wondered that too.  But then I only seem to see these shared tones in the evening (for fairly obvious reasons), and Eric would probably have to try hard to create a time-dependent bug, I guess, unless there was also some associated technical issue that caused it! 

[krypton]

A bug in the device's firmware or in the code of Eric's utility? 

Because the raw data changes the same way these must be bugs on the device itself.
I bet broadcom is reading this forum and will fix this problems as fast as Eric would patch his program.

[ColinS]

A bug in the device's firmware or in the code of Eric's utility? 

Because the raw data changes the same way these must be bugs on the device itself.
I bet broadcom is reading this forum and will fix this problems as fast as Eric would patch his program.

Yes, I agree it (the raw data) does.  But this still looks like bitswapping to me.  These same tones are reported as heavily bitswapped (both as tone bins and rate).  So, it may not just be a reporting problem, it might be some 'flaw' in the bitswapping algorithm, which (I am happy to be corrected) I would have thought was driven more by the DSLAM?  But one way or another there certainly seems to be some anomalous behavior taking place down there (in tones ~30-100)!!

Perhaps someone with their own DSLAM might be able to reproduce, or at least monitor this?  Cue Asbokid? 

[Bald_Eagle1]

How often are you guys harvesting the data via Eric's program?

It could just be that 'too frequent' harvesting catches bit-swapping in mid-flow i.e. before it has actually completed.

As mentioned, the 'missing' data seems to be restored after a few seconds.

The HG612 seems to also update its GUI every 10 seconds or so.
That's 6 harvests per minute plus however many times per minute you have rs-w set to harvest data may just be many harvests in any given minute.

It may not be relevant but I have caught a resync still 'training' on rare occasions via my previous scripts & now the program versions where SNRM is still reported as zero, yet sync speed is captured.

I have also occasionally seen gaps in bitloading, rectified by harvesting the data again, a few seconds later.

TBH, as I understand things, bit-swapping is a good thing as it seems to be intended in order to load as many bits as possible into the most 'receptive' tones at any given time.

On the other hand, too much may be an indication of fluctuating/intermittent 'electrical noise interference' etc?

The new BLOB for the HG612 seems to stop this 'problem' (on my connection anyway) as it seems to simply stop most of the bitloading in the 'Shared/Other' tones & moves some of the remaining bitloading to different tones.

I have now reverted to the original BLOB & bitloading in the 'Shared/Other' tones has been restored.
The slightly higher sync speed from using the new BLOB firmware has also dropped back down to the level previously provided via the original BLOB firmware.

Also, seeing sync speed higher than attainable rate isn't necessarily a 'fault'.

Quite often a connection can sync quite close to attainable rate when SNRM is at its peak during daylight hours.

As SNRM levels tend to reduce in the evenings (particularly DS SNRM) & the fact that attainable rates reduce directly in proportion to SNRM reduction, the result can be that the connection stays happily at a sync speed which is temporarily higher than attainable rate(s).


EDIT:
Here's an example:-

Max:    Upstream rate = 14559 Kbps, Downstream rate = 62792 Kbps
Path:   0, Upstream rate = 14660 Kbps, Downstream rate = 62576 Kbps

SNRM is currently 6.1dB for all 3 DS bands.

If SNRM were to reduce to say 4.5dB overnight, there's every likelyhood that at some time, sync speed will be higher than attainable rate.

[ColinS]

How often are you guys harvesting the data via Eric's program?

It could just be that 'too frequent' harvesting catches bit-swapping in mid-flow i.e. before it has actually completed.

TBH, as I understand things, bit-swapping is a good thing as it seems to be intended in order to load as many bits as possible into the most 'receptive' tones at any given time.

On the other hand, too much may be an indication of fluctuating/intermittent 'electrical noise interference' etc?

The new BLOB for the HG612 seems to stop this 'problem' (on my connection anyway) as it seems to simply stop most of the bitloading in the 'Shared/Other' tones & moves some of the remaining bitloading to different tones.

Thanks B-E, finger on the pulse as usual.  Eric's default sampling is every 30 secs, so that would mean 8 harvests/min + your own ongoing stats.  I take your point.  Does the HG612 still harvest even if the Gui is not on show?

In practise (by observation) I would say that one transition, from shared tones on and higher bit-loadings, to shared tones off and lower ones, in that tone range ~30-90, takes about 3-4 of Eric's refreshes, so about 2 mins.

Glad to hear that the new blob might reduce and/or eliminate this cyclical activity by shifting the bins in use a bit.  Next thing to try.

There is definately more REIN (mostly broadcast radio of one sort or another) at night, I guess for obvious reasons, and a little more now that I am on the distributed filter arrangement.  However the observed behaviour predates that.  So a matter of degree rather than occurrence I would think. 

[roseway]

If I could find a way of recognising when the refreshing of the bitloading is taking place, then I could probably work around it, but I can't see any way to do this.

[Bald_Eagle1]

Here are 2 examples from a high speed connection where remote monitoring commenced last night.

The stats were harvested on a schedule at 22:00 last night & at 06:00 this morning.

The bitloading differences at the lower frequencies are very clear.

I can only put it down to the modem not having completed its own update at the time my program harvested the stats for our monitoring as SNR was only very slightly lower last night.