Re: [PATCH spice-gtk] gst-audio: Do not update mmtime without real audio channel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Tue, Jul 18, 2017 at 06:55:12PM +0200, Christophe de Dinechin wrote:
> Interestingly, I just discovered something I did not really expect: a
> hot CPU is more than enough to make the spice client lack “oxygen”,
> even if nothing else is running.
>
> If I start under light load and keep running that way, it can run a
> long time without a problem. The queue length typically runs up and
> down a little, but it does not diverge. See
> http://blackbox.dinechin.org/images/170718-NotDiverging.png.
>
> There is even plenty of CPU left to converge back if we temporarily
> accumulate things in the queue:
> http://blackbox.dinechin.org/images/170718-Reconverge.png.
>
> However, if the machine gets hot, then it does not reconverge, because
> the machine spends over 50% “in the kernel” just trying to cool down.
> Starting the client under these conditions, it rapidly diverges:
> http://blackbox.dinechin.org/images/170718-WithHotCPU.png.

Isn't it expected as the CPU lost 50% of its processing time in order to
cool down? We can think about different ways to workaround this kind of
issue. Dropping the queue as you did in a different patch is a good
approach for peaks like this, I think.

If those situations happens too often it would be a good signal that
current stream is too much for the client to handle and we could lower
quality/fps, increase I-FRAME, etc. in order to make it less demanding
for the client.

Still, it should be much better if you were doing hw decoding, I guess.

> Also, without enough I-frames to recover, when this starts happening,
> we are a bit stuck.  This is all documented in more details here:
> http://blackbox.dinechin.org/170718.html.

Cool charts

> Tons of messages that look like:
>
> channel-display-gst.c:266: [783802 1768.364819] spice_warning: got an
> unexpected decoded buffer!

First time seeing it, cool!

> So I think we will need the mechanism we discussed with Uri, where we
> send something back to tell the server we need an I-frame. Or we
> close/reopen the channel.

Definitely! We should start discussing about it... I think it will
require a new/improved protocol.

Cheers,

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]