[ardour-users] [Fwd: Re: Is 64 bit dual core supported and stable yet?]

[Joel White]

Fernando Lopez-Lezcano wrote:

>>>On Sat, 2005-12-03 at 10:49 -0500, Joel White wrote:
>>>      
>>>
>>>>><Snip>
>>>>>          
>>>>>
>>Ok, cool.  I was wondering about that.  I've just tried setting the cpu 
>>affinity of the jack processes to one processor using taskset, along 
>>with setting the smp_affinity of the sound card IRQ back to 0x03 (both 
>>processors).  I've been recording 8 tracks at -r 44100 -p 64 -n 2 
>>(duplex) for over an hour now without an xrun or "delay..." message.  I 
>>think this will give me a good working system for recording.
>>    
>>
>
>Sounds very good. Did you reboot? The TSC drift depends on the cpu being
>idle and for how long. So right after a reboot you won't see the problem
>but it will get worse over time (without reboots and with light
>workload). A loaded system will definitely drift very little. I have
>note tested vanilla 2.6.14 but on -rt patched kernels the situation
>could take a while to show up, once it did it kept getting worse over
>time, of course. 
>  
>
It has been a while (days) since reboot.  If I start jack running on 
both processors, I see the delay problem immediately.  If I then set the 
affinity of all the jackd processes to one processor (the one showing 
the fewer interrupts on /proc/interrupts), the "delay..." messages cease.

I then recorded 8 tracks at -r 44100 -p 64 -n 2 for over 3 hours without 
an xrun or "delay..." problem.  Just to be cruel, I stressed X by 
running "x11perf -scroll500 -shmput500" from the old latencytest suite 
of tests.  The display on ardour slowed considerably during the 
-scroll500, but there were no recording problems.

I then ran 'emerge mozilla-thunderbird' (which runs make with -j3), 
which halted ardour, but not with an xrun.  Something to do with disk 
access.  I tried this again (letting ardour run for about 20 minutes 
first to make sure files were flushing to disk), and the same thing 
happened (along with messages from ardour that the peak files weren't 
being read properly).

I then set -p 128 and repeated - no problems whatsoever (not that I 
would ever build a package during a recording session, it just seemed a 
good stress test :-0.  Not bad at all!

Now, it seems I need to tune my harddrive.  It is a SATA disk, and I 
haven't found much yet on how to do that (google returns lots of stuff 
about RAID and SATA).  If anyone has any suggestions, I'd appreciate any 
pointers.

>Could be that vanilla 2.6.14 is better than what I thought. 
>  
>
Yes, I'm impressed with the performance (once I worked out setting the 
jackd affinity to one processor).

>FYI the latest -rt patch (-rt21) does not choose the TSC for system
>timing - that plus a patched jack should also be good without pinning
>processes to individual cpus (not to suggest you switch to that). 
>  
>
I might try that eventually, but in the meantime I'm a happy camper.

Thanks!

Joel

>-- Fernando
>
>
>
>  
>