smp, jack, TSC and "delay exceeds" warnings...

classic Classic list List threaded Threaded
69 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

smp, jack, TSC and "delay exceeds" warnings...

Fernando Lopez-Lezcano
Hi all, I first posted about this problem on Sep 27 (look for a subject
that says "delay of nnn exceeds... and weird behavior"), I think I have
now a diagnostic.

I'm running the latest and greatest low latency kernels based on (at
this time) 2.6.14 + Ingo's 2.6.14-rt13 realtime preemption patches. This
runs on top of a dual core Athlon based computer.

Right after booting into the kernel I start Jack and everything is fine.
After a while I start getting the dreaded "delay of xxx exceeds"
messages. There are no audible xruns. The reported delay keeps growing
over time. The only solution I found to return to normal is to reboot
the machine. The messages happen frequently, but not on all Jack cycles.
They seem to be triggered by user activity (moving between windows,
doing things), but not always.

Here's what seems to be happening: apparently Jack is using the TSC
("Time Stamp Clock") for timing purposes. It reads it at startup,
establishes a timing reference and then reads it again when it needs to
calculate how much time has elapsed (disclaimer: I have not read the
code).

Just a couple of days ago I learned on the lkml that the TSC's of the
two processors can drift apart over time!

That would seem to explain perfectly all the symptoms I have seen so
far. When Jack reads the TSC to calculate a time difference it can be
running on the _other_ cpu (not the one that was used originally to set
the reference time) and so the time difference is going to be wrong, and
that is reported as an error. Plus if the TSC does indeed drift then it
is not a good absolute time reference either (may lead to problems on UP
systems as well).

So, all this time I thought there was a kernel problem but it appears to
be an assumption on the part of Jack of how the TSC's work (so I'm not
cc'ing lkml).

I have not done any actual coding or experiments to _prove_ this is the
problem, but so far it fits the facts well.

Solutions so far:

- use gettimeofday instead (is this somehow a compile time option?)
- pin the thread that uses the TSC to run on only one of the processors

I think this is a serious problem that potentially affects all SMP users
that use the TSC as the time reference.

-- Fernando




-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: smp, jack, TSC and "delay exceeds" warnings...

Paul Davis
> Just a couple of days ago I learned on the lkml that the TSC's of the
> two processors can drift apart over time!

can i get a link? back in circa 2000-2001, i was assured on lkml that
this could *not* happen.




-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: smp, jack, TSC and "delay exceeds" warnings...

Jens Hannemann
On Saturday 19 November 2005 16:08, Paul Davis wrote:
> > Just a couple of days ago I learned on the lkml that the TSC's of the
> > two processors can drift apart over time!
>
> can i get a link? back in circa 2000-2001, i was assured on lkml that
> this could *not* happen.

I'm currently tinkering with this. From my manpage for clock_gettime (SuSE
9.3, Kernel 2.6.11.4-21.9-default):

-- snip --
If  the  CPUs in an SMP system have different clock sources then there
is no way to maintain a correlation between the timer registers  since
each  CPU  will  run at a slightly different frequency. If that is the
case then clock_getcpuclockid(0) will return ENOENT  to  signify  this
condition.  The  two  clocks  will  then  only  be useful if it can be
ensured that a process stays on a certain CPU.
-- snap --

I have yet to find an SMP system, however, where clock_getcpuclockid actually
does return ENOENT. For now, I assume this means all my SMP systems do have
only one clock source. Maybe Fernando should check this on his system.

Jens

--
Dr.-Ing. Jens Hannemann --- [hidden email] --- GPG Key Available
University of Kentucky -- Dept. of Electrical and Computer Engineering
Center for Visualization and Virtual Environments


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: smp, jack, TSC and "delay exceeds" warnings...

Lee Revell
In reply to this post by Paul Davis
On Sat, 2005-11-19 at 16:08 -0500, Paul Davis wrote:
> > Just a couple of days ago I learned on the lkml that the TSC's of the
> > two processors can drift apart over time!
>
> can i get a link? back in circa 2000-2001, i was assured on lkml that
> this could *not* happen.

That was the case with 2000-2001 hardware but now it seems that dual
core systems with unsynced TSC's are getting common.  I think the kernel
developers were surprised by this also.

See http://bugzilla.kernel.org/show_bug.cgi?id=5105 and this (very long
thread):
http://marc.theaimsgroup.com/?l=linux-kernel&m=112715749117684&w=2

Lee



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: smp, jack, TSC and "delay exceeds" warnings...

Fernando Lopez-Lezcano
In reply to this post by Paul Davis
On Sat, 2005-11-19 at 16:08 -0500, Paul Davis wrote:
> > Just a couple of days ago I learned on the lkml that the TSC's of the
> > two processors can drift apart over time!
>
> can i get a link? back in circa 2000-2001, i was assured on lkml that
> this could *not* happen.

New hardware, I guess....
This is part of it:
  http://lkml.org/lkml/2005/11/15/58
Ingo's fragment that suggested the drift was off the list, I'm including
it here:

On Fri, 2005-11-11 at 20:39 +0100, Ingo Molnar wrote:

> * Fernando Lopez-Lezcano <[hidden email]> wrote:
> > I'm attaching it... looks like they sync. I presume they would not
> > drift over time, right? Strange. I'm also attaching the configuration
> > file for the smp build just in case.
>
> hm, they are not in sync:
>
> > Nov  4 13:50:32 cmn3 kernel: Linux version 2.6.14-0.5.rrt.rhfc4.ccrmasmp ([hidden email]) (gcc version 4.0.1 20050727 (Red Hat 4.0.1-5)) #1 SMP PREEMPT Fri Nov 4 14:25:00 EST 2005
>
> > Nov  4 13:50:34 cmn3 kernel: checking TSC synchronization across 2 CPUs:
> > Nov  4 13:50:34 cmn3 kernel: CPU#0 had -1459757 usecs TSC skew, fixed it up.
> > Nov  4 13:50:34 cmn3 kernel: CPU#1 had 0 usecs TSC skew, fixed it up.
>
> there was a more than 1 second offset between the two TSCs. This does
> happen occasionally, if the BIOS doesnt fix them up.
>
> normally they should not drift over time - although that could happen
> too. Does the stock kernel report a TSC drift too?
>
> oh - it's an Athlon 64 X2 dual core box, right? There the TSCs can drift
> over time. Could you try to boot with idle=poll, does that make things
> better?
>
> Ingo

So it would seem that this is hardware dependent...
-- Fernando




-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: smp, jack, TSC and "delay exceeds" warnings...

Paul Davis
On Sat, 2005-11-19 at 12:39 -0800, Fernando Lopez-Lezcano wrote:

> On Sat, 2005-11-19 at 16:08 -0500, Paul Davis wrote:
> > > Just a couple of days ago I learned on the lkml that the TSC's of the
> > > two processors can drift apart over time!
> >
> > can i get a link? back in circa 2000-2001, i was assured on lkml that
> > this could *not* happen.
>
> New hardware, I guess....
> This is part of it:
>   http://lkml.org/lkml/2005/11/15/58
> Ingo's fragment that suggested the drift was off the list, I'm including
> it here:

having the read the bugzilla report and the kernel thread, it is clear
that JACK's "get_microseconds" call needs to be run-time switchable
to use gettimeofday() rather than the TSC. this will allow people to use
the same binary of JACK on systems with and without synced TSC's (as far
as i could tell, it is only dual core systems, not "true SMP" systems
that have this issue). ideally, someone could use Jens' test to figure
out what to use at run time, but otherwise, a cmdline arg would work.

anybody want to cook that up?

--p




-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: smp, jack, TSC and "delay exceeds" warnings...

Lee Revell
On Sat, 2005-11-19 at 17:20 -0500, Paul Davis wrote:
> having the read the bugzilla report and the kernel thread, it is clear
> that JACK's "get_microseconds" call needs to be run-time switchable
> to use gettimeofday() rather than the TSC. this will allow people to
> use the same binary of JACK on systems with and without synced TSC's
> (as far as i could tell, it is only dual core systems, not "true SMP"
> systems that have this issue). ideally, someone could use Jens' test
> to figure out what to use at run time, but otherwise, a cmdline arg
> would work.
>

Personally I find it a bit dismaying that AMD has so cavalierly rendered
rdtsc useless for high res timing and failed to provide an alternative.

Lee



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: smp, jack, TSC and "delay exceeds" warnings...

Fons Adriaensen
In reply to this post by Paul Davis
On Sat, Nov 19, 2005 at 05:20:55PM -0500, Paul Davis wrote:

> having the read the bugzilla report and the kernel thread, it is clear
> that JACK's "get_microseconds" call needs to be run-time switchable
> to use gettimeofday() rather than the TSC. this will allow people to use
> the same binary of JACK on systems with and without synced TSC's (as far
> as i could tell, it is only dual core systems, not "true SMP" systems
> that have this issue). ideally, someone could use Jens' test to figure
> out what to use at run time, but otherwise, a cmdline arg would work.
>
> anybody want to cook that up?

What about making this the *only* time source ?

This would have one interesting advantage. Clients using OSC need a DLL
or something similar to map OSC time (which is in terms of gettimeofday())
to frame time or buffer offsets. By making jackd's DLL use this time
it could provide the necessary information without any overhead.
Otherwise a second one is needed, either per client or within jackd.
I've had such a thing in my modified jackd for some time now, and
together with some API extensions, it provides the necessary info
to all clients.

If the overhead of calling gettimeofday() on each cycle is too much
(I don't think it is, unless maybe you have very short periods such
as 16 or 32), it is possible to this do ever Nth cycle instead.
The DLL can easily be adapted to cope with this.

--
FA

 


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: smp, jack, TSC and "delay exceeds" warnings...

Paul Davis
On Sat, 2005-11-19 at 22:44 +0100, fons adriaensen wrote:

> On Sat, Nov 19, 2005 at 05:20:55PM -0500, Paul Davis wrote:
>
> > having the read the bugzilla report and the kernel thread, it is clear
> > that JACK's "get_microseconds" call needs to be run-time switchable
> > to use gettimeofday() rather than the TSC. this will allow people to use
> > the same binary of JACK on systems with and without synced TSC's (as far
> > as i could tell, it is only dual core systems, not "true SMP" systems
> > that have this issue). ideally, someone could use Jens' test to figure
> > out what to use at run time, but otherwise, a cmdline arg would work.
> >
> > anybody want to cook that up?
>
> What about making this the *only* time source ?

what other time source is there?




-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: smp, jack, TSC and "delay exceeds" warnings...

Lee Revell
In reply to this post by Paul Davis
On Sat, 2005-11-19 at 17:20 -0500, Paul Davis wrote:

> On Sat, 2005-11-19 at 12:39 -0800, Fernando Lopez-Lezcano wrote:
> > On Sat, 2005-11-19 at 16:08 -0500, Paul Davis wrote:
> > > > Just a couple of days ago I learned on the lkml that the TSC's of the
> > > > two processors can drift apart over time!
> > >
> > > can i get a link? back in circa 2000-2001, i was assured on lkml that
> > > this could *not* happen.
> >
> > New hardware, I guess....
> > This is part of it:
> >   http://lkml.org/lkml/2005/11/15/58
> > Ingo's fragment that suggested the drift was off the list, I'm including
> > it here:
>
> having the read the bugzilla report and the kernel thread, it is clear
> that JACK's "get_microseconds" call needs to be run-time switchable
> to use gettimeofday() rather than the TSC. this will allow people to use
> the same binary of JACK on systems with and without synced TSC's (as far
> as i could tell, it is only dual core systems, not "true SMP" systems
> that have this issue). ideally, someone could use Jens' test to figure
> out what to use at run time, but otherwise, a cmdline arg would work.
>
> anybody want to cook that up?
>

Can someone test this program on a modern machine?  It shows that
gettimeofday() is 30x slower than rdtsc() on my machine - 3 microseconds
vs. 100 nanoseconds.  According to http://lkml.org/lkml/2005/11/18/261,
the kernel developers think they can get it to be as fast as 175 ns -
comparable to rdtsc.

This is what I get:

