Re: [9fans] usb slowness

[Tristan <9p-st@imu.li>]

> if you could temporarly run a 9atom kernel,

cpu% dd -if /dev/sdU0.0/data -of /dev/null -count 1024 -bs 65536

/dev/irqalloc yields
trap	irq	delta count	delta cycles	type	name
35	3	27648           510854000	i8259	usbehci

which doesn't seem extraordinary. and nothing else is huge either.

mpirq doesn't appear to exist in #P

the whole transfer takes about 8% longer on 9atom.

> > if i force polling, it's a little faster: 0.01u 0.45s 17.70r
> That's interesting - it shouldn't make a difference unless there's
> something wrong with the controller or the driver.  What did you do to
> force polling?

added 'ctrl->poll.must = 1' to init in usbehci.c

> Yes, I think you're right - system cputime will only be incremented for
> a running process.  But you can watch the last column of /dev/sysstat
> (or use 'stats -I') to see the percentage of time spent in interrupt
> handlers.

interrupt time is quite low/very low... (olpc / intel)

> How about number of interrupts?  Erik's theory was that you were
> getting too many of these.

interrupt count is very low/moderate... (olpc / intel)

my working theory is that i'm getting all the interrupts, but not soon
enough... the fascinating piece is that the olpc and the pc with intel
ehc take just about the same amount of time.

and a different usb flash device doesn't change it (which was expected as
usb/ether seems to suffer also).

enjoy,
tristan

-- 
All original matter is hereby placed immediately under the public domain.