Kitz Forum
Broadband Related => Router Monitoring Software => Topic started by: roseway on August 30, 2012, 03:09:02 PM
-
Changes compared to v0.71:
- added pause and resume feature
- added option to plot QLN and HLog data
- improved tabulation of telnet data
- clearer icons on toolbar
- added option to change the thickness of graph lines
- included HTML help
https://docs.google.com/folder/d/0BxbUtOYVZ_SCZ1BnY3RKYnN2b1U/edit
-
rs-ux v0.8, 64-bit, has been downloaded, extracted, configured and set to work.
The new icons are just "purrfect" for a pair of sleepy eyes. Thank you. :)
-
I've downloaded the 'official' 0.8 now although the pre-release I got ny accident did not give me any problems.
Stuart
-
Just to say it all works OK except the DSL Connection Uptime at the bottom of the screen. Dont know if that is a problem with my D-Link 2740B or the program?
Here's my telnet data:-
> adsl info --stats
adsl: ADSL driver and PHY status
Status: ShowtimeRetrain Reason: 8000
Channel: FAST, Upstream rate = 1020 Kbps, Downstream rate = 8191 Kbps
Link Power State: L0
Mode: ADSL2+
Channel: Fast
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 4.1 5.9
Attn(dB): 41.0 22.0
Pwr(dBm): 0.0 12.9
Max(Kbps): 9124 1040
Rate (Kbps): 8191 1020
G.dmt framing
K: 135(0) 146
R: 16 0
S: 1 1
D: 96 1
ADSL2 framing
MSGc: 55 10
B: 134 145
M: 1 1
T: 2 1
R: 16 0
S: 0.5254 4.5447
L: 2299 257
D: 96 1
Counters
SF: 508719530 238609251
SFErr(CRCErr): 423611 4294967265
RS: 1934240532 0
RSCorr: 453900347 0
RSUnCorr: 7832104 0
HEC: 382447 1
OCD: 6760 0
LCD: 22 0
Total Cells: 2871497067 1722528
Data Cells: 1084093576 164093
Drop Cells: 235181
Bit Errors: 0 32
ES: 79842 1
SES: 4195 0
UAS: 31 0
AS(Uptime): 8152923
INP: 2.67 0.00
PER: 16.02 18.17
delay: 12.61 1.13
OR: 30.45 7.04
Bitswap: 726503 143890
Total uptime: 8152923
Total time = 1 days 8 hours 43 min 7 sec
SF = 508719530
CRC = 423611
LOS = 5
LOF = 0
ES = 79842
Latest 1 day time = 8 hours 43 min 7 sec
SF = 1958486
CRC = 699
LOS = 0
LOF = 0
ES = 175
Latest 15 minutes time = 13 min 7 sec
SF = 49130
CRC = 25
LOS = 0
LOF = 0
ES = 9
Previous 15 minutes time = 15 min 0 sec
SF = 56139
CRC = 29
LOS = 0
LOF = 0
ES = 11
Previous 1 day time = 24 hours 0 sec
SF = 5391045
CRC = 17348
LOS = 0
LOF = 0
ES = 2474
15 minutes interval [-30 min to -15 min] time = 15 min 0 sec
SF = 56139
CRC = 30
LOS = 0
LOF = 0
ES = 13
15 minutes interval [-45 min to -30 min] time = 15 min 0 sec
SF = 56202
CRC = 34
LOS = 0
LOF = 0
ES = 14
15 minutes interval [-60 min to -45 min] time = 15 min 0 sec
SF = 56139
CRC = 12
LOS = 0
LOF = 0
ES = 4
Showtime Drop Reason: 8000
Last Retrain Reason: 8000
>
Stuart
-
rs-ux v0.8, 64-bit, has been downloaded, extracted, configured and set to work.
The new icons are just "purrfect" for a pair of sleepy eyes. Thank you. :)
You're very welcome. I did it just for you. ;D
-
Just to say it all works OK except the DSL Connection Uptime at the bottom of the screen. Dont know if that is a problem with my D-Link 2740B or the program?
Here's my telnet data:-
I seem to have made a false assumption here. The stats on my HG612 end with a section which is labelled "Since link time = hh hours mm minutes ss seconds" and I use this for the uptime information. Your 2740B doesn't have this section, so I'll have to look elsewhere.
-
you could probably work back to it from the superframes (SF) counter
-
In case it helps here is a snapshot of what the stats page via the router web pages shows...
Stuart
-
My First Report on V0.8
I have configured the utility to harvest data every minute and display graphs with a width (X-axis) of one hour.
The seven primary tabs (SNR margin, Connection speed, Bitloading, QLN, Hlog, Telnet data and Configuration) all display the expected information.
Looking closely at the secondary tabs under Telnet data, I see that Connection stats, Bitloading, pbParams, QLN, Hlog and SNR are available. It is a little surprising that pbParams is offered, as the modem is connected to (and configured for) an ADSL2+ service. Upon taking the pbParams tab a blank screen is displayed, as expected, as pbParams can only be harvested from a VDSL2 connection.
The utility is also configured to automagically take a snapshot of each completed graph. Here is an observed defect. Both the Bitloading and Speed graphs do not show any data. Please see the attached snapshots, below.
-
I seem to have made a false assumption here. The stats on my HG612 end with a section which is labelled "Since link time = hh hours mm minutes ss seconds" and I use this for the uptime information. Your 2740B doesn't have this section, so I'll have to look elsewhere.
Maybe use AS(Uptime) - as that's shown in seconds on the D-Link?
-
Quick feedback from my HG612 on a VDSL2 connection.
Everything seems to be working O.K. (in use for around 1 hour).
Snapshot graphs are working & I will confirm whether or not the graphs are generated automatically following the default 2 hour period.
It may be of interest that on VDSL2 connections, maximum values (taken as "invalid" values - not to be plotted) are:-
Hlog -96.0000
QLN -160.0000
I see lots of these invalid values on my HG612 connection to a Huawei DSLAM (valid Upstream values are not reported by the DSLAM).
However, HG612 modems connected to ECI DSLAMS do (sometimes) report valid Upstream values.
So, any valid Hlog & QLN data reported when connected to Huawei DSLAMs should all be the colour for Downstream, with Upstream shown in a different colour only when connected to ECI DSLAMs.
If looking closely at my QLN graph, 3 colours can be seen currently (red, purple & green), along with "invalid" data at -160.0000.
There are one or two Kitz members with VDSL2 connections to ECI DSLAMS that may be able to post relevant rs-w or rs-ux graphs for you.
-
Just noticed that I have got an Invalid Floating Point Operation message on this now, not sure when or why, its been running about 2 hours. Clicked OK and it seems to have carried on. It says saving snapshot at the top of the screen, I have it set to snap all graphs every 2 hours. Looks like it had a problem with the bit loading graph as that snapshot was not taken and the graph has now disappeared as well. Restarted program and nothing shows on bit loading graph, other two are graphing OK.
Stuart
-
Looking closely at the secondary tabs under Telnet data, I see that Connection stats, Bitloading, pbParams, QLN, Hlog and SNR are available. It is a little surprising that pbParams is offered, as the modem is connected to (and configured for) an ADSL2+ service. Upon taking the pbParams tab a blank screen is displayed, as expected, as pbParams can only be harvested from a VDSL2 connection.
I take it that you enabled the option "Stats per band"? If so, I can confirm your finding, and it's a detail I need to attend to.
The utility is also configured to automagically take a snapshot of each completed graph. Here is an observed defect. Both the Bitloading and Speed graphs do not show any data. Please see the attached snapshots, below.
I'm checking this out now. It worked before, and I don't recall making any changes to how it works, but I'll find out.
-
you could probably work back to it from the superframes (SF) counter
Maybe use AS(Uptime) - as that's shown in seconds on the D-Link?
Thanks for those suggestions. I'll look into them.
-
It may be of interest that on VDSL2 connections, maximum values (taken as "invalid" values - not to be plotted) are:-
Hlog -96.0000
QLN -160.0000
I see lots of these invalid values on my HG612 connection to a Huawei DSLAM (valid Upstream values are not reported by the DSLAM).
However, HG612 modems connected to ECI DSLAMS do (sometimes) report valid Upstream values.
So, any valid Hlog & QLN data reported when connected to Huawei DSLAMs should all be the colour for Downstream, with Upstream shown in a different colour only when connected to ECI DSLAMs.
If looking closely at my QLN graph, 3 colours can be seen currently (red, purple & green), along with "invalid" data at -160.0000.
There are one or two Kitz members with VDSL2 connections to ECI DSLAMS that may be able to post relevant rs-w or rs-ux graphs for you.
Thanks, I didn't know that. I can certainly blank out the invalid values, and I'll look at the possibility of changing the plotting dependent on the DSLAM type.
-
Just noticed that I have got an Invalid Floating Point Operation message on this now, not sure when or why, its been running about 2 hours. Clicked OK and it seems to have carried on. It says saving snapshot at the top of the screen, I have it set to snap all graphs every 2 hours. Looks like it had a problem with the bit loading graph as that snapshot was not taken and the graph has now disappeared as well. Restarted program and nothing shows on bit loading graph, other two are graphing OK.
Stuart
I don't know if this is related to the blank snapshots referred to by b*cat, but I'll give it my attention.
-
Graphs were generated at 2 hours connection time (19:06).
However, it seems that data stopped being harvested at 17:58.
-
Following the partial graph generation at 19:06, I received 2 error messages & the program shut itself down, the first message being Stats_Error_Message.
EDIT:
I have also just discovered that my own harvesting program that had been running for a few days crashed at around the same time.
It may just be that both programs tried to access the modem at the same time, but I have until recently been also harvesting my stats via a different method along with my harvesting program with no issues.
-
Looking closely at the secondary tabs under Telnet data, I see that Connection stats, Bitloading, pbParams, QLN, Hlog and SNR are available. It is a little surprising that pbParams is offered, as the modem is connected to (and configured for) an ADSL2+ service. Upon taking the pbParams tab a blank screen is displayed, as expected, as pbParams can only be harvested from a VDSL2 connection.
I take it that you enabled the option "Stats per band"? If so, I can confirm your finding, and it's a detail I need to attend to.
Yes, indeed. The "Stats per band" box was ticked -- because it was there. ;) As that is a known current feature, then there is no problem.
The utility is also configured to automagically take a snapshot of each completed graph. Here is an observed defect. Both the Bitloading and Speed graphs do not show any data. Please see the attached snapshots, below.
I'm checking this out now. It worked before, and I don't recall making any changes to how it works, but I'll find out.
All subsequent snapshot graphs have been produced correctly. I think I need to stop the utility, wait a few minutes and start it from "cold" once again to see if there is a repetition of the event when the very first snaphot graphs time occurs.
-
Thanks, I didn't know that. I can certainly blank out the invalid values, and I'll look at the possibility of changing the plotting dependent on the DSLAM type.
Is this the DSLAM vendor for my connection:-
# xdslcmd info --vendor
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 4497 Kbps, Downstream rate = 32156 Kbps
Path: 0, Upstream rate = 4435 Kbps, Downstream rate = 28075 Kbps
ChipSet Vendor Id: BDCM:0xa350
ChipSet VersionNumber: 0xa350
ChipSet SerialNumber:
If it helps at all, this is the Discovery Phase Band Plan from a Huawei DSLAM.
It's how I determine which of the two DSLAMs is in use:-
Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)
This is the Discovery Phase Band Plan from an ECI DSLAM:-
Discovery Phase (Initial) Band Plan
US: (0,95) (880,1195) (1984,2771)
DS: (32,859) (1216,1959) (2792,4083)
-
Following the partial graph generation at 19:06, I received 2 error messages & the program shut itself down, the first message being Stats_Error_Message.
EDIT:
I have also just discovered that my own harvesting program that had been running for a few days crashed at around the same time.
It may just be that both programs tried to access the modem at the same time, but I have until recently been also harvesting my stats via a different method along with my harvesting program with no issues.
It's been my understanding (although I must check this) that BCM-based routers only accept a single telnet login at any one time. My program logs in, collects the data, then logs out. I've been able to have two instances of it running and collecting data, but only so long as their sampling periods don't conflict.
-
# xdslcmd info --vendor
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 4497 Kbps, Downstream rate = 32156 Kbps
Path: 0, Upstream rate = 4435 Kbps, Downstream rate = 28075 Kbps
ChipSet Vendor Id: BDCM:0xa350
ChipSet VersionNumber: 0xa350
ChipSet SerialNumber:
That suggests that the DSLAM is Broadcom - are Broadcom and Huawei related?
I get the following, and I know that I'm connected to an Infineon MSAN:
# xdslcmd info --vendor
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 8000
Max: Upstream rate = 1064 Kbps, Downstream rate = 9264 Kbps
Path: 0, Upstream rate = 1067 Kbps, Downstream rate = 8670 Kbps
ChipSet Vendor Id: IFTN:0x71be
ChipSet VersionNumber: 0x71be
ChipSet SerialNumber:
#
-
Observations using rs-w32-0.8 and DG834GT with DGTEAM
Very impressed with the work so far, however have come across a few additional minor issues
Bitloading Graphs
1) Only plotted when also plotting SNR per tone
2) The GUI timestamps are updated twice, once at start of stats collection and then when data processed.
3) Snaphot doesn't always plot Tone 0 correctly - see attached
4) Upstream SNR off screen
QLN & Hlog Graphs
1) Data requested on first two sample only.
2) The GUI timestamps are updated on every sample, despite no data requested.
-
It's been my understanding (although I must check this) that BCM-based routers only accept a single telnet login at any one time. My program logs in, collects the data, then logs out. I've been able to have two instances of it running and collecting data, but only so long as their sampling periods don't conflict.
My program runs once every minute via Windows Task Scheduler, at 30 seconds past the minute.
It logs in to telnet, harvests the data, logs out & exits the program completeley.
My graphs are intentionally only generated on demand from an ongoing data log file, rather than being continuously updated in memory.
I restarted your program at 35 seconds past the hour leaving it set at 30 second sampling periods, so the 2nd sample should be at 5 seconds past the minute.
My program takes around 2 seconds to complete the harvest & sort the data for numerous graphs.
The Telnet harvest itself only takes around 1.25 seconds, so the 2 programs shouldn't now clash with each other.
-
It's been my understanding (although I must check this) that BCM-based routers only accept a single telnet login at any one time.
The only time I've had a problems with multiple telnet sessions on the DG834GT is when debug mode was enabled after a telnet session was established, this tended to kill any existing telnet session.
-
My program takes around 2 seconds to complete the harvest & sort the data for numerous graphs.
The Telnet harvest itself only takes around 1.25 seconds, so the 2 programs shouldn't now clash with each other.
Unfortunately the timer isn't accurate, so the two programs will soon clash. It's been in my mind to substitute an accurate timer, and clearly I must do this now.
-
Bitloading Graphs
1) Only plotted when also plotting SNR per tone
2) The GUI timestamps are updated twice, once at start of stats collection and then when data processed.
3) Snaphot doesn't always plot Tone 0 correctly - see attached
4) Upstream SNR off screen
1. I can't reproduce this. Can anyone else confirm?
2. See (2) below.
3. I haven't seen this myself. It suggests that the router is reporting a negative dB value sometimes. As tone 0 isn't used anyway, I'll simply trap negative values and make them zero.
4. Yes, I can confirm this. I'll deal with it.
QLN & Hlog Graphs
1) Data requested on first two sample only.
2) The GUI timestamps are updated on every sample, despite no data requested.
1. The QLN and HLog data is collected by the router at initialisation time, and isn't refreshed until the next re-sync, so the program only issues these commands at the start of recording, or after a re-sync. It does so twice because the first sample is used to establish what kind of connection it is.
2. The way it works at present is that the time stamp is updated whenever the window is redrawn. Perhaps I can intercept this and fix the timestamp between samples. I'll have a look at this.
-
My Second Report on V0.8
Having stopped the utility and closed it down completely, the snapshot graphing directory was tidied up. After five minutes, the utility was re-invoked, the configuration adjusted to de-select Stats per band and then recording was started. Two hours have passed since the above was performed, so there are now six snapshot graphs in the relevant directory.
I attach, below, the Bitloading, SNRMargin and Speed graphs automagically obtained after the first hour and the following Speed graph from after the second hour.
Something is definitely not correct. ???
-
This is from a MSAN which has an Infineon chipset --
# xdslcmd info --vendor
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 928 Kbps, Downstream rate = 5996 Kbps
Path: 0, Upstream rate = 940 Kbps, Downstream rate = 5820 Kbps
ChipSet Vendor Id: IFTN:0x71c6
ChipSet VersionNumber: 0x71c6
ChipSet SerialNumber:
#
-
My Second Report on V0.8
Having stopped the utility and closed it down completely, the snapshot graphing directory was tidied up. After five minutes, the utility was re-invoked, the configuration adjusted to de-select Stats per band and then recording was started. Two hours have passed since the above was performed, so there are now six snapshot graphs in the relevant directory.
I attach, below, the Bitloading, SNRMargin and Speed graphs automagically obtained after the first hour and the following Speed graph from after the second hour.
Something is definitely not correct. ???
Have you got the Connection speed graph disabled? The auto snapshot feature can only work if the corresponding graph is enabled. One thing I plan to do in the next version is set it up so that the corresponding graph is automatically enabled when auto-snapshot is enabled.
-
Have you got the Connection speed graph disabled? The auto snapshot feature can only work if the corresponding graph is enabled. One thing I plan to do in the next version is set it up so that the corresponding graph is automatically enabled when auto-snapshot is enabled.
No, that is not the cause. :no: The Connection speed graph is enabled. My configuration screens are attached, below.
-
No, that is not the cause. :no: The Connection speed graph is enabled. My configuration screens are attached, below.
OK, thanks. I'll put my thinking cap on tomorrow, but for now it's time for slumber.
-
now it's time for slumber.
A very good suggestion. :sleep:
-
3. I haven't seen this myself. It suggests that the router is reporting a negative dB value sometimes. As tone 0 isn't used anyway, I'll simply trap negative values and make them zero.
FWIW, I've never noticed negative SNR values, but I have often seen negative SNRM values, not always resulting in a resync.
-
3. I haven't seen this myself. It suggests that the router is reporting a negative dB value sometimes. As tone 0 isn't used anyway, I'll simply trap negative values and make them zero.
FWIW, I've never noticed negative SNR values, but I have often seen negative SNRM values, not always resulting in a resync.
Yes, a negative value of SNRM isn't unknown, but I would guess that a negative value of SNR for tone 0 is probably a false report. But it could also be a bug in the program.
-
Been having a bit more play this morning. Now I find that bit loading does show only if I also select SNR per tone as well. If I turn off the SNR/Tone the bit loading graph seems to continue to display (but I suspect may not update) however after stopping and starting the application it no longer displays, BUT if I right click on a Tone the data in the box below the graph shows up so it looks like the data is simply not graphing.
Stuart
-
Thanks Stuart, that's helpful.
-
The router is reporting correctly - there are no negative values, it's as if on occasions the initial y offset is not been applied correctly. I also see the problem in the main GUI when rsw is resized
adsl info --SNR
adsl: ADSL driver and PHY status
Status: ShowtimeRetrain Reason: 8000
Channel: FAST, Upstream rate = 1135 Kbps, Downstream rate = 13403 Kbps
Tone number SNR
0 0.0000
1 0.0000
2 0.0000
3 0.0000
4 0.0000
5 0.0000
-
Thanks, I think I know what's causing this now.
-
It may be of interest that on VDSL2 connections, maximum values (taken as "invalid" values - not to be plotted) are:-
Hlog -96.0000
QLN -160.0000
I see lots of these invalid values on my HG612 connection to a Huawei DSLAM (valid Upstream values are not reported by the DSLAM).
However, HG612 modems connected to ECI DSLAMS do (sometimes) report valid Upstream values.
So, any valid Hlog & QLN data reported when connected to Huawei DSLAMs should all be the colour for Downstream, with Upstream shown in a different colour only when connected to ECI DSLAMs.
If looking closely at my QLN graph, 3 colours can be seen currently (red, purple & green), along with "invalid" data at -160.0000.
I've got around to thinking about this (after fixing the other reported issues). It seems to me, looking at the purple section of the graph in your snapshot, that there are invalid values for upstream tones 0-31, so these can be blanked, but tones 32-95 are 'shared' and therefore could contain valid downstream data. I'm inclined to leave these displayed in purple, unless there is a good reason not to.
We don't seem to have a definitive way of determining the type of DSLAM, and until we do I'll leave the graph colouring as it is, but blanking out the invalid values.
-
I've got around to thinking about this (after fixing the other reported issues). It seems to me, looking at the purple section of the graph in your snapshot, that there are invalid values for upstream tones 0-31, so these can be blanked, but tones 32-95 are 'shared' and therefore could contain valid downstream data. I'm inclined to leave these displayed in purple, unless there is a good reason not to.
We don't seem to have a definitive way of determining the type of DSLAM, and until we do I'll leave the graph colouring as it is, but blanking out the invalid values.
As mentioned, I am connected to a Huawei DSLAM that does NOT report US QLN & Hlog data.
Therefore, as tones 32 to 95 contain valid data, for my Huawei connection, it MUST be DS data.
Would it assist if I were to email/post here an example Plink snapshot log from an ECI DSLAM for you to have a look at (in conjunction with the differing band plans as discovered by Huawei & ECI DSLAMS)?
My scripts don't actually determine which type of DSLAM is used as such, rather they just plot data as US (if it is a valid value - i.e. ECI DSLAM) or simply ignore it if it is an invalid value - HUAWEI DSLAM.
The quickest way to determine the type of DSLAM (if actually needed) seems to be to look at the maximum DS tone "discovered" & reported via xdslcmd info --pbParams.
It is currently tone 3959 for Huawei DSLAMs (it was 3939 for the first few months of the 17a profile) & is currently 4083 for ECI DSLAMs.
Perhaps I haven't explained that very well, but I'm sure you will get the jist of what I actually mean :-\
-
Great work, Eric!
We don't seem to have a definitive way of determining the type of DSLAM, and until we do I'll leave the graph colouring as it is, but blanking out the invalid values.
Is the --vendor option of xdslcmd any use?
ECI's VDSL2 DSLAM hardware presumably lists as IFTN (Lantiq) whereas Huawei lists as BRCM, maybe?
# xdslcmd info --vendor
...
ChipSet Vendor Id: IFTN:0x71c6
ChipSet VersionNumber: 0x71c6
ChipSet SerialNumber:
#
cheers, a
-
As mentioned, I am connected to a Huawei DSLAM that does NOT report US QLN & Hlog data.
Therefore, as tones 32 to 95 contain valid data, for my Huawei connection, it MUST be DS data.
Would it assist if I were to email/post here an example Plink snapshot log from an ECI DSLAM for you to have a look at (in conjunction with the differing band plans as discovered by Huawei & ECI DSLAMS)?
My scripts don't actually determine which type of DSLAM is used as such, rather they just plot data as US (if it is a valid value - i.e. ECI DSLAM) or simply ignore it if it is an invalid value - HUAWEI DSLAM.
The quickest way to determine the type of DSLAM (if actually needed) seems to be to look at the maximum DS tone "discovered" & reported via xdslcmd info --pbParams.
It is currently tone 3959 for Huawei DSLAMs (it was 3939 for the first few months of the 17a profile) & is currently 4083 for ECI DSLAMs.
Perhaps I haven't explained that very well, but I'm sure you will get the jist of what I actually mean :-\
That's quite clear, thanks. I think I'll have to determine the DSLAM type because of the uncertainty about tones 32-95. As you say, these must be downstream tones (red) if they show valid data when connected to a Huawei DSLAM, but could in principle be upstream or downstream (blue) when connected to an ECI DSLAM.
Your snapshot log from an ECI DSLAM might be helpful, so I would appreciate a copy, either by email or here (if not too long), thanks.
-
Is the --vendor option of xdslcmd any use?
ECI's VDSL2 DSLAM hardware presumably lists as IFTN (Lantiq) whereas Huawei lists as BRCM, maybe?
# xdslcmd info --vendor
...
ChipSet Vendor Id: IFTN:0x71c6
ChipSet VersionNumber: 0x71c6
ChipSet SerialNumber:
#
cheers, a
Thanks, I was hoping to get the information there, and if IFTN corresponds with ECI, and BRCM (BDCM I think) corresponds with Huawei, that would seem to be definitive.
-
Your snapshot log from an ECI DSLAM might be helpful, so I would appreciate a copy, either by email or here (if not too long), thanks.
Zipped copy attached.
Tones 32 to 95 appear to contain invalid data for QLN & Hlog (-160.0000 & -96.2500 respectively, so any graphs are blank for those tones).
This log is from a high speed connection can that max out the 20Mb US cap at higher frequencies, thus apparently leaving any "shared" tones at lower frequencies available for DS bit-loading, as suggested by the SNR & bit-loading data values.
Poorer or longer distance connections (such as mine) actually use more of band US0 that was apparently optionally implemented by BT for Upstream data on UK connections.
-
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
-
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?
-
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.
-
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.
-
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.
-
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).