From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51187) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VfxAG-0003pV-5O for qemu-devel@nongnu.org; Mon, 11 Nov 2013 14:28:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VfxA8-0007iZ-CG for qemu-devel@nongnu.org; Mon, 11 Nov 2013 14:28:48 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52851) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VfxA8-0007iN-4B for qemu-devel@nongnu.org; Mon, 11 Nov 2013 14:28:40 -0500 Message-ID: <52812FE4.8070700@redhat.com> Date: Mon, 11 Nov 2013 20:28:36 +0100 From: Hans de Goede MIME-Version: 1.0 References: <1379583298-7524-1-git-send-email-kraxel@redhat.com> <1379583298-7524-2-git-send-email-kraxel@redhat.com> <524C1C42.8050502@siemens.com> <1381130180.13574.13.camel@nilsson.home.kraxel.org> <52553638.7000801@siemens.com> <1381318925.12583.82.camel@nilsson.home.kraxel.org> <527CEE60.5020109@siemens.com> <1383925171.4350.3.camel@nilsson.home.kraxel.org> <527D1685.8020503@siemens.com> <1384159623.32143.12.camel@nilsson.home.kraxel.org> In-Reply-To: <1384159623.32143.12.camel@nilsson.home.kraxel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/7] usb: remove old usb-host code List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann , Jan Kiszka Cc: qemu-devel@nongnu.org Hi, On 11/11/2013 09:47 AM, Gerd Hoffmann wrote: > On Fr, 2013-11-08 at 17:51 +0100, Jan Kiszka wrote: >> On 2013-11-08 16:39, Gerd Hoffmann wrote: >>> Hi, >>> >>>> OK, then here is the first issue I ran into while trying libusbx (git >>>> head, i.e. 1.0.17+: The new stack causes significant latency issues that >>>> makes it almost unusable for pass-through of USB audio devices (some >>>> headset in my case). Reverting usb-linux and disabling libusb over QEMU >>>> git head makes things work again. I'll have to stick with this for now >>>> as it is affecting my work environment. >>>> >>>> Any spontaneous ideas how to analyse or even resolve this? >>> >>> Try setting isobsize property to something smaller than 32 (which is the >>> default). >> >> OK, isobsize=2 and isobufs=32 helped, possibly other combinations as >> well - but not just reducing isobsize or increasing isobufs. Any theory >> about this? How can we find better defaults? > > isobsize is the size of a single buffer (in MaxPacketSize units). > isobufs is the number of buffers in the ring. > > So the total ring buffer size is MaxPacketSize * isobsize * isobufs. > > isobsize basically trades overhead for latency. Larger numbers reduce > the overhead, smaller numbers reduce latency. > > isobufs should be as small as possible. Start with 4 (default). If you > get overruns/underruns increase. > > We should probably look at the endpoint interval, then calculate how > many packets we should expect within a certain time range and use that > as additional factor for the buffer size. That should get the defaults > closer to the actual needs of the device. hw/usb/redirect.c actually has some code for that, you could use that as a start for the host redirection code... Regards, Hans