[CoinUtils] User and System time in CoinCpuTime

[Giacomo Nannicini]

Hi Matthew,
the problem can be reproduced on my machine, that has a kernel 2.6.32
(with a recent Ubuntu distribution). The timer stops when I run
Couenne on some specific input problems, and always at the same time,
depending on the instance.

Before the user timer stops, both user CPU time and system CPU time
advance - of course the user CPU time at a much faster rate. Then at
some point, the user CPU time halts completely, and only system CPU
time keeps advancing - now very quickly, because in fact only system
time is accumulated. The Branch-and-Bound algorithm continues
normally, so I am sure that user CPU time should be accumulated (in
fact nodes are processed and lower/upper bounds change, so, definitely
the algorithm is still working). However for some reason user CPU time
is stuck at always the same value. I could not find any information
regarding such a bug with my kernel version.

This is very strange, and at the moment I have no intuitions as to why
this could happen. However, on my machine I fixed the problem by
simply adding user and system CPU time.

Giacomo

On Thu, Nov 4, 2010 at 7:37 PM, Matthew Saltzman <mjs at clemson.edu> wrote:
> I think I recall that long ago there was a timer bug in the Linux
> kernel, but I don't recall its nature and I find it hard to believe that
> it would have persisted this long.
>
> I'm also suspicious of the idea that a cpu-intensive task like this
> would not accumulate user time at a much higher rate than system time.
> Is the trouble you're seeing reproducible, or is it intermittent?
>
> CoinCpuTime uses various mechanisms in an attempt to be portable, so
> what service is being called depends on various macro variable settings.
> It's kind of ugly.
>
> Ah, according to the clock() man page, if the code spawns children to do
> the work, clock() is definitely the wrong thing to use.
>
> On Wed, 2010-11-03 at 18:29 -0400, Giacomo Nannicini wrote:
>> On Wed, Nov 3, 2010 at 6:12 PM, Lou Hafer <lou at cs.sfu.ca> wrote:
>> > Giacomo,
>> >
>> >        Thanks for pursuing this. It's nice to know it's not a cbc bug :-)
>> >
>> >        On the other hand, if user code is executing and the user time is not
>> > increasing, that sounds like a bug within Linux. It would be useful to
>> > know if you see the same behaviour on other platforms.
>> >
>> >        Coming at this from another direction, is it a bug or just a deficiency
>> > in CoinCpuTime, as you suggest. Is this a failure to correctly account
>> > for user time, or is your code really spending all its time executing
>> > system tasks?
>>
>> I find it hard to believe that the code is spending all its time in
>> system calls, because the number of processed/active nodes reported in
>> the Branch-and-Bound log changes over time even after the timer stops
>> advancing. This makes me think that user time is being used, but I
>> cannot completely rule out what you suggest.
>>
>> It could be a problem with my machine, but I know another user that
>> had the same problem (on a different machine). I will try to see if we
>> had the same Linux distribution, and let you know if I find something.
>>
>> >
>> >        I don't know the reason for the original decision to not include system
>> > time. Someone else will have to speak to that. Speculation would be that
>> > user time accounts for the cost of your code, while system time
>> > potentially includes costs attributable to other code running on the
>> > system and interrupting the continuous execution of your code.
>> >
>>
>> Maybe the choice could be added as an option at compile time.
>> I personally find user + system CPU time to be closer to the human
>> perception of passed time, but I can see its drawback.
>>
>> Giacomo
>>