06 Apr, 2009, Ubasti wrote in the 1st comment:
Votes: 0
Quote
The MUD server is allocated 2g, and 2% of that is about 41mb, which is what people are allowed,…..


I lifted that quote from Banner's thread for his hosting service.

i was freecycled an old desktop. The person who had given it to me didn't know the specs, but I said that I would take it anyway. It has a 500Mz Processor, 64mb or ram and a 15g HDD. At first I wanted to use it to host a small website, but then I got the idea to put eventually throw my MU* on it so I can play around with it. But I cannot for the life of me find the system requirements for any codebase.

I plan on using Ubuntu's alternative install which requires:
Quote
Absolute minimum requirements
Intel 486 processor
32 MB of system memory (RAM)
300 MB of disk space

Absolute minimum graphical installation
Intel Pentium 66 MHz processor
48 MB of system memory (RAM)
468 MB of disk space
VGA graphics card


Edited: I quoted the wrong OS requirements. The above has been edited for the text-based bare minimum install. Before I had the mininum for the normal alternative install, which will work, but it may not work well, according to the Ubuntu homepage.

So, I have the OS covered. But will this work OK to run a mud?

I'm just being lazy, but I've given thought on just taking the HDD out and putting it into my current computer and use it there. I'm not a hardware person, but I'm hoping that would work too. I could go the free/cheap hosting route, but I'd like to try out different codebases at first and I was thinking this may be the easiest way.
06 Apr, 2009, Cratylus wrote in the 2nd comment:
Votes: 0
wyncha just try it?

short answer, probably thats enough for most codebases. A few outliers
like coffeemud will choke on it prolly, but generally it's fine, if you have
the right OS for such a weak machine.

Out of perverse curiosity I loaded my codebase (which is relatively
resource hungry) onto a pentium 133 with 40m of ram, and it ran fine.

A dikurivative should do just dandy…again, assuming your OS isn't lame.

-Crat
http://lpmuds.net
06 Apr, 2009, Ubasti wrote in the 3rd comment:
Votes: 0
Cratylus said:
wyncha just try it?


True! Just wanted a heads up, is all. :)

This is going to be something.
06 Apr, 2009, Kline wrote in the 4th comment:
Votes: 0
I'd certainly recommend ccache and using dependency files. Your compile speed is going to be painfully slow enough anyhow, so you might as well try to help it as best you can :P
06 Apr, 2009, Zeno wrote in the 5th comment:
Votes: 0
I wouldn't recommend ccache.
http://www.smaugmuds.org/index.php?a=top...
I had that same problem when I tried it.
06 Apr, 2009, Kline wrote in the 6th comment:
Votes: 0
I routinely compile 3 separate MUDs and test-build various other ones just to see how a feature works, etc…For a few months now. I'm just under 1gb in my cache size (I am the sole user of my home box this runs on). What problem did you encounter exactly? I've never had an issue with it putting old code or anything else in, and my poor Sempron does appreciate the assistance :).
06 Apr, 2009, Zeno wrote in the 7th comment:
Votes: 0
06 Apr, 2009, Kline wrote in the 8th comment:
Votes: 0
Ah interesting, sorry I somehow managed to entirely glance over those the first read through, lol.
07 Apr, 2009, The_Fury wrote in the 9th comment:
Votes: 0
Throw a couple of decient sticks of ram in that and you will have an uber server, shuld be able to pick up 2ndhand ram for it for a few bucks, there is a shop here with PC100 ram for $5 per 256meg stick.
07 Apr, 2009, David Haley wrote in the 10th comment:
Votes: 0
You can get a lot of benefit just from using precompiled headers, without a lot of ccache's drawbacks. (Of course, precompiled headers are a somewhat experimental in gcc/g++, but hey…)
07 Apr, 2009, elanthis wrote in the 11th comment:
Votes: 0
ccache works fantastically. yes you actually have to know how to use it, but the same is true of any other development tool. if you can't figure it out, you don't need to be coding on a public game server.

