Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: 1 2 [3] 4

Author Topic: rs-ux and rs-w v0.8 released  (Read 11312 times)

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 27725
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: rs-ux and rs-w v0.8 released
« Reply #30 on: August 30, 2012, 11:10:38 PM »

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.
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

roseway

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 39516
  • Penguins CAN fly
    • DSLstats
Re: rs-ux and rs-w v0.8 released
« Reply #31 on: August 30, 2012, 11:17:05 PM »

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.
Logged
  Eric

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 27725
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: rs-ux and rs-w v0.8 released
« Reply #32 on: August 31, 2012, 12:15:14 AM »

Quote
now it's time for slumber.

A very good suggestion.  :sleep:
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Bald_Eagle1

  • Helpful
  • Kitizen
  • *
  • Posts: 2721
Re: rs-ux and rs-w v0.8 released
« Reply #33 on: August 31, 2012, 05:34:19 AM »


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.

Logged

roseway

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 39516
  • Penguins CAN fly
    • DSLstats
Re: rs-ux and rs-w v0.8 released
« Reply #34 on: August 31, 2012, 06:49:19 AM »


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.
Logged
  Eric

broadstairs

  • Kitizen
  • ****
  • Posts: 3202
Re: rs-ux and rs-w v0.8 released
« Reply #35 on: August 31, 2012, 08:27:30 AM »

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
Logged
ISP:TalkTalk Connection:FTTC Cab:ECI Router:Netgear D6220

roseway

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 39516
  • Penguins CAN fly
    • DSLstats
Re: rs-ux and rs-w v0.8 released
« Reply #36 on: August 31, 2012, 09:45:03 AM »

Thanks Stuart, that's helpful.
Logged
  Eric

rhohne

  • Member
  • **
  • Posts: 76
Re: rs-ux and rs-w v0.8 released
« Reply #37 on: August 31, 2012, 02:29:04 PM »

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

Code: [Select]
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 
Logged

roseway

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 39516
  • Penguins CAN fly
    • DSLstats
Re: rs-ux and rs-w v0.8 released
« Reply #38 on: August 31, 2012, 03:31:04 PM »

Thanks, I think I know what's causing this now.
Logged
  Eric

roseway

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 39516
  • Penguins CAN fly
    • DSLstats
Re: rs-ux and rs-w v0.8 released
« Reply #39 on: September 02, 2012, 10:50:42 PM »

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.
Logged
  Eric

Bald_Eagle1

  • Helpful
  • Kitizen
  • *
  • Posts: 2721
Re: rs-ux and rs-w v0.8 released
« Reply #40 on: September 02, 2012, 11:26:33 PM »


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  :-\


Logged

asbokid

  • Kitizen
  • ****
  • Posts: 1286
    • Hacking the 2Wire
Re: rs-ux and rs-w v0.8 released
« Reply #41 on: September 02, 2012, 11:28:01 PM »

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?

Code: [Select]
# xdslcmd info --vendor
...
ChipSet Vendor Id: IFTN:0x71c6
ChipSet VersionNumber: 0x71c6
ChipSet SerialNumber:
#

cheers, a
Logged

roseway

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 39516
  • Penguins CAN fly
    • DSLstats
Re: rs-ux and rs-w v0.8 released
« Reply #42 on: September 03, 2012, 07:18:11 AM »

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.
« Last Edit: September 03, 2012, 09:26:28 AM by roseway »
Logged
  Eric

roseway

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 39516
  • Penguins CAN fly
    • DSLstats
Re: rs-ux and rs-w v0.8 released
« Reply #43 on: September 03, 2012, 07:22:49 AM »

Is the --vendor option of xdslcmd any use?

ECI's VDSL2 DSLAM hardware presumably lists as IFTN (Lantiq) whereas Huawei lists as BRCM, maybe?

Code: [Select]
# 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.
« Last Edit: September 03, 2012, 07:43:33 AM by roseway »
Logged
  Eric

Bald_Eagle1

  • Helpful
  • Kitizen
  • *
  • Posts: 2721
Re: rs-ux and rs-w v0.8 released
« Reply #44 on: September 03, 2012, 08:06:41 AM »


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.

Logged
Pages: 1 2 [3] 4
 

anything