Kitz Forum

Broadband Related => Router Monitoring Software => Topic started by: roseway on April 05, 2018, 04:15:30 PM

Title: DSLstats v6.5 released
Post by: roseway on April 05, 2018, 04:15:30 PM
This is the first full release since the demise of MDWS. Changes since pre-release version 6.3.5:
Full list of changes at http://dslstats.me.uk/changelog.html (http://dslstats.me.uk/changelog.html)

Downloads from: http://dslstats.me.uk/downloads.html (http://dslstats.me.uk/downloads.html)
Title: Re: DSLstats v6.5 released
Post by: burakkucat on April 05, 2018, 04:51:04 PM
Thank you. Downloaded to The Cattery, extracted and executing.

Nothing odd or unexpected has, so far, been observed.  :)
Title: Re: DSLstats v6.5 released
Post by: burakkucat on April 05, 2018, 07:22:23 PM
Having been running this latest version of DSLstats for a few hours, I can now confirm that the format of the DataStore/Stats.log file is as expected.
Title: Re: DSLstats v6.5 released
Post by: roseway on April 05, 2018, 10:31:56 PM
Thank you.
Title: Re: DSLstats v6.5 released
Post by: g3uiss on April 06, 2018, 10:07:42 AM
Running here on server 2012 with no issues. Thanks for the development.

Tony
Title: Re: DSLstats v6.5 released
Post by: broadstairs on April 06, 2018, 10:26:21 AM
Running here on W7 seems fine, will check out thoroughly later when it has been running a few hours.

Stuart
Title: Re: DSLstats v6.5 released
Post by: toulouse on April 06, 2018, 11:57:55 AM
All's well here in sunny Somerset running on a Raspberry Pi Model B.

Well done Eric, and thanks for all the hard work that you are putting in to this extremely useful program.

toulouse
Title: Re: DSLstats v6.5 released
Post by: tiffy on April 06, 2018, 05:16:05 PM
v.6.5 now running on my 3 RPi's, one RPi 1B and two RPi Zero W's, all looking good, no apparent issues so far.

Many thanks for your continued support of the program, much appreciated.
Title: Re: DSLstats v6.5 released
Post by: roseway on April 06, 2018, 06:26:04 PM
Thank you all :)
Title: Re: DSLstats v6.5 released
Post by: Westie on April 06, 2018, 07:54:42 PM
Installed and running well on RPi Zero W. Data stored on attached USB HDD. Looking good.

Thank you Eric.  :)
Title: Re: DSLstats v6.5 released
Post by: kitz on April 07, 2018, 12:06:17 AM
Thank you :)
Title: Re: DSLstats v6.5 released
Post by: banger on April 07, 2018, 12:35:03 AM
Thanks Eric for all your effort, running smooth on a Win 10 box.
Title: Re: DSLstats v6.5 released
Post by: dgilbert2 on April 07, 2018, 07:16:38 AM
Many thanks for this latest release  :)

All running fine on my RPi3.

Thanks also for the "Total ES in the Day" data now shown. I noticed this value is not saved though as part of the Text file or Clipboard buttons?
Title: Re: DSLstats v6.5 released
Post by: roseway on April 07, 2018, 07:49:13 AM
Thanks for all the comments.

@dgilbert2: the "Total ES in the day" doesn't need to be saved because it's calculated from the ES/hour data (which is saved). But I agree about the clipboard, and I'll fix that.

[Edit] On reviewing this I realise that my answer wasn't really adequate. With the next release, both clipboard copies and snapshot copies of average errors will include the Total ES in the day line.
Title: Re: DSLstats v6.5 released
Post by: Westie on April 09, 2018, 12:48:41 AM
I am running DSLstats v6.5 on RPi, graphing all stats.

I noticed that all graphs (except ES per hour) showed 24 hours from the time the program started, so in order to get one full day showing on each graph I stopped recording, then restarted recording just after midnight. Most graphs were then redrawn with 00:00 as the first indicated x-value. However the graphs for "SRNM per Band" initially did not display at all until after the next sample was taken, at which point they retained the 'old' initial x-value (22:54), and continued to show the recorded values from 22:54 onwards. This was true both for downstream and upstream graphs.

I then rebooted the Pi, and all graphs restarted with the boot time as the first indicated x-value. After 2 minutes I stopped and restarted recording, and again all graphs except "SRNM per Band" adjusted to the new recording start time, but the latter continued with the boot time.

Is this a feature or a bug? In order to display the graphs starting at 00:00 each day, I will probably reboot again just after next midnight.

It's not an issue that needs to be addressed with any urgency, as the work-around is quite easy (if you're a night-owl like me)!  :)

Title: Re: DSLstats v6.5 released
Post by: roseway on April 09, 2018, 07:18:54 AM
@westie: feature or bug? I suppose it counts as a bug because it's an inconsistency. I'll take a look at it.

[Edit] This is corrected in the next version. This also applies to the traffic/minute graph, which has the same issue.
Title: Re: DSLstats v6.5 released
Post by: Westie on April 09, 2018, 09:33:56 AM
Thanks, Eric. I only reported it because I suspect you like to get get things 'right'. In my view it's a very low priority, because the work-around is so easy. DSLstats is much appreciated just as it is!  :)
Title: Re: DSLstats v6.5 released
Post by: Deathstar on April 09, 2018, 07:43:59 PM
Updated and running fine.

FTP to my Synology NAS also working

Cheers
Title: Re: DSLstats v6.5 released
Post by: roseway on April 09, 2018, 10:33:11 PM
Thank you.
Title: Re: DSLstats v6.5 released
Post by: emontes on April 10, 2018, 10:16:00 AM
Updated mine as well on a Raspberry PI, working fine. Thanks!
Title: Re: DSLstats v6.5 released
Post by: broadstairs on April 10, 2018, 05:40:33 PM
Prompted by chrysalis' problem I can see something funny but not synchronising. I stopped DSLStats and started it with the buttons at the top, did not close the program, and yes the graphs all got wiped but when I went to SNRM per Band graph all I got was white space where the graph should display and then a floating point error. Definitely something peculiar going on. This is 6.5 btw on my W7 system and using FTP if that matters. I'll do some more testing to try to clarify what happens.

Stuart

Edit: I've tried this now a few times and often I end up with the floating point error on a restart especially if I select the SNRM per band display. Program starts and seems to run fine if left alone but a stop with the red button and a start with the green one and something strange happens. So for now will only stop it if I intend to close the program.
Title: Re: DSLstats v6.5 released
Post by: roseway on April 10, 2018, 06:32:47 PM
Stuart,

Yes, following the report I checked it out. When recording is restarted after stopping, all the time-scrolling graphs should be reset so DSLstats behaves just like a new start. But two of the graphs (SNRM per band and traffic/minute) weren't being reset. I've now fixed this for the next release.

It's been like this for a long time, so I'm not sure why it's shown up now.
Title: Re: DSLstats v6.5 released
Post by: Westie on April 10, 2018, 08:25:45 PM
It's been like this for a long time, so I'm not sure why it's shown up now.

In my case it's because I used to use DSLstats to harvest the stats and upload them to MDWS, and I used MDWS to monitor what was happening to my line. Only since the demise of MDWS have I begun to appreciate (and use) the wealth of reporting facilities in DSLstats. Thanks for a great resource!

George
Title: Re: DSLstats v6.5 released
Post by: broadstairs on April 10, 2018, 09:50:39 PM
Stuart,

Yes, following the report I checked it out. When recording is restarted after stopping, all the time-scrolling graphs should be reset so DSLstats behaves just like a new start. But two of the graphs (SNRM per band and traffic/minute) weren't being reset. I've now fixed this for the next release.

It's been like this for a long time, so I'm not sure why it's shown up now.

I suspect that I am using it more than before with the demise of MDWS, and that I am having issues with SNRM right now, also I dont often stop/pause it but I decided to try after Chrysalis reported an issue after doing that, bad decision on my part to play with a working system - although it has now got another bug killed.

Thanks

Stuart
Title: Re: DSLstats v6.5 released
Post by: renluop on April 11, 2018, 10:41:48 AM
I have installed, though for my needs I don't need the latest bells and whistles.
It's been OK until this morning, when it has solidly reported, "unable to log in to router". I can see nothing to cause that. Other than a reinstall, can anyone think why or the cure?
Title: Re: DSLstats v6.5 released
Post by: roseway on April 11, 2018, 11:27:42 AM
Sorry to be a little pedantic, but I think the actual message is "Unable to login to modem/router". As far as I can see, the message you mentioned doesn't exist in the present version of DSLstats. It seems that DSLstats has lost contact with the modem, either because you're using WiFi or because the telnet interface of the modem has stopped functioning. In the latter case a reboot of the modem may be needed.
Title: Re: DSLstats v6.5 released
Post by: renluop on April 11, 2018, 12:25:58 PM
Sorry that finger fatigue led to a slovenly post.  ;D Unbelievably, at 11:34 all became well again. I had done nothing either yesterday or this morning to cause either failure or restoration.
To me Errors look odd; are they?
Code: [Select]
Average error rates for 11 Apr 2018

CRC erors per hour:  30.0 Down,  2.40 Up
FEC erors per hour:  0 Down,  0 Up
HEC erors per hour:  779 Down,  136 Up
ES per hour:  212 Down,  72.0 Up
SES per hour:  0 Down,  0 Up
Title: Re: DSLstats v6.5 released
Post by: j0hn on April 11, 2018, 12:31:52 PM
Looks odd to me. The ES is usually lower than CRC.
Title: Re: DSLstats v6.5 released
Post by: roseway on April 11, 2018, 01:15:49 PM
A very large number of HEC errors too, which is unusual. What modem is it now?
Title: Re: DSLstats v6.5 released
Post by: renluop on April 11, 2018, 01:35:25 PM
Billion 8800NL v1.

