wrong delay with /timer - mIRC Discussion Forums

When searching for a bug i found out that:
//!timer 1 1 echo -agt test
took about 10s to echo, while:
//!timer -m 1 1000 echo -agt test
did have the correct delay of 1s.

Now I know you'll probably not be able to reproduce it, I've never seen it either. What I would like to know is the difference between -m and a normal timer, because there must be some reason for one to work and the other not.

It happens on a pc with window server web, 32bit

mIRC timers aren't meant to be 100% accurate. You can use the -h switch on millisecond timers to be as accurate as mIRC can be. I used this code to calculate actual timer delays:

Code:


//set %ticks $ticks | timer 1 1 echo -a $($calc($ticks - %ticks),0) $+ ms

//set %ticks $ticks | timer -m 1 1000 echo -a $($calc($ticks - %ticks),0) $+ ms

//set %ticks $ticks | timer -h 1 1000 echo -a $($calc($ticks - %ticks),0) $+ ms

The 1 second delay varied a lot in my tests, from 1300-1500ms. The -m millisecond delay was always 1014ms, and the -h millisecond delay was always 998ms.

-genius_at_work

well you're talking about tens of a second difference, which is indeed acceptable. But I have a difference of seconds...

normal: 2589ms 2216ms 5102ms 3339ms 1420ms
-m: 1014ms 1014ms 1014ms 1014ms 1014ms
-h: 1014ms 998ms 999ms 998ms 998ms
normal again: 5039ms 2636ms 1014ms 1420ms 6396ms

Now I always thought -m works the same as a normal timer, with the only difference that you have to multiply with 1000. But it seems it must use some other method to delay as it works so much better.

-m uses a multimedia timer (If I remember correctly)
-h uses a high-resolution multimedia timer

Regular timers use a message queue, where as multimedia timers use a callback. I'd say your server probably just has a lot of calls to its timer service and the scheduler is overloaded at times.

Quote:

I'd say your server probably just has a lot of calls to its timer service and the scheduler is overloaded at times.

That's hard for me to believe, since when it only runs mirc with 20 running timers, it still has the long delays.

-m is milliseconds

/timer 1 1 works fine over here, always has. I suspect this doesn't happen in a clean copy of mIRC with no scripts running. It would be really hard to justify how /timer 1 1 not working would have gone unreported until now in proper installations of mIRC.

Ok you were right, on a clean install the delay was indeed fine. So I've been trying to locate the cause of the large delays (as cpu load only showed peaks up to 5%).
So i tried this test script:

Code:

alias test {
  .timer 1 1 echo -sgt $!calc( $!ticks - $ticks ) ms
  var %i = 1000
  while (%i) { .signal test | dec %i }
}
on *:SIGNAL:test:{ var %i = 10 | while (%i) { dec %i } }

With the on signal script in 5 (empty) files.
This script gave me cpu load peaks of 40%, but still delays of < 2s. So if you have any other suggestions to test, they are welcome.

Hn, how many timers are usually running in your "normal" setup (with scripts)? How many of them are "unnamed" timers?

Code:

alias test {
  var %n = 1, %t = 0
  while ($timer(%n)) {
    if ($v1 isnum) inc %t
    inc %n
  }
  echo -ag %t of $timer(0)
}

I decided to up the ante and try 10 files (2.2Ghz Dual Core, mIRC emulated through Wine under Linux):

Quote:

1435 ms
1484 ms
1488 ms
1530 ms
1476 ms
1477 ms
1457 ms
1467 ms
1479 ms
1473 ms

22% peak. However, this has nothing to do with the timer accuracy. mIRC isn't multi-threaded, so you're waiting for 102,000 iterations of execution to complete before any other processing can occur (i.e. checking the time scope of the timer). That's A LOT for mIRC. mSL isn't designed to compete with other interpreted languages, it's for an IRC client. Now.. there is a DLL that exists called Whilefix that you might be interested in. I've never personally used it, but it allegedly allows processing to continue outside of while loops. Give a try.

Originally Posted By: Horstl

Hn, how many timers are usually running in your "normal" setup (with scripts)? How many of them are "unnamed" timers?

Well when I just checked there were 16 all named, with the test i was also running 20 timers (numbered).

Thats what i was trying to say: even though normally mIRC has less todo (see cpu load peaks) it has those large delays of 1-10 seconds. While with the test script, which also fills up the msg queue and has a larger load on the cpu the delay is only 1.5 seconds. So it must be something else, but i can't think of what.

Does this happen consistently or randomly-- if randomly, how often (in some ballpark % ratio) does it occur?

If you could narrow down a particular timer (and relevant code regardless of how spider-webbed it is), perhaps it could be reproduced consistently by us which could probably lead to a more viable answer/solution, or as well as confirmation of this as a bug.

Often scripters lean towards straight forward coding practices, which in more than less of most cases are unfit for optimal performance. With so many timers running, I'd have to say ruling out the code (attached to those timers) would be relevant to confirming this as a non-limitation of mSL, until it becomes multi-threaded.

Ok I didn't really feel like doing this, but I did it after all. I narrowed it down to:

Code:

alias -l timed.checks {
  .timer.checks. $+ $1 1 10 timed.checks $1
}

alias starttest {
  .timer.checks.48 1 10 timed.checks 48
  .timer.checks.57 1 10 timed.checks 57
  .timer.checks.40 1 10 timed.checks 40
  .timer.checks.1 1 10 timed.checks 1
  testtime
}

alias -l testtime { .timer 1 1 echo -sgt $!calc( $!ticks - $ticks ) ms $chr(124) testtime }

This should show: ~1000 ms every second. But instead (tested on 6.35 at different pc's) it echoes like:

[13:33:31] 1000 ms
[13:33:32] 1000 ms
[13:33:33] 1000 ms
[13:33:34] 1000 ms
[13:33:35] 1000 ms
[13:33:40] 5000 ms
[13:33:41] 1000 ms
[13:33:42] 1000 ms
[13:33:43] 1000 ms
[13:33:44] 1000 ms
[13:33:45] 1000 ms
[13:33:50] 5000 ms

For each extra timer, the delay is 1s larger. It seems to execute only 1 timer command per second.

Also just found out, when using another timername than the one that triggered the alias fixes it.

Confirmed with Vliedel using mIRC 6.35, trying to set a timer with the same name which just activated the command causes it to pause for a second.