From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 20:16:02 2006 Return-Path: X-Original-To: freebsd-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 CE92516A42A; Fri, 27 Jan 2006 20:16:02 +0000 (GMT) (envelope-from gad@FreeBSD.org) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8E7343D53; Fri, 27 Jan 2006 20:15:57 +0000 (GMT) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.13.0/8.13.0) with ESMTP id k0RKFsgT009301; Fri, 27 Jan 2006 15:15:55 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <29245.1138186687@critter.freebsd.dk> References: <29245.1138186687@critter.freebsd.dk> Date: Fri, 27 Jan 2006 15:15:53 -0500 To: "Poul-Henning Kamp" From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.3 Cc: freebsd-current@FreeBSD.org, freebsd-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: Fri, 27 Jan 2006 20:16:03 -0000 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! -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA