#10045 HIGH 1.5-sof: XO-1.5 Record audio/video are out of sync with each other

[Tiago Marques]

On Tue, May 11, 2010 at 12:47 AM, James Cameron <quozl at laptop.org> wrote:

> On Mon, May 10, 2010 at 05:33:07PM +0100, Tiago Marques wrote:
> > On Mon, May 10, 2010 at 7:37 AM, James Cameron <quozl at laptop.org> wrote:
> >     On Sat, May 08, 2010 at 05:24:00PM +0000, Tiago Marques wrote:
> >     > I was just looking into this and the issue with SD cards' random
> write
> >     > performance intrigued me in this particular case.   Isn't recording
> >     > being performed sequentially, hence no lag problem?
> >
> >     At the moment, assuming an application that opens a file, and writes
> to
> >     it at _any_ speed, occasionally the write will block for a huge
> amount
> >     of time.  [...]
> >
> >     Now this is surprising given that the I/O rate is trivial, and that
> >     there is ample memory for buffering the writes.
> >
> > Indeed. But that's the price paid for non-cached 0.04KB/s random write
> > media.
>
> I'm worried you might not have understood my point.  I don't believe it
> should have anything to do with the speed of the media.  In this first
> test, the rate of the application write is much lower than the random
> write speed of the media.
>
> It is as if the kernel is failing to buffer a write, instead blocking
> it for the duration of some media related event.  I think this is wrong.
>

I did get wrong what you said. Well, then that does go in line with the
problem of Firefox freezing around the same time regardless of using a very
fast SSD like Intel's X25-M(what linus used) vs regular HDDs. Given the
speed of random writes on the intel SSD, they should be much lower. Their
fix was moving ext3 and ext4 to default to data=writeback, which seems to me
that went around the problem by a different approach, without exactly
solving it. Plus, data=writeback is not very safe.

You seem to be on to something with those VM tweaks in the more recent
e-mails.


>
> I won't consider different filesystems or I/O schedulers until I can see
> why the kernel fails to buffer a write.  Because if it is going to do
> this, then no matter what filesystem or scheduler is used, it will
> happen again.
>

True.


>
> Userspace should be permitted to continue execution.
>
> >     [root at xo-a7-2a-5a tmp]# echo 1 > /proc/sys/vm/drop_caches
> >     [root at xo-a7-2a-5a tmp]# echo 2 > /proc/sys/vm/drop_caches
> >     [root at xo-a7-2a-5a tmp]# echo 3 > /proc/sys/vm/drop_caches
> >     [root at xo-a7-2a-5a tmp]# free
> >     [root at xo-a7-2a-5a tmp]# time strace -o /tmp/k -e write -T dd
> if=/dev/zero of=/root/file bs=8192 count=32000
> >     [root at xo-a7-2a-5a tmp]# free
> >     [root at xo-a7-2a-5a tmp]# grep write k|cut -f2 -d'<'|cut -f1
> -d'>'|sort -rn|more
> >     11.648413
> >     8.020875
> >     4.299857
> >
> >     I've no explanation for this behaviour.
> >
> > hmmm? But this is to the tmpfs???
>
> Not so.  This is to SD card.  /root is on SD card.  Please reconsider
> your reply in that light.
>

I tested your script and I'm having an order of magnitude lower on my
desktop (0.04) for the maximum delay but it still varies a lot. I'll have to
look into it in more depth and test it on the XO when I find the time.

Best regards,
Tiago


>
> --
> James Cameron
> http://quozl.linux.org.au/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20100512/c2cf4063/attachment.html>