Time::HiRes hell...

Discussion in 'Perl Misc' started by Mark Seger, Jul 1, 2008.

  1. Mark Seger

    Mark Seger Guest

    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
    Mark Seger, Jul 1, 2008
    #1
    1. Advertising

  2. Mark Seger

    Mark Seger Guest

    > 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
    Mark Seger, Jul 1, 2008
    #2
    1. Advertising

  3. Mark Seger

    Ben Morrow Guest

    Quoth Mark Seger <>:
    >
    > 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.


    Is the RHEL? RedHat are know to have messed up perl's @INC ordering in
    many of their perl packages. Unfortunately there's not much you can do
    to fix that...

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


    Where is the old copy? Is it the version installed as part of 5.8.8, or
    some other version installed by your package manager?

    On my system I have

    /usr/local/lib/perl5/5.8.8/mach/Time/HiRes.pm
    /usr/local/lib/perl5/site_perl/5.8.8/mach/Time/HiRes.pm

    but since my @INC is

    /usr/local/lib/perl5/5.8.8/BSDPAN
    /usr/local/lib/perl5/site_perl/5.8.8/mach
    /usr/local/lib/perl5/site_perl/5.8.8
    /usr/local/lib/perl5/site_perl
    /usr/local/lib/perl5/5.8.8/mach
    /usr/local/lib/perl5/5.8.8
    Ben Morrow, Jul 1, 2008
    #3
  4. Mark Seger

    Mark Seger Guest


    > Where is the old copy? Is it the version installed as part of 5.8.8, or
    > some other version installed by your package manager?

    [root@hadesn0 ~]# find /usr | grep HiRes
    /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/auto/Time/HiRes
    /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/auto/Time/HiRes/HiRes.so
    /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/Time/HiRes.pm

    >
    > # make install UNINST=1
    >
    > will remove any other versions it can find that might conflict. This
    > isn't the default because it could be dangerous on systems with multiple
    > versions of perl installed and a carefully-constructed @INC (or
    > networked filesystems serving machines with multiple versions of perl),
    > but on systems with only one perl it's safe. Of course the package
    > manager will probably complain that whichever package HiRes.pm belonged
    > to is now corrupt. :(

    very cool! thanks...
    -mark
    Mark Seger, Jul 1, 2008
    #4
  5. Mark Seger

    Mark Seger Guest


    > 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 :cool:
    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
    Mark Seger, Jul 1, 2008
    #5
  6. Mark Seger

    Ben Morrow Guest

    Quoth Leon Timmermans <>:
    > On Tue, 01 Jul 2008 12:36:50 -0400, Mark Seger wrote:
    >
    > 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.


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

    Ben

    --
    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.
    The Levellers, 'Believers'
    Ben Morrow, Jul 1, 2008
    #6
  7. Mark Seger

    Mark Seger Guest

    just got another report from another user - according to him the
    messages went away once the ntpd service started. any thoughts?
    -mark
    Mark Seger, Jul 1, 2008
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Adam
    Replies:
    2
    Views:
    88
    Michele Dondi
    Nov 17, 2004
  2. mastermagrath
    Replies:
    4
    Views:
    396
    robic0
    Dec 1, 2005
  3. Mark Seger
    Replies:
    1
    Views:
    91
    Mark Seger
    Sep 28, 2006
  4. Mark Seger
    Replies:
    6
    Views:
    104
    Martijn Lievaart
    Apr 15, 2008
  5. John

    accuracy of Time::HiRes

    John, Jun 27, 2008, in forum: Perl Misc
    Replies:
    1
    Views:
    110
Loading...

Share This Page