After many tests with nice and different clustersizes if have found from my point of view the true reason for the poor /O performance to/from the hdd if the box make many write and read operations to/from the drive
The actual I/O scheduler for block devices like drives has tree methods to schedule the orders to the disk
NOOP. easy fifo method
dreadline: different queues and sortings for matching the sector numbers and some deadlines to prevent starving of drive orders
cfq : faire schedule based am time slices for different processes. This is the default scheduler
you can see the setting with
cat /sys/block/sd*/queue/scheduler
I don´t know exactly why cfq doesn´t work so efficient for the enigma box application if I make many recording in parallel to mcut and mv/cp commands but fact is, the i/o load is between 80-100 percent, if you use massiv write and read operation, but the write transferrate to the disk is often poor. The idle load often is zero Sometimes you see only some Mbyte/s write performance to the hole drive for all recordings if you make mcut on mv/cp in parallel to the recordings. Maybe the timeslice doesn´t match the real time requirement of recording jobs. The result are interrrupts in the recordings and a poor GUI responsibiltiy. That is not what I expected from a modern box
Now I´ve tested the method deadline. Setting is possible on runtime with
echo deadline >/sys/block/sdx/queue/scheduler
sdx = sda,sdc,sdc ...
for each drive
The result is phantastic: The box doesn´t make interrupts in the recordings if other jobs make massiv read operations. The reaction of the GUI ist much more better than with cfq.
For example with the cfg schedule if you are in the movielist and you select a movie which is recording in background (many records are running), very often you see a spinner or it needs time to show the size of the file. Now with deadline scheduler it is very quick. No waitings. I´ve seen that waitings also on my old et9200 box, They also use cfq scheduler but there it works better., I don´t know why cfg works better an MIPS than on ARM.
I´ve tested deadline with 14 parallel recordings and a cutting queue with mcut for other movies and moving movies with mv command (from EMC). The recording jobs now write all there datablocks to the disk and mcut and mv/cp get the restpower of the box for disk I/O. The command top now shows very often higher idle loads for the two cores and the I/O load is in a expected range
The problem with cfq are on all images. I´ve tested VTI, openATV and openpli. All use the same 4.1.20 kernel for unokse.
Now with the solution deadline I´m very happy and the box works as I expected. Other users may testet it and if all are happy, it would be great if the openpli team will integrate deadline to the default scheduler during kernel compilation or later with startscripts on runlevel
