From owner-freebsd-arch@FreeBSD.ORG Fri Jan 27 20:48:34 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D1E316A420; Fri, 27 Jan 2006 20:48:34 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0509643D48; Fri, 27 Jan 2006 20:48:33 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k0RKmVUW047825; Fri, 27 Jan 2006 13:48:31 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43DA871F.8020707@samsco.org> Date: Fri, 27 Jan 2006 13:48:31 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Garance A Drosehn References: <29245.1138186687@critter.freebsd.dk> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: Poul-Henning Kamp , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [TEST/REVIEW] CPU accounting patches X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 20:48:34 -0000 Garance A Drosehn wrote: > At 11:58 AM +0100 1/25/06, Poul-Henning Kamp wrote: > >> >> With my definition you would be more likely to see lower numbers >> maybe >> user 0.20 sys 0.03 real 4.00 >> >> And they would have meaning, they should be pretty much the same >> no matter what speed your CPU runs at any instant in time. >> >> In theory, it should be possible to compare user/sys numbers >> you collect while running at 75 MHz with the ones you got >> under full steam at 1600 MHz. >> >> In practice however, things that run on the real time, HZ >> interrupting to run hardclock() for instance, will still make >> comparison of such numbers quite shaky. >> >> But at least they will not be random as they are now. > > > Here at RPI we used to have a mainframe, and we used to charge > by the CPU second, so I am familiar with that side of the > question. However, I am not too concerned by it for my own > interests. For one, we don't charge by CPU second any more. For > two, even if we did start charging again, we would just come up > with some other metric, or simply pick a different rate for > charging. > > The other big usage for timing programs is to compare the > performance of various algorithms. We have always had users who > cared very much about the accuracy and consistency of such > measurements, whether or not we were charging people by the "CPU > second". Based on the above description, the new CPU accounting > patches will make those comparisons more meaningful, since the > values measured will be the same no matter what speed the CPU is > running at. As such, I think it's a good idea, even if we ignore > the performance improvement. > > Rambling part: > > Getting back to the question of charging, I can almost convince > myself that these changes are also a good idea for when those > values are used for charging. When we (RPI) charged for CPU time, > we weren't really charging "for CPU seconds". We were charging > to say "when we are forced to buy a new computer because this > computer is maxed out, then how much of that load (and thus the > expense for the new computer) is the fault of any given user?". > > Thus, if we had a computer which could vary it's speed, we don't > really care about "running out of CPU seconds" if the CPU is in > fact running at half-speed. We only incur the cost of a new > machine once we "run out of CPU seconds" when it is running at > *maximum* speed. > > Furthermore, if we had a load which was low enough that we > *could* get it all done by running the CPU at half-speed, then > we (as the computer center) would *prefer* to run it at half- > speed. That way, we reduce power and cooling costs. However, > we will create extreme hostility in our users if we save that > money, only to charge them twice as much because they are now > forced to use "twice as many CPU seconds" when we run the CPU > at half-speed. Oddly enough, consistency is also the big issue > when it comes to charging. The user expects to see the exact > same charge every time they run a specific job, and not see > their charges vary by a dramatic amount due issues they have > no control over. > > Poul-Henning says the values will "not be as random as they are now". > If someone *is* charging by the CPU second, then they don't want > those values to be "random". People who receive random bills can > get really really hostile, perhaps to the point of bringing in > lawyers. (and I have seen that happen). > > So, it seems to me that this change is *always* the behavior that > everyone would prefer. Yes, we have to describe it. And maybe we > should call the value something other than "CPU seconds" to make > that clear, although I don't know what would be a better name. But > I think I have convinced myself that there is no downside to these > proposed changes. > > ...Assuming the changes work, of course! > Just call it 'cpu cycles'. If I have a job that calls nop 1 billion times, then I expect to get charged for 1 billion cycles regardless of if it takes 1 second or 5 days to run. I agree completely with your argument for consistency and that this will improve consistency and predictability. Scott