Kitz Forum
Broadband Related => Router Monitoring Software => Topic started by: roseway on June 27, 2013, 11:42:45 AM
-
This version adds an option to save the accumulated graph data to XML files, and restore it later for viewing.
Full list of changes since v3.41:
- added optional command line parameter "maximised" or "maximized"
- added miscellaneous option "Start program maximised"
- corrected error which put the upstream INP value on the wrong line in the Stats page
- corrected missing Status value with routers which report status and speed on the same line
- added option to save accumulated graph data as XML files, and to load the saved data back
into the program (for all graphs which have time on the X axis)
- fixed issue with repeated recording start with Windows version when starting automatically
- fixed issue with event log being saved in the wrong directory and with no filename extension
- corrected errors in autosaving on exit (hopefully)
http://dslstats.plainroad.me.uk
-
Thank you, Eric. Downloaded and testing is under way. :)
-
I look forward to your results. :)
-
Eric how often should the error averages be saved and reset? On restart of this new version it happened 3 times, 1st time after 24 minutes, then again 2 minutes later and again after a further 4 minutes, it has not happened now for about 30 minutes.
Stuart
-
I have installed it, and at same time have tried to set up where I want snapshots saved to but, as to be expected from YT, my plan does not work. ::) :D My idea was to save to
C:\Users\...\dslstats\dslstats32W-3.5\snapshots, but, though I have got rid of the unable to save warning, and a snapshot is seemingly saved, thre is nothing in my snapshots folder.
Once more :-[ what am I doing wrong? :-[
-
Thank you for this new version.
It seems you made some changes in the IP detection feature since v.3.31. Now the program stops working with an "unknown telnet error" if your server is not reachable (blocked by firewall), instead of only put an error to the log.
-
Eric how often should the error averages be saved and reset? On restart of this new version it happened 3 times, 1st time after 24 minutes, then again 2 minutes later and again after a further 4 minutes, it has not happened now for about 30 minutes.
Stuart
It should only happen when it needs to, as a result of something happening which causes the values reported by the router to be reset. I assume that your connection didn't re-sync at those times, so something isn't working quite right. I'll check it out.
-
Thank you for this new version.
It seems you made some changes in the IP detection feature since v.3.31. Now the program stops working with an "unknown telnet error" if your server is not reachable (blocked by firewall), instead of only put an error to the log.
Yes, I did make a change in that area, because the earlier method was a bit clumsy. On my system it quietly continues if the server isn't reachable, so I'll try to work out why its behaviour is different on some systems.
-
I have installed it, and at same time have tried to set up where I want snapshots saved to but, as to be expected from YT, my plan does not work. ::) :D My idea was to save to C:\Users\...\dslstats\dslstats32W-3.5\snapshots, but, though I have got rid of the unable to save warning, and a snapshot is seemingly saved, thre is nothing in my snapshots folder.
Once more :-[ what am I doing wrong? :-[
I can't ignore the possibility that it's a bug. Could you try a little test? Take a note of your login settings, then close down DSLstats. Move or rename dslstats.ini, then start up DSLstats again. Fill in the login details and start recording without changing any other configuration details. Check if manual snapshots are saved properly, then set up a couple of automatic snapshots, and check if those are saved correctly. (By default, snapshots will be saved in the same folder as dslstats.ini).
-
Given the attached FEC error graph, are the averages out by a factor of 10 ?
FEC Up 0 0 0 0
Down 584 35041 2102446 50458696
-
Given the attached FEC error graph, are the averages out by a factor of 10 ?
FEC Up 0 0 0 0
Down 584 35041 2102446 50458696
Do the averages cover the same period as the graph? If you were running DSLstats previously, the new version would still retain the accumulated error data from before, unless you explicitly reset the averages.
-
No it's not down to a bug, just inadequate moi :( :D
I'd got the path wrong and forgotten that I had selected a folder for each day's items.
-
That's quite all right. Thanks for letting me know. :)
-
I restarted DSLstats and reset the averages at 8PM and after about 20 mins I got
FEC Up 0 0 0 0
Down 10142 608521 36511284 876270848
The averages bear no relation to the graph.
Have just restarted again and the averages currently are tracking the graph
Are there plans to save the "Save/Resore XML" options in the ini file, along with the selected router model?
-
Kept an eye on the values for approx. 30mins and they appeared OK.
Just had another look, approx. 1.25 hrs after last restart and averages are way out.
FEC Up 0 0 0 0
Down 4159 249555 14973271 359358496
-
Kept an eye on the values for approx. 30mins and they appeared OK.
Just had another look, approx. 1.25 hrs after last restart and averages are way out.
FEC Up 0 0 0 0
Down 4159 249555 14973271 359358496
OK, thanks for that information. I'm not sure what's going wrong here, but your FEC rates are very high so I suspect that I'm mishandling large numbers somewhere.
Are there plans to save the "Save/Resore XML" options in the ini file, along with the selected router model?
Yes, I should certainly save the XML options in the ini file. I could also save the router model, but I'm not quite sure what purpose this would serve - I guess I could include it for the sake of completeness.
-
Should the errors average page self-save periodically in a twenty four hour cycle? Roseway, you and other more savvy than I am, may think not, but could it be useful to have some source to calculate if they peak at certain times.
-
Should the errors average page self-save periodically in a twenty four hour cycle? Roseway, you and other more savvy than I am, may think not, but could it be useful to have some source to calculate if they peak at certain times.
I don't think that the averages data is very useful as a means of finding out when the errors peak. By its nature, it's a set of averages over some time.
If you have the CRC and FEC graphs enabled, you can drag them back though time to see the peaks and troughs. It's a good idea to pause the recording while you do this, otherwise the graph will return to the present time when the next sample is taken. And you can save those graphs to an XML file at any time to get all the accumulated values in text form.
-
Something more learned ;D
OT: I know little ( that applies to HTML too). Why does each sample end with <DrawBlank>False</DrawBlank>?
-
If there are gaps in the graph, such as when the router re-syncs or the recording is paused, the DrawBlank parameter becomes true and as a result dotted lines are plotted on the graph.
-
Eric I'm not sure my FEC averages from my HG622 are correct, either that or I dont understand them!
Average error rates over a 24 hour period
24 hours starting 29 Jun 2013 07:56:23
Per second Per minute Per hour Per day
CRC Up 0 0 0 0
Down 0.01 0.66 39.5 949
FEC Up 3330 199801 11988030 287712704
Down 3330 199800 11987986 287711648
HEC Up 0 0 0 0
Down 0.05 3.21 192 4619
ES Up 0 0 0 0
Down 0 0.33 20.0 480
Stuart
-
The FEC down averages anomaly looks similar to mine. Tracked it down to a blip in the reporting of FEC upstream values from the router (DG834GT with DGTeam Rev. 1018) which is detected by DSLstats.
Have you a record of the RSCorr counter values at the time the averages were saved?
-
Have you a record of the RSCorr counter values at the time the averages were saved?
Not at the time I saved this data. However I wonder if these values in the HG622 are only reset on a POR of the router as it has been up 147 days now without a POR. The last DSL connect was 23 days ago.
Stuart
-
Out of interest what are you current averages and counter values?
A negative delta of the FEC values is enough to cause the symptom. This could be due to counter wrapround or firmware bug.
-
It seems you made some changes in the IP detection feature since v.3.31. Now the program stops working with an "unknown telnet error" if your server is not reachable (blocked by firewall), instead of only put an error to the log.
The "Unknown telnet error" isn't related to the IP address determination (which doesn't use telnet). It's a catchall error trap for telnet errors which aren't explicitly trapped. I've made a small change to the error trap code which will hopefully avoid a program freeze from this cause. I've also changed the error trapping for the IP address collection, so it should continue working if the server is unreachable.
-
Given the attached FEC error graph, are the averages out by a factor of 10 ?
FEC Up 0 0 0 0
Down 584 35041 2102446 50458696
Further to our discussions on this, I've rewritten the sections of code relating to CRC and FEC errors, to try to take into account all the possible ways in which these values can deviate from their normal continuous upward progression. I don't know how successful this has been, because I can't test all the variations, but it seems to be doing the right things insofar as I can test it.
-
Eric how often should the error averages be saved and reset? On restart of this new version it happened 3 times, 1st time after 24 minutes, then again 2 minutes later and again after a further 4 minutes, it has not happened now for about 30 minutes.
Stuart
Stuart,
Sorry that I didn't respond to this at the time. I've located one way in which this may happen, and fixed it. Now (hopefully) it should only save and reset the average errors when it actually needs to.
-
Hi Eric,
Unfortunately I'm still getting the access violation on Debian x64 (I thought it had gone but it hadn't)
Anything we can go through to try and look at this?
Thanks again :)
-
Hi Eric,
Unfortunately I'm still getting the access violation on Debian x64 (I thought it had gone but it hadn't)
Anything we can go through to try and look at this?
Thanks again :)
I'm sorry about this. Can you give any more information about what the program is doing when the access violation occurs? It's quite safe to press the OK button ("Press OK and risk losing data") when you get the error message, then you can check the event log to see if anything is recorded there.
-
Eric this isnt imperative, because I am sure you have more important things to do.... but is it possible to add an auto-resume from pause after 'x' time option.
This is because idiot me pauses dslstats to scroll back and look at the stats say over the past 12 hours.. then totally forgets to resume recording. I have done this so many times now :-[
---
Edit to show the latest kitz dumb blonde moment... Id scrolled back at 7am to see what had been happening overnight.. and it was only at 9.15 when I checked the state of the line again cause Im loosing sync.. that I realised none of it had been recorded. :(
Having looked at dsl stats again, I think it may be because when dslstats is on pause, the triangle 'play' button is in green.
I think my brain must automatically register green means that its recording, so it doesnt stand out to me that the program is in pause mode?
-
.. and another request... option to record attenuation please.
I know this isnt something that normally needs to be recorded, but atm my upstream atten seems to be jumping between 5 and 10 dB. Ive just put Routerstats on to record for now, so again no hurry, but a possible request to add to your list for future - thank you :flower:
-
Eric this isnt imperative, because I am sure you have more important things to do.... but is it possible to add an auto-resume from pause after 'x' time option.
This is because idiot me pauses dslstats to scroll back and look at the stats say over the past 12 hours.. then totally forgets to resume recording. I have done this so many times now :-[
---
Edit to show the latest kitz dumb blonde moment... Id scrolled back at 7am to see what had been happening overnight.. and it was only at 9.15 when I checked the state of the line again cause Im loosing sync.. that I realised none of it had been recorded. :(
Having looked at dsl stats again, I think it may be because when dslstats is on pause, the triangle 'play' button is in green.
I think my brain must automatically register green means that its recording, so it doesnt stand out to me that the program is in pause mode?
Dumb blonde? I don't think so.
I'm sure I can add that feature quite easily.
-
.. and another request... option to record attenuation please.
I know this isnt something that normally needs to be recorded, but atm my upstream atten seems to be jumping between 5 and 10 dB. Ive just put Routerstats on to record for now, so again no hurry, but a possible request to add to your list for future - thank you :flower:
Yes, I can do that. I don't know what you think, but it doesn't really seem worth graphing (although it would be easy enough to do). Perhaps a simple text record of times and values when it changes?
-
Hi Eric,
Unfortunately I'm still getting the access violation on Debian x64 (I thought it had gone but it hadn't)
Anything we can go through to try and look at this?
Thanks again :)
I'm sorry about this. Can you give any more information about what the program is doing when the access violation occurs? It's quite safe to press the OK button ("Press OK and risk losing data") when you get the error message, then you can check the event log to see if anything is recorded there.
Hi Eric,
I've checked the program log and all it says is that it's unable to retrieve stats. When I log back in and see the violation error, it's just like the program has frozen, and hasn't done anything since the violation. I click okay, and must restart the program before it'll start working again.
I'm using this on Debian Squeeze x64.
Thanks again for your help.
P.S I thought this had solved itself in 3.2, but when the server was restarted after updates, it happened again. It's still happening in 3.5.
-
Can you remind me what router you're using?
By the way, version 3.6 (just released) has some additional error trapping, so it's just possible that it will fix the problem, even though I haven't been able yet to identify the source.
-
Thank you Eric, that would be great
-
Can you remind me what router you're using?
By the way, version 3.6 (just released) has some additional error trapping, so it's just possible that it will fix the problem, even though I haven't been able yet to identify the source.
Hey,
It's a Netgear DGN2200. I'll give the new version a go :)