Vojtech Pavlik wrote:
On Fri, Nov 18, 2005 at 05:13:03PM -0500, Lee Revell wrote:
On Fri, 2005-11-18 at 14:05 -0800, Fernando Lopez-Lezcano wrote:
On Fri, 2005-11-18 at 16:54 -0500, Lee Revell wrote:
On Fri, 2005-11-18 at 10:02 -0800, Fernando Lopez-Lezcano wrote:
You mentioned before that the TSC's from both cpus could drift from
each other over time. Assuming that is the source of timing (I have no
idea) that could explain the behavior of Jack, it gets a reference
time from one of the cpus and then compares that with what it gets
from either cpu depending on where it is running at a given time. If
it is the same cpu all is fine, if it is the other and it has drifted
then the warning is printed.
Yes, JACK uses rdtsc() for microsecond resolution timing and assumes
that the TSCs are in sync.
I've asked on this list what a better time source could be and didn't
get any useful responses, people just told me "use gettimeofday()" which
is WAY too slow.
Arghhh, at least I take this as a confirmation that the TSCs do drift
and there is no workaround. It currently makes the -rt/Jack combination
not very useful, at least in my tests.
Is there a way to resync the TSCs?
I don't think so. A better question is what mechanism have the hardware
vendors provided to replace the apparently-no-longer-reliable TSC for
cheap high res timing on modern machines. Unfortunately I suspect the
answer at this point is "nothing, you're screwed".
There are many mechanisms to keep time:
1) RTC: 0.5 sec resolution, interrupts
2) PIT: takes ages to read, overflows at each timer interrupt
3) PMTMR: takes ages to read, overflows in approx 4 seconds, no interrupt
The PMTMR can be read from user space (if you can find it). See the
"iopl" man page. It is an I/O access and so is slow, but you can read
it.
Finding it is another matter. It does not have a fixed address (i.e.
it differs from machine to machine, but is constant on any given
machine). The boot code roots it out of an info block put in memory
by the BIOS. I suppose one could put a printk in the boot code to
disclose it...
George
--
4) HPET: slow to read, overflows in 5 minutes. Nice, but usually not present.
5) TSC: fast, completely unreliable. Frequency changes, CPUs diverge over time.
6) LAPIC: reasonably fast, unreliable, per-cpu
Userspace can only use 1), 4) and 5). mplayer uses the RTC to
synchronize, using it as a 1 kHz interrupt source.
The kernel does quite a lot of magic and jumps through many hoops to
make a reliable and fast time source combining these.
I've read that gettimeofday() does not have to enter the kernel on
x86-64, maybe it's fast enough, though almost certainly orders of
magnitude slower than rdtsc().
It depends on the hardware config, and kernel version. With my latest
patch it takes approximately 175 ns on a reasonably fast CPU to do
gettimeofday() from userspace. And much better results will be possible
(~5x better) when RDTSCP enabled CPUs become available.
This patch still has problems, and as such I'll still have to rewrite
significant portions before I release it.
Anyway, current gettimeofday() on SMP AMD x86-64 can be as bad as 1500ns.
It seems like a huge step backwards for
any apps with high res timing requirements.
gettimeofday() is the only guaranteed working mechanism. And it's as
fast as the hardware allows.
--
George Anzinger [email protected]
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
