Kitz Forum
Broadband Related => Router Monitoring Software => Topic started by: roseway on May 30, 2013, 10:46:09 AM
-
Changes since 3.2:
- added option to send custom CLI commands to the router at specified times
- removed the "First login" option from Special login (replaced by the above feature)
- added seconds value to snapshot filenames
- added a reminder on the normal Login page if Special login is enabled
- now records the user's IP address in the event log, and logs it again if it changes
- on the "Advanced tweaks" page, if Apply is pressed when no options are set, an advisory
message is displayed, and no action is taken
http://dslstats.plainroad.me.uk
-
Thank you, Eric. I shall now have a play . . . :)
-
Have fun :)
-
Up and running here now as well.
Stuart
-
Thanks :)
-
thanks Eric... :) (even though I cant use it just yet) hehe
-
Thanks for the new version Eric. :clap2:
:-[ I must be doing something wrong (again) ....
It's been running since ~midnight last night, and there is data in the Telnet tabs, but ...
the only tabs with any graphs in them are: Tones.bitlloading, Tones.SNR, QLN, Hlog, & Stats
Nothing in the error log except my IP address!!
What am I not doing? :(
-
It's been running since ~midnight last night, and there is data in the Telnet tabs, but ...
the only tabs with any graphs in them are: Tones.bitlloading, Tones.SNR, QLN, Hlog, & Stats
Are the graphs visible but with no data being plotted, or are the tabs visible but blank, or are the tabs not visible at all?
Nothing in the error log except my IP address!!
Logging your IP address in the event log is a new feature with this version.
-
It's been running since ~midnight last night, and there is data in the Telnet tabs, but ...
the only tabs with any graphs in them are: Tones.bitlloading, Tones.SNR, QLN, Hlog, & Stats
Are the graphs visible but with no data being plotted, or are the tabs visible but blank, or are the tabs not visible at all?
The former, I think. The tabs have the grids, but no line graphs on them, apart from the ones I have listed (in my case). Sorry to be a pain. :-[
Nothing in the error log except my IP address!!
Logging your IP address in the event log is a new feature with this version.
Yes, I knew. I was just observing that it was working! :)
-
You're not being a pain Colin :)
I'm going to be a bit of a pain myself, and ask some more questions:
- do you still see "Sampling" in red at the top every 30 seconds (or whatever time you've set)?
- does the bitloading graph get refreshed with each sample (small changes in the bitloading)?
- what router are you using?
-
You're not being a pain Colin :)
I am ... but...
- do you still see "Sampling" in red at the top every 30 seconds (or whatever time you've set)? No, which goes some way to explaining it! :-[
- does the bitloading graph get refreshed with each sample (small changes in the bitloading)? No, I don't think so. See the above. :-[
- what router are you using? 612
-
OK then, for some reason it's paused or stopped recording without logging that fact in the event log. I'll have to think about this one, but I suspect that if you close the program down and restart it, it will work normally.
-
OK then, for some reason it's paused or stopped recording without logging that fact in the event log. I'll have to think about this one, but I suspect that if you close the program down and restart it, it will work normally.
OK, I'm a bit more aware now ...
It's not sampling again after the first sample. Sampling interval is 60 secs. The missing graphs are still missing 5 mins after a reload of DSLstats. The Stats tab doesn't show any update in the time up - although that may be a red-herring.
Ready and available to do further diagnostics for you; or alternatively, I'll just leave you alone to think about it.
Sorry. :(
-
I'm a bit baffled at the moment. Could you copy your dslstats.ini to me please, so I can duplicate your setup and see if it brings anything to light.
-
Sent by PM.
It's still running, but I noticed the .ini says:
LastCheck=31/05/2013 13:21:38 ???
I would be happy to blame the windows environment, but 3.2 worked OK there, and all I've done personally is close it down, and overwritten the 3.2 versions of DSLstats.exe and Routers.Dat.
I know it'll be bugging the :flamer: out of you, but it's not causing me any issues, so there's no pressure. :)
-
Received it, thanks.
The "LastCheck" should be OK - it's the last time the program checked to see if an updated version is available, and it's remembered in the inifile. But I see that the date format is different to mine, so I will make sure that this isn't the issue (it shouldn't be).
-
I haven't been able to reproduce this error, but I'm fairly sure that I've located its source (in the clean-up code after it logs your IP address). I'll be uploading corrected versions later today.
-
I haven't been able to reproduce this error, but I'm fairly sure that I've located its source (in the clean-up code after it logs your IP address). I'll be uploading corrected versions later today.
Well done Eric. :clap2: You're a star! :dance:
-
:-[
Corrected (hopefully) version 3.31 now available for download.
http://dslstats.plainroad.me.uk (http://dslstats.plainroad.me.uk)
-
:thumbs: :dance: :clap2:
-
Just a very minor one from me, when I selected 'close button minimizes program' it still tries to close it :D
I don't know if you remember I was having crashes with one of the other versions of rs-ux, I'll let you know if I'm having any problems with this one :)
The other problem I had with the GUI cutting off half the text has been fixed.
Thanks :D
-
Just a very minor one from me, when I selected 'close button minimizes program' it still tries to close it
I guess you're talking about the window close button in the title bar? That one does close the program. The program Exit button (the one with a cross and a down arrow) is the one which is affected by the option "Exit button minimises program". It's possibly not an ideal arrangement, but as this is a cross-platform application I found that the behaviour of the window close button was different on different operating systems.
The other problem I had with the GUI cutting off half the text has been fixed.
Thanks for letting me know.
-
I shall mention something I have just observed, something that I'll describe as a quirk . . . :)
Having 'scrolled back in time' to review some earlier events, I decided to stop recording and close the utility. As I have the 'snapshot all active graphs upon closure' function configured, the graphs were duly created. On checking the contents of these last snapshot graphs I discovered that they were of the period 'back in time' and not of the current period.
My conclusion, therefore, is that the snapshot function will create an image of the currently displayed range regardless of the time-frame.
I wonder what happens if one is looking back into the past at the precise moment when an automagical snapshot is taken? It needs to be tested but is somewhat difficult to set-up . . . :-\
-
Yes, you accurately describe what happens: snapshots of the time-related graphs all show the view at the time of the snapshot. Obviously I need to retain that for manual snapshots, but I agree that auto snapshots should show the current time view. I'll correct this.
Sorry, I was wrong. :-[ Having checked the code, I see that auto snapshots are taken after a sample is processed, so all the time-related graphs should have returned to the current time view. So the situation you describe applies only to the shutdown situation. It's still a little quirk which needs correction.
-
Thank you for looking, Eric. If it is not something that can easily be 'taken care-of' within the code then just a mention in the documentation would be sufficient, I think. :)
-
Suggestion:
Can you give more options on the SNR chart clipping level
Currently just maximums of 20 and 10.
These are in effect the Y axis scaling commands available. So giving you a scale of either 0-20 or 0-10.
It would be nice to be able to expand the scale on this graph to suit.
If program had both more options on the top clipping levels and also a new bottom clip level options box as well this would be possible
So for instance in my particular case I could choose to look at the D/S SNR margin by itself (target SNRM is 3) I could say clip from 0-6 or if I wanted to look at the U/S margin I could clip from 10-20 (Interleaved for U/S - sync limited to 888 so I have a simply huge U/S SNR margin - 20 is only just enough!)
-
Can you give more options on the SNR chart clipping level
Currently just maximums of 20 and 10.
These are in effect the Y axis scaling commands available. So giving you a scale of either 0-20 or 0-10.
That's not quite how it works at present. The Y axis scaling is a function of the actual values plotted, so if you never see values higher than 10, then the graph will scale to a maximum of 10, regardless of the clipping level. The clipping level just acts as a maximum limit on the Y axis.
I agree that it can be improved, and I'll take a serious look at your suggestion.
-
Thinking about this some more, I propose to offer two different options for the SNRM graph. The present arrangement would be the default, but an alternative would be to disable autoscaling completely, and allow the user to set the max and min Y axis values directly. You'll be able to switch between the two views with a single click.
-
Sounds good to me.
Keep up the good work!
-
Thanks :)
-
Eric,
A quick question if you don't mind? :graduate:
Are the average errors for FEC errors cumulative?
Per second Per minute Per hour Per day
CRC Up 0 0.04 2.24 53.7
Down 0 0.01 0.56 13.4
FEC Up 0 0 0 0
Down 109896 6593761 395625632 9495014400
HEC Up 0 0 0 0
Down 0 0 0 0
ES Up 0 0.04 2.24 53.7
Down 0 0 0.19 4.47
-
Colin,
No, they're supposed to be the same as the other items on that page, i.e. the average rates over a period of up to 24 hours. The actual period which applies is shown above the table. The FEC per-minute values in the table should broadly correspond with the FEC per minute graph for the same period.
So the values you have are completely wrong, and it looks as though you've uncovered a bug. Can I ask that you press the button "Reset values" on that page, and see how the values develop when starting afresh?
-
So the values you have are completely wrong, and it looks as though you've uncovered a bug. Can I ask that you press the button "Reset values" on that page, and see how the values develop when starting afresh?
Sure. what would you like me to look out for?
FYI:
Since Link time = 22 hours 6 min 51 sec
FEC: 509819 189 <--- bad enough as it is!! :) ;)
CRC: 185 63
ES: 3 61
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
[EDIT] Not sure which way around you are calculating it Eric, but atm after 15mins, it seems that day (number)/24=hour, hour/60=mins, mins/60=secs, so these are self-consistent, and, it seems that the day number is not (yet at least) accumulating, in that the figure for 1 min's day sample (2034704) can be less than the previous one (2095496). ???
However, by the same token, the FEC graphs are currently showing minute-by-minute DS rates in the 300-10,000/min on the logarithmic scale. While the modem is reporting:
Since Link time = 22 hours 38 min 51 sec
FEC: 573967 194
-
I'd just like to see if it continues to report crazy values for average FECs, or if the values settle down to sensible levels. You'll need to run it for an hour or so after the reset to collect enough data to be meaningful.
-
OK, will do. Let you know later ....
-
Thanks :)
-
Sorry for the delay Eric. I was waiting to see if perhaps when the 24hr period rolled over the count wasn't reset properly or something. The good news is that it looks OK, i.e. it doesn't have astronomical figures anymore, just big ones. So maybe they really were as high as that - I do have other output from BE's programs that showed that FEC rates reached something like 10^7/min for about 12hrs on 09/06, and at the point I posted the question, DSL stats had been running for 4-5 days over that time.
I do still have a bit of a niggle at the back of my mind though, as somehow (it may just be me again) I can't see to reconcile the FEC/min graphs & averages with what is recorded in the telnet stats for e.g. the 15 min periods. Is there some way we can snapshot those 3 things together for you to see if I'm just barking again or not?
Cheers,Colin
-
Thanks for the information, Colin. I'll have a think about ways of reconciling those different views of the data, although it will involve some head scratching. :)
-
Thanks for the information, Colin. I'll have a think about ways of reconciling those different views of the data, although it will involve some head scratching. :)
I only meant - as a diagnostic - not as a facility, if I gave you the wrong impression. I'm not sure yet that anything's wrong, it just doesn't seem right. SoI thought if you could see your own telnetlog stats data, at the same time as snapshots of the FEC rate and averages, it might tell us if they are the same or not?
-
I'll see what I can do. I suppose that if I set the sampling period to 15 minutes, then the points plotted on the graph will correspond directly with 15-minute periods, and it may be possible to relate these values to the 15-minute periods reported in the telnet stats.
-
I'll see what I can do. I suppose that if I set the sampling period to 15 minutes, then the points plotted on the graph will correspond directly with 15-minute periods, and it may be possible to relate these values to the 15-minute periods reported in the telnet stats.
What a good idea - I'll try that myself! ;D
-
What a good idea - I'll try that myself!
Unfortunately you won't be able to with the version you've got, because the sampling period is limited to 10 minutes. This is a purely arbitrary limit, and I've set it higher for test purposes. I'll increase the limit in the next version.
-
I set my sampling period to 15 minutes, and by trial and error I roughly aligned the sample times with the 15 minute periods in the router stats. I read the downstream values on the FEC/minute graph and multiplied them 15, to compare with the values reported by the router in its 'Latest 15 minutes' section:
Downstream FEC rates
--------------------
Graph Stats
----- -----
Per minute Per 15 min Latest 15 min
---------- ---------- -------------
Time
10:35 6.0 90 89
10:50 28.5 427 449
11:05 16.0 240 215
11:20 4.0 60 56
11:35 8.0 120 124
11:50 9.0 135 134
12:05 15.0 225 227
12:20 21.5 322 321
Allowing for the fact that the 15 minute periods weren't perfectly aligned, there's very good correlation, so I'm reasonably confident that the graph is reporting correct values.
I'm still thinking about how best to validate the averages.
(Sorry that the formatting isn't very good)
-
Thanks Eric, that's pretty conclusive. :thumbs:
I guess it was harder for me to see that properly when the numbers were so big and the periods not sufficiently aligned. Apologies for doubting it, but this gives me more confidence to believe what I am seeing (but hoperfully nothing like 10^7/min again!)
:drink:
-
Thanks Colin. I'd still like to validate the averages, and I think I can do that, but it will take 24 hours. :)
-
Hi Roseway,
I'm still new to Linux and was wondering if you could help.
How would I go about getting dslstats to start automatically on boot?
I'm currently running debian.
Thanks :)
-
Hi xreyuk,
For a GUI program like this, autostarting a program is a desktop function, so the method depends on what desktop you use. With KDE it's easy - there's a folder <your home directory>/.kde/Autostart and all you have to do is put a link to the executable in that folder. I'm afraid I don't know about other desktops, but you might find the answer in the Debian user forums http://forums.debian.net/ .
-
Thanks Colin. I'd still like to validate the averages, and I think I can do that, but it will take 24 hours. :)
Actually, there's nothing much to validate here. The averages are calculated directly from the totals reported by the router at the start and end of the averaging period, and there's little scope for error in the normal running situation. A check over the last 24 hours confirmed that the averages were correct. Where errors could arise is when there's a re-sync or some other event which resets the totals. I think I've properly covered that situation (unless somebody reports otherwise).
-
Thanks Eric. :friends:
Just for my education, by the totals reported by the router at the start and end of the averaging period
are you referring to the 15min and 1day periods of the router stats, or e.g. a 24hr period from the start of DSLstats? :graduate:
-
I'm referring to the cumulative totals reported by the router:
Path 0
SF: 9890971 516400
SFErr: 950 566
RS: 573676243 1769321
RSCorr: 32667 1668
RSUnCorr: 8472 0
RSCorr = FEC
SFErr = CRC
etc.
While DSLstats is running it takes a note of these totals at 24-hour intervals and uses the difference between the totals at two successive 24-hour points to calculate the error rates for that period.
-
:thumbs: Thanks. :graduate:
-
Hi xreyuk,
For a GUI program like this, autostarting a program is a desktop function, so the method depends on what desktop you use. With KDE it's easy - there's a folder <your home directory>/.kde/Autostart and all you have to do is put a link to the executable in that folder. I'm afraid I don't know about other desktops, but you might find the answer in the Debian user forums http://forums.debian.net/ .
Thanks Eric.
I though it would have to be done in command line, but I've just added it to the GNOME startup applications.
-
Excellent.
-
Also I forgot to ask, I'm assuming a disconnect will show in the event log?
I also don't know if you remember the problem I was having with an access violation whilst this program was still rsux? I had the same problems with DSLStats, but changed the permissions on my config directory from 775 and 777 and this seems to have fixed it.
Thanks again!
-
Yes, there should be an entry in the event log when the connection drops. Normally it will say "No DSL connection" possibly more than once, depending on how long it takes to reconnect. If the connection drops while it's in the middle of sampling you may see other log messages.
Regarding the permissions on your config directory, it has to be writeable for the user running DSLstats. I'll add a check to warn the user if there's a problem with writing there.
-
I'm referring to the cumulative totals reported by the router:
Path 0
SF: 9890971 516400
SFErr: 950 566
RS: 573676243 1769321
RSCorr: 32667 1668
RSUnCorr: 8472 0
RSCorr = FEC
SFErr = CRC
etc.
While DSLstats is running it takes a note of these totals at 24-hour intervals and uses the difference between the totals at two successive 24-hour points to calculate the error rates for that period.
I have no idea how other modems/routers operate, but the HG612 does reset a number of its stats to zero once the integer limit has been reached, so that MAY just skew the use of averages over a 24 hour period.
I believe this is the HG612's limit before resetting stats (e.g. RSCorr/FEC errors) back to zero:-
2^32 or 4,294,967,296
That seems a huge cumulative total, but I have seen it exceeded within much less than 24 hours on a number of connections, particularly when a HG612 is connected to an ECI VDSL2 DSLAM.
-
Thanks, I wasn't aware of that. I'll check the code again to make sure that it's handled properly, but I think it is (if DSLstats sees a cumulative total value which is less than the previous value, it assumes that a reset has taken place, unless the value is exactly zero, in which case it's ignored as a missing sample).
(Later) I've checked the code, and I see that I've been storing these values in signed integers (maximum positive value 2^31) so there's a possibility of wrong values being reported when FEC rates are very high. I've now corrected this by storing the values in unsigned integers (maximum value 2^32). Apart from that, the program does handle resets of these values correctly, by saving the current error data as a text file and resetting the error data.
-
Not too sure if this is intentional/a feature whatever
My tones plot graph is constantly re-scaling back and fro between samples
So on one sample the LHS scale is up to 22 bits and the RH up to 66 SNR
Then at a next sample the scale swaps to 24 bits/72 SNR as a max on the scale (max SNR is actually 19
and so on - its not changing every single time methinks but is does quite a bit, so the whole graph is moving from sample to sample.
I only noticed this as I was looking for which tone was changing by spotting the jump and discovered I couldn't really do it as the entire graph jumped when it re-scaled the plot between samples.
-
It shouldn't rescale unless the data requires it to do so, so it looks as though you've uncovered a bug. Fairly recently I changed the scaling of that graph so that the SNR and the bitloading are properly proportional (3 dB SNR corresponds with 1 bit) and I may have got the rescaling slightly wrong at that time. I'll check it out.
-
I looked a bit closer and I think I know why its re-scaling.
My router has some sort of bug that it doesn't on some/regular occassions report the upstream SNR values - they are just zero.
This U/S SNR peak is the highest value - so it is the scale determinator.
So when the data returned DOES include the U/S SNR value then it re-scales it to 24 bits max/72 SNR
But when the data returned does NOT include the U/S SNR the max is SNR in the data is lower so it scales it lower to 22 bits/66 SNR.
Hence the back/fro swapping.
If I opt not to include the SNR value on the bitloading data graph then the bit loading data scaling does not change from graph to graph: - its always scaled upto 24 bits.
Ironically the now separate SNR/tone graph is scaled up to 60 SNR regardless of whether the U/S section is there or not!
The problem only occurs when they are both plotted on the bits/tone graph.
OK, so it is router bug causing the scaling to flip flop --------
-
Thanks for that information. I'll still try to handle it a bit more gracefully.
I'm not sure if the sometime absence of the upstream SNR is actually a router bug or intended behaviour. I have the same situation with my HG612 and I've tried to work out what causes the presence or absence of the upstream SNR. I get the impression that the upstream data only appears when the peak SNR exceeds 50 dB, which in my case isn't very often.
-
I believe this is the HG612's limit before resetting stats (e.g. RSCorr/FEC errors) back to zero:-
2^32 or 4,294,967,296
That seems a huge cumulative total, but I have seen it exceeded within much less than 24 hours on a number of connections, particularly when a HG612 is connected to an ECI VDSL2 DSLAM.
Like this you mean? :-\ :o
Looking back at the sorts of error rates I was getting around the time I asked Eric the question, I see that on 09/06 alone I had FEC error-rates of ~8*10^7/min for 10hrs.
i.e. 10*60*8*10^7 = 4,800,000,000 > 2^31 = 2,147,483,648 and even > 2^32 = 4,294,967,296 :-\
So, at the time, my line was doing things that no-one, not Eric or me, would have anticipated it might! :-[
-
My tones plot graph is constantly re-scaling back and fro between samples
So on one sample the LHS scale is up to 22 bits and the RH up to 66 SNR
Then at a next sample the scale swaps to 24 bits/72 SNR as a max on the scale (max SNR is actually 19
and so on - its not changing every single time methinks but is does quite a bit, so the whole graph is moving from sample to sample.
A follow-up on this: I've realised that when I changed the proportionality between the bits and the SNR on that graph I didn't change the autoscaling to match the new proportions. So the graph rescales unnecessarily when the SNR exceeds 50. I've now corrected this, and the next version shouldn't exhibit the irritating behaviour.