# HTML + MOO + NT = ???

Christopher Unkel (cunkel@us.itd.umich.edu)
Wed, 5 Feb 1997 18:42:13 PST

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    On Wed, 5 Feb 1997, Don Mitchell wrote:

    > If you think your MOO or ColdMUD is going to be a very big world, NT
    > would be a better choice than W95.  In theory, you should be able to
    > tune the network I/O and use a few I/O threads to get more throughput.
    > I wonder if anyone has experimented with this?  A 'thread per head"
    > doesn't seem wise (i/e/, one thread per connected player), but having a
    > few of them doing the network I/O will practically never block.  You
    > could also try using async I/O (which W95 doesn't do).

    My guess is that for the large majority of MOO applications, a single
    separate thread doing network I/O would be more than sufficient, provided
    that the thread waits simultaneously on sockets to be ready for I/O and
    for server network queues to be ready for I/O.  As a rule, general MOOing
    is a low-bandwidth activity, and the server isn't particularly
    network-bound.  A side benefit of threading the network I/O would be
    eliminating the delay before output starts--if you have a task that does
    lots of output you don't see any until it's not running any more.

    Of course, using a MOO as a webserver is a much different animal, and
    there having multiple threads might well be quite effective.

    Windows Sockets under '95 do support what the Winsock *calls* asynchronous
    I/O; however this just means that messages are posted to the application
    when sockets are ready for read/write.  Since messages aren't processed
    preemptively like Unix signals are, this is unhelpful.

    >  And of course, if you have a
    > multiprocessor PC, multi threading gets you some parallel processing as
    > well.  But read/write blocking is the main reason to do this.  If you
    > think the world is REALLY going to be huge, you probably need Server NT,
    > which unfortunately is expensive.  I know ftp servers running SNT deal
    > with 600 connections or so, but I don't think any MUD on the net is that
    > big.  Furry gets close to 400 on their P-100 machine (they're running
    > NetBSD).

    I don't think that workstation or server will have much impact on the
    performance of a MOO.  As I understand it, the only substatial difference
    is the size of timeslice given to applications; the longer timeslice keeps
    performance from degrading at high load from zillions of context
    switching, at the price of losing some responsiveness.  But with a MOO, a
    single thread is using all the CPU, so it's not so much an issue.
    Actually, the responsiveness of workstation might be an asset--initial
    network output happens that much faster, so overflowing the internal
    network buffer is that much less likely.

    Of course, using NTW 4.0 as a MOOserver with more than 10 users is a
    violation of the EULA, but that's a different story entirely.

    Ultimately, I think MOO size is clearly not currently limited by network
    performance, but rather by the speed at which it can execute MOO tasks.
    Seems to be the case with LambdaMOO itself.

    > Anyway, with NT or UNIX, it would be fun to hear about experiments with
    > multi-threading and async I/O..

    Agreed.  There are other areas that could benefit from multi-threading on
    SMP machines.  Database loading is one--the slowest thing is verb-code
    parsing and that would parallelize easily.  Checkpointing is another.
    I've also had ideas for ways to structure a server so that it could break
    past the one-processor-executing-tasks barrier while maintaining
    appearances that it was happening...

      --Chris                           cunkel@umich.edu
        ResComp Senior Network Support Technician (SNST)
        Home Page: http://www-personal.engin.umich.edu/~cunkel/
        "Invisibility is in the eye of the beholder."