Print

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

[tiffy]

Ahh, We live and learn !

I am obviously confusing this with my recent experiences with the 3 systems I look after, mine, son's and daughter's where I had issues with DSLStats not running on their respective RPi's and in one instance the RPi's clock being so badly out it could not correct itself, in these cases, once data uploading was re-established (and the RPi clock was correct) the percentage upload indicator started to increment towards 100%.

Did not appreciate that an outage at your end of the system would not produce the same results, now I know !

[jelv]

The difference is what happened in the 24 hours before the outage.

With the server outage there was continuous connection before. It was out for about an hour so at just after 3am when it came back it had recorded one about hour of outage during the previous 24 hour period from 3am the previous day. At 4am it is still the same amount of outage during the 24 hours from 4am the previous day - so the same percentage. That will continue for about 23 hours until it is exactly 24 hours after the outage started when the percentage will climb reaching 100% exactly 24 hours after the outage ended.

With your experience with the RPi's not uploading at all during the previous 24 hours the uptime will start at 0% and climb back to 100% 24 hours after they started uploading again.

[toulouse]

Hello all,

In a moment of what I can only think of as being madness this morning, I appear to have cleared out my browser history, and now I am unable to log in to MDWS. I have my username and password, but for the life of me I cannot remember what my memorable phrase is or was. Pretty memorable, huh.

I assume there must be a recovery mechanism for this self inflicted issue, but I am unable to see how I should proceed.

Any pointers to get me back into MDWS would be greatly appreciated.

toulouse

[tbailey2]

Reset your password...

[tiffy]

The difference is what happened in the 24 hours before the outage.

With the server outage there was continuous connection before. It was out for about an hour so at just after 3am when it came back it had recorded one about hour of outage during the previous 24 hour period from 3am the previous day. At 4am it is still the same amount of outage during the 24 hours from 4am the previous day - so the same percentage. That will continue for about 23 hours until it is exactly 24 hours after the outage started when the percentage will climb reaching 100% exactly 24 hours after the outage ended.

With your experience with the RPi's not uploading at all during the previous 24 hours the uptime will start at 0% and climb back to 100% 24 hours after they started uploading again.

Thanks for the explanation, makes sense now.

[22over7]

I've just been playing with zoom + once to increase everything including the table width, then zoom text only and zoom in some more and have managed to create a version of the basic edition screen that looks very, very similar to 22over7's screen shot.

I've found my "wrong" setting in Firefox 56, and learnt something about zooming by several experiments.
For some unknown reason in preferences/language&appearance/advanced/ I had a minimum font size set.

When this size is set to "None", which I guess is the default, the MyDSLWebStats pages look perfect.
(This is not affected by the setting about sites being allowed to choose fonts.)

[Ronski]

Just a reminder that a lot of users need to update their clocks this morning.

[tbailey2]

Yes and currently they are:

audiruss*** AvonHouse*** bigg*** billybudd*** chakobsa*** chouse*** derekh*** donnermike*** frogfoot10*** ip75*** loonylion*** NGDragon*** Pet0r*** Pet0r-2*** RDSSky*** spiralarms*** syserr0r*** UNCLEKNOBB***

The great majority of these are RPi users as always.

You can see these in the uploaders list at the bottom of the main window if you haven't hidden that list...

RPi Users
If you are running an RPi you may well need to reset the time on it as the change of time from BST to GMT/UTC and vice versa doesn't always work and also need to restart DSLStats as that will not pick up the change otherwise. The RPi command is:

sudo dpkg-reconfigure tzdata and select Europe and London

Leave it for 5 minutes after setting, then restart DSLStats

You'll get Duplicate Upload mails once you reset the clock (because you've already uploaded the current hour!) so either switch off MDWS uploads for an hour or have a cup of tea/coffee.

[tommy45]

There seems to be a small issue with the top pane not displaying the data /loading fully, i have tried reducing the number  and still, the top pane isn't loading, If only 1 pane selected it doesn't load , yesterday or the day before it would load minutes later, but the list of users didn't load at all , that list at the bottom is now loading fine,  using FF56.02

[tbailey2]

@tom34
I can't see any problems with the rate at which data was being delivered to you yesterday from looking at the server logs and my real time Dashboard. Everything on MDWS is logged and timed per user for all graphs and other data. It shows on average 110-180 milliseconds for you per graph, which is normal, to finish sending the data BUT it all then has to be processed LOCALLY by the browser at your end which is where the problem probably lies.

