Fig 1. Sometimes all of the work is done by three of the CPU cores. Then the speed becomes good because data is likely to be in the cache memory pretty often.
|
Hardware is developing rapidly and the current trend is towards
systems with many processor cores.
Linrad is multithreaded since year 2006.
Originally it could not take much advantage of more than one
CPU core,
but it has gradually improved over time and today, (year 2009)
Linrad will benefit from having access to three CPU cores.
Operating systems with support for SMP, symmetric multiprocessing, have been around for quite a while. Table 1 shows the timing for Linrad when processing a file from the hard disk. The file has a sampling rate of 2 MHz and was recorded as a wav file using Perseus.exe. The Linrad parameters were deliberately selected to cause a high cpu load on several threads. It is obvious from the table that different operating systems behave differently. The tests were performed with Linrad-03.07 using these parameters: xeontest.zip (2981 bytes) (Saved here mainly for my own reference.) |
|
|
Table 1. CPU load in percent running Linrad with the same parameters
on a 8-core Xeon E5410 system under various operating systems.
Tot is the total load. About 75% of the CPUs are not used,
most of the time most of the cpu cores are idle.
Some of the threads have a high CPU load.
It means that they run nearly always and that just a little more
processing would cause malfunction.
Comments to table 1: Ubuntu 6.0: The thread doing fft1 transforms runs at 100% and does not have the time to fully do what it should. There are underrun errors and short interruptions in the loudspeaker output. Presumably the sceduler Debian lenny: The thread reading the hard disk sometimes runs with very low CPU load, but sometimes it reports a very high CPU load. (0.5% or 50%) The reported timings are averages over about 10 minutes. The timings for individual threads are probably incorrect with the 2.6.26 kernels of Debian. MIT-SHM does not work because the X11 server does not report keyboard and mouse events to the event handler until after a long delay (seconds) This seems to be an X11 bug because there are plenty of idle CPUs and none of the CPUs is near 100% load. Windows 7, 64 bit: This operating system runs Linrad in several distinctly different modes. The mode seems to be selected at random at the moment Linrad opens the processing threads. Once Linad has started, the threads have a fixed CPU load. It seems the scheduler can adopt different strategies that make good or poor use of the cache in the processors. Figures 1 and 2 show the Linrad screen with the different thread loads as well as the system monitor that displays how work is distributed between the processors. |
Fig 1. Sometimes all of the work is done by three of the CPU cores. Then the speed becomes good because data is likely to be in the cache memory pretty often. |
 Fig 2. Sometimes the work is distributed over more CPU cores. Then the speed becomes slow because data is not likely to be in the cache so often. |
The main reason for doing the tests presented on this page was not to check the effectiveness of the schedulers in the different operating systems but to look for possible errors in the Linrad code that might become visible. The ratio fastest/slowest for the different threads are like this: File input Rxfi 0.0 Soundcard output RxDA 0.29 Screen Scre 0.07 Wideband dsp (fft1) Wdsp 0.75 Narrowband dsp (fft3, FIR) Ndsp 0.50 Second FFT fft2 0.59 To what extent the fairly large differences are only due to cache usage or whether there are also differences in program flow remains to be investigated. The testing reported on this page did not reveal any obvious malfunction of Linrad-03.07. To SM 5 BSZ Main Page |