[1407] in Release_7.7_team
Re: 8.2.8 slowdown
daemon@ATHENA.MIT.EDU (Greg Hudson)
Thu Jul 30 18:00:26 1998
To: Bill Cattey <wdc@MIT.EDU>
Cc: "Ask, and it will be given you" <mbarker@MIT.EDU>,
Greg Hudson <ghudson@MIT.EDU>, release-team@MIT.EDU, kcr@MIT.EDU,
jhawk@MIT.EDU, ops@MIT.EDU, network@MIT.EDU
In-Reply-To: Your message of "Thu, 30 Jul 1998 17:50:48 EDT."
<ApkCesIGgE6g1nH1xg@mit.edu>
Date: Thu, 30 Jul 1998 18:00:19 EDT
From: Greg Hudson <ghudson@MIT.EDU>
> 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.
It's not that simple. update_ws runs out of reactivate, which does a
bunch of other things too. The machine needs to remain functional
as a workstation while we're waiting for try again later.
> Instead I propose: Is it possible to have the answer to updatesync
> be yea or nay depending on the server load?
It's certainly possible, if we could get a good channel of server load
information to the update sync daemon. But there are things to worry
about here; if 50 machines have just started the update and are busy
deleting outdated files, they're putting no load on the servers, but
they're all going to start putting lots of load on the servers in a
few minutes.