BTW here are yesterday's errors FWW.
Code: [Select]
Average error rates for 10 Apr 2018

CRC erors per hour:  34.4 Down,  10.9 Up
FEC erors per hour:  0 Down,  0 Up
HEC erors per hour:  102 Down,  11.9 Up
ES per hour:  27.8 Down,  8.09 Up
SES per hour:  0 Down,  0 Up
Title: Re: DSLstats v6.5 released
Post by: Chrysalis on April 23, 2018, 05:39:12 AM
I have got issues with dslstats just silently crashing, by silent I mean no error prompt, just closing down.  The event log even tho its set to save on exit, is wiped when this happens, so when its relaunched the first entries are when it is launched.  So I dont know how to diagnose this, Eric I can take this to pm if you prefer for further diagnosis.

This has seemed to start since I updated to 6.5 I have now reverted to 6.0.8 just to see if it still crashes, because I have also changed a few settings which may have triggered the problem.
Title: Re: DSLstats v6.5 released
Post by: roseway on April 23, 2018, 11:21:16 AM
I'm struggling to work out how to diagnose this. How soon does it crash after starting, and is it possible to relate the time of the crash to something happening at the time? Would it be possible to reverse your recent changes in the settings and see if it still crashes?

If you could give me a copy of your dslstats.ini file (with anything confidential removed) I can try to reproduce it on a Windows 8.1 system.
Title: Re: DSLstats v6.5 released
Post by: Chrysalis on April 23, 2018, 01:50:11 PM
I will send it, but I think I have already diagnosed it.
Title: Re: DSLstats v6.5 released
Post by: roseway on April 23, 2018, 04:35:52 PM
Thanks, I've received your PMs and responded.
Title: Re: DSLstats v6.5 released
Post by: pluto on May 09, 2018, 02:24:19 AM
.... I think I have already diagnosed it.

What were your conclusions? I have a similar issue – instant closure without warning the instant anything on the program's interface is touched :o

Windows 7, x64. Updated to 6.5.3 but this one is tricky. It sometimes doesn't happen until after several days of normal running.

But I also know, for a fact, that this problem goes back quite a long time – I guess I'm just a bit more focussed on it at the moment.
Title: Re: DSLstats v6.5 released
Post by: Chrysalis on May 09, 2018, 02:25:26 PM
It was when 2 programs were trying to access the files dslstats writes at the same time.

The older version was more elegant and threw up a warning prompt whilst the newer version just silently crashed.

Mine was nothing to do with touching the interface.
Title: Re: DSLstats v6.5 released
Post by: konrado5 on June 09, 2018, 01:55:08 AM
 I've noticed on netstat that dslstats opens many telnet connection at once. However I suspect Netgear DGND3700v2 doesn't like many connections.
Code: [Select]
09 Jun 2018 00:51:53 Event Log saved to Snapshots folder, then cleared
09 Jun 2018 00:53:09 Timeout while retrieving stats
09 Jun 2018 00:53:09 No stats received
09 Jun 2018 00:53:35 Timeout while retrieving stats
09 Jun 2018 00:53:35 No stats received
09 Jun 2018 00:53:51 Timeout while retrieving stats
09 Jun 2018 00:53:51 No stats received
09 Jun 2018 00:54:18 Timeout while retrieving stats
09 Jun 2018 00:54:18 No stats received
09 Jun 2018 00:56:00 Timeout while retrieving stats
09 Jun 2018 00:56:00 No stats received
09 Jun 2018 00:58:30 Timeout while retrieving stats
09 Jun 2018 00:58:30 No stats received
09 Jun 2018 01:04:19 Timeout while retrieving stats
09 Jun 2018 01:04:19 No stats received
09 Jun 2018 01:06:12 Timeout while retrieving stats
09 Jun 2018 01:06:12 No stats received
09 Jun 2018 01:09:50 Timeout while retrieving stats
09 Jun 2018 01:09:50 No stats received
09 Jun 2018 01:10:57 Timeout while retrieving stats
09 Jun 2018 01:10:57 No stats received
09 Jun 2018 01:13:15 Timeout while retrieving stats
09 Jun 2018 01:13:15 No stats received
09 Jun 2018 01:14:54 Timeout while retrieving stats
09 Jun 2018 01:14:54 No stats received
09 Jun 2018 01:20:29 Timeout while retrieving stats
09 Jun 2018 01:20:29 No stats received
09 Jun 2018 01:21:30 Timeout while retrieving stats
09 Jun 2018 01:21:30 No stats received
09 Jun 2018 01:21:55 Timeout while retrieving stats
09 Jun 2018 01:21:55 No stats received
09 Jun 2018 01:22:20 Timeout while retrieving stats
09 Jun 2018 01:22:20 No stats received
09 Jun 2018 01:25:08 Timeout while retrieving stats
09 Jun 2018 01:25:08 No stats received
09 Jun 2018 01:25:27 Timeout while retrieving stats
09 Jun 2018 01:25:27 No stats received
09 Jun 2018 01:25:43 Timeout while retrieving stats
09 Jun 2018 01:25:43 No stats received
09 Jun 2018 01:26:51 Timeout while retrieving stats
09 Jun 2018 01:26:51 No stats received
09 Jun 2018 01:27:37 Timeout while retrieving stats
09 Jun 2018 01:27:37 No stats received
09 Jun 2018 01:30:04 Timeout while retrieving stats
09 Jun 2018 01:30:04 No stats received
09 Jun 2018 01:30:20 Timeout while retrieving stats
09 Jun 2018 01:30:20 No stats received
09 Jun 2018 01:31:02 Timeout while retrieving stats
09 Jun 2018 01:31:02 No stats received
09 Jun 2018 01:33:02 Timeout while retrieving stats
09 Jun 2018 01:33:02 No stats received
09 Jun 2018 01:33:58 Timeout while retrieving stats
09 Jun 2018 01:33:58 No stats received
09 Jun 2018 01:34:50 Timeout while retrieving stats
09 Jun 2018 01:34:50 No stats received
09 Jun 2018 01:36:09 Timeout while retrieving stats
09 Jun 2018 01:36:09 No stats received
09 Jun 2018 01:38:07 Timeout while retrieving stats
09 Jun 2018 01:38:07 No stats received
09 Jun 2018 01:38:23 Timeout while retrieving stats
09 Jun 2018 01:38:23 No stats received
09 Jun 2018 01:39:16 Timeout while retrieving stats
09 Jun 2018 01:39:16 No stats received
09 Jun 2018 01:43:16 Timeout while retrieving stats
09 Jun 2018 01:43:16 No stats received
09 Jun 2018 01:45:18 Timeout while retrieving stats
09 Jun 2018 01:45:18 No stats received
09 Jun 2018 01:45:42 Timeout while retrieving stats
09 Jun 2018 01:45:42 No stats received
09 Jun 2018 01:46:14 Timeout while retrieving stats
09 Jun 2018 01:46:14 No stats received
09 Jun 2018 01:46:46 Timeout while retrieving stats
09 Jun 2018 01:46:46 No stats received
09 Jun 2018 01:47:13 Timeout while retrieving stats
09 Jun 2018 01:47:13 No stats received
09 Jun 2018 01:47:49 Timeout while retrieving stats
09 Jun 2018 01:47:49 No stats received
09 Jun 2018 01:48:06 Timeout while retrieving stats
09 Jun 2018 01:48:06 No stats received
09 Jun 2018 01:51:19 Timeout while retrieving stats
09 Jun 2018 01:51:19 No stats received
09 Jun 2018 01:52:34 Timeout while retrieving stats
09 Jun 2018 01:52:34 No stats received
09 Jun 2018 01:55:15 Timeout while retrieving stats
09 Jun 2018 01:55:15 No stats received
09 Jun 2018 01:58:13 Timeout while retrieving stats
09 Jun 2018 01:58:13 No stats received
09 Jun 2018 02:02:28 Timeout while retrieving stats
09 Jun 2018 02:02:28 No stats received
09 Jun 2018 02:03:10 Timeout while retrieving stats
09 Jun 2018 02:03:10 No stats received
09 Jun 2018 02:03:49 Timeout while retrieving stats
09 Jun 2018 02:03:49 No stats received
09 Jun 2018 02:04:46 Timeout while retrieving stats
09 Jun 2018 02:04:46 No stats received
09 Jun 2018 02:07:00 Timeout while retrieving stats
09 Jun 2018 02:07:00 No stats received
09 Jun 2018 02:07:21 Timeout while retrieving stats
09 Jun 2018 02:07:21 No stats received
09 Jun 2018 02:09:09 Timeout while retrieving stats
09 Jun 2018 02:09:09 No stats received
09 Jun 2018 02:12:28 Timeout while retrieving stats
09 Jun 2018 02:12:28 No stats received
09 Jun 2018 02:13:01 Timeout while retrieving stats
09 Jun 2018 02:13:01 No stats received
09 Jun 2018 02:13:18 Timeout while retrieving stats
09 Jun 2018 02:13:18 No stats received
09 Jun 2018 02:13:58 Timeout while retrieving stats
09 Jun 2018 02:13:58 No stats received
09 Jun 2018 02:14:37 Timeout while retrieving stats
09 Jun 2018 02:14:37 No stats received
09 Jun 2018 02:19:43 Timeout while retrieving stats
09 Jun 2018 02:19:43 No stats received
09 Jun 2018 02:20:08 Timeout while retrieving stats
09 Jun 2018 02:20:08 No stats received
09 Jun 2018 02:22:14 Timeout while retrieving stats
09 Jun 2018 02:22:14 No stats received
09 Jun 2018 02:23:04 Timeout while retrieving stats
09 Jun 2018 02:23:04 No stats received
09 Jun 2018 02:24:11 Timeout while retrieving stats
09 Jun 2018 02:24:11 No stats received
09 Jun 2018 02:24:20 Incorrect login name or password
09 Jun 2018 02:25:46 Timeout while retrieving stats
09 Jun 2018 02:25:46 No stats received
09 Jun 2018 02:26:17 Timeout while retrieving stats
09 Jun 2018 02:26:17 No stats received
09 Jun 2018 02:26:49 Timeout while retrieving stats
09 Jun 2018 02:26:49 No stats received
09 Jun 2018 02:27:35 Timeout while retrieving stats
09 Jun 2018 02:27:35 No stats received
09 Jun 2018 02:28:00 Timeout while retrieving stats
09 Jun 2018 02:28:00 No stats received
09 Jun 2018 02:31:04 Timeout while retrieving stats
09 Jun 2018 02:31:04 No stats received
09 Jun 2018 02:36:22 Timeout while retrieving stats
09 Jun 2018 02:36:22 No stats received
09 Jun 2018 02:37:15 Timeout while retrieving stats
09 Jun 2018 02:37:15 No stats received
09 Jun 2018 02:39:40 Timeout while retrieving stats
09 Jun 2018 02:39:40 No stats received
09 Jun 2018 02:40:53 Timeout while retrieving stats
09 Jun 2018 02:40:53 No stats received
09 Jun 2018 02:43:42 Timeout while retrieving stats
09 Jun 2018 02:43:42 No stats received
09 Jun 2018 02:44:04 Timeout while retrieving stats
09 Jun 2018 02:44:04 No stats received
09 Jun 2018 02:45:31 Timeout while retrieving stats
09 Jun 2018 02:45:31 No stats received
09 Jun 2018 02:46:20 Timeout while retrieving stats
09 Jun 2018 02:46:20 No stats received
09 Jun 2018 02:51:00 Timeout while retrieving stats
09 Jun 2018 02:51:00 No stats received
09 Jun 2018 02:53:44 Timeout while retrieving stats
09 Jun 2018 02:53:44 No stats received

