Linux, mysql, IO schedulers

A colleague called a couple of days ago. I compared the performance of mysql on solarium and centos. Asked to make a comparison on a self-assembly gent.
I collect mysql, for tests it is used run-all-tests from the directory sql-bench of a distribution of a muskulya. I did all this on my home machine, where CFQ is used by default. The machine is an AMD Athlon (tm) 64 X2 Dual Core Processor 4800+, both cores work (although for some reason only one was used for tests), 2 gigabytes of memory. Screw - SATA1, AHCI. Mysql 5.0.54.
The total test time was used as test results. On the Ghent it was 1600 seconds, on the solarium - 1300, on the centros - strongly for 2000.
Today I decided to extend the experiment and test the behavior of the muscle on different IO schedulers. The results are somewhat puzzled. So,
Anticipatory - 1795 sec.
Deadline - 1867 sec.
CFQ - 1523 sec.
That is not at all what could have been expected. According to the help when configuring the kernel:

• The choice of the I / O scheduler is more than a large scale when compared with the deadline I / O scheduler.
  
• I / O scheduler is a compact and easy-to-use workloads, better. It is a good choice.
  
• The CFQ I / O scheduler scans to distribute bandwidth. It should provide a working environment.
  

That is, the best performance was expected on the deadline, in fact, it turned out to be the slowest. Anticipatory showed average results, but CFQ (desktop !!!) beat competitors by almost five minutes. Although the tests were performed on a running desktop system, there was practically no load on the screw at that time.
Perhaps it makes sense to play with other versions of muscle, but I was thinking about transferring my production mysql servers to another sheduler.