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