[1406] in Release_7.7_team
Re: 8.2.8 slowdown
daemon@ATHENA.MIT.EDU (Bill Cattey)
Thu Jul 30 17:50:50 1998
Date: Thu, 30 Jul 1998 17:50:48 -0400 (EDT)
From: Bill Cattey <wdc@MIT.EDU>
To: "Ask, and it will be given you" <mbarker@MIT.EDU>,
Greg Hudson <ghudson@MIT.EDU>
Cc: release-team@MIT.EDU, kcr@MIT.EDU, jhawk@MIT.EDU, ops@MIT.EDU,
network@MIT.EDU
In-Reply-To: <199807291732.NAA12824@the-light-fantastic.mit.edu>
I've been pondering Greg's proposed slowdown and I have a couple of thoughts:
I dont like using updatesync to tell a server we've started/stopped
updating. It has the risk that if something screws up, like machines
hang during the update, that somebody's got to go onto the update
server, and manually correct the count, or reset it or something.
Instead I propose: Is it possible to have the answer to updatesync be
yea or nay depending on the server load? Then the throttle is directly
related to the ability to answer. This prevents any complexity related
to guessing how many is too many, and to recovering from having lost the
license to update.
Another suggestion: "Try again later" should probably be an exponential
backoff just like all other right thinking network protocols. Ideally,
mimic Van Jacobson slow-start behavior.
-wdc
