28 Oct
2008
28 Oct
'08
9:38 a.m.
Hi,
I'm CC'ing this mail to jack-devel and using a more meaningful subject, to ease
data-mining.
This is the first ring buffer test on a PowerPC SMP, and there is apparently no
failure caused by the lack of memory barrier.
Jesse Chappell wrote:
For the records, here is the output from a dual IBM
Cell system
(QS-21), each PowerPC unit is exposed with two cores.
jlc
$ cat /proc/cpuinfo
processor : 0
cpu : Cell Broadband Engine, altivec supported
clock : 3200.000000MHz
revision : 5.1 (pvr 0070 0501)
processor : 1
cpu : Cell Broadband Engine, altivec supported
clock : 3200.000000MHz
revision : 5.1 (pvr 0070 0501)
processor : 2
cpu : Cell Broadband Engine, altivec supported
clock : 3200.000000MHz
revision : 5.1 (pvr 0070 0501)
processor : 3
cpu : Cell Broadband Engine, altivec supported
clock : 3200.000000MHz
revision : 5.1 (pvr 0070 0501)
timebase : 14318000
platform : Cell
machine : CHRP MCS, -n/a
=================================================================
./run-tests.sh bit-circle 512 jack jack-fix1 portaudio portaudio-nobarrier lfq
test-bit-circle-jack - starting (5s max) - buffer size: 512
||-||||||-||||-||||------------- SUCCESS
test-bit-circle-jack-fix1 - starting (5s max) - buffer size: 512
||||||||-||||||||--------------- SUCCESS
test-bit-circle-portaudio - starting (5s max) - buffer size: 512
||||||-|||-||||||--|------------ SUCCESS
test-bit-circle-portaudio-nobarrier - starting (5s max) - buffer size: 512
||||-|-|-||||||-||--||---------- SUCCESS
test-bit-circle-lfq - starting (5s max) - buffer size: 512
||-|||||||-||-|-||||------------ SUCCESS
./run-tests.sh int-array 16 jack jack-fix1 portaudio portaudio-nobarrier lfq
test-int-array-jack - starting (120s max) - array/buffer size: 8/16
[reader started] [writer started] [flowing] 29364 != 29360 at offset 0
FAILURE in chunk 702810
This failure is normal, it is the Jack ring buffer without my patch applied. It
also happens on x86 SMP and single-cpu, as previously reported.
test-int-array-jack-fix1 - starting (120s max) -
array/buffer size: 8/16
[reader started] [writer started] [flowing] SUCCESS
Once patched, jack's ringbuffer succeeds. The tests run two minutes, I think
Jesse's machine (dual 3.2Ghz PowerPC) runs fast enough so that a failure should
appear in this time interval, if it's technically possible. It's hard to be sure
though.
test-int-array-portaudio - starting (120s max) -
array/buffer size: 8/16
[reader started] [writer started] [flowing] SUCCESS
test-int-array-portaudio-nobarrier - starting (120s max) -
array/buffer size: 8/16
[reader started] [writer started] [flowing] SUCCESS
Whether memory barriers are deactivated or not in Portaudio's ringbuffer, the
test succeeds.
test-int-array-lfq - starting (120s max) -
array/buffer size: 8/16
[reader started] [writer started] [flowing] SUCCESS
This last one is Fons' LFQ.
Jesse: it might be worth running test-int-array longer (change the sleep() call
at the end of test-int-array.c). You could also try and run the test suite
several times: the threads might have been scheduled to run on the same
processor/core in your first attempt.
In this regard you can try with rbtest at r309:
svn co -r309 http://svn.samalyse.com/misc/rbtest
It prints the cpu on which the threads are started (I deactivated this because
sched_getcpu() was randomly absent or crashing, but it might work in you case).
Thanks,
--
Olivier Guilyardi / Samalyse