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?