Kitz Forum
Broadband Related => Router Monitoring Software => Topic started by: Bald_Eagle1 on September 07, 2014, 10:46:58 AM
-
Please note:
Beta version 4.0 programs are available & can be downloaded/installed via the GUI if "Receive beta updates" is ticked in the "Help & About" tab.
These updates include some programming improvements & graphing 'enhancements'.
They are also needed to enable uploading of data (for registered users) to MyDSLWebStats online data store/graphical stats display.
-
For those that don't have an existing installation you can download V3 from Freeware Files (http://www.freewarefiles.com/HG612-Modem-Stats_program_84567.html). Then simply extract it to where you want it located and then run the GUI program located in the scripts folder. Once set up you can update as detailed above.
-
HG612 Stats appears to be working on Windows 10 :)
Installed V3 and fully updated to V4 and logging data, I'll leave it going overnight, although I won't test MyDSLWebStats uploads.
-
Chrysalis (or anyone)
I understand you might have had this problem At between 1-3AM each morning the HG612V4 stops logging. The Logs show 2 instances of the stats program running. It only started a few nights ago (see post). Tony suggested you had this ? Its running on a Server 2008R2 that is doing noting else. There are no backups or any log activity.
Perhaps you might have seen this, and found a resolution. Its strange it happens at the same time each early morning. I have the delay settings at 0 and 10 secs.
Also posted in Topic DSL WEB Stats
Tony
-
Update
Its happens every night at 0102 goes into 2 instance and starts logging again at 0301
I have enabled enhanced logging and I cant see any differences in the logs at the minutes before it goes into " 2 instances are running"
This started on Tuesday after the MS patches were applied to the Server2008R2 it runs on
There are no other services running on this server at all
I was around just before it started again at 0301 and I could see no issues on the server noting shows in the logs as happening at those times !
I guess I need the detailed logs looking at ?
Thanks in advance :'(
-
Hi Tony, I've had similar problems in the past and never really got to the bottom of it and to be honest I didn't look to far. If you look at my work stats over the last few weeks you can see it often misses a beat around 1am.
The only thing I can think of is to look at the scheduled task history, there is a bug in windows where the task can fire twice in quick succession. There is a patch available if this is the case.
-
Hi I looked at the task history and it doesn't seem to fire more than once at a time.
What I find Odd is it last for the same time 2 hours and then returns to normal. Thanks for the comment
Tony
-
My HG612 Stats fell over at 20:34 on the 17th as well.
Not sure what's going on - the GUI is still showing that set of data from the modem, although the task kicks off once per minute as it should.
Only a single instance at a time.
I think I may need an eagle eye cast over my logfiles.
-
My HG612 Stats fell over at 20:34 on the 17th as well.
Not sure what's going on - the GUI is still showing that set of data from the modem, although the task kicks off once per minute as it should.
Only a single instance at a time.
I think I may need an eagle eye cast over my logfiles.
I'm now back from my holidays, so feel free to post relevant log extracts for me to look at.
It MAY be a server issue.
My latest version (v 4.0.0.6) does include a Curl program timeout of 20 seconds to (hopefully) avoid any 'stuck' programs.
Which version of HG612_stats.exe are you using?
-
Version 4.0.0.6 is now available for download. Thanks BE1
-
A number of us don't log continuously. I find that in spite of this the program is generally quite happy and the output very useful. I think there is one issue that may however be possible fix some time.
The graph plots give the average error values but it is my impression that they display the total errors recorded each minute relative to total time interval and for intermittent logging give too low an error rate. I wondered if it might be possible to replace the total number of minutes with the sum of the errors per minute divided by the sample time interval i.e. the number of 1 minute samples collected. Apologies if my impressions are not well founded.
-
I wondered if it might be possible to replace the total number of minutes with the sum of the errors per minute divided by the sample time interval i.e. the number of 1 minute samples collected. Apologies if my impressions are not well founded.
I'm not quite sure what you are asking.
Could you perhaps give me an example of where you believe the error rate is too low when using your own stats?
I'm not a great fan of using averages as
a) doing so can mask peaks/troughs &
b) if the period is too small, it doesn't give a realistic indication of performance.
e.g. if my connection typically averages say 897 DS error seconds in a given 24 hour period, that would average out as 37.38 errors per hour or 0.62 per minute.
However, in the latest 12 hours of that given period, only 372 errors occurred.
Multiplying that by 2 would equate to only 744 errors per day, 31 per hour & 0.52 per minute
Using the latest 6 hours, 278 errors occurred.
Multiplied by 4, that would give 1112 errors per day, 46.33 per hour & 0.77 per minute.
This might help to explain how my graphing program calculates average error rates:-
Regardless of any time gaps in the data, when 24 hours is chosen, the latest 1440 samples are used
For 12 hours, the latest 720 samples are used
For 1 hour, the latest 60 samples are used.
So, lets say there was a gap of around 4 days between pausing & resuming logging.
The latest 1440 samples would still be used for a 1 day graph, but the start date would be clearly incorrect:-
You entered (or it was determined) a period of 1440 m
*** Using the specified log file ***:-
C:\HG612 Modem Stats with Spaces\Ongoing Stats\TEST\modem_stats.log
The whole log file contains 412740 rows
DSL_MODE = VDSL2
The graphs will be plotted using 1440 samples
From 21/10/2014 14:57 to 26/10/2014 15:58
i.e. 1 Day
Please wait......
* DS & US SNRM
** DS & US SYNC
*** CRC
**** FEC
***** DS HEC
***** US HEC
****** Up Time
******* DS RSCorr.................................
The number of errors per sample are indeed summed for the latest 1440 samples used for the graphs & divided by 24 for the hourly averages & divided by 1440 for the averages per minute.
That method can also be somewhat misleading when attempting to calculate averages etc.
The only realistic method appears to be to continue the logging 24/7, which will include peaks/troughs for day-time/night-time periods & any other periods where error counts can fluctuate due to external influences/interference etc.
-
Thanks for the helpful reply to my badly asked question. I asked after looking at my last 2 plots made in the last month or so. Looking again there are big gaps in those records when I have used unsupported modems. I just tried running a number of other different times and the answers are indeed sensible.
I will now be more cautious when choosing intervals on time.
-
i wondered if in some future version it might be possible enable plots like those here
http://forum.kitz.co.uk/index.php?topic=14598.msg275067#msg275067
Ideally they would be a daily total of ES in valid samples normalized so that a 24 hour figure is given. i.e. if only about x hours of data is available the total would be x24/x so that comparable figure is given each day. Generally when looking at long plots daily error numbers for all the error types should make trends clearer.
-
Is the attached DS ES graph from 1st January to 17th November anything like you mean?
-
I don't think so. It is plot of just the daily values (values like 500 on that plot) that I wondered about. Although trends can be seen in your example it is hard to see how daily totals may be varying and the daily total ought to might give a better view of the trends. The example from tbailey2 showed it with the daily ramp up but I think just the daily value would be fine. Ideally for those of us who don't run 24/7 it would as I said be an estimated daily value based on the up time.
-
Do you mean something like this attachment?
-
Yes :) just like that. Those value seem to be the main data input to the DLM. You could look at yours over a long period with a plot to of thst yipe see if you agree that is useful.
-
I knocked that graph together very quickly using Excel & data harvested at the same time each day from my 24/7 logs.
How regularly would you intend to grab the snapshot stats?
In my opinion, the big disadvantage of only grabbing snapshot stats on a daily basis is that you cannot see exactly where or when any errors occurred.
In order to graph the data when only logging sporadically, a log would still have to be maintained & maybe updated manually.
Logging 24/7 for 'problematic' lines seems (to me) to be the better option.
If you were to see a big increase in errors between one day & the next, you would have no real idea how severe the spike or sudden increase was & when it occurred & thus miss the chance to even try to track down what might have caused it.
I suppose it could act as some sort of indicator as to when start logging more regularly though.
A long time ago, I kept a manually updated log of IP Profile changes (copy attached), but it was the data in between the changes that reinforced the need for engineer visits (none of which was I ever charged for).
Having set up HG612 Modem Stats previously, you do already have the relevant software on your PC.
I could give you a batch file script & example log to demonstrate how to plot relevant data if you wished to manually maintain a log.
-
I haven't run HG612_stats for over a week, as I had to switch back the modem.
However, I was looking through my pfsense firewall logs and I noticed an entry that was trying to connect to my router on port 23. Using netstat I was able to see that the connection attempt was coming from the HG612_stats.exe so I looked at the windows task manager and processes from all users. Every minute or so the prog appears in the list and shortly afterwards it disappears again !
Any thoughts ?
-
Sounds like you still have a scheduled task running HG612_stats.exe.
-
Seems like you still have it running
You either need to delete the task or disable logging by clicking both Ongoing stats & Snapshot stats in the GUI.
The Task enabled button should then turn from green to red.
-
Thanks. That's it sorted.
I assumed closing the program and several reboots would have killed it!
Also, by default it doesn't show up in Task Manager under running tasks, unless you tick "show processes from all users"
Where is it actually being loaded? Is there a registry entry or something ?
-
Also, by default it doesn't show up in Task Manager under running tasks, unless you tick "show processes from all users"
Where is it actually being loaded? Is there a registry entry or something ?
There are intentionally no registry entries to be concerned about.
It simply runs from a scheduled task as a running process for a few seconds every minute.
To completely get rid of it (but why would you want to do that?), simply delete the scheduled task & delete any files/folders created when you set it up & that's it.
All trace of it ever existing erased, especially if you also emptied the Recycle bin).
-
In my opinion, the big disadvantage of only grabbing snapshot stats on a daily basis is that you cannot see exactly where or when any errors occurred.
My aim was to ask if that sort of daily display could easily be produced from the existing stored data base and whether you and others thought that extra plot might be useful. I did not intend to imply any extra or different sampling "just" an extra plot. My line has very spiky errors on it so any trends in a long plot are currently hidden in a forest of the spikes within each day. On yours it seems easier to see the trends. It may be best if I first try extracting and plotting the values from the current logs myself to see if they really help.
Power use has been my only issue with 24/7 logging. I have now got dslstats and MDWS working 24/7 via a rasberry pi but I do like using HG612 modem stats :) as well for long plots.
-
I think I understand what les is asking for. In view of the fact that we now know for sure that DLM monitors ES and SES and that it uses the daily total midnight to midnight. I can understand why some people may want them.
The one thought that occurs though.. When you ask HG612 stats to run graph PD, how would it affect daily totals if some time slots were missing. I cant think how to explain what I mean.. but when it calculates a day, does it use the last 1440 plots, rather than 0:00 to 23:59.
-
I think I understand what les is asking for. In view of the fact that we now know for sure that DLM monitors ES and SES and that it uses the daily total midnight to midnight. I can understand why some people may want them.
The one thought that occurs though.. When you ask HG612 stats to run graph PD, how would it affect daily totals if some time slots were missing. I cant think how to explain what I mean.. but when it calculates a day, does it use the last 1440 plots, rather than 0:00 to 23:59.
Yes, it does use the last 1440 samples, on the assumption that logging is running 24/7.
That can be misleading if logging only runs for a short while each day though.
e.g. If logging runs for exactly 6 hours each day, a 1 day plot would display all the latest 1440 samples, inserting gaps for the periods where logging wasn't running (see attached example).
The DS ES graph counts up all the delta values for the number of samples plotted & reports averages per minute, hour, day.
However, this data gives incorrect (too high) daily averages for 6 hours per day logging as it has only used a period from 18:00 to 23:59 each day (noisy periods).
The raw modem_stats.log does store cumulative values AND delta values for each sample, so I suppose I could get it to report the delta values per day, regardless of whether logging was 24/7 or not (assuming the stats included samples from the same time each day).
The other attached example shows 4 days of 24/7 logging & the total DS ES value reported for the period is correct.
The real DS ES data, using daily cumulative delta values, is:-
1140 between 28/11/14 & 29/11/14
1007 between 27/11/14 & 28/11/14
1091 between 26/11/14 & 27/11/14
1105 between 25/11/14 & 26/11/14
i.e. a total of 4343 for the 4 day period