here any possibility  to change the DSLAM code in order to use one telnet connection?
Title: Re: DSLstats v6.5 released
Post by: j0hn on June 09, 2018, 03:09:50 AM
It does only use 1 telnet connection.

It opens telnet session.
It gathers the specified stats.
It closes the telnet session.

1 min later....

It opens telnet session.
It gathers the specified stats.
It closes the telnet session.

Your problem is your sample time is only about 15 seconds.
With older/slower modems this is too much.
Try increasing the sample time.
60 seconds is more than sufficient.
Title: Re: DSLstats v6.5 released
Post by: konrado5 on June 09, 2018, 05:14:42 PM
I sample stats every second but I haven't had this problem on D-Link DSL-2740B. Perhaps it would be good solution to open telnet session without closing it.
Title: Re: DSLstats v6.5 released
Post by: roseway on June 09, 2018, 06:39:44 PM
It's been discussed before, and I'm not going to do that. In my opinion, sampling every second is not sensible or helpful.

Title: Re: DSLstats v6.5 released
Post by: kitz on June 09, 2018, 09:47:04 PM
I've noticed on netstat that dslstats opens many telnet connection at once.

I sample stats every second.

1 second isn't sufficient time to gather stats even on the fastest systems.  I'm not surprised it shows as having multiple sessions open.   The next session(s) will be starting before the previous have finished.

Quote
Perhaps it would be good solution to open telnet session without closing it.

No because there are several modems where it could become a problem because they only allow one open telnet session at a time.   
Some people use both DSLstats and HG612 stats and many times in the past it has caused issues if they both have telnet sessions open at the same time - which is why Eric had to code "HG612 stat compatibility" into DSLstats so that DSLstats' session would be finished before HG612 modem stats would open a session.  This is ignoring any manual telnet sessions where a user is logging in to change configs etc.   

Although I'm currently using a Zyxel VMG8324 on f/w that will allow more than one concurrent session,  I also have a few other modems which wont - such as a VMG8924 (which I should really put on because of the wifi).    How would it be fair to implement something which would cause problems for other modems just so that you can run every 1 second.    As mentioned by J0hn, every minute is more than sufficient to get a good overview of line health.
Title: Re: DSLstats v6.5 released
Post by: konrado5 on June 09, 2018, 10:49:07 PM
1 second isn't sufficient time to gather stats even on the fastest systems.
But on D-Link DSL-2740B it doesn't cause any problems. It causes problems on Netgear DGND3700v2.   
Quote
No because there are several modems where it could become a problem because they only allow one open telnet session at a time.
Why couldn't dslstats use the same telnet session  all the time? I understand it would cause problems if refresh rate is 30s (somebody couldn't log to telnet in this situation). But it would be helpful at 1s refresh rate.
Title: Re: DSLstats v6.5 released
Post by: burakkucat on June 10, 2018, 12:05:00 AM
Please stop your unreasonable behaviour right now.

DSLstats will not be modified to suit your requirements. I suggest that you write you own utility, then you can have every feature doing exactly what you require.

This thread is now locked.
Title: Re: DSLstats v6.5 released
Post by: konrado5 on June 10, 2018, 04:20:29 PM
I don't understand why my behaviour is unreasonable. I merely explain why kitz argumentation is unconvincing for me. Many people proposed additional features to DSLStats.
Title: Re: DSLstats v6.5 released
Post by: kitz on June 10, 2018, 06:52:06 PM
Quote
I merely explain why kitz argumentation is unconvincing for me.

Because if implemented in the way you are requesting, it would cause problems for those who have modems which only allow 1 telnet session at a time of which there are quite a few.

As I explained that some of us run both DSLstats and HG612modem stats.   Eric had to specifically code something so that DSLstats session closed before HG612 stats ran..  otherwise they clashed and caused either DSLstats for HG612 stats to crash. Keeping the session open would mean that those who run HG612 stats would see frequent crashes and have no stats recorded.     

When it takes circa 7 seconds (perhaps longer on slower systems) to login and gather stats, then it is no wonder you're seeing multiple sessions if you are running every 1 second.

Quote
Many people proposed additional features to DSLStats.

...  and Eric will usually do his best to add the feature if it is beneficial for all. 

