Re: [TEST/REVIEW] CPU accounting patches

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