Click here to get back home

Time::HiRes hell...

 HomeNewsGroups | Search | About
 comp.lang.perl.misc    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
Time::HiRes hell... Mark Seger 07-01-2008
Posted by Mark Seger on July 1, 2008, 12:36 pm
Please log in for more thread options
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
Writing
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/auto/Time/HiRes/.packlist
Appending installation info to
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/perllocal.pod

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.

-mark

Posted by Mark Seger on July 1, 2008, 1:54 pm
Please log in for more thread options
> 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.

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?
-mark

Posted by Leon Timmermans on July 1, 2008, 2:41 pm
Please log in for more thread options
On Tue, 01 Jul 2008 12:36:50 -0400, Mark Seger wrote:

> 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!

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

> 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.

That's strange indeed.

> 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.
>

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...

Leon

Posted by Mark Seger on July 1, 2008, 2:55 pm
Please log in for more thread options

> 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.
It looks like Ben's trick of installing with the make switch UNINST=1
did the trick

> Alternatively, you could use plain old sleep. Inaccurate but reliable...
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
-mark

Posted by Mark Seger on July 1, 2008, 3:00 pm
Please log in for more thread options
just got another report from another user - according to him the
messages went away once the ntpd service started. any thoughts?
-mark

Similar ThreadsPosted
Hell of a time extracting bits from a vector February 29, 2008, 12:09 pm
accuracy of Time::HiRes June 27, 2008, 4:38 pm
Time::HiRes < 1.91 and glibc 2.4 incompatibility April 12, 2008, 8:46 am
Time::HiRes module and timing a command... November 16, 2004, 10:54 am
problems with Time::HiRes on some SLES systems September 28, 2006, 1:08 am
Time::HiRes usleep on windows strange behaviour...please please help!! November 29, 2005, 11:37 pm
GMT time to local time, according to timezone and summer/winter time. May 15, 2005, 10:45 pm
Calculating time of employee session from the log date/time stampusing perl May 24, 2005, 5:55 pm
How do I convert TIME into Cookie and last-modified-time format? October 1, 2004, 3:05 pm
Compare UNIX file time with time in a variable November 23, 2006, 2:39 pm

Our other projects:

Art Dolls, Fairies and Mermaids - Sunnyfaces.net

Roy's Linux, Programming and Search Engines messages

1-Script XML SitemapXML Sitemap