Results look pretty stable now
Probably you have happily ignore the literature I've referenced, but your method is only stable as long as no one change the timer resolution. Also the values vary tremendously from the theoretical values (assuming no CPU throttling applies). The attached testbed shows the influence of the current timer resolution on the slice/quantum length.
Remarks that you will only see a different, if no other application has already requested a timer resolution of 1ms (default values for the resolution are 10 or 15ms).
actual timer resolution : 0.01s , CPU frequency: 2294 MHz
clocks/quantum: 7.64667E+006
Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz (SSE4)
9 valid tests, 90789 avg kCycles
9 valid tests, 91772 avg kCycles
9 valid tests, 91738 avg kCycles
9 valid tests, 91776 avg kCycles
9 valid tests, 91796 avg kCycles
9 valid tests, 91827 avg kCycles
9 valid tests, 91797 avg kCycles
10 valid tests, 91540 avg kCycles
9 valid tests, 91812 avg kCycles
10 valid tests, 91622 avg kCycles
set timer resolution to 1ms
actual timer resolution : 0.001s , CPU frequency: 2294 MHz
clocks/quantum: 764667
Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz (SSE4)
9 valid tests, 73421 avg kCycles
9 valid tests, 73454 avg kCycles
9 valid tests, 73433 avg kCycles
9 valid tests, 73450 avg kCycles
9 valid tests, 73420 avg kCycles
9 valid tests, 73473 avg kCycles
9 valid tests, 73437 avg kCycles
10 valid tests, 73413 avg kCycles
10 valid tests, 73359 avg kCycles
10 valid tests, 73324 avg kCycles
ok
qWord