You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by wr...@apache.org on 2002/08/04 20:29:34 UTC
cvs commit: apr/time/win32 time.c
wrowe 2002/08/04 11:29:33
Modified: include apr_time.h
time/unix time.c
time/win32 time.c
Log:
Time in exact ms intervals can be very useful in benchmarking... this
patch defines a general API for doing so if the platform supports
toggling the clock resolution. Don't recommend doing so for HTTPD,
but flood and ab should appreciate it.
Revision Changes Path
1.56 +8 -0 apr/include/apr_time.h
Index: apr_time.h
===================================================================
RCS file: /home/cvs/apr/include/apr_time.h,v
retrieving revision 1.55
retrieving revision 1.56
diff -u -r1.55 -r1.56
--- apr_time.h 15 Jul 2002 06:43:34 -0000 1.55
+++ apr_time.h 4 Aug 2002 18:29:33 -0000 1.56
@@ -256,6 +256,14 @@
apr_size_t max, const char *format,
apr_time_exp_t *tm);
+/**
+ * Improve the clock resolution for the lifetime of the given pool.
+ * Generally this is only desireable on benchmarking and other very
+ * time-sensitive applications, and has no impact on most platforms.
+ * @param pool The pool to associate the finer clock resolution
+ */
+APR_DECLARE(void) apr_time_clock_hires(apr_pool_t *p);
+
#ifdef __cplusplus
}
#endif
1.70 +6 -0 apr/time/unix/time.c
Index: time.c
===================================================================
RCS file: /home/cvs/apr/time/unix/time.c,v
retrieving revision 1.69
retrieving revision 1.70
diff -u -r1.69 -r1.70
--- time.c 8 Jun 2002 20:04:26 -0000 1.69
+++ time.c 4 Aug 2002 18:29:33 -0000 1.70
@@ -364,6 +364,12 @@
#endif
+/* A noop on all known Unix implementations */
+APR_DECLARE(void) apr_time_clock_hires(apr_pool_t *p)
+{
+ return;
+}
+
/* Deprecated */
APR_DECLARE(apr_status_t) apr_explode_time(apr_time_exp_t *result,
apr_time_t input,
1.36 +20 -0 apr/time/win32/time.c
Index: time.c
===================================================================
RCS file: /home/cvs/apr/time/win32/time.c,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- time.c 9 Jun 2002 20:25:51 -0000 1.35
+++ time.c 4 Aug 2002 18:29:33 -0000 1.36
@@ -65,6 +65,7 @@
#endif
#include <string.h>
#include <winbase.h>
+#include "misc.h"
/* Leap year is any year divisible by four, but not by 100 unless also
* divisible by 400
@@ -281,6 +282,25 @@
*/
Sleep((DWORD)(t / 1000));
}
+
+
+static apr_status_t clock_restore(void *unsetres)
+{
+ ULONG newRes;
+ SetTimerResolution((ULONG)unsetres, FALSE, &newRes);
+ return APR_SUCCESS;
+}
+
+APR_DECLARE(void) apr_time_clock_hires(apr_pool_t *p)
+{
+ ULONG newRes;
+ if (SetTimerResolution(10000, TRUE, &newRes) == 0 /* STATUS_SUCCESS */) {
+ /* register the cleanup... */
+ apr_pool_cleanup_register(p, (void*)10000, clock_restore,
+ apr_pool_cleanup_null);
+ }
+}
+
/* Deprecated */
APR_DECLARE(apr_status_t) apr_explode_time(apr_time_exp_t *result,
RE: cvs commit: apr/time/win32 time.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 11:25 PM 8/4/2002, Ryan Bloom wrote:
> > From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> >
> > At 05:05 PM 8/4/2002, Aaron Bannert wrote:
> > >On Sun, Aug 04, 2002 at 06:29:34PM -0000, wrowe@apache.org wrote:
> > > > wrowe 2002/08/04 11:29:33
> > > >
> > > > Modified: include apr_time.h
> > > > time/unix time.c
> > > > time/win32 time.c
> > > > Log:
> > > > Time in exact ms intervals can be very useful in
>benchmarking...
> > this
> > > > patch defines a general API for doing so if the platform
>supports
> > > > toggling the clock resolution. Don't recommend doing so for
> > HTTPD,
> > > > but flood and ab should appreciate it.
> > >
> > >If APR can't guarantee a certain precision across the board, how will
> > >that API be useful?
> >
> > APR cannot guarantee anything. We have too many platforms. The point
> > of this API is that win32, perhaps others, have more than one
>granularity
> > of time. Your question should be, if we can't guarantee a certain
> > precision across the board, how are ab or flood useful? I'd argue
>they
> > only provide insufficient resolution, and if there is an api to toggle
>it, > this new function exposes that API.
>
>I disagree. When APR was started, we only provided functions that could
>reasonably be implemented on _most_ of our platforms. IMHO, if we can
>find other platforms that can reasonably implement this feature, then we
>should keep it, but if we can't, then this function should go.
And our API defines time resolution in a 1us units. This function simply
guarantees that if a platform can improve it's apr_time_now() resolution
-towards- 1us units, than it should do so for the duration of the pool [which
will generally be the lifetime of the process, if you call with the base or
global pool.]
Great for benchmark timings, worthless for HTTPD.
So, find another place to put this platform specific anomaly, such as a new
argument to the apr_initialize fn [which I REALLY didn't want to change]...
or this fn needs to remain. In case you didn't get the gist, from a
performance
perspective it's not a change you want to make for every apr application.
Bill
Re: cvs commit: apr/time/win32 time.c
Posted by Aaron Bannert <aa...@clove.org>.
On Sun, Aug 04, 2002 at 09:05:17PM -0500, William A. Rowe, Jr. wrote:
> ... Your question should be, if we can't guarantee a certain precision
> across the board, how are ab or flood useful? I'd argue they only provide
> insufficient resolution, and if there is an api to toggle it, this new
> function exposes that API.
Both flood and ab do not require high-precision timers, since they take
many samples and perform aggregate calculations. At a certain calculatable
point, the precision lost from large-grain timers is overtaken by sampling
errors. By increasing the precision we are only changing that crossover
point, but you're still going to have those inherent errors from things
like network latency, processing delays, etc...
-aaron
RE: cvs commit: apr/time/win32 time.c
Posted by Ryan Bloom <rb...@covalent.net>.
> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
>
> At 05:05 PM 8/4/2002, Aaron Bannert wrote:
> >On Sun, Aug 04, 2002 at 06:29:34PM -0000, wrowe@apache.org wrote:
> > > wrowe 2002/08/04 11:29:33
> > >
> > > Modified: include apr_time.h
> > > time/unix time.c
> > > time/win32 time.c
> > > Log:
> > > Time in exact ms intervals can be very useful in
benchmarking...
> this
> > > patch defines a general API for doing so if the platform
supports
> > > toggling the clock resolution. Don't recommend doing so for
> HTTPD,
> > > but flood and ab should appreciate it.
> >
> >If APR can't guarantee a certain precision across the board, how will
> >that API be useful?
>
> APR cannot guarantee anything. We have too many platforms. The point
> of this API is that win32, perhaps others, have more than one
granularity
> of time. Your question should be, if we can't guarantee a certain
> precision across the board, how are ab or flood useful? I'd argue
they
> only provide insufficient resolution, and if there is an api to toggle
it, > this new function exposes that API.
I disagree. When APR was started, we only provided functions that could
reasonably be implemented on _most_ of our platforms. IMHO, if we can
find other platforms that can reasonably implement this feature, then we
should keep it, but if we can't, then this function should go.
Ryan
Re: cvs commit: apr/time/win32 time.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 05:05 PM 8/4/2002, Aaron Bannert wrote:
>On Sun, Aug 04, 2002 at 06:29:34PM -0000, wrowe@apache.org wrote:
> > wrowe 2002/08/04 11:29:33
> >
> > Modified: include apr_time.h
> > time/unix time.c
> > time/win32 time.c
> > Log:
> > Time in exact ms intervals can be very useful in benchmarking... this
> > patch defines a general API for doing so if the platform supports
> > toggling the clock resolution. Don't recommend doing so for HTTPD,
> > but flood and ab should appreciate it.
>
>If APR can't guarantee a certain precision across the board, how will
>that API be useful?
APR cannot guarantee anything. We have too many platforms. The point
of this API is that win32, perhaps others, have more than one granularity
of time. Your question should be, if we can't guarantee a certain precision
across the board, how are ab or flood useful? I'd argue they only provide
insufficient resolution, and if there is an api to toggle it, this new function
exposes that API.
>Also, I'm curious how this works, if you happen to have some
>references to docs about how this works on NT, I'd be interested.
Google for NtSetTimerResolution ... sysinternals.com has some interesting
bits on it.
Bill
Re: cvs commit: apr/time/win32 time.c
Posted by Ian Holsman <ia...@apache.org>.
Aaron Bannert wrote:
> On Sun, Aug 04, 2002 at 06:29:34PM -0000, wrowe@apache.org wrote:
>
>>wrowe 2002/08/04 11:29:33
>>
>> Modified: include apr_time.h
>> time/unix time.c
>> time/win32 time.c
>> Log:
>> Time in exact ms intervals can be very useful in benchmarking... this
>> patch defines a general API for doing so if the platform supports
>> toggling the clock resolution. Don't recommend doing so for HTTPD,
>> but flood and ab should appreciate it.
>
I'm just wondering if we this API could work in the reverse way.
so for example we could tell the apr_time interface that we only want
responses with 1 second increments, allowing apr-time to do some
internal magic to store the time, and various formating of it.
essentially putting all the time-caching stuff backing into the main APR.
--Ian
Re: cvs commit: apr/time/win32 time.c
Posted by Aaron Bannert <aa...@clove.org>.
On Sun, Aug 04, 2002 at 06:29:34PM -0000, wrowe@apache.org wrote:
> wrowe 2002/08/04 11:29:33
>
> Modified: include apr_time.h
> time/unix time.c
> time/win32 time.c
> Log:
> Time in exact ms intervals can be very useful in benchmarking... this
> patch defines a general API for doing so if the platform supports
> toggling the clock resolution. Don't recommend doing so for HTTPD,
> but flood and ab should appreciate it.
If APR can't guarantee a certain precision across the board, how will
that API be useful?
Also, I'm curious how this works, if you happen to have some
references to docs about how this works on NT, I'd be interested.
-aaron