Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[roseway]

When I checked this before, I managed to convince myself that the reported QLN values are dBm/Hz, i.e. the noise power in dBm divided by the frequency. Most of the sources I found do plot it that way. I would really like to see a definitive reference.

[burakkucat]

Hmm . . . I shall have to put it on my "search" list.

Signal power (as dB relative to 1 mW) divided by the frequency (Hz) versus frequency (Hz) . . .   

[kitz]

I just went to look and dslstats, and I noticed that it had crashed.
 
I attach the relevant screen caps.   Because the icon sits in the system tray I hadnt noticed it had crashed, but judging from the last stats gathered, it last reported the 2hr stats yesterday at 13:06:33 meaning that it crashed some point inbetween then and 2 hrs later.

I dont know if it makes any difference but those graphs at 13:06:33 would have been snapshots that I manually captured knowing that it may crash if I manually ran HG612modem stats.  The last scheduled 2 hr run I have is at 11:36:38.

Not sure if the next schudule would have been due to run therefore at 13:36 if this narrows the time frame down further.
Looks like I may have possibly managed to make it crash.   I had the DSLstats window open when I was running, but minimised it to system tray at about 13:22 when I made the above post. I didnt look at dslstats again until now, which is why I hadnt noticed earlier.

[roseway]

It does look as though the crash was probably the result of a conflict. I will try to find some way to make it less susceptible. I suppose I could check for the presence of HG612-Modem-Stats before each sample. I'll give it some thought.

[NewtronStar]

Its strange Kitz your system is having issues with the pre-releace version of Dslstats as it's working very well here on my system, to me it sounds like some configuration settings with Both Dslstats and HG612_Modem_stats or OS, you could use the Event Viewer and look at the windows logs application and system to see if there is any failures at the time range you think the crash happened.

the only time I get a Division by Zero is when i adjust the sampling rate from the default of 1 minute to say 20 seconds but it sorts itself out in on the next sample of 20 seconds.

[Bald_Eagle1]

I don't think that plotting 7 days of ongoing stats via HG612 Modem Stats is the issue as the modem isn't accessed.
The graphing program simply obtains data from the modem_stats.log file.

Scheduled stats harvesting for ongoing stats and/or current (snapshot) stats is usually completed well before 35 seconds past the minute.

However, running HG612_current_stats.exe manually, either directly or via the GUI to harvest & optionally plot snapshot data could cause a clash if the timing coincides with DSLStats harvesting data at the same time.

There's a bit of a lead in period, creating folders etc., before the start of the snapshot stats harvesting & on my 'slow' system, harvesting itself takes around 3 seconds.

It may take longer if 0.25 second or 0.50 second pauses have been introduced to slow down faster PCs.


So, if manually running HG612 Modem Stats' snapshot harvesting/graphing whilst DSLStats is running, it might be wise to do it before say 25 seconds past the minute or after 45 seconds past.

[kitz]

>>> Its strange Kitz your system is having issues with the pre-releace version of Dslstats

This isnt limited to the pre-release version.  Its happened with previous versions.  The only reason I mentioned it in here because it may have been relevant to what broadstairs was reporting in this thread.  It happens if DSLstats co-incides with HG612 modem stats snapshot.  So it could be happening because broadstairs is running dslstats on 2 PCs, thereby they could be clashing too.

>>> to me it sounds like some configuration settings with Both Dslstats and HG612_Modem_stats or OS

Everytime its happened I know its been a result of a conflict with both progs running.
That is...aside from today/yesterday .... because I dont know when that happened other than it was some time after 13:06 yesterday.


>>> you could use the Event Viewer

Unfortunately, that doesnt help.   The time reported in Event viewer isnt until I actually attempt to open dslstats from my sys tray.   Its not until I re-open it from minimised will it be recorded in event viewer.


So this is what I currently see

01/06/2014 17:02:45

