[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [HTCondor-users] RemoteWallClockTime vs CommittedTime


I understand the multiple core issue as a potential cause of CPU exceeding Wall but I don't see how a RemoteWallClockTime of 1 sec would be corrected by number of cores. It is the CommittedTime far exceeding the RemoteWallClockTime that has me baffled. I did not make up the example. This is what we collected from the classads on the job.

Am I incorrect in understanding that RemoteWallClockTime should always exceed CommittedTime?

John Weigand

On 10/15/2013 9:04 AM, Todd Tannenbaum wrote:
Cpu time could exceed wall clock time if the job is using multiple cores (via
multiple threads or processes), which is always a possibility unless you
configured htcondor to enforce cpu limits on a slot via either cpu affinity
knobs or by enabling cgroups...

-- Sent from my HP Veer mobile phone

On Oct 15, 2013 8:44 AM, John Weigand <weigand@xxxxxxxx> wrote:

We have noticed a problem in collecting accounting data from the HTCondor
classads. We are seeing situations where CPU is exceeding Wall time.

We use the RemoteWallClockTime classad as the basis of Wall time. According
to the documentation, this appears to be the correct one to use. The accounting
system also captures CommittedTime. We are seeing conditions where
CommittedTime exceeds RemoteWallClockTime. One of many cases....
CommittedTime = 3944 RemoteWallClockTime = 1 Total CPU = 1935

Based on the documentation, if I am interpreting it correctly, CommittedTime
should never exceed RemoteWallClockTime since CommittedTime can get reset to
zero if evicted w/o a checkpoint. And RemoteWallClockTime does not.

I am trying to understand under what conditions this can occur.
It is making no sense to us.

John Weigand
HTCondor-users mailing list
To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
subject: Unsubscribe
You can also unsubscribe by visiting

The archives can be found at: