Print

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

[Weaver]

Over the last couple of days, I enhanced my DSL line monitoring software for the ipad to have it watch for variations in attenuation and tx-power figures.

Almost immediately I got the following warning, which is correct (checked the figures by hand):

--
* Warning: line properties out of range: this may indicate a line fault, but this is not automatically assumed here. Significance depends on the direction of change and the size.
   Link #3:   upstream: the current value of the attenuation 40.4 dB differs from the expected 40.5 dB
   Link #3: downstream: the current value of the tx power 18.2 dBm differs from the expected 17.9 dBm

That’s the whole report, no changes for other lines. This report was obtained in the middle of the night, and the comparison expectation values were obtained in daytime. So I’m wondering if this is a daytime-night time thing as far as the attenuation is concerned, but a difference that low could just be in the noise, a rounding change. I don’t understand the tx-power change though. Also there are no changes for other lines.

What kind of daily variation and occasional variations do other people see?

This is the first release, and I’m going to put in ignore-tolerance bands of some sort, yet to be determined.


This being an early release, I’m thinking that I could extend the use of this code. My aim is to spot indicators of line faults or any kinds of serious weirdness. Are there other important DSL line properties that I should monitor to check their values remain constant?

One final thing, I’m concerned about what might happen with bogus differences if the SNRM and hence the sync speeds change, as I seem to remember that Kitz has pointed out that the calculation of the SNRM might be bits-per-bin spectrum dependent -  is that correct? I don’t really want to make my existing database of expected comparison values SNRM-dependent, that would be a lot of typing and it would be well nigh impossible to obtain all those values.

[XGS_Is_On]

SNR margin has to be dependent on bits per bin. SNRM is the margin between required SNR for a particular modulation order and, hence, bits per symbol in the bin and the actual SNR in that frequency range.

Using QPSK / 2 bits per symbol requires an SNR of about 12 dB, using 64 QAM / 6 bits per symbol needs 24 dB. With an SNR in that bin's frequency of 27 dB you've a margin of 3 dB if 64 QAM is being used but 15 if using QPSK.

It's this lowering of modulation order and, indeed, bins that don't have good enough SNR for QPSK not being used, that is why speeds slow in the presence of noise, all other things being equal. It's also why interleave is used: the coding gain from FEC alongside increased resistance to impulse nose improves the bit error rate for a given RF SNR allowing more bits to be packed in without increasing error rate.

[Weaver]

Hi Carl, I do monitor SNRM already, but using different code, and a somewhat different algorithm for interpreting and classifying the results. In that case, I only ring a bell if the SNRM goes outside one of several ranges above and below a target SNRM. I treat above-target and below-target cases separately and have more than one threshold used in reporting severity. If a value is inside an inner threshold it just gets ignored and is classified as the case of being within the usual expected level of variation.

So SNRM isn’t on the list for new properties to check. I also check sync rates and the ES counts within the two most recent duration buckets.

I have now added ignore-tolerance bands and intelligence so that the code knows whether ‘>’ and ‘<‘ means good or bad, so that the code can either warn the user about potential badness, or else report the condition with a mere level=informational report. I need to make the thresholds more easily user-configurable and put them in an external config database that is easily altered. I also need multiple additional property value deviation thresholds with different associated severity / significances ratings, but I have no idea how to choose those figures at the moment.

[XGS_Is_On]

I've no idea how you would choose those values either, Sir. The Tx power can probably be ditched and the attenuation given how much of your line is overhead will vary somewhat.

[Weaver]

Could you explain, Carl?


Today I note a drop in line 3 "power" downstream of 0.7 dB. Was 18.2 dBm now 17.5 dBm and falling. It is now growing dark and it has been very wet for a good part of today. No change for other lines, and no change for upstream tx-power.

Can anyone explain something for me, I realise that I don’t know what the power value means. In the case of downstream power, does this  value mean tx-power as reported by the ATU-C to the ATU-R, or is it something measured by the ATU-R? I’m assuming that this is not the case, as this would be mixing in the concept of attenuation.

[burakkucat]

Can anyone explain something for me, I realise that I don’t know what the power value means. In the case of downstream power, does this  value mean tx-power as reported by the ATU-C to the ATU-R, or is it something measured by the ATU-R? I’m assuming that this is not the case, as this would be mixing in the concept of attenuation.

I assume the former rather than the latter, for the same reason that you mention in the second sentence (which I have quoted above).

[Weaver]

My calculator says that -0.7 dB is a drop of ~7.7% in voltage terms (as opposed to power). So given that we’re assuming that this is a report originating in the ATU-C received by the ATU-R and passed on to me giving the ATU-C’s opinion of its own output, then that ought to show a conscious decision by the ATU-C to reduce the output power. Why would it do that ? To reduce crosstalk? Could that be to do with a new bit loading in the ATU-C’s downstream? And that did indeed happen. There were two retrains in the afternoon, and those happened before the figures were captured. There was a loss of downstream sync rate of about 250k on that line, compared to the day before, for reasons unknown.

[XGS_Is_On]

The DSLAM, if so configured, will lower power to the minimum required to achieve SNRM. Given your service can't rate adapt up no point wasting electricity driving a 15 dB margin if the target's 6 for instance.

Best guess you lost the 250 kbps due to a transient line condition and the DSLAM is happy that it can maintain the circuit at the target SNRM with that power level. It'll increase it if it needs to.