precompiled headers can help a lot, but not nearly as much as ccache, especially for C++ where most of the work involves instantiating templates and not parsing the text. be warned that you can easily get precompiled headers to crash gcc even on the latest release, and in other cases precompiled headers can totally throw off the error reporting. if you use a precompiled header, move all your system headers to it, and make sure you remove them all from the source files that the precompiled header is included from. if you include the same header twice, weird things may happen (usually they don't… but usually != always).

it's pretty easy to use ccache. if your host does not want to install it out of fear that the other people he's hosting might hurt themselves with it, it's quite easy to just install yourself. there's no reason for you to need the host to install software like that when you can just download the tarball, unpack it, compile it, and install it to ~/local or something. Add ~/local/bin to your PATH in your .profile and off you go.
07 Apr, 2009, quixadhal wrote in the 12th comment:
Votes: 0
Well, the DikuMUD we used to run at university ran on a Sun 4/110 with 16Megs of RAM and doubled as the campus usenet server. We typically used about 9M of RAM and had around 40 players on at a time. I suspect we used about 5M of disk space, including log files.

We originally ran on a Sun 3/60, but we had to limit the number of players to 25 to avoid having the machine nosedive. I believe that machine only has 12M of RAM.

For comparison, a Sun 3/60 used a Motorola 68040 CPU running at 20MHz, and was probably the equivalent of a 386/40 in terms of performance. The Sun 4/110 used a Sparc CPU, also running at 20MHz?, and was more like a 486/40.

Frankly, you'd be hard pressed to find a used machine that is NOT powerful enough to run almost any mud out there, possibly excepting CoffeeMUD (as it's a pretty feature-rich java beast). I could probably run 10 copies of our old mud in VM's on my desktop and still play World of Warcraft with no lag.
07 Apr, 2009, Wodan wrote in the 13th comment:
Votes: 0
Wow, I expected we used a bit more than average, but the difference is stunning compared to the posts so far.
Discworld uses 2 GB (2048MB) after 2 days uptime and slowly grows from there, it would never run on any of those systems :) (although we did run on such hardware in the past)
Unless we're talking empty stock muds, in which case I'm pretty sure the last shipped dwlib release runs fine in 16MB!
08 Apr, 2009, Guest wrote in the 14th comment:
Votes: 0
At our peak, Alsherok consumed at most about 50MB of memory. That was with an average of 50 players at a time during peak hours, with the following stats:
Quote
Total number of zones in the world: 121
Total number of rooms in the world: 10647

Number of distinct mobs in the world: 2391
Number of mobs loaded into the world: 7146

Number of distinct objects in the world: 2779
Number of objects loaded into the world: 13489

Current number of registered players: 22
All time high number of players on at one time: 295


And no, that all time high figure is wrong. I have no idea what the correct number is cause until today I hadn't even noticed it was bad. Likely 55-60 though.

Currently the idling game hovers around 30MB, but this is after having spent a lot of time on trimming code and doing C++ conversions on things.

I can't really fathom how any one single text based game could eat up 2GB since I figured 50MB was exceedingly wasteful :)
08 Apr, 2009, David Haley wrote in the 15th comment:
Votes: 0
It depends on how the program is allocating memory. If it allocates a huge chunk of heap (like some Java VM implementations do) then it will appear to be using a huge amount of memory, but the majority of it won't actually be resident in memory. I'd be very, very surprised if Discworld were actually using all 2GB of its memory. I suspect that a far, far smaller number needs to be resident at any given time, and the rest can be swapped out.
08 Apr, 2009, Ubasti wrote in the 16th comment:
Votes: 0
Wow, I was thinking about running CoffeeMud, too. I found an external 250gig HDD that I thought I had left in DC. I'll just use the VM there. I just may be alot easier that way. It should be more than enough room for CoffeeMUD, PennMush and whatever else I want to play around with, I guess.
08 Apr, 2009, Wodan wrote in the 17th comment:
Votes: 0
David Haley said:
It depends on how the program is allocating memory. If it allocates a huge chunk of heap (like some Java VM implementations do) then it will appear to be using a huge amount of memory, but the majority of it won't actually be resident in memory. I'd be very, very surprised if Discworld were actually using all 2GB of its memory. I suspect that a far, far smaller number needs to be resident at any given time, and the rest can be swapped out.


You'd think so, but no, when the system starts to swap even tiny bits out, the mud slows down instantly, we're really using it all!

200000 objects for 2.2GB at the moment after 2 days and 17 hours.

I see Samson has 50MB for 13489 objects, so ehm, we use slightly over three times the memory per object, that could be because we're running in LPC which uses a VM like thing. Or maybe our objects are just more interesting :)

The main thing is that we have so many things loaded, I blame player housing!
08 Apr, 2009, quixadhal wrote in the 18th comment:
Votes: 0
Heh, you could always implement a "portal" system like the old AberMUDs had, and put all the player housing on a second server that people get sent to when they enter a house. *grin*

Yeah, I'm kidding….

Mostly…

*grin*
08 Apr, 2009, elanthis wrote in the 19th comment:
Votes: 0
2.2GB for 200,000 objects is insane. That's over 10MB per object in the game. Even if you had 2,000,000 objects, there's no reason each needs an entire 1MB (that's one million bytes… a million!) There is no excuse for that, not even a little bit. LPC is very unlikely to be the culprit, as other VM-based systems run with far larger data sets without chewing up that kind of memory. Something is flat out wrong. My guess is that you just have a massive memory leak that you need to fix instead of throwing more hardware at the problem.
08 Apr, 2009, Wodan wrote in the 20th comment:
Votes: 0
elanthis said:
2.2GB for 200,000 objects is insane. That's over 10MB per object in the game. Even if you had 2,000,000 objects, there's no reason each needs an entire 1MB (that's one million bytes… a million!) There is no excuse for that, not even a little bit. LPC is very unlikely to be the culprit, as other VM-based systems run with far larger data sets without chewing up that kind of memory. Something is flat out wrong. My guess is that you just have a massive memory leak that you need to fix instead of throwing more hardware at the problem.


Oh, I'd be upset if we were anywhere near that, but last time I checked 10 million times 200 000 is 200GB, we're nowhere near :)
0.0/20