From owner-freebsd-current@FreeBSD.ORG Thu Jan 26 10:11:57 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 10AC916A420; Thu, 26 Jan 2006 10:11:57 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D7CF43D64; Thu, 26 Jan 2006 10:11:44 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id 6C79AC0; Thu, 26 Jan 2006 05:12:05 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id E70B67FA9; Thu, 26 Jan 2006 05:12:01 -0500 (EST) Received: from lists by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F246M-000AgD-Oz; Thu, 26 Jan 2006 10:11:38 +0000 Date: Thu, 26 Jan 2006 10:11:38 +0000 From: Brian Candler To: Poul-Henning Kamp Message-ID: <20060126101138.GA40773@uk.tiscali.com> References: <20060125201450.GE25397@cirb503493.alcatel.com.au> <56988.1138220896@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56988.1138220896@critter.freebsd.dk> User-Agent: Mutt/1.4.2.1i Cc: Peter Jeremy , current@freebsd.org, arch@freebsd.org Subject: Re: [TEST/REVIEW] CPU accounting patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 10:11:57 -0000 On Wed, Jan 25, 2006 at 09:28:16PM +0100, Poul-Henning Kamp wrote: > Right, so we bill users in "full speed CPU second equvivalents" How about "BogoMIPS-seconds"? Seriously... don't forget that the *other* usage of CPU-second accounting is for system administrators to assess the amount of CPU resource used by a particular task, in order to plan when the machine is going to need upgrading. In this case, the administrator is not so much interested in the absolute amount of work done, as the amount of work done as a proportion of total work capacity on a particular machine. That is, if task X uses 1200 CPU-seconds over a period of one hour, that's a third of the total available capacity on that machine [1]. If the CPU were then cranked down to 1/3rd of its clock speed, this task would be using the full CPU capacity - and observing that this process is now using 3600 CPU-seconds in an hour is a useful view of the real situation, rather than some mythical 1200 CPU-seconds which it *would have* used *if* it had been running on a different machine (i.e. a machine similar to this one, but running at a faster clock speed). The machine is maxed out on CPU, and that's what matters. Another way of looking at this is that if the CPU is running at 1/3rd speed then CPU cycles are three times as rare, and therefore three times as expensive. That's not good from the point of view of a timeshare user who pays for CPU seconds, as they end up paying three times as much for the same amount of work [2][3]. But it's realistic, especially if the end user owns, runs and pays for the whole asset (which I suggest is more common than the timeshare user these days) Regards, Brian. [1] Of course a dual-CPU box has a capacity of 7200 CPU-seconds per hour, so 1200 CPU-seconds would be one sixth. I don't see a need to normalise that, even if that means I'm taking a slightly inconsistent position :-) Admins are used to thinking of a 4-CPU box as a kind-of cluster of 4 machines. [2] If today CPU cycles are three times as expensive as normal, because the sysadmin needed to reduce the clock speed (e.g. air conditioning failure?) then the user can always choose to run their application on a different day instead. [3] On a multi-CPU machine, bottlenecks such as RAM I/O may mean that the same sequence of instructions takes more cycles (and hence time) to execute than on a single CPU machine, even at the same clock speed. The timeshare user may also feel unfairly penalised for this - but I don't see there's much that can be done about it. That is, it's very difficult to charge the timeshare user for absolute work done, completely independent of the platform their application runs on. I think it's reasonable to charge them based on the proportion of resource they've used on the actual machine they've chosen to run it on, at the time they've chosen to run it.