Deadline for video capture

Deadline for video capture

[Con Kolivas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all

I suspected that the anticipatory scheduler might not have been the best 
choice for video capture because of the interruption to writes by reads and 
the subsequent anticipatory delay associated with it.  I have now confirmed 
that booting with the default anticipatory i/o elevator I get many dropped 
frames that I don't get if I boot with elevator=deadline. 

briefly: dual 7200 rpm ATA5 IDE drives in software RAID0

I guess there isn't really a lot to do about this, it's a compromise one way 
or the other. The anticipatory scheduler seems better all round but in this 
large streaming write situation it doesn't seem ideal. Any sysctl settings I 
could use to blunt the anticipation just before I do video capture?

Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAD1qzZUg7+tp6mRURAuekAJ9pFVgSLkY7zr4TL7CEfdRfKdp1DQCfUC6T
RnALyU70HgP9AQt8LS4+B6M=
=H3WY
-----END PGP SIGNATURE-----

Re: Deadline for video capture

[Nick Piggin]

Con Kolivas wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi all
>
>I suspected that the anticipatory scheduler might not have been the best 
>choice for video capture because of the interruption to writes by reads and 
>the subsequent anticipatory delay associated with it.  I have now confirmed 
>that booting with the default anticipatory i/o elevator I get many dropped 
>frames that I don't get if I boot with elevator=deadline. 
>
>briefly: dual 7200 rpm ATA5 IDE drives in software RAID0
>
>I guess there isn't really a lot to do about this, it's a compromise one way 
>or the other. The anticipatory scheduler seems better all round but in this 
>large streaming write situation it doesn't seem ideal. Any sysctl settings I 
>could use to blunt the anticipation just before I do video capture?
>

echo 0 > /sys/block/*/queue/iosched/antic_expire
Turns it off alltogether.

You could also adjust read and write batch expire settings which are
heavily biased toward reads.

Re: Deadline for video capture

[Timothy Miller]

Nick Piggin wrote:
> 
> 
> Con Kolivas wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi all
>>
>> I suspected that the anticipatory scheduler might not have been the 
>> best choice for video capture because of the interruption to writes by 
>> reads and the subsequent anticipatory delay associated with it.  I 
>> have now confirmed that booting with the default anticipatory i/o 
>> elevator I get many dropped frames that I don't get if I boot with 
>> elevator=deadline.
>> briefly: dual 7200 rpm ATA5 IDE drives in software RAID0
>>
>> I guess there isn't really a lot to do about this, it's a compromise 
>> one way or the other. The anticipatory scheduler seems better all 
>> round but in this large streaming write situation it doesn't seem 
>> ideal. Any sysctl settings I could use to blunt the anticipation just 
>> before I do video capture?
>>
> 
> echo 0 > /sys/block/*/queue/iosched/antic_expire
> Turns it off alltogether.
> 
> You could also adjust read and write batch expire settings which are
> heavily biased toward reads.

Please excuse my potentially very stupid questions....


In AS, are there any sorts of "pressure levels" which indicate how many 
read and write blocks are pending?  Perhaps AS itself could be modified 
to strongly favor writes once some water mark of available pages (page 
cache, right?) has been reached.

The main idea behind AS is to increase throughput at the expense of 
additional latency.  It certainly wouldn't hurt us if occasionally there 
was a sudden burst of well-ordered writes.

I'm assuming that AS attempts to order reads and writes in ascending 
block number, right?  Why not order I/O's by ascending block number 
regardless of whether they're reads or writes, especially when the write 
pressure reaches a certain point?


Also, what kind of other system load was going on when the capture was 
happening?  A kernel compile?  Is there any feedback from the process 
scheduler to AS which indicates that an interactive task is what is 
doing the writes?

It seems to me that video playback would be helped by AS.  If capture is 
hurt by AS, that would be a shame.  Who wants to have to reboot or 
change /proc parameters to switch between record and playback?

But then again, anyone doing professional video editing is not likely to 
be doing a kernel compile in the background.  :)

Re: Deadline for video capture

[Con Kolivas]

On Fri, 23 Jan 2004 01:28, Timothy Miller wrote:
> Also, what kind of other system load was going on when the capture was
> happening?  A kernel compile?  

Basically idle. With the deadline scheduler I was able to continue using the 
machine without dropping frames.

Con