[MUD-Dev] Ticks?

[John Buehler]

David B. Held writes:
> 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).

I dunno which service to use, but I'd go with whatever was closest
to the hardware.  If you've got one place where you worry about
time, hand code the derned thing.  Drop down to assembly level if
that saves you enough cycles.  I'm only offering this in the
assumption that you're burning too many clocks on figuring out the
elapsing of time.

I wasn't thinking in terms of ANSI C, but more in terms of Windows
system service calls.  For Unix flavors, ANSI C is probably most
practical.  Walking through a call chain to an ANSI C implementation
can be pretty revealing.  Make sure you know what that ANSI C call
is actually doing.

>> 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).

Sure.  It's all up to you as to where to place the tradeoffs.  As
others have said, for a small MUD, you don't need grand
architectures, nor do you need to worry about how many time() calls
can dance on the head of a pin.

JB

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