Print

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

[roseway]

Thanks again. So it looks as though tones 32-95 must remain either blank (for invalid values), red (for valid values from a Huawei DSLAM), or blue (for valid values from an ECI DSLAM) as they can be used for either upstream or downstream, depending on the quality of the connection.


Corrected to include Huawei red tones

[Bald_Eagle1]

Weeeell, yes - sort of.

Huawei DSLAMs are easy - they simply do NOT report US QLN, Hlog & SNR - ever!

ECI DSLAMs sometimes report those US stats, but even on a "good" connection they are not always reported.
It appears that when they are not reported, DS SNR is usually reported exactly as it would have been reported anyway.
From that. I rightly or wrongly deduced that if DS SNR is ALWAYS reported, any valid data that is occasionally reported at the same tones must also be DS.
Bit-loading is shown blue for (shared/other tones), but that also appears to be DS rather than US (in most cases).

FWIW, I have attached raw data & my own graphs from a "poor" & very long distance ECI connection.

My script has graphed what is percieved to be DS only for SNR, QLN & Hlog, although it still shows some of the bit-loading tones as shared.
Looking at the values of the shared tones, I take the view that it must actually be DS data, but I'm not 100% sure.

What do you think?

[roseway]

What do you think?

I think we're rather in the area of guesswork. I follow your reasoning, but I think I prefer to leave the uncertain areas blue, rather than (possibly) guessing wrongly.

I suppose that the real question is - what use is made of these graphs, and how important is it to distinguish between up and down in the uncertain areas? I confess that I'm doing this in a rather mechanistic way, without really understanding the value of the information. If you consider that a best guess is better than no guess at all, I'll happily go along with that.

[Bald_Eagle1]

I think we're rather in the area of guesswork. I follow your reasoning, but I think I prefer to leave the uncertain areas blue, rather than (possibly) guessing wrongly.

I'd agree with that for the bit-loading graph as that is truly dynamic & picks up changes such as bit swapping etc. during the life of a connection, as does the SNR graph.

I suppose that the real question is - what use is made of these graphs, and how important is it to distinguish between up and down in the uncertain areas? I confess that I'm doing this in a rather mechanistic way, without really understanding the value of the information. If you consider that a best guess is better than no guess at all, I'll happily go along with that.

Hlog & QLN are very important as they basically dictate sync speeds etc. as they do reflect actual physical conditions at the time a connection syncs.
Any significant changes in these (attenuation & noise) have quite a dramatic effect upon a connection's speed/stability.
e.g. I often saw dips/valleys in my Hlog graph when my connection was regularly "playing up". The graphs were partially the proof of the problem that prompted so many engineer/technician visits without being charged for any of them.
I haven't seen a single sudden dip/valley in my Hlog graph since my connection was finally repaired.

How important it is to distinguish between DS & US for the "shared" tones as seen on VDSL2 connections & not seen for ADSL connections is debatable, especially as Huawei DSLAMs only report DS QLN & Hlog data anyway.
I chose to make a reasoned sort of stab at it for ECI DSLAMs.

Please don't let this particular matter detract from the excellent work that you have carried out so far & will hopefully continue to carry out as you further develop your program.
TBH, it is probably way down the list of priorities.
I only mention such things as I am aware that you don't have a VDSL2 connection of your own to play with, as my attempt to assist with your overall perception of VDSL2 matters in general.

[roseway]

Please don't let this particular matter detract from the excellent work that you have carried out so far & will hopefully continue to carry out as you further develop your program.
TBH, it is probably way down the list of priorities.
I only mention such things as I am aware that you don't have a VDSL2 connection of your own to play with, as my attempt to assist with your overall perception of VDSL2 matters in general.

I do appreciate all the help you give me, and I do want to ensure that the program provides the most useful information. So I'll return to this when I've done some other things which are clamouring for attention. For now, I'll take the easy route and blank the invalid QLN and HLog data, show all valid Huawei QLN and HLog data as downstream, and colour ECI QLN and HLog data in the same way as the bitloading graph.

[Bald_Eagle1]

For now, I'll take the easy route and blank the invalid QLN and HLog data, show all valid Huawei QLN and HLog data as downstream, and colour ECI QLN and HLog data in the same way as the bitloading graph.

That sounds like a good plan to me 

At least we have flagged the potential issue(s).