It certainly won't help hammering the server as you were with manual whole page refreshes every few seconds as eventually it will drop your connection for a while but this doesn't work as well as I like - I may have to improve that at this rate. Reloading the entire page takes a lot of resources as against the minute or so auto refreshes of data that takes place under normal operation and is how the system was designed to run locally along with intermittent page refreshes that do result from changing various settings

The remote part of the Google API was very slow at times yesterday and taking quite a while at times to respond to Ajax calls which will cause long delays in frame loading on the user side (and Google doesn't allow the code to be stored and called/run locally). Can't say I noticed what you are specifically  reporting though with the first pane/frame yesterday.

The very slow response a few days back did happen - a programme on the server went rogue and started eating all the memory. This meant that the database table caching of normally about 20Gb of data started being eroded and eventually the data was being fetched mostly off off the disk (which is an Enterprise class SSD now) and was very slow by comparison to normal as a result. Killing the prog and restarting it eventually got everything back to normal.

However, quite often what I DO notice is that a browser (any browser) will, for want of a better description, 'seize up' in stages while running MDWS and eventually stop responding. Repeated fast manual refreshing just makes it worse and the only cure is to exit the browser and start again. MDWS is very resource hungry as all the data processing to display what you see on the screen is performed by the browser locally and the more panes you have the quicker it will get to that stage. Five panes is about the maximum and higher than this is not sustainable from experiments I've made in the past..

Past making those comments there isn't much I can do but see if reloading (i.e exit/restart) the browser gets things back to normal.

[tommy45]

Well it has been working fine today must of been down to the web browser i use, sorry about that

[ktz392837]

Can anyone help with the meaning of the values in the XTR section? Eg what does B: 10 mean etc?  TIA

[tbailey2]

They were added just under a couple of years ago at the request of one of the resident Kitz experts at stats analysis - there is a discussion starting roughly here if you can get your head round it.

In there is also this on basically what they mean (originally from Kitz web pages) but not all these are displayed on MDWS as the data is not available

Reed Solomon Parameters

MSGc = Number of bytes in overhead channel message
K = Number of bytes in the DMT Frame
B = Number of bytes in the data frame
N = NFEC = Length of codeword         (N = K + R)
R = RFEC = RS check bytes / Amount of redundancy
S = Symbols per codeword
T = Number of dataframes in an OH subframe/ Data frames over sync bytes
Q = Number of RS codewords per DTU (g.inp)
V = Number of padding octets per DTU (g.inp)

Interleaving Parameters

I = Number of Interleaver branches / The interleaver block size in bytes.  Should be a sub-multiple of N
M = Incremental delay / Number of Mux Data Frames in FEC Data Frame/RScodeword
D = Interleave Depth      (D = M * I + 1)
L = LSYMB = Number of bits per symbol in the latency path / Number of bits in PMD data frame


Interleaving introduces a delay of M * I * (I-1)
Actual delay - ADSL  shown in ms =  [S x D]/4   
Actual delay - If retransmission is used this specifies the actual value of the time independent component of the delay due to retransmission only.

[nivek1612]

Minor

I may be the first thats gone through this sequence

Line had G.INP for months
Vectoring went on recently and user kwillers was displayed as "kwillers GV" on MyDSLWebStats - correct

Port moved today as there was fault on my current port

Vectoring still on but G.INP disabled, hope it goes back on soon or my ES will be huge :-)
Anyway userid is showing "kwillers g" which is correct for G.INP

No mention of the V for vectoring   

Telnet data

Stats recorded 06 Nov 2017 17:02:26

DSLAM/MSAN type:           BDCM:0xa48c / v0xa48c
Modem/router firmware:     AnnexA version - A2pv6F039g1.d24m
DSL mode:                  VDSL2 Profile 17a
Status:                    Showtime
Uptime:                     0 hour 32 min 53 sec
Resyncs:                   7 (since 18 Oct 2017 15:57:25)
         
            Downstream   Upstream
Line attenuation (dB):     19.1      0.0
Signal attenuation (dB):   Not monitored      
Connection speed (kbps):   74126      11722
SNR margin (dB):           7.6      6.7
Power (dBm):               13.5      7.6
Interleave depth:          1      1
INP:                       0      0
G.INP:                     Not enabled      Not enabled
Vectoring status:          1 (VECT_FULL)      

RSCorr/RS (%):             N/A      0.0004
RSUnCorr/RS (%):           N/A      0.0000
ES/hour:                   32.2      3.42

[tbailey2]

It's early days on vectoring and haven't seen this before.

There was an assumption that you couldn't have vectoring without G.INP when this was set up but as your router is reporting vectoring is on at the moment (vectoring is reported in real time from each upload) then that can't be right. I've altered it for now.