What you are requesting is unreasonable.   I have no idea how many people run HG612 modem stats, nor how many people use DSLstats but for the later you are probably talking multiple hundreds of users.   
For the sake of you being able to run stats once per second..  there's a high probability that it would crash stats for a heck of a lot of other users.  :(
Stats once per min is sufficient to gauge line health. 
Title: Re: DSLstats v6.5 released
Post by: johnson on June 10, 2018, 07:06:52 PM
Why in the world do you even want to try and gather stats once per second? The modem itself doesnt update that fast in my experience.
Title: Re: DSLstats v6.5 released
Post by: ejs on June 10, 2018, 07:49:55 PM
If you've got a modem that normally only allows a single telnet session, and you've got the full root shell level access (which you usually do if you've got the ability to run the stats collecting commands), then you could probably enable additional telnet sessions by running extra instances of telnetd, each one listening on a different port.
Title: Re: DSLstats v6.5 released
Post by: konrado5 on June 10, 2018, 09:17:20 PM
Because if implemented in the way you are requesting, it would cause problems for those who have modems which only allow 1 telnet session at a time of which there are quite a few.
Perhaps I have explained it not clear enough but I don't want to change default setting on 1 telnet session at a time. I want merely additional feature which would be perhaps recommended on very fast sampling (sampling every second or every 2 seconds). Everybody could enable or disable this option.
Title: Re: DSLstats v6.5 released
Post by: jelv on June 10, 2018, 09:27:07 PM
How much did it cost you to buy/register DSLstats in the first place? How much are you paying per month/year for maintenance?

If like the rest of us the answer is nothing you just have to accept whatever the author of the software offers. Nobody is forcing you to use it and if there is something about it you don't like you have four choices:
Title: Re: DSLstats v6.5 released
Post by: konrado5 on June 10, 2018, 09:34:25 PM
I also not forcing roseway to change this code. I merely explain why I think it could be added.
Title: Re: DSLstats v6.5 released
Post by: Chrysalis on June 10, 2018, 10:26:58 PM
Please understand konrado5 its free software, Eric develops it unpaid and he has the final say on whats implemented, he told you no which should be the end of the matter, I personally agree with his reasoning.  Adding every second support is the sort of thing that will cause problems with crashing modems, incomplete stats etc.
Title: Re: DSLstats v6.5 released
Post by: johnson on June 10, 2018, 10:27:11 PM
I also not forcing roseway to change this code. I merely explain why I think it could be added.

You still have not explained what aspect of the statistics you think are not being captured with the current sample rate. If you want a new feature, then at least give a compelling reason for it if you are not willing to implement it yourself. What do you think you could capture at 1 sample a second that is missed at one every 30? All errors accumulate and are still read, do you think you have some sub 30s noise bursts that you are aligning perfectly with to not sample? It makes no sense.
Title: Re: DSLstats v6.5 released
Post by: konrado5 on June 10, 2018, 10:35:36 PM
I have am radio enabled and I notice that I see new CRC error when I hear crack on the radio. Moreover, capturing at 1 sample a second is already feature of DSLStats. I merely give tips how this feature could work better.
Title: Re: DSLstats v6.5 released
Post by: johnson on June 10, 2018, 10:39:18 PM
So you are going on CRCs... they could be sampled once every 10 minutes and they would still be included. Why does 1 second updating matter to you?
Title: Re: DSLstats v6.5 released
Post by: konrado5 on June 10, 2018, 10:43:09 PM
So you are going on CRCs... they could be sampled once every 10 minutes and they would still be included. Why does 1 second updating matter to you?
Because I have CRC errors which I hear on AM radio and CRC errors which I don't hear on AM radio. If crc errors are sampled every second I know if crack on AM radion in some second gives CRC error. Furthermore, rarely I have single second lowering of SNR margin.
Title: Re: DSLstats v6.5 released
Post by: johnson on June 10, 2018, 10:46:25 PM
If you are so inclined I suggest you get set up with a software defined radio and go chase your noise sources.

Having the CRCs show up in your DSLstats graphs real time isnt giving you any new information, and would be of little use to others even in the same situation.
Title: Re: DSLstats v6.5 released
Post by: roseway on June 10, 2018, 10:48:25 PM
Konrado, my answer is No, for several reasons mentioned above.
Title: Re: DSLstats v6.5 released
Post by: konrado5 on June 10, 2018, 10:51:38 PM
Konrado, my answer is No, for several reasons mentioned above.
Perhaps I have explained it not clear enough but I don't want to change default setting on 1 telnet session at a time. I want merely additional feature which would be perhaps recommended on very fast sampling (sampling every second or every 2 seconds). Everybody could enable or disable this option.
Title: Re: DSLstats v6.5 released
Post by: johnson on June 10, 2018, 11:10:37 PM
Perhaps I have explained it not clear enough but I don't want to change default setting on 1 telnet session at a time. I want merely additional feature which would be perhaps recommended on very fast sampling (sampling every second or every 2 seconds). Everybody could enable or disable this option.

If you want this then write it yourself. From experience most modems/routers take seconds in total from telnet login to cmd output to close. If you think you have a special case that requires fast sampling then write it and demonstrate its worth, there are many languages with telnet clients that are easy to use. If you only sample a few things, no long lists like SNR per tone etc, fast sampling should be possible.

But again, can you tell me why this would be useful? You say:
Quote
Because I have CRC errors which I hear on AM radio and CRC errors which I don't hear on AM radio.

Where does differentiating between the two get you? Does it let you find the noise source better? I'm lost.
Title: Re: DSLstats v6.5 released
Post by: jelv on June 10, 2018, 11:56:57 PM
konrado5What do you not understand? Roseway has said NO - that is the end of it - give up!
On second thoughts - keep going and arguing - the result will be a permanent ban and the rest of us will no longer have to put up with your selfish requests!
Title: Re: DSLstats v6.5 released
Post by: konrado5 on June 11, 2018, 01:33:20 AM
I haven't got selfish request. I am merely not convinced by kitz argumentation. I explained reasons.
Title: Re: DSLstats v6.5 released
Post by: kitz on June 11, 2018, 02:41:49 AM
I haven't got selfish request. I am merely not convinced by kitz argumentation. I explained reasons.

 :o

I thought the reasons were quite clear.   I explained reasons why. 

Quote
but I don't want to change default setting on 1 telnet session at a time.

The one telnet session at a time is a restriction of many modems and why Eric has to close the telnet session rather than keep it open once the stats have been obtained. 

Every second is ridiculous because it takes longer than that to gather stats from the modem.    You are asking Eric to develop a feature that changes the structure of his code just for you, because I cannot see anyone else gathering stats more frequently than every minute*.
It is selfish because its putting pressure on Eric who already puts a heck of a lot of time into developing what is without doubt the best line stat monitoring app available.   Fair enough you can request a feature, but if he says no then he will have a valid reason for doing so.   

TBF you are very close to pushing the button.   Eric has said NO.  That's the final word.



*I think there may have been one person who had it running about every 10-15 seconds, and he was OCD about his stats.   He ended up getting banned from here and other forums.
Title: Re: DSLstats v6.5 released
Post by: konrado5 on June 11, 2018, 03:00:40 AM
Quote from: kitz
The one telnet session at a time is a restriction of many modems and why Eric has to close the telnet session rather than keep it open once the stats have been obtained. 
I don't understand. It is not obstacle to add additional function which somebody could enable ("use one telnet session").
Title: Re: DSLstats v6.5 released
Post by: roseway on June 11, 2018, 06:40:00 AM
This discussion is at an end. One more word from you on this subject and you will no longer be a member of this forum.
Title: Re: DSLstats v6.5 released
Post by: toulouse on June 11, 2018, 07:32:50 AM
Well said Eric
Title: Re: DSLstats v6.5 released
Post by: 99den on August 24, 2018, 01:14:46 AM
Hello,

at first thanks for this awesome tool and especially for the x-platform support!! (mainly Linux since I am an Arch user)

I have this tool (v6.5) running now for some weeks and I found some bugs and issues. I hope I am allowed to report some of them in this thread.


You are asking Eric to develop a feature that changes the structure of his code just for you, because I cannot see anyone else gathering stats more frequently than every minute*.
[...]
*I think there may have been one person who had it running about every 10-15 seconds, and he was OCD about his stats.   He ended up getting banned from here and other forums.

*Well I gather information from my router/modem every 5 seconds. :P
Mainly because sometimes (but almost daily and several times a day) I have a disturber on my line which drains my SNRM with different intensity (which can change nearly every second) and imo a granularity of 1m is too low (but I never tested it, maybe it works quite well). But imo going lower than 5s has only little to no benefit.
But I have no plans on getting banned here.

Cheers
Title: Re: DSLstats v6.5 released
Post by: snadge on January 01, 2019, 02:22:03 PM
Hi

Iam trying to use DSL stats 6.5 on  a Zyxell VMG 8924-B10A but upon login it says "UNABLE TO LOG IN TO ROUTER"...?  I got this router as I was told it had the Telnet unlocked and could access the stats, Im just hoping this one isnt locked out... or its going back on ebay

can anyone help?

thanks
Title: Re: DSLstats v6.5 released
Post by: roseway on January 01, 2019, 02:51:55 PM
Can you log into the device manually by telnet? If you're not familiar with this you can install PuTTY on your machine and use that.

Depending on what firmware version the router has, it's quite likely that only a single telnet access is allowed at any one time. This will only be a problem if you have two devices trying to log in together.
Title: Re: DSLstats v6.5 released
Post by: snadge on January 01, 2019, 02:59:38 PM
Can you log into the device manually by telnet? If you're not familiar with this you can install PuTTY on your machine and use that.

Depending on what firmware version the router has, it's quite likely that only a single telnet access is allowed at any one time. This will only be a problem if you have two devices trying to log in together.

ive fixed it Eric thanks :)

it was TELNET wasnt enable in the zyxell webGUI - the program has come on leaps and bounds since I last used it about 4.5 years ago :) love the email/alert feature
Title: Re: DSLstats v6.5 released
Post by: m48t02 on March 02, 2019, 01:17:40 AM
Hi guys,

This question is directed to roseway - excellent application.

I am running 64bit linux DSLstats (6.5) headlessly within Xvfb on a system without a display (./dslstats minimised startrecording), and it's very stable. I am however not able to interact with the GUI, so am directly editing the ~/.dslstats/dslstats.ini file and having to kill the running process and restart DSLstats. In doing so I am loosing whatever data has been cached within the process during the stop/start process.

My question is therefore, is it possible to send an ANSI C signal to the DSLstats process PID after editing the .ini file, in order for it to reread the config file without the need to restart the process  SIGHUP, SIGUSR1 etc?

I have tried the obvious, but DSLstats doesn't currently seem able to handle the signal, and quits.

If not currently implemented, could it possibly be a feature request?

I know this application is used on Raspberry Pi's and I'm sure this would remove the need for VNC etc. and provide an alternate method to GUI administration.

SIGUSR1 to pause, SIGUSR2 to read config and start:  e.g. kill -USR1 <pid> ; kill -USR2 <pid>


Many thanks for considering.
Title: Re: DSLstats v6.5 released
Post by: roseway on March 02, 2019, 10:52:50 AM
DSLstats automatically saves its configuration and error data on shutdown. If you've already worked out what manual changes you want to make to make to the ini file, then shutting down, editing the ini file and restarting would only take a minute or so. Unless I'm failing to understand what you're hoping to achieve.

I'm afraid I'm not going to be able to make significant changes to DSLstats in the forseeable future because of an eyesight problem which is limiting the time I can spend staring at a screen.
Title: Re: DSLstats v6.5 released
Post by: jelv on March 02, 2019, 11:12:24 AM
I don't think he has an issue doing what you said, but...

In doing so I am loosing whatever data has been cached within the process during the stop/start process.

I think he's asking for a clean way to do the shutdown when running headlessly.
Title: Re: DSLstats v6.5 released
Post by: m48t02 on March 02, 2019, 02:46:04 PM
DSLstats automatically saves its configuration and error data on shutdown. If you've already worked out what manual changes you want to make to make to the ini file, then shutting down, editing the ini file and restarting would only take a minute or so. Unless I'm failing to understand what you're hoping to achieve.

Many thanks for the feedback, it's probably my not using dslstats correctly. But if running from the GUI, I can store graph data to XML on exit, and then restore the graph data when it is restarted. I currently only snapshot every 24 hours to get daily graphs in single image files for upload to remote server, and if I headlessly stop the process midday - I loose the first 12hrs of data upon restart - I can't restore from XML while headless?

I'm sure when I have all the settings correct this will be less of an issue, as I won't be restarting. I was hoping I could trigger the app to re-read its config without having to shut it down and loose the data.

Am I missing a trick here?

Fully understand on the development, and many thanks for the existing program :)

Cheers
Title: Re: DSLstats v6.5 released
Post by: m48t02 on March 02, 2019, 03:49:57 PM
I don't think he has an issue doing what you said, but...

I think he's asking for a clean way to do the shutdown when running headlessly.

I run dslstats in 'screen' under linux, so the shutdown is fine using CTRL-C, program terminates correctly and cleanly. It's the data loss in performing a restart that I am trying to solve....

Thanks again.
Title: Re: DSLstats v6.5 released
Post by: Alucidnation on March 13, 2019, 07:18:50 PM
I know this might be the wrong question, but is there any version for OSX or one in the pipeline?

I only have a windows laptop at the moment, but have a MacMini right next to my modem.

Thanks.

:)
Title: Re: DSLstats v6.5 released
Post by: roseway on March 13, 2019, 10:29:39 PM
I understand from some other users that the Windows version of DSLstats can be run on an OSX system using Wine. I'm afraid that it's not going to be possible to make a native OSX version.
Title: Re: DSLstats v6.5 released
Post by: Alucidnation on March 13, 2019, 10:50:28 PM
Thanks Eric.

Since posting, i have managed to set up my ageing Windows laptop with permanent power and a "do nothing with the lid closed" setting so that it can run with the lid shut.

 :)
Title: Re: DSLstats v6.5 released
Post by: Alucidnation on March 15, 2019, 06:42:51 AM
Had this running for a couple of days but for some reason, each morning i get up to check it, and it's shut down overnight.

Laptop still running but the app has closed itself.

Is there a setting somewhere that needs unticking or ticking?

Thanks
 :)
Title: Re: DSLstats v6.5 released
Post by: roseway on March 15, 2019, 06:51:13 AM
No, there's nothing in DSLstats that's intended to make it close down overnight. At a guess, it's probably something to do with Windows power saving.
Title: Re: DSLstats v6.5 released
Post by: Alucidnation on March 15, 2019, 06:52:57 AM
Thanks Eric,

I have turned off all the power save options (i think).

This is running on Windows 10, if that makes any difference?
Title: Re: DSLstats v6.5 released
Post by: Alucidnation on March 16, 2019, 11:18:33 AM
Hmmm, not running again this morning, however, i did notice that for some reason my laptop had dropped off the wifi, and wasn't set to join automatically.

Will see what happens tonight!!
Title: Re: DSLstats v6.5 released
Post by: adslmax on March 17, 2019, 12:50:25 AM
Does this DSLstats work with G.fast if enabled and active with future G.fast?
Title: Re: DSLstats v6.5 released
Post by: Alucidnation on March 17, 2019, 06:51:09 AM
Seems ok this morning.

:)
Title: Re: DSLstats v6.5 released
Post by: roseway on March 17, 2019, 11:57:59 AM
What you said about WiFi sounds like the explanation. DSLstats performs more reliably with a wired connection. There's no reason why it shouldn't work with WiFi of course, but it needs to be always on.
Title: Re: DSLstats v6.5 released
Post by: Alucidnation on March 17, 2019, 12:38:38 PM
Thanks Eric.

I will be plugging into my router at some point but was just using WiFi whilst I played about with it.
Title: Re: DSLstats v6.5 released
Post by: Chrysalis on April 25, 2019, 08:17:48 PM
Eric I have this in my logs, and since then uploads have never resumed, and I see no way to resume then other than maybe restarting the app.

"Webserver upload failed four times in succession. Uploading disabled"

Is it possible to either disable this behaviour (perhaps via a setting), or maybe make it retry again each hour until it starts working again?
Title: Re: DSLstats v6.5 released
Post by: roseway on April 25, 2019, 10:32:35 PM
I'll take a look at it, Chrys.
Title: Re: DSLstats v6.5 released
Post by: tiffy on April 26, 2019, 08:34:45 AM
Quote
Eric I have this in my logs, and since then uploads have never resumed, and I see no way to resume then other than maybe restarting the app.

"Webserver upload failed four times in succession. Uploading disabled"

Running RPi 3B (DSLStats V.6.5.9) I get this very occasionaly with "data store" usually when I have been messing about with my modem/router via a Telnet session for too long and don't remember to disable "FTP Uploads/Data Store uploads" first.

Perhaps stating the obvious, but "re-ticking" the "FTP Uploads/Data Store/Upload data to online service" box again resumes the service without any requirement to re-boot the application or halt/restart recording.

Edit:  Typo correction.
Title: Re: DSLstats v6.5 released
Post by: Chrysalis on April 26, 2019, 08:28:40 PM
Thank you tiffy.
Title: Re: DSLstats v6.5 released
Post by: underzone on April 27, 2019, 02:11:11 PM
I am having an issue running DSLstats under the new Ubuntu 19.04, I had it running OK with 18.04.2 LTS.

But with this latest Ubuntu version the program (v6.5.9) won't open (the executable bit IS set).

Any ideas?
Title: Re: DSLstats v6.5 released
Post by: roseway on April 27, 2019, 04:06:08 PM
@underzone: Do you get any clues if you try to launch DSLstats from a terminal? You can ignore the messages about duplicate resources, but any other error messages might be helpful.
Title: Re: DSLstats v6.5 released
Post by: underzone on April 27, 2019, 04:37:55 PM
Hi,

after entering (from within the dslstats directory):
./dslstats

I get the error:
./dslstats: error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory
Title: Re: DSLstats v6.5 released
Post by: roseway on April 27, 2019, 06:34:19 PM
Some searches suggest that this might solve the problem:

Code: [Select]
sudo apt-get install --reinstall libgtk2.0-0
Title: Re: DSLstats v6.5 released
Post by: underzone on April 27, 2019, 06:44:39 PM
Worked a treat! Thanks  ;)
Title: Re: DSLstats v6.5 released
Post by: roseway on April 27, 2019, 10:25:43 PM
Excellent!
Title: Re: DSLstats v6.5 released
Post by: adslmax on May 09, 2019, 11:32:34 AM
There appear bug on dslstats 6.5 on the connection stats you will notice total time still ongoing correct but link time has stopped worked after 49 days and never updated? Even the billion link time are 64 days?

Correct total time:
Code: [Select]
Total time = 64 days 7 hours 16 min 32 sec
FEC:            237775384               12247781
CRC:            9566            11227
ES:             688             3607
SES:            190             35
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0

Incorrect total link time:
Code: [Select]
Since Link time = 49 days 17 hours 2 min 47 sec
FEC:            237775384               12247781
CRC:            9566            11227
ES:             688             3607
SES:            190             35
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
Title: Re: DSLstats v6.5 released
Post by: roseway on May 09, 2019, 12:42:57 PM
That's not a DSLstats bug. The data you've copied above is taken from the full stats info, which is read directly from the modem. It uses the command "<prefix> info --stats". In every other Broadcom-based modem we've seen, the "Total time" value never goes beyond two hours, and continuously cycles from one hour to two hours and back again. That's a bug in the modem firmware.

"Since link time" also has a bug, in that it never exceeds the value you showed above. DSLstats deals with this by using the "Available seconds" value to calculate the connection uptime.
Title: Re: DSLstats v6.5 released
Post by: RTouris on May 29, 2019, 09:53:09 PM
I know I'm pushing it to the limits here, but I'm not having much luck running the 32bit Linux version on an Ubuntu Xenial distro compiled for - wait for it;...ARMv7 - an old tablet running Android 4.4.2 via Linux deploy..could someone more Linux-oriented suggest some workarounds? Managed to get most of the system up and running with no issues, however DSLstats won't launch :/ ...file downloaded via Ubuntu FF, extracted with CLI tar utility
Title: Re: DSLstats v6.5 released
Post by: roseway on May 29, 2019, 10:27:44 PM
You might learn something if you try to launch DSLstats from a terminal. There will be some messages about duplicate resources, which you can ignore, but any other messages might be informative.
Title: Re: DSLstats v6.5 released
Post by: RTouris on May 30, 2019, 06:51:08 PM
bare with me, first time linux diver - here goes:

Code: [Select]
android@localhost:~$ '/home/android/dslstats659/dslstats'
bash: /home/android/dslstats659/dslstats: cannot execute binary file: Exec format error

I guess it's not of much help...?
Title: Re: DSLstats v6.5 released
Post by: roseway on May 30, 2019, 07:12:32 PM
It's telling you that the Raspberry Pi (Raspbian) version of DSLstats is incompatible with Android. In theory I could possibly build an Android version, but at present I'm not going to be able to.
Title: Re: DSLstats v6.5 released
Post by: RTouris on May 30, 2019, 07:14:06 PM
In actual fact I'm attempting to run the 32bit Linux version, not the Raspbian version...

[edit_1]
...well, I'm happy to report that not only does the Raspbian version work on this frankenstein setup, but it appears faster than the one I'm currently using under OSX using Wine...LOL - kudos and thanks for the suggestion ;)

