Re: 2.6.14-rt13

[Lee Revell <rlrevell@joe-job.com>]

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".

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 seems like a huge step backwards for
any apps with high res timing requirements.

Lee