Hi, On Fri, Oct 09, 2015 at 02:59:05PM +0200, Victor Toso wrote: > When channel wants to send much more data then the wire can handle, the > queue grows fast. This patch does not limit the queue growth but > introduces an internal API to check if queue size is too big. > > In the case of usbredir, video devices on high latency can easily > trigger this situation. > > An easy way to test locally is sharing and webcam and simulating high > latency with tc: > tc qdisc add dev lo root netem delay 100ms > tc qdisc change dev lo root netem delay 1000ms > tc qdisc del dev lo root netem > > Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1264156 I forgot to mention the difference. v1 was using the amount of messages to say the queue is full. 500 by default. v2 is using the amount of memory in the queue to say it is full. 10 MB by default. To play around on windows client, in v2 I've also included env var to set this limit. Overall, I think this is working well in my local tests.. but maybe the memory/message limit could be channel-specific? Thanks for any input. toso _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel