[MUD-Dev] Re: MUD Development Digest

Justin McKinnerney xymox at toon.org
Sat Apr 4 11:01:56 CEST 1998


First, I agree with your first comment. I have heard people claim their
disk-based muds run faster than memory-based, but this all semantics. If a
disk-based game does run notably faster than it's memory-based equivilant,
it's simply due to the fact the operating system is doing a better job of
memory managment (perhaps doing cache alignment, for instance), which
wouldn't be suprising considering some of the code for MUDs I have seen.

I think you are on the right track with the concept of using multiple
processes. The alternative would be to use threads instead (ie: lightweight
processes), however, not only is this not supported under all UN*X (unless
you wanted to compile your own user-level thread library), but tends to be a
lot less clean and relies a great deal on the thread library you are using.
Of course, this is coming from someone who has exprienced re-entrancy
problems in such complex calls as sleep() <grin>. On the other hand, if you
ever want to port to NT, using threads would be highly recomended.

I agree with you that a RAID is a good thing to have, but I do not believe
that it will completely eliminate the possible need for a seprate process to
do disk IO on a large multiuser system. While it's true most RAID systems
have hardware level memory caching, the operating system still blocks all
accesses to the hardware. This causes a sleep state in your process, and if
you have enough access going on, even a large buffer can be heavily
burdened.

Going with a seprate process for all blocking IO guarentees that you will
not loose any processor cycles due to sleep states you did not design your
application to have. This enables you to continue executing, say, the
command of another user while disk IO relative to the first user is being
processed. Then once you've done your roundrobin queue (or however you set
it up) and come back to the first user, the disk IO should be ready.

And remember! Non-blocking syncronous IO is your friend. :)

	- Justin -

> -----Original Message-----
> From: mud-dev [mailto:mud-dev at null.net]On Behalf Of Dr. Cat
> Sent: Saturday, April 04, 1998 2:04 AM
> To: mud-dev at null.net
> Subject: [MUD-Dev] Re: MUD Development Digest
>
>
> I presume the comments about disk-based muds running faster than
> memory-based ones are including the tacit assumption that one is talking
> about muds that don't have the option of running on a machine with a
> large surplus of RAM?  I run a commercial project, and it seems the only
> option for really optimal performance is to make sure you have enough
> RAM to keep everything in memory that you need.  I also don't do a bunch
> of dynamic stuff - I prefer to do all mallocs and loading of maps and
> objects at startup, and keep it there.  I always believe malloc and free
> are the devil's tools for fragmenting heaps and bloating memory usage,
> if used during runtime rather than only at startup and shutdown.
>
> Anyway, my server can currently handle over 150 people quite well with a
> memory footprint of under 32 megabytes.  I don't see any reason why I
> should ever be experiencing a significant number of page faults.  Disk
> reads consist pretty much of just the character name/password file,
> which I presume the OS has mostly in its cache most of the time.
> Writing out logfile info, and maps when a builder uploads a new one,
> both can generate some overhead.  I was planning to set up a seperate
> process that does all disk writes, and have the other processes dump
> data to it and then go on about their business.  But a friend of mine
> told me about how they eliminated their disk-writing bottlenecks when
> they purchased a RAID array for the server, which essentially does the
> same caching of writes into RAM, only it's done for you, in hardware.
>
> I realize that purchasing a RAID array isn't an option for most hobby
> projects.  Still, I would think that disk-based servers would be faster
> for some muds, not for all muds.  (Depending on memory footprint,
> configuration of the machine in question, and whether it's running other
> things besides the mud or not.)
>
> *-------------------------------------------**--------------------
> ---------*
>    Dr. Cat / Dragon's Eye Productions       ||       Free alpha test:
> *-------------------------------------------**
> http://www.bga.com/furcadia
>   Furcadia - a new graphic mud for PCs!     ||  Let your imagination soar!
> *-------------------------------------------**--------------------
> ---------*
>




More information about the mud-dev-archive mailing list