[LAD] [Jack-Devel] How is the TSC calibration accuracy on dual core 2 computers? (And what about HPET?)

[Kjetil S. Matheussen]

On Tue, 28 Apr 2009, Jussi Laako wrote:

> Kjetil S. Matheussen wrote:
>>
>> I've looked at the HPET code in jack, but am unsure how accurate it is,
>> and whether there are any overhead using it?
>
> Resolution on my machine is 1 / 14.318180 MHz. Frequency can vary
> typically from 12 to 16 MHz. Access is usually rather fast through MMIO.
> Accuracy can vary depending on hardware and environment, same applies
> even more for TSC.
>

Thanks! I'll look closer at the jack code.


>> that's the accuracy of usleep(). So it looks promising, but
>> I need at least 0.1ms accuracy...
>
> In my opinion, clock_gettime() with CLOCK_MONOTONIC is pretty good if
> kernel is using reasonably good clock source. You can check the current
> one by "cat
> /sys/devices/system/clocksource/clocksource0/current_clocksource". Over
> rather long periods, CLOCK_REALTIME with good NTP sync would probably be
> a good choice.
>

It shows hpet.


> Over what time span you would need that 0.1 ms accuracy?
>

Hard to say. This is for testing a couple of garbage collectors, and the
difference between worst case and best case can be quite high.
Worst-case is probably around 1ms, and best case maybe around 0.1ms.
It also depends on buffer settings, so I can use higher buffers
to get higher timings.

But calls to clock_gettime()/HPET/etc. will only happen maximum 6 times
per audio block, so clock_gettime()/HPET/etc. doesn't have to be extremely
efficient.