[Nut-upsdev] NUT Bugs #313634 & #313714: unification & encapsulation of timer proposition

[Arnaud Quette]

2012/10/10 <VaclavKrpec at eaton.com>

>    Hi Arnaud,****
>
> **
>

Hi Vasek,


> The below link will provide you a good summary of the situation, what we
> can do and how.
>
> AFAICT, there is no way on HPUX (and some other older Unix) to use
> clock_gettime with CLOCK_MONOTONIC, but CLOCK_REALTIME (which is
> functionally different).
> gethrtime (high resolution time) seems to be the fallback here:
>
> http://nadeausoftware.com/articles/2012/04/c_c_tip_how_measure_elapsed_real_time_benchmarking
>
> ****
>
> Yes, I’ve found that myself, too.****
>
> HP-UX is definitely kind of a troublemaker... :-)****
>
> **
>

you'll never know how much! Even Solaris and Aix have put some Linux salt
in their plate.

CLOCK_MONOTONIC_PRECISE for BSD and****
>
> CLOCK_HIGHRES for Solaris shall be used for monot. clock..****
>
> ** **
>
> As already mentioned, mach_absolute_time shall be used****
>
> for Mac OS X for the monotonic clock.****
>
> For RTC on OS X, I’ve found the following (see answer #17):****
>
>
> http://stackoverflow.com/questions/5167269/clock-gettime-alternative-in-mac-os-x
> ****
>

OS X is also a troublemaker..
your ref. suits me fine.

**
>
> For the HP-UX, I’llcheck whether gethrtime is available; if so, it’ll be
> used****
>
> for monot. clock. If it’s not, well, I guess then HPUX user is screwed;***
> *
>
> I can’t find any other monot. clock implementation, so POSIX RTC shall****
>
> have to be used.****
>

as told in another thread, gethrtime is not available with gcc.
back on the warning thread, probably...


> **
>
> I’ll add the Windows-specific GetSystemTime* support, too,****
>
> although for now, there’ll be no way to even compile the code :-(****
>

you can check with Fred (Bohe @ Eaton) for testing some code.
now that nss is done, the windows port will be my next point of focus.


> **
>
> but this requires (for HPUX) the native compiler and CFLAGS set to
> "Extended Ansi" mode...
> so there is a 2nd (more general) fallback, using... gettimeofday! :-/
>
> ****
>
> I can see no reason for using gettimeofday; we have POSIX clock (almost)
> everywhere,****
>
> on OSX, we do have the above solution and on HPUX, we won’t do better than
> POSIX****
>
> CLOCK_REALTIME with gettimeofday if we don’t have gethrtime...****
>
> **
>

right


>  Another reading on configure checks:
>
> http://www.nco.ncep.noaa.gov/pmb/codes/nwprod/gempak/nawips2/extlibs/glib/v2.15.6/configure.in
>
> ****
>
> Thanks.****
>
> ** **
>
>
> As a separate comment, here is the list of remaining gettimeofday:
> common/common.c:        gettimeofday(&now, NULL);
> drivers/bcmxcp_usb.c:    gettimeofday(&start_time, NULL);
> drivers/bcmxcp_usb.c:            gettimeofday(&now, NULL);
> drivers/dstate.c:    gettimeofday(&now, NULL);
> drivers/main.c:        gettimeofday(&timeout, NULL);
> drivers/usbhid-ups.c:    gettimeofday(&now, NULL);
>
> ****
>
> Yep, I know what grep is for... ;-)****
>
> But I use the –n switch, too.****
>

right answer ;)


> **
>
> Thanks for the comments, tbc,****
>
> **
>
> your integration period will be straightforward.

Arnaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20121013/a406e136/attachment-0001.html>