Subject: onc() induced lag...

From: Andrew Wilson <[email-masked]>
Date: Wed, 13 Jan 1993 12:33:05 -0800

Haakon espouses: (espouses?  does that mean he's married or something?)

> I have just made changes in the server code to limit the possible delay
> to about five seconds; if the connection can't be made in that time,
> E_INVARG is raised.

Mmmm, I don't think five seconds will be enough.  Could you make it closer to
15 seconds for us folks in Europe and the rest of the world.  The internet
wasn't built by Ferrari you know.  At the very least it should be a 'tuneable'
(sp?) property which could be set at server-compile time.

Networker (a few seconds later).

Oh, on another, not entirely unrelated tack, can we have a wiz-only
built-in, 'set_maximum_task_ticks(<value>)', which can be used to alter
the number of ticks granted to a task before it is killed, or more often
before a :suspend_if_needed is called and fills up the task queue in LambdaMOO
lag fashion.  I've been reading up on my degree-level operating systems text
books and they reckon that simple scheduling mechanisms, specifically the
'round-robin' queue can frequently promote lag in the systems they exist to
manage.  The consensus solution in such circumstances is to INCREASE the
maximum task time for any task's running in near-lag conditions and so
reduce the liklehood of the task queue filling with suspended tasks.
  I'll give references if anyone wants them, sorry I don't have them on hand
right now.  Either way, I'm no expert, but what do people think about the idea
of there being some MOO-code way of influencing the behaviour of the queue
under lag conditions.  Of course :suspend_if_needed would need to be altered
to increase the tick allotment when it detected a lag.

:Networker_if_needed(<you know where to call>);

---

From: Pavel Curtis <[email-masked]>
Date: Wed, 13 Jan 1993 19:24:45 -0800

> Date:	Wed, 13 Jan 1993 12:33:05 -0800
> From:	Andrew Wilson <[email-masked]>
> 
> wasn't built by Ferrari you know.  At the very least it should be a
> 'tuneable' (sp?) property which could be set at server-compile time.

I will make it a parameter in the options.h file in the distribution.  However,
I think you'll be better off keeping it small and letting the MOO code do the
retrying instead of the kernel, since that way other MOO tasks will get a
chance to run while you're trying.

> 'set_maximum_task_ticks(<value>)'

If you want this to change the number of ticks allotted to *all* tasks in the
system, then it really ought to be called something like
`set_scheduler_parameters' and take four arguments, giving the numbers of
ticks/seconds for foreground/background tasks.  I'm not entirely averse to
providing such a facility.

If, on the other hand, you want this to apply just to the task calling this
function, I'm a bit less enthused.  I don't keep track of per-task limits right
now and would have to torque things around a bit to make it happen.

I'm not very enthused about the whole thing, though, since I'd rather not
encode too many assumptions about the scheduling algorithm into the language.
I'd like to be able to make significant changes to that algorithm without
breaking a lot of code.

> I've been reading up on my degree-level operating systems text
> maximum task time for any task's running in near-lag conditions and so reduce
> the liklehood of the task queue filling with suspended tasks.

This makes sense only if you have reason to believe that the queues are getting
filled up with tasks that, if ONLY given a bit larger quantum, would finish
sooner.  My feeling, though, is that most of our lag (that's not due to
external forces, like thrashing) is due to long-running tasks that would not
finish substantially sooner given larger quanta.

	Pavel

---

From: David Miller <[email-masked]>
Date: Thu, 14 Jan 1993 10:54:17 -0800

|I will make it a parameter in the options.h file in the distribution.
|
|...
|
|If you want this to change the number of ticks allotted to *all* tasks in the
|system, then it really ought to be called something like
|`set_scheduler_parameters' and take four arguments, giving the numbers of
|ticks/seconds for foreground/background tasks.  I'm not entirely averse to
|providing such a facility.
|
|...
|
|I'm not very enthused about the whole thing, though, since I'd rather not
|encode too many assumptions about the scheduling algorithm into the language.
|I'd like to be able to make significant changes to that algorithm without
|breaking a lot of code.

Having been burned numerous times by compiled-in limits and options in
many applications, I'm all for an interface to let me tweek these at
runtime.  Perhaps something like:

	value get_server_option(string)

		Returns the value of the named option.  If the string
		is "all", a list of the server option names is
		returned.  Returns E_VARNF if the string is not a
		server option or "all".

	bool set_server_option(string, value)

		Sets the passed server option to the passed value.
		Returns true if the change was made.  Returns E_PERM
		if the caller does not have wizard perms, E_VARNF if
		the string is not a valid option name, E_INVARG if the
		value is of the wrong type, or E_RANGE if the value is
		out of range.

The first time I built LambdaMOO, I used the defaults for foreground
and background ticks and seconds.  After a little use, I found I
needed to raise these values, since ``help index'' was running out of
time.  So I had to built it again with higher fg limits.  A little
while later, we added anonymous ftp to the server machine.  Lo and
behold, ``help index'' broke again.  Rebuild again with higher limits.

Typing:
	; set_server_option("FG-SECONDS", 20)

would have been much easier!

DavidM
-- 
DavidM			CATS - Commodore Applications and Technical Support
+1 215 431 9425		[email-masked]
"Commodore Amiga 3000UX - Born to Run UNIX SVR4"