Author Topic: DS Extreme!  (Read 2573 times)

daelaskai

  • Guest
DS Extreme!
« on: September 21, 2006, 09:38:10 am »

Dead Souls v2.1

From the mudos.cfg file





Below is a segment of the file that controls the basic code limits

for DS. What I am curious about is how far those limits can go, and

what side-effects might come from extreme settings.



I personally am not running a testmud at this time so I am loath to

do any experimenting with this myself. But since I know a lot of

people around here do have such safe environments I thought I could

turn my curiosity into useful information for others.



For myself I know I must turn the maximum array size up, but how

far I can go is the question. There are also some performance

options mentioned towards the bottom of the code, and perhaps we

could come up with some settings tables for people to use when

configing their Mud.



If this information is to be useful then what we report has to

be tested and verified. Just saying 'oh you can set the max array

size to 2 billion if you want' is not the same as actually doing

it, rebooting, and building an array large enough to prove it.



So if you have a testmud, and a little bit of time. Try some

extreme tweeks to the values below and let us know what happened.

Test one thing, or everything, whatever you wish.



 



------------------Begin File-----------------------------------------



# if an object is left alone for a certain time, then the

# function clean_up will be called. This function can do anything,

# like destructing the object. If the function isn't defined by the

# object, then nothing will happen.

# This time should be substantially longer than the swapping time.

time to clean up : 14400



# How long time until an unused object is swapped out.

# Machine with too many players and too little memory: 900 (15 minutes)

# Machine with few players and lot of memory: 10000

# Machine with infinite memory: 0 (never swap).

time to swap : 90000



# How many seconds until an object is reset again.

time to reset : 900000



# Maximum number of bits in a bit field. They are stored in printable

# strings, 6 bits per byte.

maximum bits in a bitfield : 1200



# Max number of local variables in a function.

maximum local variables : 30



# Maximum amount of "eval cost" per thread - execution is halted when

# it is exceeded.

maximum evaluation cost : 5000000



# This is the maximum array size allowed for one single array.

maximum array size : 15000



# This is the maximum allowed size of a variable of type 'buffer'.

maximum buffer size : 400000



# Max size for a mapping

maximum mapping size : 15000



# Max inherit chain size

inherit chain size : 30



# maximum length of a string variable

maximum string length : 200000



# Max size of a file allowed to be read by 'read_file()'.

maximum read file size : 200000



# max number of bytes you allow to be read and written with read_bytes

# and write_bytes

maximum byte transfer : 10000



# Reserve an extra memory area from malloc(), to free when we run out

# of memory and allow the mudlib to shutdown.

# If this value is 0, no area will be reserved.

reserved size : 0



# Define the size of the shared string hash table.  This number should

# a prime, probably between 1000 and 30000; if you set it to about 1/5

# of the number of distinct strings you have, you will get a hit ratio

# (number of comparisons to find a string) very close to 1, as found strings

# are automatically moved to the head of a hash chain.  You will never

# need more, and you will still get good results with a smaller table.

hash table size : 7001



# Object hash table size.

# Define this like you did with the strings; probably set to about 1/4 of

# the number of objects in a game, as the distribution of accesses to

# objects is somewhat more uniform than that of strings.

object table size : 1501



------------------End File-------------------------------------------





A.T

(-)


Offline cratylus

  • Your favorite and best
  • Administrator
  • ***
  • Posts: 1024
  • Cratylus@Dead Souls <ds> np
    • View Profile
    • About Cratylus
DS Extreme!
« Reply #1 on: September 21, 2006, 09:52:58 am »

I'd be interested in knowing the results of such tests as well.



A heads-up, though. These settings may not do what

they imply. The mudos.cfg for Dead Souls was written

around or before 1998. MudOS development went on until

December 2003. I suspect some of these parameters

no longer have the effect they originally did.



For example, a while back I ran into a problem where an

object failed to update because I had coded too many local

variables in it. Problem was, I needed all of them there. I

upped the max local variable parameter in mudos.cfg, but

this did not fix the problem.



I modified the local_options file in the driver source and

recompiled, and that *did* raise that limit to what I needed.



So, be aware that to really push the envelope with DS,

there's a good chance you'll need to be able to modify and

recompile the driver source (or at least edit the local_options

header file and recompile). In unix, this can be complex but is

not a great challenge. In Windows, however, this is something I would

not advise to the casual lib coder.



daelaskai

  • Guest
DS Extreme!
« Reply #2 on: September 21, 2006, 10:09:13 am »

Ok that means we need to do a few more things along the way...



1. Identify which settings in mudos.cfg are fully functional

2. Tag the lines which are not as such

3. Add the contents of local_options to this project



 



A.T

(-)