PERL Modules - large inaccuracies in Time::HiRes on Opteron

Author

large inaccuracies in Time::HiRes on Opteron

Harry Mangalam

2005-02-26, 3:55 am

Hi All,

I'm using the Time::HiRes module on a dual opteron running:
kernel 2.6.8.1-4-amd64-k8-smp #1 SMP Fri Jan 14 11:33:56 UTC 2005 x86_64
GNU/Linux (ubuntu in 64bit mode).

I've been using it as the basis for some timing tests that were written on
the x86 platform and work well there, only to find that when they are run
on the AMD platform, I'm getting very strange results.
Over 50 runs:

bodi (Thinkpad laptop) gives:
model name : Pentium III (Coppermine)
stepping : 10
cpu MHz : 896.806
cache size : 256 KB

Mean 0.88455094
Median 0.8648625
Mode FLAT
NModes No # was represented more than once
Min 0.833735
Max 1.038166
Range 0.204431
Variance 0.00273128724911877
Std_Dev 0.0522617187731017
SEM 0.00739092314818491
Skew 1.40932180828111
Std_Skew 4.06836162692955
Kurtosis 0.920845344533371

note the small range and Std dev above

soot: (dual P4 server)
model name : Intel(R) Xeon(TM) CPU 2.80GHz
stepping : 7
cpu MHz : 2790.786
cache size : 512 KB

Mean 0.42476272
Median 0.4233855
Mode FLAT
NModes No # was represented more than once
Min 0.421679
Max 0.432386
Range 0.010707
Variance 8.54562669551022e-06
Std_Dev 0.00292329038850235
SEM 0.000413415691417494
Skew 1.18841742422774
Std_Skew 3.43066559893764
Kurtosis -0.0115141094577815

range and std dev even smaller than with a PIII

and finally sand (dual opteron server):
model name : AMD Opteron(tm) Processor 244
stepping : 8
cpu MHz : 1804.771
cache size : 1024 KB
gives a result of:
Mean 1.49244808
Median 1.4834005
Mode FLAT
NModes No # was represented more than once
Min -9.135598
Max 12.178202
Range 21.3138
Variance 4.6358785749246
Std_Dev 2.15310904854459
SEM 0.304495601771999
Skew 0.0418761635411303
Std_Skew 0.120886071465502
Kurtosis 21.4969759461221

note huge range and std dev.

most of the extreme difference is due to results like this:

Run 0 - Elapsed time = 1.540971
Run 1 - Elapsed time = 1.540029
Run 2 - Elapsed time = 1.539234
Run 3 - Elapsed time = 1.538987
Run 4 - Elapsed time = 1.527153
Run 5 - Elapsed time = -9.135598
Run 6 - Elapsed time = 1.536252
Run 7 - Elapsed time = 1.536256
Run 8 - Elapsed time = 12.178202
Run 9 - Elapsed time = 1.48397
Run 10 - Elapsed time = 1.484179
Run 11 - Elapsed time = 1.483353
Run 12 - Elapsed time = 1.483417
Run 13 - Elapsed time = 1.483169
Run 14 - Elapsed time = 1.483386
Run 15 - Elapsed time = 1.483782

typically, I'll get one high and one low extreme for each 50 run test and
typically tests whch involve running lots of different tests which use it
will show much more variation than a single test that uses the calls
repeatedly (the case above is from one script that repeats identical runs).

The README says that Time::HiRes is sensitive to load, but these are all
essentially unloaded machines when I run the tests.

Has anyone else seen this kind of variation on Opterons?

hjm@tacgi.com

Big and Blue

2005-02-26, 8:55 pm

Harry Mangalam wrote:
>
> I'm using the Time::HiRes module on a dual opteron running:
>.....
> on the AMD platform, I'm getting very strange results.
>...
> typically, I'll get one high and one low extreme for each 50 run test and
> typically tests whch involve running lots of different tests which use it
> will show much more variation than a single test that uses the calls
> repeatedly (the case above is from one script that repeats identical runs).

There was an issue with the IBM Summit chipset (fixed in 2.4.15 IIRC)
which caused Timer::Hires to do odd things on IBM x400 series.

The symptoms could be seen by just runnning a simple C program which
looped doing gettimeofday() calls with 1s sleeps in between. Occassionally
(20% of the time?) the result would be out by something like 1.2s (either
forwards or backwards). Perhaps you are seeing something similar here?

--
Just because I've written it doesn't mean that
either you or I have to believe it.

Sponsored Links