Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: 1 2 3 [4]

Author Topic: DSLstats pre-release version 4.54.4  (Read 14967 times)

roseway

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 43467
  • Penguins CAN fly
    • DSLstats
Re: DSLstats pre-release version 4.54.4
« Reply #45 on: June 03, 2014, 08:40:05 AM »

Quote
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.

It actually can start between 35 and 40 seconds past the minute. If you press the green button between those times it will start sampling immediately, otherwise it will wait until the next 35 seconds past the minute. It will skip a maximum of 5 samples in succession, after which it will bypass the check for 30 samples. With the new networking library, sampling takes between 1 and 5 seconds (generally less than 3 seconds).

Quote
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.

That's what it does. After each message is sent to the modem, it waits until the prompt returns before sending the next message. It automatically detects what the prompt is.

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

There is some sort of critical timing issue associated with this, and no doubt other factors as well, so the best solution will be to try to avoid clashes altogether.

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

Yes, I think I could do that. I'll have to think about what form the dummy program will take (it needs to sleep while running so it doesn't use CPU cycles) but I should be able to do that.

Quote
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.

From my viewpoint, that would be the best solution. When the "co-operation" option is set in DSLstats, I can almost guarantee that sampling won't be happening outside the times of 35-45 seconds after the minute (assuming a maximum of 5 seconds for sampling). The only exception to this would be some unexpected error condition in the program, and I'm currently enhancing the error trapping to try to eliminate this possibility. So if your programs could restrict their activities to the period from 45 seconds after the minute to the next 35 seconds after (including processing time) that would largely eliminate all clashes.

I expect I'll have some more thoughts, but I have to go off and do things now.
Logged
  Eric

roseway

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 43467
  • Penguins CAN fly
    • DSLstats
Re: DSLstats pre-release version 4.54.4
« Reply #46 on: June 03, 2014, 11:07:16 PM »

(Continuing)

Quote
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.
..
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.

The changes I've recently made should result in DSLstats behaving in a similar way: while in the telnet interface, every command sent to the modem is error trapped, a timeout is included in case the command fails to return, and the results are logged. So, hopefully, if a clash does occur, the programs should be able back out without misbehaving.
Logged
  Eric

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33879
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: DSLstats pre-release version 4.54.4
« Reply #47 on: June 04, 2014, 12:28:36 AM »

Note for BE.

Ive given Eric a copy of the steps I sent to you via email the other night of how I can repeatedly cause a clash, which causes DSLstats to display strange behaviour.   In particular the Incorrect login name or password, and not being able to close it until it displays the div by 0 error.
 
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

Bald_Eagle1

  • Helpful
  • Kitizen
  • *
  • Posts: 2721
Re: DSLstats pre-release version 4.54.4
« Reply #48 on: June 04, 2014, 12:44:46 AM »

Thanks, Kitz.

I think we are now very close to ensuring 100% compatibility between the programs.

We just need to be careful to avoid fixing one issue that could introduce a different issue.

As long as Eric & I are fully aware of what we are doing with our respective programs, everything should be just fine & dandy  :)


Logged

Bald_Eagle1

  • Helpful
  • Kitizen
  • *
  • Posts: 2721
Re: DSLstats pre-release version 4.54.4
« Reply #49 on: June 05, 2014, 07:47:35 AM »


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

Yes, I think I could do that. I'll have to think about what form the dummy program will take (it needs to sleep while running so it doesn't use CPU cycles) but I should be able to do that.

Quote
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.

From my viewpoint, that would be the best solution. When the "co-operation" option is set in DSLstats, I can almost guarantee that sampling won't be happening outside the times of 35-45 seconds after the minute (assuming a maximum of 5 seconds for sampling). The only exception to this would be some unexpected error condition in the program, and I'm currently enhancing the error trapping to try to eliminate this possibility. So if your programs could restrict their activities to the period from 45 seconds after the minute to the next 35 seconds after (including processing time) that would largely eliminate all clashes.

I expect I'll have some more thoughts, but I have to go off and do things now.


As a temporary measure, the programs that harvest stats (HG612_stats.exe & HG612_current_stats.exe) now check if DSLStats is running.

If not, they will continue as normal.

If DSLStats is running & the time is greater than 32 seconds past the minute & less than 45 seconds past, they will wait until 45 seconds past before moving on to login to the modem & harvest the stats.

e.g. if the time is 32 seconds past the minute, the programs will wait for 13 seconds.
      if the time is 36 seconds past the minute, they will wait for 9 seconds
      if the time is 42 seconds past the minute they will wait for 3 seonds (just in case).


My preference would still be to check for a dummy process started by DSLStats that only runs during the sampling period.
My programs would then only need to wait until DSLStats sampling had completed rather than have to wait until 45 seconds past the minute.


If my programs start just before 32 seconds past the minute, they will continue as normal as DSLStats checks for them running & either waits for them to complete or aborts sampling for that minute.

If my programs do end up stuck in a loop, failing to obtain any valid data from the modem, they should exit cleanly, also freeing up the modem to be ready for the next attempt.




The only potential problem area I can think of at the moment would be if a user has sufficiently & permanently delayed the start of my programs or perhaps has 2 instances running for testing purposes or as a belt & braces back up system, one copy starting on the minute & the other copy starting at say 30 seconds past.

In those cases from a very slow PC, it is possible that one of the programs could still be running when DSLStats is due to start sampling.



For any of these checks & clash avoidance measures to work, DSLStats & HG612 Modem Stats programs do have to be running on the same machine in order to check for each other.

Using seconds past the minute alone as the criteria for clash avoidance measures would not always work if running the programs on different machines either as each machine's system time can & occasionally does drift out of sync with system time on the other machine, leading to each machine attempting to access the modem at the same time.

This can also cause clashes when running instances of the same program on separate machines.


I have attached copies of HG612_stats.exe & HG612_current_stats.exe if anyone wishes to test the clash avoidance measures.

Evidence of avoidance action should be visible in CURRENT_ERROR.LOG_file_ERROR.TXT & ONGOING_ERROR.LOG_file_ERROR.TXT

e.g:-

**** From IsRunningVB.exe, DSLStats.exe *IS* running 1 instances - seconds past the minute = 34
**** Sleeping for 11 seconds


Logged

roseway

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 43467
  • Penguins CAN fly
    • DSLstats
Re: DSLstats pre-release version 4.54.4
« Reply #50 on: June 05, 2014, 08:02:00 AM »

Quote
My preference would still be to check for a dummy process started by DSLStats that only runs during the sampling period.
My programs would then only need to wait until DSLStats sampling had completed rather than have to wait until 45 seconds past the minute.

Later this morning I'll be uploading a new test version which does this. At the start of sampling it runs a dummy program called dslstatssampling.exe, and when sampling is complete it closes this program. As a backstop in the event of something going badly wrong, the dummy program times out after 20 seconds (perhaps I should make this 10 seconds?).

Logged
  Eric
Pages: 1 2 3 [4]
 

anything