rdtsc: 10000 calls in 1035 usecs
gettimeofday: 10000 calls in 34759 usecs

Lee

#include <stdio.h>
#include <stdlib.h>
#include <sys/time.h>

typedef unsigned long long cycles_t;

#define rdtscll(val) \
     __asm__ __volatile__("rdtsc" : "=A" (val))

static inline cycles_t get_cycles_tsc (void)
{
        unsigned long long ret;

        rdtscll(ret);
        return ret;
}

static inline cycles_t get_cycles_gtod (void)
{
       struct timeval tv;
       gettimeofday (&tv, NULL);

       return tv.tv_usec;
}

int main (void) {
        int i;  
        cycles_t start_time;
        start_time= get_cycles_gtod();
        for (i = 0; i < 10000; i++) {
                get_cycles_tsc();
        }      
        printf("rdtsc: %i calls in %llu usecs\n", i, get_cycles_gtod() - start_time);
        start_time = get_cycles_gtod();
        for (i = 0; i < 10000; i++) {
                get_cycles_gtod();
        }      
        printf("gettimeofday: %i calls in %llu usecs\n", i, get_cycles_gtod() - start_time);
        return 0;
}




-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: smp, jack, TSC and "delay exceeds" warnings...

Fons Adriaensen
In reply to this post by Paul Davis
On Sat, Nov 19, 2005 at 05:53:31PM -0500, Paul Davis wrote:

> On Sat, 2005-11-19 at 22:44 +0100, fons adriaensen wrote:
> > On Sat, Nov 19, 2005 at 05:20:55PM -0500, Paul Davis wrote:
> >
> > > having the read the bugzilla report and the kernel thread, it is clear
> > > that JACK's "get_microseconds" call needs to be run-time switchable
> > > to use gettimeofday() rather than the TSC. this will allow people to use
> > > the same binary of JACK on systems with and without synced TSC's (as far
> > > as i could tell, it is only dual core systems, not "true SMP" systems
> > > that have this issue). ideally, someone could use Jens' test to figure
> > > out what to use at run time, but otherwise, a cmdline arg would work.
> > >
> > > anybody want to cook that up?
> >
> > What about making this the *only* time source ?
>
> what other time source is there?

??? The one that's used now (TSC based).

--
FA


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: smp, jack, TSC and "delay exceeds" warnings...

D. Michael McIntyre-3
In reply to this post by Lee Revell
On Saturday 19 November 2005 04:59 pm, Lee Revell wrote:

> Can someone test this program on a modern machine?  It shows that
> gettimeofday() is 30x slower than rdtsc() on my machine - 3 microseconds
> vs. 100 nanoseconds.

This is on a 2 GHz P4.  I'm not sure if this is "modern" enough for your
purposes or not.  It's a smaller gap, but still a huge gap.

rdtsc: 10000 calls in 548 usecs
gettimeofday: 10000 calls in 7516 usecs

--
Michael McIntyre  ----   Silvan <[hidden email]>
Linux fanatic, and certified Geek;  registered Linux user #243621
http://www.geocities.com/Paris/Rue/5407/
http://rosegarden.sourceforge.net/tutorial/



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: smp, jack, TSC and "delay exceeds" warnings...

Rui Nuno Capela
In reply to this post by Lee Revell
Lee Revell wrote:

>
> Can someone test this program on a modern machine?  It shows that
> gettimeofday() is 30x slower than rdtsc() on my machine - 3 microseconds
> vs. 100 nanoseconds.  According to http://lkml.org/lkml/2005/11/18/261,
> the kernel developers think they can get it to be as fast as 175 ns -
> comparable to rdtsc.
>
> This is what I get:
>
> rdtsc: 10000 calls in 1035 usecs
> gettimeofday: 10000 calls in 34759 usecs
>

I get this very consistently on a P4@3.3Ghz/HT (OpenSUSE 10.0
2.6.13-15-smp):

rdtsc: 10000 calls in 253 usecs
gettimeofday: 10000 calls in 26547 usecs

So, it gets 100x slower here.

