Forums Scripts & Popups Max Timer speed?

Well after sending mIRC into a endless timer of 1ms, and a small benchmark for the ammount of times it is called. It seems mIRC only calls the timer 64 times a second?

I've tried on multiple PC's of different CPU's and all have returned 64, 63, or close to that. But NEVER above 64.

Is there a hardcoded limit in mIRC for the max speed of a timer, because for what I need it for I need it to go as fast as possible. It's on a dedicated PC so lag isn't much of an issue..

That is weird, and I get different results for the following...

//unset %test | timerTEST -m 0 1 inc %test | timer -m 1 1000 timerTEST off
-
//echo -a --> %test
--> 63

//unset %test | timerTEST -m 1000 1 inc %test
-
//echo -a --> %test
--> 1000

Also, the timers in the first test ran for 1 second, the timer in the 2nd test ran for 15 seconds.

Using the -h switch didn't make much of a difference in either test, but adding the -c and -d switches to the first test made a huge difference..

//unset %test | timerTEST -cdm 0 1 inc %test | timer -cdm 1 1000 timerTEST off
-
//echo -a %test
--> 1000

Well, that IS weird.

Well both of your examples get roughly 64/sec done. Except the last lives up to the expectation of 1000, it just does it very slowly!

Anyone else got any idea why its like this, or how to fix it? I remember doing the same thing almost a year ago and it still having 64/sec on timers. I know it isn't exactly practicle to need to call something every 1ms, but sometimes it IS needed!

Also, putting "-mc 1000 1" appeared to get it done in 1 second flat oddly. But "-mc 0 1" didn't result in any change..

I disagree...

//unset %test | echo -aet start | timerTEST -cm 0 1 inc %test
-
[12:29:04] start
-
* Timer test activated
-
//timertest off | echo -aet stop --> %test
-
* Timer test halted
-
[12:29:06] stop --> 2485
-

~ Edit ~
Added timestamp.

The timer is not meant to be an accurate to the ms method of time keeping. Any limit is likely imposed by the way the Windows system works, because mIRC tells Windows to inform mIRC of what "1ms later" means. You can, however, try the -h switch, which might improve the results.

Check my first reply, using the -h switch didn't make much difference at all. Also, to the OP, using the -c switch may make everything add up in the end, but it still won't be very accurate during execution because...


So obviously the timers in my examples are executing several times in some intervals to catch up rather than executing once per ms interval as it seems you want.

Yeah. I need it to basicaly check stuff and write results to a file as quickly as possible..

And as for argv0's post, If I do the exact same thing in C it goes a LOT faster.. So it doesn't seem to be a Windows thing . Maybe an mIRC dev could comment on the matter? Never know, it might be an actual bug with mIRC :S

PS, Rock, your test may be inaccurate,

Timers are likely initiated on a queue basis in Windows, so the timer to stop the first timer may likely never be triggered before the first timer finished, not to mention if the claim is that timers are not being accurate, the 1000ms timer wont be any more accurate.

To be safe, you should not use /timer to test the accuracy of your /timer... $ticks would be better

//unset %test | %start = $ticks | echo -a Timer start: %start | timerTEST -cm 1000 1 set %test $!ticks

then check $duration($calc(%test - %start)) when the timer ends



//echo -a $calc((%test - %start) / 1000)

I get 1.014, which is (approximately) in seconds, which is close enough to one second between the first trigger and last trigger of the timer.. makes sense.

What's weird is that using -mh (the supposedly high res timer) executes in FIFTEEN seconds, not one.. hmmmmm

As I said, it *is* mIRC, and no, it's not a bug. The timers are NOT meant for accurate local timing. mIRC script may be used for many purposes, but the language is intended for IRC, where time is accurate to the second, not the millisecond. mIRC posts a WM_TIMER message to Windows and waits for the API to reply to the message-- this is all controlled by Windows.

If you need true high resolution timers, write a DLL. Writing it in C != writing it in "Windows". The Windows API is completely different from low level C, especially at the Window messaging layer.

Yeah I couldn't really think of a way to make the test more accurate without using that second timer, that's why in my one reply I used a timestamp and stopped the test timer manually just to show that it was a lot closer than without the -c switch.

this will help but i found out the number of times changes every time but its around 1,000 or more per second. put this in aliases
timer { set %test 0 | echo -at start | timerTEST -ch 0 1 inc %test | timer1 1 1 timertest off
}
times { echo -a times: %test }

How are you making sure that you are doing the same thing as /timer -m in your C code?

The 64 you get sounds about right. mirc uses SetTimer for its timers and those are of limited accuracy, depending on your hardware (you can find more details on the latter here and here). 64 reps/sec implies a clock res of 15-16msec, which as you found is quite common (there's a little utility that can tell you what your system clock's resolution is).

A multimedia timer, which is what /timer -h uses, can give more accurate results but cannot increase the resolution past that of you system clock.