In message: <200903041001.37376.hsela...@c2i.net>
Hans Petter Selasky <hsela...@c2i.net> writes:
: On Wednesday 04 March 2009, M. Warner Losh wrote:
: > In message: <200903040922.48163.hsela...@c2i.net>
: >
: > Hans Petter Selasky <hsela...@c2i.net> writes:
: > : Hi Steve,
: > :
: > : On Tuesday 03 March 2009, Steve Calfee wrote:
: > : > > 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?
: > :
: > : If the transaction completes before 125us we take the interrupt before
: > : 125us. The problem is that the interrupt delay becomes critical to
: > : performance when the interrupt rate is close to the interrupt limitation.
: > :
: > : For example:
: > :
: > : Transferring 13Mbyte/sec at blocksize equal to 65536 bytes generates 600
: > : interrupts. Hence the Mass Storage state machine has three steps the
: > : throughput is computed like (600/3)*65536 bytes. If we on the average
: > : have to wait 0.5ms for an interrupt we loose throughput.
: >
: > Shouldn't you be using filters and such to make this less relevant? A
: > filter runs on the order of 5us after the interrupt on fast machines,
: > and 20us on slower (400MHz) ones. You can feed the pipeline better,
: > and handle higher interrupt rates...
: >
:
: Yes, that's one possibility. It looks like there is some timing slightly out
: of sync. I have an AMD box with the same symptoms. I will try to figure out
: what is causing it.
Maybe there's just good, old-fashioned lock contention going on? 7.x
has more Giant use than 8.0 will, and in the past this has been a
source of problems. Something else to check into. Maybe enabling
lock profiling might yield some good data?
Warner
_______________________________________________
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
