28 Apr
2009
28 Apr
'09
10:46 a.m.
I'm doing some benchmarking where I need about 0.1ms accuracy.
I'm using an intel dual core 2 computer. This is for a paper,
so I just need the numbers, and the code is not going to run
on any other computer.
I've looked at the HPET code in jack, but am unsure how accurate it is,
and whether there are any overhead using it?
And I have also tried using tsc[1]. tsc seems to work perfectly,
but I don't know how accurate it is on intel dual core machines?
Testing the accuracy of tsc by bounding my thread to one processor
using sched_setaffinity and using usleep(), and comparing
with code which is forced to switch to read the tsc value from the
other CPU, shows that the accuracy of tsc when reading and writing
using two different CPUs is below 1ms since
that's the accuracy of usleep(). So it looks promising, but
I need at least 0.1ms accuracy...
Anyone know how much jitter there might be for tsc?
I've not found anything on google yet.
[1] __asm__ __volatile__("rdtsc" : "=A" (ret))
28 Apr
28 Apr
3:03 p.m.
New subject: How is the TSC calibration accuracy on dual core 2 computers? (And what about HPET?)
I don't know about jitter, but certainly a few years ago, you
sometimes got stalls - eg. under heavy DMA load. That may not be an
issue with modern CPUs and chipsets. I think I posted some code that
demonstrated it to the l-a-d list at the time, but good luck finding
it :)
The TSC is only required to be monotonic, so you wont get any
guarantees, just practical knowledge of whether you can get away with
it or not.
- Steve
On 28 Apr 2009, at 13:46, Kjetil S. Matheussen wrote:
I'm doing some benchmarking where I need about 0.1ms accuracy.
I'm using an intel dual core 2 computer. This is for a paper,
so I just need the numbers, and the code is not going to run
on any other computer.
I've looked at the HPET code in jack, but am unsure how accurate it
is,
and whether there are any overhead using it?
And I have also tried using tsc[1]. tsc seems to work perfectly,
but I don't know how accurate it is on intel dual core machines?
Testing the accuracy of tsc by bounding my thread to one processor
using sched_setaffinity and using usleep(), and comparing
with code which is forced to switch to read the tsc value from the
other CPU, shows that the accuracy of tsc when reading and writing
using two different CPUs is below 1ms since
that's the accuracy of usleep(). So it looks promising, but
I need at least 0.1ms accuracy...
Anyone know how much jitter there might be for tsc?
I've not found anything on google yet.
[1] __asm__ __volatile__("rdtsc" : "=A" (ret))
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
3:43 p.m.
On Tue, 28 Apr 2009, Steve Harris wrote:
I don't know about jitter, but certainly a few
years ago, you sometimes got
stalls - eg. under heavy DMA load. That may not be an issue with modern CPUs
and chipsets. I think I posted some code that demonstrated it to the l-a-d
list at the time, but good luck finding it :)
Thanks for the warning. I'm not planning to run other programs or do any I/O
besides audio though. And to avoid rescheduling while my code
snippets run, I'll probably set the threads to SCHED_FIFO/99 too.
Hopefully that'll give accurate results.
Paul Davis wrote:
the cycle counter on intel systems is (was?)
guaranteed to run exactly
in sync. AMD had a problem a few generations back where they neglected
to provide this feature and it caused havoc for several different
categories of users. they corrected their error very quickly and i
believe that all their chipsets will now also always have precisely
A synced cycle counter.
Thanks.
in the absence of frequency scaling, there is no
jitter that can be
measured using anything else you're likely to have attached to the
computer.
Sorry, really bad use of the word "jitter" on my part. I ment
slightly wrong values caused by unsynchronized tsc clocks.
6:26 p.m.
New subject: [Jack-Devel] How is the TSC calibration accuracy on dual core 2 computers? (And what about HPET?)
Kjetil S. Matheussen wrote:
Paul Davis wrote:
I would just warn that, AFAIK, on some CPUs frequency scaling affects
TSC while not on some others... And the frequency of CPU clock is not
necessarily very precise and can vary depending on hardware/temperature/etc.
Some hardwares may employ spread spectrum on the clock - ie. generating
jitter on the clock to lower EMI.
Best option for timing is usually to use hardware intended for timing.
Kernel can use HPET as clock source with "clocksource=hpet" parameter.
- Jussi
the cycle counter on intel systems is (was?)
guaranteed to run exactly
in sync. AMD had a problem a few generations back where they neglected
to provide this feature and it caused havoc for several different
categories of users. they corrected their error very quickly and i
believe that all their chipsets will now also always have precisely
A synced cycle counter.
Thanks.
6:09 p.m.
New subject: [Jack-Devel] How is the TSC calibration accuracy on dual core 2 computers? (And what about HPET?)
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.
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.
Over what time span you would need that 0.1 ms accuracy?
- Jussi
29 Apr
29 Apr
8:19 a.m.
New subject: [Jack-Devel] How is the TSC calibration accuracy on dual core 2 computers? (And what about HPET?)
On Tue, 28 Apr 2009, Jussi Laako wrote:
It shows hpet.
Kjetil S. Matheussen wrote:
Thanks! I'll look closer at the jack code.
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.
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.
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.
30 Apr
30 Apr
12:26 a.m.
New subject: [Jack-Devel] How is the TSC calibration accuracy on dual core 2 computers? (And what about HPET?)
On Wed, Apr 29, 2009 at 6:19 AM, Kjetil S. Matheussen
<k.s.matheussen(a)notam02.no> wrote:
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.
With a modern kernel clock_gettime() should always be the best choice.
The kernel's timekeeping system has been completely redone since the
days when JACK needed to use its own timers. Linux is now very good
at picking the cheapest working clock source.
If there were no need to support old kernels, I think JACK's hardware
timer support could be removed entirely in favor of the POSIX clock
api.
Lee
1:09 p.m.
New subject: [Jack-Devel] How is the TSC calibration accuracy on dual core 2 computers? (And what about HPET?)
Lee Revell wrote:
If there were no need to support old kernels, I think
JACK's hardware
timer support could be removed entirely in favor of the POSIX clock
api.
Only reason for those is the lower cost of reading the time versus going
through syscall...
- Jussi
5714
days inactive
5716
days old
linux-audio-dev@lists.linuxaudio.org
7 comments
4 participants
participants (4)
-
Jussi Laako -
Kjetil S. Matheussen -
Lee Revell -
Steve Harris