Messages in this thread |  | | | Subject | Re: 2.6.14-rt13 | | From | Fernando Lopez-Lezcano <> | | Date | Fri, 18 Nov 2005 14:05:33 -0800 |
| |
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? -- Fernando
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |