From owner-freebsd-ports Sun Feb 13 19: 7:40 2000 Delivered-To: freebsd-ports@freebsd.org Received: from mail.utexas.edu (wb1-a.mail.utexas.edu [128.83.126.134]) by builder.freebsd.org (Postfix) with SMTP id 50931494E for ; Sun, 13 Feb 2000 19:07:36 -0800 (PST) Received: (qmail 18282 invoked by uid 0); 14 Feb 2000 03:07:37 -0000 Received: from dial-51-34.ots.utexas.edu (HELO nomad.dataplex.net) (128.83.113.130) by umbs-smtp-1 with SMTP; 14 Feb 2000 03:07:37 -0000 From: Richard Wackerbarth To: Chuck Robey Subject: Re: /usr/ports/ too big? Date: Sun, 13 Feb 2000 20:19:07 -0600 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: In-Reply-To: Cc: freebsd-ports@freebsd.org MIME-Version: 1.0 Message-Id: <00021321052504.06543@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 13 Feb 2000, you wrote: > Excuse me Richard. I don't want to make a real point of it, but you're > partially right. Yes, you're certainly right that ctm of ports is the > major contributor to processing time; but I think I have to make clear, no > one is hurting yet, in that regard. CTM is only using about 60% of the > available clock time on the machine (previous ctm runs, started every 8 > hours, always complete early enough not to interfere fatally with the next > ones). I watch load very carefully to keep it that way. I *did* poll > users about curtailing ctm services on the 2.2 branch in the next quarter > or two, and I think I will do this because of the new RELENG_4 starting > up, but things aren't at emergency point yet. > > The machine is a pentium 120; maybe if things get worse sometime, the > hardware could be upgraded. Contrary to popular belief, there are still a > large number of ctm users. > > I just didn't want folks to think that I would allow ctm to drift into > trouble. I would *not* do that. I didn't want to imply that you would not attempt to provide service in spite of the fact that the load is constantly increasing and the hackers are ostrichs. Truthfully, I'm not sure what the minimum acceptable level of service would be. With so many users using "pull on demand", those left might be satisfied with once/day service, etc. Who knows? However, we could be giving much more frequent service if we were working from a smaller tree. We used to do that, but had to reduce the frequency when my machine started getting near the crisis point. As you, but perhaps not most of the others, know, I provided both the hardware and administration for CTM for a period of time. Finally, I had to give up trying to do it because I couId not handle the load. If we could increase the frequency of service, we might be able to reduce the load on the demand servers, and thus the overall load on the total resources of the organization. However, most of the developers don't care to consider the "social" costs because it doesn't seem to affect them. They get direct access to freefall and are not impacted by "distribution" problems. As I have said, their attitude is "I've got mine and I don't care about anyone else's problems" I'm also sure that ALL the distribution servers are paying some penalty each time they process the larger tree. From my point of view, we are seeing the classic attitude -- throw more hardware at it rather than consider a change to the algorithm so that we use the existing resources more efficiently. The only problem with that is that the long term economics show that you save in the long run by saving a little very many times. And we are still plagued by sandboxers who cannot see over their cubicle walls. -- Richard Wackerbarth rkw@Dataplex.NET To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message