Date: Tue, 3 Mar 2009 14:15:43 -0800 From: Steve Calfee <stevecalfee@gmail.com> To: Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: Low perfomance when read from usb flash drive Message-ID: <4a5ff6bc0903031415s16158407m386b8321a5082996@mail.gmail.com> In-Reply-To: <200903032243.31914.hselasky@c2i.net> References: <200903010045.44904.man@email.com.ua> <200903031516.02744.hselasky@c2i.net> <200903032006.54451.man@email.com.ua> <200903032243.31914.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> I think the reduced performance can be explained by a clamp on the interrupt > rate around 1000 interrupts per second instead of 8000. Maybe someone has an > explanation for this? > > The EHCI is being programmed to interrupt at 125us intervals, but there seems > to be limits other places. > > It is possible to workaround this in the umass driver by doing the cmd + read > in one operation. Hi Hans, I am looking at using FreeBSD in an embedded product. I have not examined your ehci software, but I am aware of how Linux and other OSes run the controller. Why are you taking an interrupt every uFrame SOF? What can you possibly do then? You are not in a RTOS, you are not guaranteed to even get that fast an interrupt. The whole point of the magic ehci DMA engine is that many transactions can be programmed and then they can interrupt when they are done. The Periodic list is set up with (hopefully) enough transactions that the OS can keep up, and async doesn't care at all - the only impact is possible xfer speed. Taking really fast periodic (uFrame) interrupts guarantees no faster transfers than just having the end of transfer interrupt. Just wondering. Regards, Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4a5ff6bc0903031415s16158407m386b8321a5082996>