On Fri, 11 Nov 2005, Aras Vaichas wrote: > Hi, > > my test department tells me that they need to perform immunity tests on the > hardware and therefore I will need to collect statistics on the USB data > being > transferred. > > Can this be done? Do the USB drivers export these sorts of statistics to /sys > like ethernet does?
They do not, although some statistics could always be added. > Here is the request from my test department: My impression is that these requirements are not very well thought out. USB is not like Ethernet, and metrics that are appropriate for one are not appropriate for the other. For instance, unlike Ethernet, USB has upper- and lower-level drivers. With Ethernet this division isn't necessary, because all devices attached to an ethernet are network interfaces. With USB, many different kinds of devices can be attached to a bus. So are you interested in the low-level statistics or the high-level statistics? Or both? > --- SNIP --- > > 1. Check that data can be transferred in and out of each port at the rate > specified by the interface spec. There is no fixed data rate in the interface spec. The formulas include fudge factors to allow for system- and implementation-specific delays, and in any case the data rate will depend on the speed of the device you are communicating with. I have never seen an example where data could be transferred at the theoretical maximum rate. It's pretty safe to assume that you won't either. > 2. Monitor the data transfer to check if: > (a) data is transferred with no errors; > (b) data is transferred with errors, but then data is re-sent > successfully; > (c) data is lost. Here you will get different numbers depending on whether you measure the low-level transfers or the upper-level transfers. For example, if an error occurs at the low level and the transfer is retried, at the upper level the transfer will appear to have succeeded. In addition, with some types of transfer (Isochronous) USB provides no way at all to tell whether a transfer succeeded. > Monitoring should include: > ... > (iii) raw and net bit error rates Again, error rates depend on where you measure them. Also, USB does not detect individual bit errors. Data is transferred in packets, and errors anywhere in a packet will cause the entire transfer to fail. > ... > *(vii) operation of the "device reset detect" bit of circuitry on the > device port, and detection of that by the host. What is the "device reset detect" bit? How is the host supposed to tell when a device has been reset? > (g) For immunity testing, we would require the test to run continuously, but > be > able to identify errors within one second of their occurrence. That's a function of your test program, not of the kernel's statistical reporting. > *(h) For production testing, we would want to send a fixed amount of data, > and > check the raw and net error rates. Send the data where? Do you have a fixed testing device in mind? > Can you please add a 'raw and net bit error count' monitoring output. This > will allow monitoring of the errors on a second by second basis I don't understand the difference between "raw" and "net" errors. And like I said, bit error counts are not available, only packet errors. And not all of those. It's not always clear which category an event should fall into. If a data transfer is refused and delayed because the peripheral device isn't ready, should that count as an error, a error that was retried, or a success? Alan Stern ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
