Additional responsiveness and video-playing results
In this page we report further results, with respect to the ones provided in our main result page, with BFQ-v7r3, CFQ, DEADLINE and NOOP, under 3.14.0, and on the following devices:
- A (high-speed) Seagate ST1000DM003 HDD
- A pair of the above HDDs in a software RAID1 configuration
- A PLEXTOR PX-256M5S SSD
In particular, for each device we report both our responsiveness results with bash and konsole, and our frame-drop-rate results with mplayer.
We obtained also these results using our ad hoc benchmark suite. As in the main result page, in what follows we call reader/writer a program (we used either dd or fio) that just reads/writes a large file. In addition we say that a reader/writer is sequential or random depending on whether it reads/writes the file sequentially or at random positions.
As for responsiveness results, the same comments as in the main result page apply, so we do not repeat them also in this page.
In the video-playing tests, in parallel with the playback of the video, we executed the same workloads as for the responsiveness tests, and, to make the background workload even more demanding for such a time-sensitive application, we also started and terminated repeatedly a bash shell.
Seagate HDD
The next two figures show the cold-cache start-up time of bash and konsole while one of the following four heavy workloads is being executed: 10 parallel sequential or random readers (10r-seq, 10r-rand), 5 parallel sequential or random readers plus 5 parallel sequential or random writers (5r5w-seq, 5r5w-rand). The symbol X means that, for that workload and with that scheduler, the application failed to start in 60 seconds.
Video-playing results are shown in the next figure. This time the symbol X means that the playback of the video did not terminate within a 60-second timeout after its actual duration, and hence the test was aborted. In most of these failure cases, the playback of the video actually did not start at all during the test.
As can be seen, the performance of BFQ is not even comparable with that of the other schedulers (except for CFQ with 5r5w-seq). Finally, it is worth noting that BFQ achieves its best performance with 5r5w-seq: the reason is that writes let the block layer work in request-saturation conditions, which happened to penalize mplayer less than the other competing applications. With 5r5w-rand the drop rate is however higher because of the mechanism that, from v7r3 on, tries to keep the drive's internal queue full in the presence of random I/O.
Pair of Seagate HDDs in software RAID1
RAID results basically match the above results with one HDD, for both the responsiveness and the frame-drop-rate tests.
PLEXTOR SSD
We recall that with the SSD we consider only raw readers, i.e., processes reading directly from the device, to avoid writing large files repeatedly, and hence wearing out a costly SSD :)
The next figures show our responsiveness and frame-drop-rate results. We comment on only the latter.
Finally, the next figure shows our video-playing results.
Whereas with sequential readers BFQ dramatically outperforms the other schedulers, the performance of the latter is closer to that of BFQ with random readers (although the frame-drop rate with the other schedulers is however about twice as high as with BFQ).