Time::HiRes hell...

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
I'd posted a note on HiRes earlier but things seem to be getting more
complicated.  Here are the facts as I understand them:

- versions of HiRes older than 1.91 call setitimer with the entire time
interval as usecs even if > 1sec.  This is clearly in violation of the
calling interface to setitimer, but with glibc versions <2.4 it still
works correctly as I've been successfully using this for over 5 years.
- with glibc 2.4, you get random results if the time >4 seconds
- with glibc 2.5, you get failures but is seems only during boot!  I
know this sounds odd, but I tried running a test that did alarms > 1
second as an inet.d script and watched the console.  I got errors while
the system was booting and once it finished, the error messages stopped.

If the answer were simply to install the right version of HiRes that
wouldn't be so bad but it looks like a lot of current distros still ship
an older version of HiRes and we are talking a lot of permutations.  I
just submitted a bugzilla against rhel5.2 and they're going to try to
get it addresses in 5.3 but I have no idea where else this is a problem.

Now for my problem - I have an open source performance monitoring tool
called collectl if anyone cares - that uses HiRes.  If HiRes is present
I use high resolution timers and if not there I just do sleeps.

I'm now starting to get bug reports against systems with glibc 2.5 on
them and what I plan to do with my next release if check the versions of
HiRes and glibc and if they're incompatible point the user to cpan and
tell them to install a newer version of HiRes.  Seemed to work great
until I tried to install a new version of HiRes.  When I did my 'make
install', it told me:

[root@cag-dl585-01 Time-HiRes-1.9715]# make install
Files found in blib/arch: installing files in blib/lib into architecture
dependent library tree
Appending installation info to

and I discovered I now have both the old and new version of HiRes
installed.  But what really makes this awful when I try to use HiRes
perl loads the older one.  Clearly it's a library search path issue but
given this can run on any distro I can't make any assumptions about
where the module actually gets installed.

I'm not sure what the best solution to this is.  Is there an easy way to
remove the older version?  Ultimately I want to be able to tell users of
my tool how to get HiRes properly installed and they may not even be
perl users or developers so the solution needs to be very simple.

any helpful suggestions will be greatly appreciated.


Re: Time::HiRes hell...

Quoted text here. Click to load it

I did have a thought though I admit it's pretty brute force - how about
I just add a switch to collectl that removes all instances of HiRes so
the user doesn't have to figure out what to do?  Then they can execute
the 'make install' and not care where in the tree it gets installed into?

It looks like I'd need to delete the directories and their contents that
match *linux-thread-multi/Time/HiRes.pm
match *linux-thread-multi/auto/Time/HiRes/

Would that work?

Re: Time::HiRes hell...

On Tue, 01 Jul 2008 12:36:50 -0400, Mark Seger wrote:

Quoted text here. Click to load it

Actually, it seems it isn't glibc but the linux kernel itself that
changed behavior (in release 2.6.21).

Quoted text here. Click to load it

That's strange indeed.

Quoted text here. Click to load it

You could try saying:

use Time::HiRes 1.91 qw/sleep gettimeofday/;

I'm not quite sure that's going to work though, the documentation isn't
clear on whether it will give up after rejecting the old version or
whether it will search on.

Alternatively, you could use plain old sleep. Inaccurate but reliable...


Re: Time::HiRes hell...

Quoted text here. Click to load it
It looks like Ben's trick of installing with the make switch UNINST=1
did the trick

Quoted text here. Click to load it
actually, you really don't want to get me started on this one 8-)
but there are so many broken monitoring utilities because they do sleeps
when they could/should be handling time much more accurately.  there are
some very large clusters running collectl and all taking samples at
pretty tightly synchronized times, literally every 10 seconds day in and
day out, all using ntp of course, with virtually no drift.  how else is
one to try and correlate data across hundreds of nodes if they're not
all synchronized?  actually if you want to try it out for yourself it's
on sourceforge

Re: Time::HiRes hell...

just got another report from another user - according to him the
messages went away once the ntpd service started.  any thoughts?

Re: Time::HiRes hell...

Quoted text here. Click to load it

It will fail if the first copy found isn't the correct version. See also
only::latest on CPAN.


   If you put all the prophets,   |   You'd have so much more reason
   Mystics and saints             |   Than ever was born
   In one room together,          |   Out of all of the conflicts of time.
ben@morrow.me.uk                                    The Levellers, 'Believers'

Site Timeline