On Tuesday 28 April 2009, Sarah Sharp wrote: > > > > This patch is not completely correct. I see negative time deltas on the first > > > of several 4096 byte transfers. That means the code is probably not setting a > > > start time in some path from ehci_urb_enqueue(). > > > > And a bug. ;) > > Yes, I was hoping you could help me find the bug, since I don't > understand the EHCI urb enqueue path as well as you. If you did it in usbcore, you'd be guaranteed to catch the only paths that matter ... and eliminate even the possibility of HCD-specific bugs. One path going in, one path going out. (If you still get negative numbers, that would tell you the problem is something else.) > > I'm a bit curious why you wouldn't add all this statistics code > > to usbcore, instead of modifying each HCD. You've already got > > single access points for submit and giveback paths; and doing it > > in usbcore would provide much more consistent measurements. > > I wanted a way to measure the hardware performance, minus any software > overhead for giving back the URBs, drivers resubmitting, etc. For measurement points were inside usbcore, there'd be no resubmit path overhead, and the URBs wouldn't have been given back yet. Depending on how you structure things, there'd be at most a few dozen more instructions counted; the cost of going from usbcore into HCD (submit), or from HCD into usbcore (giveback). > I wanted > the finished timestamp for the URB to be as close as possible to the > time of the hardware interrupt, so there had to be unique code for each > HCD. I also wanted to make it generic enough that you could measure the > overhead of different parts of the USB software stack. Hmm, I'd have considered HCD entry/exit overhead to be worth including in the measurement. If it's going to be generic, that would be the most useful place to have it ... you could more usefully compare drivers that way, and the numbers will be closer to throughput as observable by drivers. What you're describing seems a bit more like dtrace to me than a throughput measurement tool. Or maybe what you'd get by plugging in a logic analyser and having capture data and (harder nowadays) instruction bus traffic. ;) > Thanks for your comments about the ifdef'ness. I'll respin this. > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