[edit_2]
..now if only I can get this setup to let me copy files here and there (to install kitz's web interface), as it appears the the mounted volume is read-only, or so does an error message claim. :/ chmod - nautilus are a no-go. Suggestions?

[edit_3]
..managed to copy all the revevant files manually via CLI, will come back to the read-only conundrum in due time; for now it's all fully functional :
Title: Re: DSLstats v6.5 released
Post by: roseway on May 31, 2019, 11:14:49 AM
I misread what you said in the original post, and I'm pleased that you got it working. :thumbs:

You should be able to make any directory read/write by typing in a terminal:

Code: [Select]
sudo chmod 777 <full path to the directory>
Title: Re: DSLstats v6.5 released
Post by: RTouris on May 31, 2019, 11:18:14 AM
I misread what you said in the original post, and I'm pleased that you got it working. :thumbs:

You should be able to make any directory read/write by typing in a terminal:

Code: [Select]
sudo chmod 777 <full path to the directory>

I'm afraid chmod 777 doesn't seem to do the trick...maybe it's perhaps Linux Deploy is ran as a chroot ENV..I'll come back to this in the future, for the time being I'm happy with the results so I'll let it settle for a while and test it in the long run.
Title: Re: DSLstats v6.5 released
Post by: Chrysalis on October 12, 2019, 05:24:15 PM
Eric I flashed my modem last night and noticed modem uptime is now not available, can you confirm where it fetches this data from?

A variable which could be used is probably "Total time = 13 hours 45 min 28 sec", this is the top block from the telnet data grabs.

vmg3925-b10b, firmware version V5.13(AAVF.12)C0

Also can you please confirm where it fetches ES from as on a modem power up it graphed 3200ES.
Title: Re: DSLstats v6.5 released
Post by: roseway on October 12, 2019, 06:50:51 PM
The "Total time =..." figure is (or was) unreliable. In all of the Broadcom firmware versions until recently this figure used to rise to 1 day 23 hours 59 minutes 59 seconds and then go back to 1 day, and continue this cycle for ever. The figure near the end of the stats "Since link time =..." has always stopped at a time I don't remember, but was 60-odd days, and it stayed there for ever after.

So DSLstats now uses the available seconds (AS) figure which has been reliable for a long time. From what you say, it appears that it's no longer reliable.
Title: Re: DSLstats v6.5 released
Post by: Chrysalis on October 12, 2019, 10:03:41 PM
AS seems to be working fine still for the dsl uptime, dsl uptime still works.
The modem uptime is now what is broken.

I can confirm tho that on my device the total time is not capped to 2 days. So that should work as a means to measure the modem uptime.

So...

"since link time" or "AS" both should be fine for dsl uptime (so keep that as is).
"total time", useable for modem uptime on the zyxel 3925-b10b.  Before I flashed this correctly showed uptime in excess of 200 days.

Code: [Select]
Total time = 212 days 6 hours 36 min 32 sec
FEC:            176459          1601
CRC:            6451            121
ES:             62343           7273
SES:            70              1
UAS:            145             114
LOS:            3               0
LOF:            17              0
LOM:            0               0
Retr:           3

also the good old "uptime" command seems valid as well.

Code: [Select]
# uptime
 18:35:41 up 18:35,  load average: 0.29, 0.29, 0.31
Title: Re: DSLstats v6.5 released
Post by: roseway on October 12, 2019, 10:31:01 PM
Sorry, I didn't read your question properly. DSLstats gets the modem uptime from the busybox command

cat /proc/uptime

Title: Re: DSLstats v6.5 released
Post by: Chrysalis on October 13, 2019, 12:06:32 AM
interesting how it says not available now, does the output I provided look correct?
Title: Re: DSLstats v6.5 released
Post by: roseway on October 13, 2019, 07:42:55 AM
If I use "man uptime" on one of my Linux systems I see this:

Quote
uptime  gives a one line display of the following information.  The current time, how long the system has been running, how many users are currently logged on, and the system load averages for the past 1, 5, and  15  minutes.

which seems to match your figures except for the number of users part. If I'd known that the uptime command existed in the Broadcom busybox shell I would have used it in DSLstats.

The command "cat /proc/uptime" gives two numbers, the first of which is the number of seconds the system has been running, and should match the uptime result. Here's what I see on my VMG8324-B10A:

Code: [Select]
> cat /proc/uptime
242032.79 0.00
 > uptime
2D 19H 14M 6S

Clearly these commands have changed in recent versions of the Broadcom firmware.
Title: Re: DSLstats v6.5 released
Post by: Chrysalis on October 13, 2019, 08:52:43 AM
I apologise, here is the output for the /proc/uptime, I didnt read what you said properly when you said its using /proc/uptime sorry.

Code: [Select]
105582.07 202052.63
also dilemma solved, the command seems ok on root, but I gave dslstats the admin username instead and cat /proc/uptime doesnt work on that login.  It did on the older firmware, but its just a change of username so shouldnt be a problem.  Now dslstats is using root its showing again :)
Title: Re: DSLstats v6.5 released
Post by: roseway on October 13, 2019, 10:35:58 AM
Thank you for resolving that.
Title: Re: DSLstats v6.5 released
Post by: tommy45 on April 01, 2020, 04:31:43 PM
A question where does dls stats store the average ES data,  because my pc bsd's yesterday and the graph has frozen since, all the other graphs seems to be working  but that one and it wont reset to zero for the daily errors I removed the es graph from the default location  C:\Users\username\AppData\Local\dslstats\
Title: Re: DSLstats v6.5 released
Post by: roseway on April 01, 2020, 06:39:58 PM
The ES/hour data is saved in a text file called es_data.txt which is in the location where your configuration files are saved. The average errors (10 days worth) are saved in a file called errors1.dat in the same location.
Title: Re: DSLstats v6.5 released
Post by: tommy45 on April 01, 2020, 07:05:21 PM
The ES/hour data is saved in a text file called es_data.txt which is in the location where your configuration files are saved. The average errors (10 days worth) are saved in a file called errors1.dat in the same location.
Thanks  because it won't for some reason clear error sec totals, when i press the reset today ,button and the graph is not updating
Title: Re: DSLstats v6.5 released
Post by: roseway on April 01, 2020, 10:22:23 PM
I'm a little confused now, because the average errors are not related to any graph. It simply stores the last ten days worth of data as shown on the average errors page.
Title: Re: DSLstats v6.5 released
Post by: GigabitEthernet on April 03, 2020, 04:31:25 PM
Sure I've asked this before but it's not possible to get the current sync speed in the resync email notifications, is it?
Title: Re: DSLstats v6.5 released
Post by: tiffy on June 20, 2020, 09:43:08 AM
Since changing by setup from VMG1312-B10A modem/router to 1312-B10A modem / VMG3925-B10B router have noted that the "traffic" graph in DSLStats indicates zero usage.
Not a drastically important parameter to me as such and probably to expectation with the modem/router 2 box setup but just wondering if there is any way around this ?

Edit: Typo correction.
Title: Re: DSLstats v6.5 released
Post by: roseway on June 20, 2020, 11:37:59 AM
@tiffy: It's probably just a matter of choosing the right interface in the traffic configuration. I have a similar setup to yours except that I use a TP-Link router, and the traffic reporting works fine. In my case the interface in the setup is Other --> ptm0.1 . You can see what's happening in the various interfaces in
Telnet Data --> Traffic.
Title: Re: DSLstats v6.5 released
Post by: tiffy on June 20, 2020, 02:41:17 PM
@roseway:
Duplicated your configuration  and bingo, traffic graph started updating again, many thanks Eric.
New config. snapshot attached for reference.

Quote
You can see what's happening in the various interfaces in
Telnet Data --> Traffic.
Did not understand this bit, perhaps you could elaborate a little for a keen to learn "numpty" ?
Title: Re: DSLstats v6.5 released
Post by: roseway on June 20, 2020, 03:06:55 PM
@tiffy: If you look at Telnet Data --> Traffic, you'll see the output of the command ifconfig (or alternative command as shown at the left hand side of the configuration). It's a list of all the network interfaces which are active in the device. Mine looks like this:

Code: [Select]
ifconfig
bcmsw     Link encap:Ethernet  HWaddr 4C:9E:FF:0C:F6:B4 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:118 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Base address:0xda00

br0       Link encap:Ethernet  HWaddr 4C:9E:FF:0C:F6:B4 
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::4e9e:ffff:fe0c:f6b4/64 Scope:Link
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:68856245 errors:0 dropped:0 overruns:0 frame:0
          TX packets:53419591 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:3672975270 (3.4 GiB)  TX bytes:2295088945 (2.1 GiB)

br1       Link encap:Ethernet  HWaddr 4C:9E:FF:0C:F6:B4 
          inet addr:192.168.2.1  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fe80::4e9e:ffff:fe0c:f6b4/64 Scope:Link
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:84820 errors:0 dropped:0 overruns:0 frame:0
          TX packets:91497 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:9524862 (9.0 MiB)  TX bytes:4575440 (4.3 MiB)

eth0      Link encap:Ethernet  HWaddr 4C:9E:FF:0C:F6:B4 
          inet6 addr: fe80::4e9e:ffff:fe0c:f6b4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:61508924 errors:0 dropped:0 overruns:0 frame:0
          TX packets:114215918 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:4088558649 (3.8 GiB)  TX bytes:390757044 (372.6 MiB)
         

eth0.0    Link encap:Ethernet  HWaddr 4C:9E:FF:0C:F6:B4 
          inet6 addr: fe80::4e9e:ffff:fe0c:f6b4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:65165477 errors:0 dropped:0 overruns:0 frame:0
          TX packets:118134768 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:242145966 (230.9 MiB)  TX bytes:3615219680 (3.3 GiB)

eth1      Link encap:Ethernet  HWaddr 4C:9E:FF:0C:F6:B4 
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
         

eth1.0    Link encap:Ethernet  HWaddr 4C:9E:FF:0C:F6:B4 
          inet6 addr: fe80::4e9e:ffff:fe0c:f6b4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:33366127 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:2259707256 (2.1 GiB)

eth2      Link encap:Ethernet  HWaddr 4C:9E:FF:0C:F6:B4 
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
         

eth2.0    Link encap:Ethernet  HWaddr 4C:9E:FF:0C:F6:B4 
          inet6 addr: fe80::4e9e:ffff:fe0c:f6b4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:33366121 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:2259706722 (2.1 GiB)

eth3      Link encap:Ethernet  HWaddr 4C:9E:FF:0C:F6:B4 
          inet6 addr: fe80::4e9e:ffff:fe0c:f6b4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:68859675 errors:0 dropped:0 overruns:0 frame:0
          TX packets:53434748 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:618632271 (589.9 MiB)  TX bytes:2510658207 (2.3 GiB)
         

eth3.0    Link encap:Ethernet  HWaddr 4C:9E:FF:0C:F6:B4 
          inet6 addr: fe80::4e9e:ffff:fe0c:f6b4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:68858401 errors:0 dropped:0 overruns:0 frame:0
          TX packets:53419507 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:3673775371 (3.4 GiB)  TX bytes:2295084635 (2.1 GiB)

eth4      Link encap:Ethernet  HWaddr 4C:9E:FF:0C:F6:B6 
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
         

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:424 errors:0 dropped:0 overruns:0 frame:0
          TX packets:424 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:26762 (26.1 KiB)  TX bytes:26762 (26.1 KiB)

