Timers not firing properly

For some reason, when I was creating a Timer to fire, I noticed it was not firing properly.

This is the Timer I am using.

<timers>
<timer name="VibrationTimer" enabled="y" second="30.00" send_to="10"
>
<send>VibrationCheck</send>

</timer>
</timers>


Now, I have it set to fire every 30 seconds...yet it is firing every 50-52 seconds. I tried resetting everything. I just reinstalled Windows a few weeks ago and this is the first time I've had an issue. Is there something I could be doing wrong? I've been using Mushclient since '99 and have never had issues with Timers, so a little confused here.

I just copied and pasted that into an open world I have. Seemed to work fine for me. Try setting the send_to=2 so that you are sure it is actually firing every 30 seconds. If it is, and the script just isn't running every 30 seconds, then the problem is with the script. If it is actually firing every 50-52 seconds, then there are bigger issues at work here.

Is your computer clock working fine?

Yeah, like I said, I just reinstalled windows a few weeks ago. I don't have any viruses or anything as I strictly use this laptop for coding on Mushclient now. I'm really not sure what can be going wrong. I tried all the different formats of making a timer, even the doafter versions and everything is running weird.

Timers are implemented in MUSHclient by periodically checking the list of timers against the current time. The interval of this check is set up in Global Preferences -> Timers.

If you had set that to 50 (seconds) - for some reason - then timers would only be checked every 50 seconds, thus leading to the sort of behaviour you describe. Even setting it to 20 seconds would probably do it, as if the timer was about to fire (eg. at 29 seconds elapsed) then it would check again in 20 seconds (at 49 seconds elapsed).

If this doesn't explain it, we need to establish if timers are out by a factor or an amount. In your described case, you expected 30 seconds, but got 50 seconds. Thus the amount is 20 seconds, however the factor is 50/30 (1.66).

So, you could try adding other timers (or changing the existing one) to see if it is always 20 seconds late, or always 1.66 times late.

For example, if you make a timer to fire in 10 seconds, will it fire in 30 seconds (20 seconds late) or in 16 seconds (1.66 times late)?

Another thing to try would be lots of extra timers (eg. just doing a "send to output" of some test message). Do they all fire at the same (incorrect) time, or randomly fire at different incorrect times? Or do some fire at the correct times and some not?

I know I haven't gotten back to this issue in awhile, but I just tested this this afternoon, with a new setup, on a new system I'm writing that had no timers. This is what happened when I made a new timer that sends to world to "dance" every 10 seconds. As you will see, the first one fires and 4.3 seconds later the next fires...then after it repeatedly goes to 17.5 seconds on average to fire...

I just checked my windows and the clock is running fun, I even ran the update on it and still my timer output in mushclient is lagging. I also just downloaded and re-installed the newest mushclient and still having the problem.

Can you please tell me what timer interval is set up in the Global Preferences -> Timers tab?

It was set at 0 for the above tests. I just uninstalled Mush and re-installed another new copy and still having the issue. The Global preference Interval is at 1 now, which was teh default. I assume it has something to do with my computer, as I tried it on my macpro and my other pc and I dont have the issue on them...its only on this one. Is there any test that I can perform to figure out wtf is going on?

I am mystified by this, particularly as it only seems to happen on this PC.

If you make it to dance every second, do you still have about a 10 second delay?

Seems to be almost a 75% delay, as I tried it with a 5sec timer and it fires every 8.6 seconds and other timers and same issues.

I would still like you to briefly try one firing every second. That might narrow it down a bit to a fixed delay (of a few seconds) or some sort of percentage delay.

I have tried a 1second timer, which was how I noticed the issue in the first place. Each 1second action was taking about 1.7 seconds to fire when set at 1 second. Thats where I came up with the 75%, since the 10seconds was going to 17.5 and the 1 second was going to 1.7.

That is very strange. If it is a simple factor, how about simply making the timer interval smaller? For example, for a 10 second timer, actually type in 7 seconds.

I recently had to debug this issue on my own computer, and traced the problem to the use of QueryPerformanceCounter by MUSHClient combined with my AMD DualCore processor and my use of Windows XP. The specific issue I was suffering from can be read about here: http://support.microsoft.com/kb/895980

The solution, in my case, was to edit boot.ini and add the /usepmtimer line.

I know this is an old bug report, but seeing how it did not seem to reach a satisfactory conclusion and that this was my first port of call in searching for a solution to my timer problems and trying to figure out why they were taking so long to fire, I thought it best to add my own findings and how I solved it for other people with this problem.

I don't see where timers in particular are using the QueryPerformanceCounter, however if doing that solves the problem I am glad to hear it.

Timers use it because they call GetTimeNow in mcdatetime.cpp to both update and reset themselves. GetTimeNow uses both QueryPerformanceFrequency and QueryPerformanceCounter if they're available. Unfortunately, there are a fair number of CPUs where these two commands do not return values you'd expect. My own issue with it was one of these.

It might be useful for there to be an option to not use these commands for checking time. Sure, you lose precision, but better that than not being able to get timers to fire when they're supposed to at all.

I think that if that happens, your windows needs patching to work around the bug and not your MUSHclient. MUSHclient can't be the only application that has faulty behaviour due to bugginess of the CPU implementation of QueryPerformanceCounter.

Hell, you listed the solution yourself in this topic. If anything, I'd recommend putting it into the FAQ so people can find information on the subject more easily.

Your Windows may need patching, yes. Or your BIOS, or the HAL or you might even need new hardware. The fix I mentioned is mainly used for AMD CPUs under Windows XP/2003: fixing it for other CPUs or under different versions of Windows requires different things.

MUSHClient does have the capability to do without QPC as-is: it simply checks to see whether QueryPerformanceFrequency returns anything. When QPC is available and is functioning correctly, it does lead to a more accurate timing than just using GetLocalTime... but it's arguably an unneeded accuracy when GetLocalTime should be accurate down to milliseconds already. I only noticed that my computer was suffering from the issue when MUSHClient's timers weren't working properly -- the system time was updating correctly, as was the GetConnectDuration script command I was using in one of my scripts.

I agree that overall, it's best that the underlying issue is fixed. I'm just concerned that the fix may not be as easy for all systems.

It isn't really the CPU's fault - the OS gives me a way of finding if the performance counter is implemented, and I check it most times. This one slipped through.

The way I understood the problem was that the Windows API gave you an A-OKAY response on the availability of the feature, but returned buggy values. If you weren't checking for the availability.. well, then I agree, MUSHclient needs fixing to check for the availability. :)