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

Wed Oct 10 06:58:51 UTC 2012

Hi Arnaud,

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

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

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.

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

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

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.

Thanks for the comments, tbc,

Regards,

vasek

________________________________
Eaton Elektrotechnika s.r.o. ~ S�dlo spolecnosti, jak je zaps�no v rejstr�ku: Kom�rovsk� 2406, Praha 9 - Horn� Pocernice, 193 00, Cesk� Republika ~ Jm�no, m�sto, kde byla spolecnost zaregistrov�na: Praha ~ Identifikacn� c�slo (ICO): 498 11 894

________________________________

-----Original Message-----
> From: Charles Lepple [mailto:clepple at gmail.com<mailto:clepple at gmail.com>]
> Sent: Monday, October 08, 2012 2:36 PM
> To: Krpec, Vaclav
> Cc: Arnaud Quette; Emilien KIA; nut-upsdev at lists.alioth.debian.org<mailto:nut-upsdev at lists.alioth.debian.org> List
> Subject: Re: [Nut-upsdev] NUT Bugs #313634 & #313714: unification &
> encapsulation of timer proposition
>
> [adding nut-upsdev back to CC list.]
>
> > While you at it --- I've written the nut_clock_gettime POSIX
> > implementation so that fallback from monotonic POSIX clock impl. to
> > RTC is actually also done if the system defines _POSIX_MONOTONIC_CLOCK
> > macro, but the call ends with EINVAL (i.e. not implemented) if monotonic clock
> is requested.
> > I thought that may be a bit over-protective; as soon as the OS defines
> > the detection macro, we should be entitled to expect it to work;
> > EINVAL should therefore be considered an error and propagated.
>
> I'm confused. Could you post pseudocode, or the actual patch, for what is being
> described above?
>
> --
> Charles Lepple
> clepple at gmail
>
>

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