Kitz Forum
Broadband Related => Router Monitoring Software => Topic started by: roseway on September 14, 2015, 04:06:29 PM
-
Just two small changes:
- the state of the error averages 24-hour/Modem-uptime option is now saved and restored
- corrected inability to save and restore the command prefix 'adslctl'
http://www.s446074245.websitehome.co.uk/downloads.html
-
Thank you kind sir, working like a charm. :)
-
Thank you for confirming it. :)
-
Thats great Roseway as i use the Averages -> modem/router uptime averages all time on the PC as it's not switched on 24/7, and as soon as i execute DSLstats on this version it remembers that setting :)
-
Yes, I believe it was you who brought my attention to it. :)
-
This is something I had noticed before, but had forgotten about. I'm either misunderstanding what the log is saying or someone is telling porkies.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fs9.postimg.org%2Fkbczhdw73%2FBitloading.png&hash=7d2055e7d29d2789c37e227bc2dd9a0c719de48d)
However....
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fs16.postimg.org%2Fpg6k9x3h1%2FEvent_Log.png&hash=abcf4720c35818fdc5b453590cead1bf46733fd3)
Is DSLStats complaining because of the zero's in the lower tones or am I missing something obvious ( probably! )
-
I'll look into this, but I suspect that the bitloading data in your first snip is the result of an earlier successful data collection, and it's remained unchanged through the period of failures to collect the bitloading data. So the question I need to answer is why it's failing to collect the data.
-
How could I test that to prove your theory for you?
-
If the bitloading graph doesn't change from sample to sample, that would strongly suggest that the theory is right. Mine shows small changes after every sample. I watched yours on MDWS for a while, and I couldn't see any changes.
-
If the bitloading graph doesn't change from sample to sample, that would strongly suggest that the theory is right. Mine shows small changes after every sample. I watched yours on MDWS for a while, and I couldn't see any changes.
Don't forget it only uploads once an hour now (see time stated against graph).... If you use the Historic option, you can see it IS changing slightly every hour if you work backwards from the latest one using the left arrow....
-
Thanks Tony, I'd forgotten that. So for real time assessment you need to see if the DSLstats graph changes from sample to sample, and if no change corresponds with the "No bitloading data received" messages.
-
So for real time assessment you need to see if the DSLstats graph changes from sample to sample, and if no change corresponds with the "No bitloading data received" messages.
It would seem that is the case, I have looked at the Event Log and from midnight to now, 8.22am, the log reports no bit data received everytime it polls. There obviously is bitloading data as the graphs are showing.
It would seem then as no-one else has reported this that it's an issue with the the D7000 data. It works, it's just an anomaly so I wouldn't spend any time on this unless you want to.
I have attached the output of the command 'adslctl into --Bits'
If you do find yourself with time on your hands and nothing better to do and you feel like looking into it then maybe it will help you find the issue.
-
Thanks for that, but the question is: does the bitloading graph change at all between samples? If it does, then the event log entry is an anomaly; if it doesn't, then the event log entry is true, and DSLstats is unable to collect the bitloading data for some reason.
-
I will watch that page in DSLStats and see....
OK, I have taken four samples from DSLStats, doing a 'Select All' on the Bitloading page and saving that to a file. I've then fed that info into diffchecker.com and they are identical apart from a change in the Max Upstream and Downstream rates, so the bitloading is not changing. DSLStats reported No Bitloading data each time.
-
Eric
Can you direct him to where the upload bits file is stored and see what the file date is and if/when it changes. Seems to be managing to upload changes at 57 mins to the hour....
-
Eric
Can you direct him to where the upload bits file is stored and see what the file date is and if/when it changes. Seems to be managing to upload changes at 57 mins to the hour....
Thanks Tony, The MDWS upload files are saved in a directory called 'mydslwebstats' which is in the snapshot directory. The bitloading data is in a file called 'xxxx_live_Bits.log' where xxxx is your MDWS username. The file which is actually uploaded is the compressed version of that file, named 'xxxx_live_Bits_file.zip'.
@marjohn56: If the bitloading isn't changing, but the max upstream and downstream speeds reported in the same stream of data are changing, then the bitloading data is being refreshed after each sample, despite what the error message says. I need to think about this and try to work out how it can happen.
-
Hi Chaps,
Looked at the *_live_bits.log and that is changing every minute, so DSL stats is updating that file.
-
@marjohn56: Thank you for all your information. I think I've now traced the source of the problem and fixed it. I was misreading the end of the bitloading data from your modem because it has an extra line (there are two lines beginning with #). A rather foolish mistake on my part.
You can download the (hopefully) fixed version here: http://www.s446074245.websitehome.co.uk/files/dslstats.exe.zip (http://www.s446074245.websitehome.co.uk/files/dslstats.exe.zip) . This is just the executable, so unzip it and copy it to yourDSLstats folder to overwrite the present dslstats.exe (version 5.6.2).
-
Just two small changes:
- the state of the error averages 24-hour/Modem-uptime option is now saved and restored
- corrected inability to save and restore the command prefix 'adslctl'
http://www.s446074245.websitehome.co.uk/downloads.html
Thank you for the fixes Eric. :congrats:
Is it possible for the Monthly/Daily/per minute Traffic radio button under the Traffic tab to persist between restarts?
I'm using currently v5.6.3 and it reverts back to Daily.
-
@bmn: Yes, I'll include that in the next release.
-
@marjohn56: Thank you for all your information. I think I've now traced the source of the problem and fixed it. I was misreading the end of the bitloading data from your modem because it has an extra line (there are two lines beginning with #). A rather foolish mistake on my part.
You can download the (hopefully) fixed version here: http://www.s446074245.websitehome.co.uk/files/dslstats.exe.zip (http://www.s446074245.websitehome.co.uk/files/dslstats.exe.zip) . This is just the executable, so unzip it and copy it to yourDSLstats folder to overwrite the present dslstats.exe (version 5.6.2).
Thank you very much for that Eric, sadly I have to say the problem still exists. I know how you feel though, I've spent the last 4 hours trying to find a rather stupid bug and I'm going around in ever decreasing circles, wouldn't be so bad but it's a coouple of string compares and it's just not behaving...sigh.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fs30.postimg.org%2F7w8z4l31t%2FCapture.png&hash=884e55f9ffe02eaca23575ac8e515a57a59cd9f3)
-
:(
I think my next stage (if you're agreeable) is to produce a version with some extra log entries to help debugging. There are a few different places where this error message can occur, and I can identify which place it is and also get some extra information about what's happening.
-
Yes, that's fine by me, throw whatever you like at me.... within reason. :)
Regards,
Martin
P.S. I found my problem, forgot to remove the leading \x02 char first! :-[
-
I'm pleased that you found your problem. :)
-
I am using an HG612 and know that after 49 an a bit days that the what is reported in xdslcmd info --stats no-longer updates an that AS=avalable seconds and UAS=unavaleable seconds
I have a question which is where do you get the system uptime from as AS+UAS comes up 7 seconds short now after a period of 68 and a half days
-
The system uptime is obtained from the command "cat /proc/uptime". This is run via the telnet interface.
-
That explains why it differs from AS+UAS because it starts from the time the router is powered or re-booted.
I thought it might have relied on the underlying linux system boot time rather than from the point at which the xdsl hardware was starting the sync process which in my case accounts for 27 seconds worth of UAS time
-
Just had a invalid floating point error on the Rasperry Pi using 5.6.2 this causes the upload to MDWS to cease thats the first time on the RPi i have seen this it happen, it often happens on the PC.
reason for edit new info:
-
If you can find a repeatable sequence of events which lead to this error, then I should be able to trace it.
-
If you can find a repeatable sequence of events which lead to this error, then I should be able to trace it.
I'm not sure Roseway, what i did yesterday was to update firmware on the RPi and then update software in both cases the RPi was rebooted after each and then i installed 5.6.2.
I'll keep a close eye on this and if it happens again will hopefully get some debug data.
-
The 5.6.2 on RPi has gone down again with invalid floating point operation
Press ok to ignore and risk data corruption.
press Cancel to Kill the program
reason for edit have removed 5.6.2 on RPi and Installed 5.6 on RPi
-
Sorry NS, I didn't mean to ignore this, but I can't locate this problem unless I can reproduce it.
-
Eric I've been away a few days and when I came back today I went to look at DSLStats 5.6.2 and up popped a divide by zero error jut after the event log showed an auto save of graphs. Dont know for sure it is related but the only thing which seemed to be at the same time. I had done nothing except open the W7 desktop screen by moving the mouse as the screen saver had obviously kicked in.
Stuart
-
Thanks Stuart, I'll look at that possibility.
-
@roseway
Using 5.6.2 on raspberry pi, on the daily traffic graph, whilst hovering over a day the pop up appears; this popup reads along the lines
21 hh:nn:ss 2015
Upstream 195 MB......
Downstream.......
As can be seen the date is incorrect.
ps sorry could not take a screenie...a picture says a thousand words.
Ian
-
Good heavens, so it does. I'll check it out.