Application Error Event ID 1000 dslstats.exe 00000000   unknown   0.0.0.0

I actually had nothing at all in Event viewer yesterday other than gupdates, notification of backup complete, and sys retore point created.


Yet dslstats actually stopped running and recording any data more than 24hrs previously. The last data recorded by dslstats was 31/05/2014 13:06:33
 
Although a conflict causes dslstats to stop recording.. it wont throw an error until you re-open the dslstats window.
Its caught be out several times now as I think its running fine, when the icon is still there minimised in sys tray.


Bear in mind I was trying to deliberately make it crash yesterday at around 1pm..  but because DSLstats window remained open I thought all was ok.  I then minimised dslstats to sys tray and made the post at 01:22:25.   It wasnt until 5pm today that I realised dslstats hadnt been recording for the past 24 hrs.

I'd been doing some additional monitoring for BE, which is why Id been running graphpd & snapshots more often than the average user would be... and thats why Im seeing more crashes.   Ive just not mentioned it to eric before, because I know its a manual run of dslstats when the time co-incided that causes the crash.  If broadstairs hadnt have reported similar, I probably wouldnt have said anything to Eric as he has enough to do & I was just attempting to help with broadstairs issue.

In fact.. this is what I said to BE the last time I caused dslstats to crash & HG612 modem stats to throw errors.

"I wouldn’t worry too much about it BE,  It was my fault I was testing and forgot to disable dslstats... or check the time.   I realised straight away what Id done. It does crash DSLstats without warning though."

So the crux is, if DSLstats is running and another prog tries to access your router for linestats, then dslstats crashes without warning, and you wont know its crashed until you next try to restore it from sys tray.


---

ETA

BaldEagle posted whilst I was doing, but Ive left the post as was.

[NewtronStar]

Kitz would it not be a good idea to focus your beta testing for BE1 HG612_Modem_Stats and disable Dslstats until BE1 is satisfied that Modem_Stats is working as it should on your system as all your doing is confusing each programers program and they don't know if it theres side or the others thats causing your issue (1 step at a time) 

[kitz]

Ummmmm, the testing for HG612 stats is now complete..   I was trying to avoid clashes.

It was my fault I was testing and forgot to disable dslstats... or check the time.   I realised straight away what Id done. It does crash DSLstats without warning though.

Shouldnt have said anything in this thread..  I was only trying to help point out what could have been the cause of broadstairs problems from what Id noticed in the past.

I wouldnt have said anything in this thread apart from the fact Id seen broadstairs post..   thought I was trying to help, because there will be others that run into the same problem at some point.   I was trying to identify what happens so that perhaps in future it could be avoided.   There are many people who run both progs.


---
Edited to clarify

<< It does crash DSLstats without warning though.>>

What I meant by that is that DSLstats crashes... and there is no warning that it has crashed.
Was going to attempt to do some further tests tonight, but obviously if no one is bothered that the 2 cause conflicts... then theres not much point me wasting my time.

[roseway]

Just to be clear, I am interested in the problem of conflict crashes, and I'm beefing up the error trapping and logging to try to resolve it. Please do continue to report these events.

[Bald_Eagle1]

I'm also interested.

Perhaps we should jointly confirm/agree how best to deal with this, otherwise we may unwittingly introduce a problem.

I'll provide some suggestions tonight as I'm setting off to work now.

[roseway]

I'll be interested to hear your thoughts.

[krypton]

...
- login should now work with modem/routers which don't require username and password to log in
...

I can confirm this works now. Thanks.

I tried the new pre-release versions several times. It is truly much faster, on my vdsl2 line one sampling period takes between 1 and 1.5 seconds with all items enabled. The old version needs about 10 seconds.

One time it worked for about 10 minutes without an error on linux 32 bit.

