[Encore] Quotas

[Kevin Jepson]

Dave
 
There is a forked task that runs periodically and recalculates all the info
used in the quota calculations.  This task only runs once every 24 hours by
default so if you recycle a lot of objects you should call it manually
afterwards.
 
There is a lot more info on how to fine tune this system which you can get
from help $byte_quota_utils. 
 
There are a couple of other gotchas in this system to be aware of.
Players are only allowed a certain amount of "unmeasured objects" (by
default I think it's something like 10)before an attempt to create anything
returns an "insufficient resources" error. The player's quota may be fine
but if they have been building and recycling a lot of stuff the system just
hasn't caught up yet. An @measure new will fix that.
 
The other has to do with the default lag value in EnCore. This value is 6
which means that any verb which suspends does so for a minimum of 6 seconds!
Time/Tick intensive tasks like @measure and @recycle etc will be very slow
on large databases if the fix Alexandre Borgia posted here isn't done:
<http://www.encore-consortium.org/Barn/files/docs/how-to
<http://www.encore-consortium.org/Barn/files/docs/how-to speed up
enCore.txt> speed up enCore.txt>  Making this worse is that the regular
daily measurement task will stop if it takes too long (500 seconds by
default) and whatever is left gets defered to the next days run.
 
I suspect that may be what you are seeing.
 
You could try changing the default measurement times or run it manually a
couple of times a day when there is a lot of building going on.
 
Ciao
KJ
 
 

 
  _____  

From: David Houghton [mailto:DJH at dmu.ac.uk] 
Sent: Thursday, October 18, 2007 4:19 AM
To: Kevin Jepson
Subject: RE: [Encore] Quotas



K

 Thanks, I get the picture. One other thing though, there seems to
be a huge delay in the recycling of objects. This gives the appearance
of running out of quota but in actual fact it is not the case.

reagrds

--

Dave Houghton
Systems Manager
Faculty of Humanities
Clephan Building, Room 00.07a
De Montfort University
Leicester LE1 9BH

Tel. No : +116 207 8260
Email   : djh at dmu.ac.uk




-----Original Message-----
From: Kevin Jepson [mailto:kevijeps at telusplanet.net]
Sent: Wed 17/10/2007 15:23
To: David Houghton; encore at encore-consortium.org
Subject: RE: [Encore] Quotas

Hi David

As others have said the number is in Bytes.

Originally the LambdaMOO system did not have any quota system at all!

This resulted in a serious problem with Database bloat, large numbers of
objects that weren't doing anything useful.

The first quota system was based on the number of objects, which was easy to
program but did not take into account the complexity of the objects. So the
system was modified to use the size of the objects in bytes. There is a
switch that changes the Quota calculation between objects and bytes. Encore
uses bytes by default.

There are several commands that can help you figure out what peole have been
building
@quota
@audit
@measure

These are all run from the text side.
If you type help quota, help audit and help measure you will get lots of
info on these verbs.

Ciao
KJ

  _____ 

From: encore-bounces at encore-consortium.org
[mailto:encore-bounces at encore-consortium.org] On Behalf Of David Houghton
Sent: Wednesday, October 17, 2007 2:25 AM
To: encore at encore-consortium.org
Subject: [Encore] Quotas





Hello

 Could some kind soul clarify for me the meaning of quotas. In the past
 we have used @quota <player> is <number> where the number is bits (eg
700000)

 I read in the "Wizards Basics and help on maintaing your own moo" that
 that it talks about object quotas and a limit of 10.

 We'd like our students to have 30 or 40 objects.

yours confused....

--

Dave Houghton
Systems Manager
Faculty of Humanities
Clephan Building, Room 00.07a
De Montfort University
Leicester LE1 9BH

Tel. No : +116 207 8260
Email   : djh at dmu.ac.uk







-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://encore-consortium.org/pipermail/encore_encore-consortium.org/attachments/20071018/5174c5b1/attachment-0001.html