[MUD-Dev] Ticks?

David B. Held dheld at codelogicconsulting.com
Wed Jun 12 19:46:17 CEST 2002


From: "John Buehler" <johnbue at msn.com>

>> In my event system, there is just a tick timer that gets
>> advanced.  I wouldn't bother checking the system clock, since
>> that gets done often enough already.  I'd just check my tick
>> counter, and infer time that way.  Seems fast enough.
 
> Try a system service that works at a very low level, such as
> elapsed clock cycles.

I assume here you mean something like clock() in ANSI C?  That
probably does give you the highest portable timer resolution, but it
gives you processor time, instead of wall clock time (at least on my
server's implementation, which I assume must be standard-
conforming).

> That avoids the formatting and conversion that the time of day
> calls and such perform.  You only need to know that some thousands
> of clocks have passed (letting you infer elapsed real time), not
> that it's Wednesday, or Eastern Standard Time.  Make those calls
> once per loop, or once per 100 loops, with math to determine the
> current time between actual system calls.  It all depends on the
> characteristics (e.g. uniformity) of your processing loops as to
> what types of mathematical games you can play.

I guess if my server gets severely loaded, to the point where I have
zero wait between ticks, I will consider such options.  For now, I
only have 4 ticks per second (standard Diku clock resolution, but it
seems to work fairly well).  I like the fact that calling
gettimeofday() gives me more or less wall clock synchronization.
And I only call it after I've done all my processing, and I'm
waiting for the next tick, so call overhead doesn't seem important
(unless, of course, it took an ungodly amount of time, and just
calling it one extra time were catastrophic to my timing).  Right
now, I don't have a graphical MUD, so I don't have to worry about
obscenely fast server updates (although, I don't see why you would
necessarily need a much higher tick resolution in a graphical MUD,
either).

Dave


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list