ptm0      Link encap:Ethernet  HWaddr 4C:9E:FF:0C:F6:B7 
          inet6 addr: fe80::4e9e:ffff:fe0c:f6b7/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3309839 errors:0 dropped:129 overruns:0 frame:0
          TX packets:1591266 errors:0 dropped:23 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3350130921 (3.1 GiB)  TX bytes:204436716 (194.9 MiB)

ptm0.1    Link encap:Ethernet  HWaddr 4C:9E:FF:0C:F6:B7 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3056847 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1726037 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:3484061415 (3.2 GiB)  TX bytes:248237557 (236.7 MiB)

 >

At the end of the description of each interface it shows RX bytes and TX bytes (number of bytes received and sent). You can infer from these figures which interface is likely to be the one handling total traffic through the device.
Title: Re: DSLstats v6.5 released
Post by: tiffy on June 20, 2020, 03:54:23 PM
@roseway:
Many thanks Eric for the additional information, much appreciated.

I'll have a little play, hopefully learn something.
Title: Re: DSLstats v6.5 released
Post by: bndwdthseekr on July 16, 2020, 07:35:48 PM
I have encountered a bit of a bug in the graph shots used for the web interface. After restarting DSLstats, a few of the graphs display a cut version of the whole graph as seen below. When I go into the bits tab and 'change tone range', then click the arrows or move the slider, then it will start posting the full graph again.

The same problem occurs with the Hlog and QLN graphs. ???

Anyone know how to fix this?
Title: Re: DSLstats v6.5 released
Post by: tiffy on August 11, 2020, 05:54:20 PM
DSLStats V.6.5.9., latest available version.
Have started to use the "Data Store" facility again, not via "FTP Uploads" which was the case back in MDWS days, just harvest the data files from my RPi 3B to my Win 10 desktop PC over the LAN in order to display historic data using the "Broadstairs" utility.

To keep the file count to minimum and not really requiring the Bitloading, SNR per tone, HLog & QLN historical data, I have opted to de-select the associated hourly downloads as per the Data Store  GUI options, however, I am still getting the 4 *.zip files per hour regardless of the options being selected or not.
(see attached screen snapshot)

I fully appreciate that Eric (roseway) is unable to offer support for his excellent utility at present but just wondering if this is an issue, known or otherwise or am I getting in a muddle once again ?
Title: Re: DSLstats v6.5 released
Post by: roseway on August 11, 2020, 06:25:15 PM
The only thing I can think of is that you may need to close down DSLstats to save the settings, and restart it before the changes take effect.
Title: Re: DSLstats v6.5 released
Post by: tiffy on August 13, 2020, 11:42:54 AM
@roseway:

Thanks for the response Eric, much appreciated.

I record my line stat's on a 4 day cycle so delayed trying a program shutdown/re-boot, now done but has had no effect on the de-selection of the Data Store *.zip files, still being stored regardless of selection or otherwise.

In my case not a big issue, I use a very simple Windows batch file periodically run with Task Scheduler, I can just omit to copy the *.zip files to my Win PC, I already delete the RPi daily Data Store files once copied.
You do of course have the FTP Uploading facility incorporated within the DSLStats program but I never managed to get this working across my LAN, the simple batch file utility although not very elegant works for me.
Title: Re: DSLstats v6.5 released
Post by: bndwdthseekr on January 21, 2021, 02:31:52 AM
Anyone know what could cause this in the event log? It prints this message every update.

Code: [Select]
20 Jan 2021 21:24:51 Error processing bitloading
20 Jan 2021 21:25:06 Error processing bitloading
Title: Re: DSLstats v6.5 released
Post by: roseway on January 21, 2021, 10:16:18 AM
Unfortunately this is a catch-all response which saves the program from misbehaving when an unknown error occurs in the section mentioned. The cause is quite probably something unexpected in the bitloading data from the particular modem in use.
The only thing I can suggest is to try a different Broadcom based modem.
Title: Re: DSLstats v6.5 released
Post by: bndwdthseekr on January 22, 2021, 10:21:33 AM
Unfortunately this is a catch-all response which saves the program from misbehaving when an unknown error occurs in the section mentioned. The cause is quite probably something unexpected in the bitloading data from the particular modem in use.
The only thing I can suggest is to try a different Broadcom based modem.

The strange part is it works when I first start the program (see attached), but I don't think its updating the bitloading graph after a certain point. Maybe Ill compile dslstats from source and try to narrow down the problem.


Code: [Select]
xdslctl info --Bits

The output of the command is :

/bin/xdslctl: ADSL driver and PHY status

Status: Showtime

Last Retrain Reason: 0

Last initialization procedure status: 0

Max: Upstream rate = 1276 Kbps, Downstream rate = 12208 Kbps

Channel: FAST, Upstream rate = 1024 Kbps, Downstream rate = 6944 Kbps



Tone number      Bit Allocation

   0 0

   1 0

   2 0

   3 0

   4 0

   5 0

   6 6

   7 5

   8 7

   9 8

   10 9

   11 10

   12 11

   13 11

   14 12

   15 12

   16 12

   17 12

   18 13

   19 12

   20 13

   21 13

   22 13

   23 12

   24 13

   25 12

   26 12

   27 12

   28 11

   29 11

   30 10

   31 9

   32 0

   33 0

   34 2

   35 2

   36 2

   37 3

   38 3

   39 3

   40 4

   41 4

   42 4

   43 5

   44 5

   45 5

   46 5

   47 6

   48 6

   49 7

   50 8

   51 8

   52 9

   53 9

   54 9

   55 10

   56 10

   57 10

   58 11

   59 11

   60 11

   61 11

   62 11

   63 11

   64 0

   65 11

   66 11

   67 11

   68 11

   69 11

   70 11

   71 11

   72 11

   73 11

   74 11

   75 11

   76 11

   77 12

   78 12

   79 11

   80 11

   81 11

   82 11

   83 11

   84 11

   85 11

   86 11

   87 11

   88 11

   89 11

   90 11

   91 11

   92 11

   93 11

   94 11

   95 11

   96 11

   97 11

   98 11

   99 11

   100 10

   101 11

   102 10

   103 11

   104 10

   105 10

   106 10

   107 10

   108 11

   109 11

   110 2

   111 11

   112 10

   113 10

   114 11

   115 10

   116 10

   117 10

   118 10

   119 10

   120 10

   121 11

   122 11

   123 10

   124 10

   125 10

   126 9

   127 9

   128 9

   129 9

   130 9

   131 9

   132 9

   133 9

   134 9

   135 9

   136 9

   137 9

   138 9

   139 9

   140 9

   141 9

   142 9

   143 9

   144 9

   145 9

   146 8

   147 9

   148 9

   149 9

   150 9

   151 9

   152 9

   153 9

   154 9

   155 9

   156 9

   157 9

   158 9

   159 9

   160 9

   161 9

   162 8

   163 8

   164 8

   165 8

   166 8

   167 8

   168 9

   169 8

   170 8

   171 8

   172 8

   173 8

   174 8

   175 8

   176 7

   177 8

   178 8

   179 8

   180 8

   181 8

   182 8

   183 8

   184 8

   185 8

   186 8

   187 8

   188 8

   189 8

   190 8

   191 8

   192 8

   193 8

   194 8

   195 8

   196 8

   197 8

   198 8

   199 8

   200 8

   201 8

   202 8

   203 8

   204 8

   205 8

   206 8

   207 8

   208 8

   209 7

   210 8

   211 8

   212 8

   213 8

   214 8

   215 8

   216 8

   217 8

   218 8

   219 8

   220 8

   221 7

   222 7

   223 7

   224 8

   225 7

   226 7

   227 7

   228 7

   229 7

   230 6

   231 7

   232 7

   233 7

   234 7

   235 7

   236 6

   237 7

   238 6

   239 7

   240 7

   241 6

   242 6

   243 6

   244 6

   245 6

   246 6

   247 5

   248 5

   249 5

   250 5

   251 5

   252 5

   253 4

   254 4

   255 0





BFR#
Title: Re: DSLstats v6.5 released
Post by: 22over7 on February 07, 2021, 11:17:15 PM
After what seems like several happy and complacent years of running dslstats32RPi-6.5.9/dslstats ,
our neighbourhood in Edinburgh experienced a splendid 15 minute power-cut.
So naturally, when it turned on, I turned to my friend 6.5.9. to tell me the gory details, and where my SNR stands.
The pi running he/she/it/them chunters on indefatigably(?),
but  6.5.9 now keels over and over with a segfault after about a minute each time.

My modem (Zyxel1312-B10A) is well enough to send this, and I can login by ssh, http etc.
somethings in dslstats' infrastructure must have changed enough to push it into the
clutches of the grim reaper.

Or not? Is any hope of resuscitating (no medic, me) my pal, or some looking up, in hope, her/his/their progeny?


Title: Re: DSLstats v6.5 released
Post by: roseway on February 08, 2021, 06:34:06 AM
At risk of stating the obvious, 6.5.9 is 6.5.9. It hasn't changed in any way since it was first released. The version which is available to download from http://dslstats.me.uk hasn't been touched since it was originally uploaded.
Title: Re: DSLstats v6.5 released
Post by: skyeci on February 08, 2021, 10:28:49 AM
I would looking at your sd card on the pi. I have had issues with crashes from dsl stats which after changing the sdcard all is well...so assumed the old card was becoming faulty.
Title: Re: DSLstats v6.5 released
Post by: kitz on February 11, 2021, 02:37:08 AM
Quote
but  6.5.9 now keels over and over with a segfault after about a minute each time

A segfault means that DSLstats is attempting to read (or failing to write to) something which is no longer there (in memory).
This infers that segments of the storage drive has become corrupt.  The storage drive (memory drive) can be a hard drive, SDcard,  USB memory stick or even CD/DVD depending upon the type of memory medium DSLstats is running from. 

Basically - your storage medium is duff - most likely caused by the power cut if the operating system was busy at the time and something was attempting to write to disk at the time power went off.  Depending upon the type of storage your operating system may be able to run a repair or declare segments as unusable.    However. take it as a warning telling you to get new drive asap, before the whole drive fails.

