Re: PerformanceCounterFrequency fix

[Michael Ost]

On Tue, 2005-01-25 at 14:05, [e-mail] wrote:
> Message: 1
> Date: Tue, 25 Jan 2005 19:30:04 +0100
> From: Andreas Mohr 
> To: Rein Klazes 
> Cc: Lionel Ulmer , [e-mail],
>    [e-mail]
> Subject: Re: PerformanceCounterFrequency fix.
>
> Hi,
>
> On Tue, Jan 25, 2005 at 06:44:04PM +0100, Rein Klazes wrote:
> > On Mon, 24 Jan 2005 15:08:56 +0100, you wrote:
> > > > How bad is it to use the gettimeofday() method?
> > >
> > > In my opinion, the RTDSC method should be suppressed from the code and we
> > > should always use the 'gettimeofday' method (despite the penalty hit of a
> > > syscall).
> >
> > I was more concerned about the accuracy of gettimeofday (not
> > incrementing in usec's). So I did a small test and I find it behaves
> > very nicely.
> >
> > That was the only reason I could see to justify the rdtsc method, so
> > here it goes. As the cpuHz variable is not used anymore, we might as
> > well move it to ntdll.
>
> (sorry for not replying earlier - no time :-)
> I'm not sure why you'd want to base it on gettimeofday().
> This is a terrible idea IMHO.
> I'm quite certain that many programs use that function for extremely time critical code
> (games, anyone??), and that thus the Windows function is equally highly optimized,
> certainly much less slow than a gettimeofday() call.
>
> This should remain based on rdtsc IMHO, or on equally suitable and fast methods
> (ACPI counter, ...).
>
> Or did you actually test it with programs calling it a large number of times,
> or test its performance behaviour on Windows?
>
> Andreas Mohr

Our system uses the performance counter all the time in extremely time
critical code. If the call is anything more than a few cycles with
absolutely no chance of blocking, we are hosed!

The application is an embedded audio plugin player. The audio is
processed with SCHED_FIFO and needs to be as deterministic and fast as
possible.

I hope this fix/change doesn't jeopardize our product's use of Wine...
mo

===================================
Michael Ost, Software Architect
Muse Research, Inc.
[e-mail]