Originally posted by: r_i_l_e_y

Hi,

I have run an MILP instance with CPLEX 5 times to examine the variability in solve times.

• The time reported is CPU seconds
• A maximum thread limit of 1 was used
• Deterministic parallel search mode used (possibly redundant due to max thread limit?)

Is this much variability in solve times usual?

Root LP time, Cplex time
Run1: 136, 669
Run2: 92, 365
Run3: 100, 342
Run4: 116, 757
Run5: 112, 706

Cheers.
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

The variability highly depends on what else was going on on your machine simultaneously. Was the CPLEX solve the only job running? Were there lots of other processes running at the same time? Are these processes disk and/or CPU intensive?
And yes, using 1 thread is always deterministic, so no need to explicitly switch to deterministic mode if you limit yourself to one thread anyway.
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: r_i_l_e_y

It was probably not the only job running at the time. I'd hoped that wouldn't make a difference for cpu seconds.
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

I think that is a common but wrong expectation for CPU timings.
For example: the more jobs you run on your machine, the higher the chance is for cache misses. A process may have to repeatedly reload the memory cache because it was destroyed by another process. If the OS includes cache-reloading times into CPU seconds (and I think most OSs do that) then CPU timings will suffer from high variability, depending on the amount of cache misses.
#CPLEXOptimizers
#DecisionOptimization