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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
