|
|
Joined: May 2007
Posts: 27
Ameglian cow
|
OP
Ameglian cow
Joined: May 2007
Posts: 27 |
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
|
|
|
|
|
Joined: Oct 2005
Posts: 1,741
Hoopy frood
|
|
Hoopy frood
Joined: Oct 2005
Posts: 1,741 |
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:
//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
|
|
|
|
|
Joined: May 2007
Posts: 27
Ameglian cow
|
|
OP
Ameglian cow
Joined: May 2007
Posts: 27 |
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.
Last edited by Vliedel; 13/11/08 03:14 PM.
|
|
|
|
|
Joined: Sep 2008
Posts: 62
Babel fish
|
|
Babel fish
Joined: Sep 2008
Posts: 62 |
-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.
|
|
|
|
|
Joined: May 2007
Posts: 27
Ameglian cow
|
|
OP
Ameglian cow
Joined: May 2007
Posts: 27 |
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.
|
|
|
|
|
Joined: Aug 2007
Posts: 334
Pan-dimensional mouse
|
|
Pan-dimensional mouse
Joined: Aug 2007
Posts: 334 |
This is not the signature you are looking for
|
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
/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.
- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
|
|
|
|
|
Joined: May 2007
Posts: 27
Ameglian cow
|
|
OP
Ameglian cow
Joined: May 2007
Posts: 27 |
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:
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.
|
|
|
|
|
Joined: Nov 2006
Posts: 1,559
Hoopy frood
|
|
Hoopy frood
Joined: Nov 2006
Posts: 1,559 |
Hn, how many timers are usually running in your "normal" setup (with scripts)? How many of them are "unnamed" timers? alias test {
var %n = 1, %t = 0
while ($timer(%n)) {
if ($v1 isnum) inc %t
inc %n
}
echo -ag %t of $timer(0)
}
|
|
|
|
|
Joined: Sep 2008
Posts: 62
Babel fish
|
|
Babel fish
Joined: Sep 2008
Posts: 62 |
I decided to up the ante and try 10 files (2.2Ghz Dual Core, mIRC emulated through Wine under Linux):
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.
|
|
|
|
|
Joined: May 2007
Posts: 27
Ameglian cow
|
|
OP
Ameglian cow
Joined: May 2007
Posts: 27 |
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).
Last edited by Vliedel; 15/11/08 10:27 PM.
|
|
|
|
|
Joined: May 2007
Posts: 27
Ameglian cow
|
|
OP
Ameglian cow
Joined: May 2007
Posts: 27 |
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.
|
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
Does this happen consistently or randomly-- if randomly, how often (in some ballpark % ratio) does it occur?
- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
|
|
|
|
|
Joined: Sep 2008
Posts: 62
Babel fish
|
|
Babel fish
Joined: Sep 2008
Posts: 62 |
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.
Last edited by _Memo; 16/11/08 02:08 AM.
|
|
|
|
|
Joined: May 2007
Posts: 27
Ameglian cow
|
|
OP
Ameglian cow
Joined: May 2007
Posts: 27 |
Ok I didn't really feel like doing this, but I did it after all. I narrowed it down to:
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.
Last edited by Vliedel; 17/11/08 01:30 PM.
|
|
|
|
|
Joined: Feb 2006
Posts: 32
Ameglian cow
|
|
Ameglian cow
Joined: Feb 2006
Posts: 32 |
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.
|
|
|
|
|