Bye.
--
rncbc aka Rui Nuno Capela
[hidden email]


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: smp, jack, TSC and "delay exceeds" warnings...

Dave Cunningham
In reply to this post by Lee Revell
rdtsc: 10000 calls in 345 usecs
gettimeofday: 10000 calls in 33240 usecs

p4 3 ghz

2.6.12 unpatched

not sure about glibc version

also, clock_gettime is comparable in speed to gettimeofday on my
system, what is the difference between these two?  I arbitrarily
used clock_gettime in jack_diplomat, you see...

these are what i see:

clock_gettime seems to have several different kinds of clocks,
including CLOCK_REALTIME and CLOCK_MONOTONIC (sometimes with
CLOCK_REALTIME i would get weird spikes in the timings, but
using CLOCK_MONOTONIC made those go away)

it returns nsecs instead of usecs in the struct, but on linux
the 3 least significant digits are zero



another issue, what about frequency scaling with rdtsc?  are we
ignoring that?


How many times does jack need to measure the time in a period
anyway?  3 usecs per call doesnt seem like that much to me but
then it might be more on other machines...



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: smp, jack, TSC and "delay exceeds" warnings...

David Mulcahy
In reply to this post by Lee Revell
On Saturday 19 Nov 2005 21:59, Lee Revell wrote:

> On Sat, 2005-11-19 at 17:20 -0500, Paul Davis wrote:
> > On Sat, 2005-11-19 at 12:39 -0800, Fernando Lopez-Lezcano wrote:
> > > On Sat, 2005-11-19 at 16:08 -0500, Paul Davis wrote:
> > > > > Just a couple of days ago I learned on the lkml that the TSC's of
> > > > > the two processors can drift apart over time!
> > > >
> > > > can i get a link? back in circa 2000-2001, i was assured on lkml that
> > > > this could *not* happen.
> > >
> > > New hardware, I guess....
> > > This is part of it:
> > >   http://lkml.org/lkml/2005/11/15/58
> > > Ingo's fragment that suggested the drift was off the list, I'm
> > > including it here:
> >
> > having the read the bugzilla report and the kernel thread, it is clear
> > that JACK's "get_microseconds" call needs to be run-time switchable
> > to use gettimeofday() rather than the TSC. this will allow people to use
> > the same binary of JACK on systems with and without synced TSC's (as far
> > as i could tell, it is only dual core systems, not "true SMP" systems
> > that have this issue). ideally, someone could use Jens' test to figure
> > out what to use at run time, but otherwise, a cmdline arg would work.
> >
> > anybody want to cook that up?
>
> Can someone test this program on a modern machine?  It shows that
> gettimeofday() is 30x slower than rdtsc() on my machine - 3 microseconds
> vs. 100 nanoseconds.  According to http://lkml.org/lkml/2005/11/18/261,
> the kernel developers think they can get it to be as fast as 175 ns -
> comparable to rdtsc.
>
> This is what I get:
>
> rdtsc: 10000 calls in 1035 usecs
> gettimeofday: 10000 calls in 34759 usecs
>
> Lee
>
And on My not so modern P111 700
kernel 2.6.14
rdtsc: 10000 calls in 764 usecs
gettimeofday: 10000 calls in 4940 usecs


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: smp, jack, TSC and "delay exceeds" warnings...

Fernando Lopez-Lezcano
In reply to this post by Lee Revell
On Sat, 2005-11-19 at 16:59 -0500, Lee Revell wrote:

> On Sat, 2005-11-19 at 17:20 -0500, Paul Davis wrote:
> Can someone test this program on a modern machine?  It shows that
> gettimeofday() is 30x slower than rdtsc() on my machine - 3 microseconds
> vs. 100 nanoseconds.  According to http://lkml.org/lkml/2005/11/18/261,
> the kernel developers think they can get it to be as fast as 175 ns -
> comparable to rdtsc.
>
> This is what I get:
>
> rdtsc: 10000 calls in 1035 usecs
> gettimeofday: 10000 calls in 34759 usecs

2.6.14-rt13, PREEMPT_RT, Athlon X2 4400+ (dual core)

rdtsc: 10000 calls in 68 usecs
gettimeofday: 10000 calls in 5170 usecs

-- Fernando




-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: smp, jack, TSC and "delay exceeds" warnings...

Dave Robillard
In reply to this post by Lee Revell
On Sat, 2005-19-11 at 16:59 -0500, Lee Revell wrote:
> Can someone test this program on a modern machine?  It shows that
> gettimeofday() is 30x slower than rdtsc() on my machine - 3 microseconds
> vs. 100 nanoseconds.  According to http://lkml.org/lkml/2005/11/18/261,
> the kernel developers think they can get it to be as fast as 175 ns -
> comparable to rdtsc.

P4 1.6 Laptop:

rdtsc: 10000 calls in 694 usecs
gettimeofday: 10000 calls in 7164 usecs

-DR-



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: smp, jack, TSC and "delay exceeds" warnings...

Lee Revell
In reply to this post by Fernando Lopez-Lezcano
On Sat, 2005-11-19 at 17:22 -0800, Fernando Lopez-Lezcano wrote:

> On Sat, 2005-11-19 at 16:59 -0500, Lee Revell wrote:
> > On Sat, 2005-11-19 at 17:20 -0500, Paul Davis wrote:
> > Can someone test this program on a modern machine?  It shows that
> > gettimeofday() is 30x slower than rdtsc() on my machine - 3 microseconds
> > vs. 100 nanoseconds.  According to http://lkml.org/lkml/2005/11/18/261,
> > the kernel developers think they can get it to be as fast as 175 ns -
> > comparable to rdtsc.
> >
> > This is what I get:
> >
> > rdtsc: 10000 calls in 1035 usecs
> > gettimeofday: 10000 calls in 34759 usecs
>
> 2.6.14-rt13, PREEMPT_RT, Athlon X2 4400+ (dual core)
>
> rdtsc: 10000 calls in 68 usecs
> gettimeofday: 10000 calls in 5170 usecs

Wow, that's amazing - rdtsc is practically free on your system.  It's
really a pity the TSCs are unsynced.

Lee



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: smp, jack, TSC and "delay exceeds" warnings...

Fernando Lopez-Lezcano
In reply to this post by Paul Davis
On Sat, 2005-11-19 at 17:20 -0500, Paul Davis wrote:

> On Sat, 2005-11-19 at 12:39 -0800, Fernando Lopez-Lezcano wrote:
> > On Sat, 2005-11-19 at 16:08 -0500, Paul Davis wrote:
> > > > Just a couple of days ago I learned on the lkml that the TSC's of the
> > > > two processors can drift apart over time!
> > >
> > > can i get a link? back in circa 2000-2001, i was assured on lkml that
> > > this could *not* happen.
> >
> > New hardware, I guess....
> > This is part of it:
> >   http://lkml.org/lkml/2005/11/15/58
> > Ingo's fragment that suggested the drift was off the list, I'm including
> > it here:
>
> having the read the bugzilla report and the kernel thread, it is clear
> that JACK's "get_microseconds" call needs to be run-time switchable
> to use gettimeofday() rather than the TSC. this will allow people to use
> the same binary of JACK on systems with and without synced TSC's (as far
> as i could tell, it is only dual core systems, not "true SMP" systems
> that have this issue). ideally, someone could use Jens' test to figure
> out what to use at run time, but otherwise, a cmdline arg would work.
>
> anybody want to cook that up?

You mean this from John Stultz?
  http://bugzilla.kernel.org/attachment.cgi?id=5993&action=view
-- Fernando




-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: smp, jack, TSC and "delay exceeds" warnings...

Jussi Laako
In reply to this post by Fons Adriaensen
On Sat, 2005-11-19 at 22:44 +0100, fons adriaensen wrote:
> What about making this the *only* time source ?
>
> If the overhead of calling gettimeofday() on each cycle is too much

IMO, using TSC or gettimeofday() is a bad solution. I think we should
use RT standard clock_gettime(CLOCK_MONOTONIC) instead. It can give
better resolution and shouldn't be messed up by NTP. That should be
universally available in all reasonably capable POSIX systems.


--
Jussi Laako <[hidden email]>



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
1234