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

Re: [Condor-users] condor_history with seconds?



On Dec 17, 2007 3:24 AM, Brad Goldsmith <bcg@xxxxxxxxxxx> wrote:
> Hi,
>
> I am looking for information about times jobs complete with precision down
> to seconds.
>
> When i do a condor_history:
>
>  ID      OWNER            SUBMITTED     RUN_TIME ST   COMPLETED CMD
>
>    4.0   bcg            12/11 13:32   0+00:00:04 C  12/11 14:28
> /data/condor-6.
>
>
> the submitted and completed times are hours and minutes. Is it possible to
> get seconds?
>
> Is this data stored anywhere I can hack at, preferably with some nice unix
> timestamps for times?
>
> Any other suggestions of getting at this kind of data would be gratefully
> received.

All times in classads are stored as unix epoch based timestamps.

If you do a CondorStatus -l you will get an awful lot of output such
as (heavily edited):

MyType = "Machine"
TargetType = "Job"
Name = "vm1@xxxxxxxxxxx"
Machine = "oo.bar.net"
CpuBusy = ((LoadAvg - CondorLoadAvg) >= 0.500000)
CondorVersion = "$CondorVersion: 6.8.5 May 17 2007 $"
CondorPlatform = "$CondorPlatform: INTEL-WINNT50 $"
VirtualMachineID = 1
VirtualMemory = 1047056
Disk = 41775777
CondorLoadAvg = 0.000000
LoadAvg = 0.000000
KeyboardIdle = 300
ConsoleIdle = 300
Memory = 895
Cpus = 1
Arch = "INTEL"
OpSys = "WINNT51"
HasIOProxy = TRUE
CheckpointPlatform = "WINNT51 INTEL Unknown normal"
TotalVirtualMemory = 4188224
TotalDisk = 167103108
TotalCpus = 4
TotalMemory = 3583
KFlops = 1464108
Mips = 4553
LastBenchmark = 1196448183
TotalLoadAvg = 0.990000
TotalCondorLoadAvg = 0.000000
ClockMin = 645
ClockDay = 1
TimeToLive = 2147483647
State = "Owner"
EnteredCurrentState = 1196448173
Activity = "Idle"
EnteredCurrentActivity = 1196448173
Start = FALSE
MonitorSelfTime = 1197888192
MonitorSelfCPUUsage = 0.084597
MonitorSelfImageSize = 58004.000000
MonitorSelfResidentSetSize = 13696
MonitorSelfAge = 1440020
MonitorSelfRegisteredSocketCount = 2
DaemonStartTime = 1196448173
UpdateSequenceNumber = 4800
LastHeardFrom = 1197888343
UpdatesTotal = 8234
UpdatesSequenced = 8229
UpdatesLost = 1

You can probably spot the timestamps. Remember that they are all
sourced from the local box so cross machine values may need to be
treated carefully (it makes it nice and easy to spot machines where
NTP has gone horribly wrong or wasn't started). If you want second
level elapsed time from a schedd you need to reference 'ServerTime'
rather than systime() if you aren't on the schedd machine.

I can't recall if a single unified ServerTime equivalent was added,
MonitorSelfTime might be it but I couldn't say for sure.
Given the distributed nature of the system and the stageing/copyback
nature of the jobs you may want to take care with using second level
data with great accuracy. I cannot recall whether the time taken for
the data to be transferred back is included in the timestamps.

Caveat Lector,  The job log itself also has high resolution timestamps
and should be the cleanest source of this data if desired, obviously
querying them is rather harder...

Matt