Click here to get back home

large inaccuracies in Time::HiRes on Opteron

 HomeNewsGroups | Search | About
 comp.lang.perl.modules    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content
Subject Author Date
large inaccuracies in Time::HiRes on Opteron Harry Mangalam 02-25-2005
Get Chitika Premium
Posted by Harry Mangalam on February 25, 2005, 5:44 pm
Please log in for more thread options


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


Posted by Big and Blue on February 26, 2005, 11:55 pm
Please log in for more thread options


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.


Similar ThreadsPosted
Does anyone knows how to install the Time::HiRes Module? February 16, 2005, 6:22 pm
dupe times in Time::HiRes March 18, 2005, 1:12 pm
error: no suitable installation target found for package Time-HiRes February 26, 2005, 5:55 am
SOAP::Lite with large web service payloads January 10, 2006, 12:42 pm
DBI problem -- storing large value into an INT8 field January 4, 2007, 10:28 am
does archive::zip support extracting large zip file, such as 12G? December 4, 2008, 4:37 am
[RFC] File::SplitStream - iterate over files >2GB when large filesupport unavailable August 20, 2005, 3:37 pm
I want an perl module for conver large html page file to multi little pages November 14, 2004, 3:02 am
ANNOUNCE: Time::Out 0.01 January 4, 2005, 11:30 pm
Writing row at a time in Excel using OLE June 14, 2007, 1:43 pm

Our other projects:

Art Dolls, Fairies and Mermaids - Sunnyfaces.net

Roy's Linux, Programming and Search Engines messages

1-Script XML SitemapXML Sitemap