But almost always it does not work and this happens: After start "sampling" stays permanent on during the configured sampling time and "Previous sample still being processed" is displayed. No graphs or status bar informations is visible. This repeats over and over.
With wireshark I can see that every sampling period the --stats data is successfully transmitted but after this, nothing more is sent or received.
If this happens dslstats can't be closed properly. It doesn't freeze but the close buttens don't react or "closing..." stays on forever. It's the same on linux and windows versions.

Some people seem to have problems with multiple graphing programs running at the same time. I tried this an let 5 instances of dslstats (4.53.3) sampling simultaneous. They worked perfectly with no errors.

[roseway]

Thanks for that report. I think I can see what's causing that, and I'll fix it.

[Bald_Eagle1]

I'll be interested to hear your thoughts.

Please correct me if any of this is incorrect, but this is how I think DSLStats works when HG612-Modem-Stats co-operation is selected:-

DSLStats will always start sampling at 35 seconds past the minute.
If any of my programs are running at that time, DSLStats will abandon that sample & try again at 35 seconds past the next minute.

Depending upon the PC's speed, sampling with your new method can take between 3 & 5 seconds.

if my programs (or any other program) attempt to log in to the modem during DSLStats' sampling period, DSLStats will currently crash (or continue looping).

I assume your new sampling method is similar to the method employed by my programs. i.e. a login/password/ATP> prompt or the '#' or '>' characters are awaited & then login details or a stats command are sent to the modem with the resulting output used for the next stage of logging in or for the stats data.

If another program 'butts in', it could  affect the expected output, which is the root cause of the problem.


I can think of 3 possible options at the moment to hopefully avoid this issue:-

1) DSLSTats could run a 'dummy' process immediately before sampling & end it immediately after sampling has completed.

My programs could check for that process & if it is present, they will keep checking until the process has ended, at which time my programs will continue to log in etc.

If 'too much' time has elapsed, my program could try to log in & if it fails, my program will exit rather than keep trying indefinitely.



2) My programs could check for DSLStats running & assume that sampling will start at 35 seconds past the minute & complete by 40 seconds past.

If my programs are started just before 35 seconds past the minute they could simply wait until 40 seconds past before continuing.

If they are started as say 36 seconds past the minute i.e. after DSLStats has started sampling because it hadn't detected my programs, they could again wait until 40 seconds past before continuing.



3) In the extremely unlikely event that DSLStats sampling & my programs' sampling start at exactly the same time, they could both fail to log in or obtain valid data.

Kitz & I think that happened once while my program was at the login password prompt stage, but she was intentionally attempting to cause a clash at the time in order to provide us both with useful feedback.
My program caught that event & after pausing & trying again a few time it eventually exited accordingly, with a logged error message:-

31/05/2014 13:15:36.75 - CURRENT-ISRUNNING-131536-710 - Start of [HG612_current_stats.exe] *** Version 2.11 Beta - 26/05/14 ***
31/05/2014 13:15:45.01 - CURRENT-ISRUNNING-131536-710 - **** expect("ssword:") FAILED!!! - exiting. Status = 1.

I think the output from the modem for DSLStats's data harvest interfered with the 'expected' password prompt for my program.


There have also been a couple of times when my program continued unhindered, but it caused DSLStats to fail.

We are dealing with minute but critical fractions of a second here so accidental clashing is very unlikely in normal scheduled logging from both sets of programs.

I recently improved error handling in my programs so that if a preset number of attempts to log in or obtain valid data fail, they will now exit rather than continue vainly looping indefinitely.

Previously if one of my programs ended up 'stuck' DSLStats would detect its presence & after 5 continuous instances where sampling would be abandoned it would wait for 30 minutes before trying again, to no avail.

Also previously, if DSLStats caused any of my programs to 'stick' none of our programs would manage to obtain data until the 'stuck' processe(s) were ended.



As mentioned above, please feel free to corect me if I have misunderstood how DSLStats operates.


Do you have any other thoughts on how we could avoid this issue or at least deal with it more robustly than at present?