To be more specific the error you are seeing means that part of the drive holding the prog DSLstats is now corrupt and therefore it can no longer run properly   OR DSLstats is trying to read data stored on parts of the drive which are now corrupt    OR the drive is now so corrupt that DSLstats cant record (write) any new data.   

For more info see Unreadable File Record Segments (https://www.stellarinfo.com/blog/what-to-do-when-file-segment-becomes-unreadable/)

---------------

PS I did happen to see your reply to one of my moderators the other night, but I was not in a position to type at that time. :( 
FYI He was trying to be helpful - for all he knew and from the info in your first post it could have been part of the drive that held the OS which was corrupt.  As he said, power cuts are well known to cause failure of the memory drives particularly on R-Pi's which do not always take kindly to not being shut down correctly.   It wasn't clear that you were running from a USB memory stick.  If everything else on the memory stick appears to be working OK then I'd guess the bad segments are where DSLstats was stored on the drive so its caused the prog to become corrupt, so you will need to redownload it.   It is time though to get a new drive because you dont know what other segments are damaged too or if other parts of the drive may not also fail in the near future.   


Title: Re: DSLstats v6.5 released
Post by: Alex Atkin UK on February 11, 2021, 01:47:53 PM
Sadly a lot of people don't seem to understand that NAND is far more sensitive to power cuts.  A write under a low power state in some cases can cause permanent damage.

SSDs I believe get round this by detecting a power cut and having enough residual energy in a capacitor to finish writing safely, SD cards and USB sticks are unlikely to be that clever plus likely use cheaper less resilient NAND to begin with.
Title: Re: DSLstats v6.5 released
Post by: jelv on February 17, 2021, 10:14:06 AM
Does anyone know if DSLstats can be used with a Technicolor DGA0122? If so is the configuration simple. Asking for a friend (really).
Title: Re: DSLstats v6.5 released
Post by: roseway on February 17, 2021, 12:47:56 PM
Most fairly recent Technicolor modem/routers were only sold via ISPs, using locked custom firmware. If this applies to your friend's model, then you'll be stuck at the first hurdle, unless someone knows a way to unlock it.
However, if it's Broadcom based and it does have an accessible telnet interface, then DSLstats may work with it - suck it and see would apply.
Title: Re: DSLstats v6.5 released
Post by: Chrysalis on September 24, 2021, 04:20:38 PM
Hi Eric

I think I may have found a bug in 6.5.9 in relation to the datastore.

My configuration is as follows.

Save data to datastore ticked
Single file each day selected
Items to include all unticked.

As I understand it, this should mean I have the main stats included every sample, which I think is the Stats.log, but should be no Bitloading, SNR Tone, Hlog or QLN data as they not ticked.

However I do see a zip file for each of the 4 above data types made every hour in the dated folder.
Title: Re: DSLstats v6.5 released
Post by: snadge on September 24, 2021, 05:02:02 PM
Im having an issue with the EERORR STATS PAGE saying NO DATA for almost ALL of the days, and data for some?
Title: Re: DSLstats v6.5 released
Post by: roseway on September 24, 2021, 06:36:57 PM
@Chrys:  That does sound like a bug, but I guess we could call it a benign one as no data is lost.

To both of you: I'm sorry but I'm not able to do any more work on DSLstats now.
Title: Re: DSLstats v6.5 released
Post by: Chrysalis on September 24, 2021, 08:07:32 PM
It is fine, I disabled datastore completely as I realised I dont need it. :)
Title: Re: DSLstats v6.5 released
Post by: Edinburgh_lad on October 09, 2021, 10:37:36 AM
Hello

Just wondering if DSLStats can be run with Draytek routers? There isn't an option to choose from the dropdown menu.

Thanks.
Title: Re: DSLstats v6.5 released
Post by: roseway on October 09, 2021, 11:00:49 AM
Rather unlikely I'm afraid. This might help: http://dslstats.me.uk/newmodem.html
Title: Re: DSLstats v6.5 released
Post by: tommy45 on November 26, 2021, 04:21:04 PM
Unable to determine IP address error  Following  re-sync /power off of the modem, i now see this in the event log Is there any reason why it would suddenly stop being able to see the IP address ? my set-up is a HG612  unlocked and a Billion 7800  router
Title: Re: DSLstats v6.5 released
Post by: g3uiss on November 26, 2021, 04:27:34 PM
This is a know issue, but it has no effect on the working of the program, it is unlikely to be addressed.
Title: Re: DSLstats v6.5 released
Post by: snadge on November 27, 2021, 03:45:47 PM
I used to have a couple of issues when i was on xDSL - but as Roseway says, he is unable to make changes to the program from now on, it works for what you need it for most, so it should be fine, my issue was not NO DATA for previous days, but now I'm on PON it is of no use anymore, which is a bit disheartening, i liked having it and I checked it DAILY!

so THANK YOU Roseway for your efforts!
Title: Re: DSLstats v6.5 released
Post by: roseway on November 27, 2021, 04:19:57 PM
Thank you for your kind words. :)
Title: Re: DSLstats v6.5 released
Post by: snadge on November 27, 2021, 04:26:26 PM
Thank you for your kind words. :)

Your welcome, it is deserved, as you put a lot of work into that and was the BEST xDSL checker on the internet. I'm sure others would agree.
.
Title: Re: DSLstats v6.5 released
Post by: broadstairs on November 27, 2021, 05:55:58 PM
Yes I agree it has been and still is an invaluable tool to monitor connections. Sadly in about 3 weeks I will also have to stop running it once I am on FTTP.

Thanks Eric...

Stuart
Title: Re: DSLstats v6.5 released
Post by: Chrysalis on November 27, 2021, 08:00:34 PM
Agree 100%.
Title: Re: DSLstats v6.5 released
Post by: g3uiss on November 27, 2021, 10:29:31 PM
Plus 1
Title: Re: DSLstats v6.5 released
Post by: roseway on November 28, 2021, 06:35:36 AM
You're all very kind.
Title: Re: DSLstats v6.5 released
Post by: Weaver on November 28, 2021, 09:41:02 AM
I have not been able to use this tool, because I don’t have a windows box, just an iPad only. I recognise the work put in and the value of this excellent tool. (Our own member Johnson did a mountain of work in building the equivalent for me that runs inside ZyXEL modems and delivers the answers to me via http port 8000.)
Title: Re: DSLstats v6.5 released
Post by: snadge on November 28, 2021, 12:26:29 PM
I have not been able to use this tool, because I don’t have a windows box, just an iPad only. I recognise the work put in and the value of this excellent tool. (Our own member Johnson did a mountain of work in building the equivalent for me that runs inside ZyXEL modems and delivers the answers to me via http port 8000.)

AHH, I wished I'd known about that! when I was on xDSL as I have the Zyxel 8924, I would have loved to have it built into the Firmware as it does have its own DSL stats reporting tool in the GUI options

BUT, still having the actual DSL-Stats GUI was great - Eric i not only checked it daily, but when off work i'd check it up to 5-7 times a day hehee - so yes i made loads of use of that app  - i even had some input in which Eric was nice enough to implement - which was:-

1) Adding the DSLAM's stats at the top of the stats page.
2) Changing Reed Solomon from raw numbers to percentages of the actual traffic corrected and uncorrected.

I was buzzing to see them still there to this day  :)
Title: Re: DSLstats v6.5 released
Post by: Weaver on November 29, 2021, 05:28:29 AM
Snadge, there’s a ZyXEL VMG 8924-B10A version (binary too) of Johnson’s work available, both binaries and the source files are of course available. See  https://github.com/johnson442/custom-zyxel-firmware/releases  (https://github.com/johnson442/custom-zyxel-firmware/releases)
Title: Re: DSLstats v6.5 released
Post by: snadge on November 29, 2021, 01:12:39 PM
Snadge, there’s a ZyXEL VMG 8924-B10A version (binary too) of Johnson’s work available, both binaries and the source files are of course available. See  https://github.com/johnson442/custom-zyxel-firmware/releases  (https://github.com/johnson442/custom-zyxel-firmware/releases)

excellent, thanks for that, i will keep a hold of those files for the future, I may move after my 2 years on PON, and end up on DSL again...you never know haha, mind as we all know, BT is trying to rid the copper even from customers premises, after they install FTTP, but i can tell you he did not at mine, he admitted he was supposed to, but as we were both not bothered and he was on 'piece-rate' he said he will just leave it, as the longer he is at any one house, the less money he is earning.

I think its terrible of BT using "piece rate" wages for the basic Linesmen (mind it was a sub-contractor - MJ Quinns), he said its 3-4 houses per day expected (which is fair to be honest) - BUT - what if one BT Linesman get's really long hard jobs in a row that he cant help but end up doing 1-2 houses a day... I think they need to change that MO of wages IMO, unless that is just MJ QUINNS doing that?

but yeah great thanks  :)
Title: Re: DSLstats v6.5 released
Post by: neil on November 30, 2021, 06:55:48 PM
Hello,

Thank you so much for this great tool.
I run this tool on my PC from time to time. I wanted to ask do you have any plans to make a package for openwrt? If such packages are already available, can you please guide if you have any idea. And sorry if same question has been asked before. 

Thank you,
Title: Re: DSLstats v6.5 released
Post by: roseway on November 30, 2021, 10:24:30 PM
I'm sorry, but I'm not able to continue development of DSLstats. In any case it would need a total redesign to fit into an openwrt package, and that would be a very big job.
Title: Re: DSLstats v6.5 released
Post by: neil on December 01, 2021, 05:47:31 AM
I'm sorry, but I'm not able to continue development of DSLstats. In any case it would need a total redesign to fit into an openwrt package, and that would be a very big job.

Ok no problem  :'(  thank you again for this great tool.  :)