Hello Jim, Thanks for your comments. Please see my response inline.
[...] > A few comments: > > - It could use some more clarification for whether transmission is > blocking or nonblocking, i.e. whether the dongle should wait for > transmission to complete before returning a response. Yes. I guess it could use some clarification. I would tend to favor blocking TX, so that the device can return the status of the TX. This is especially true when use auto-acknowledgments: the sender can know if the receiver actually received the packet or if the transmission failed. Also, without any flow control logic, I believe the network stack would flood the device at a speed that is higher than TX speed (thus leading to very high packet loss). Unless the device warns the host when it's internal buffer is full. > - What happens if there's no response? For example, if the dongle > sends "receive block" but never gets a response from the host, > should it keep sending them anyway? How long should it wait before > deciding no response is coming back? Similarly, what should each > side do if a bad response comes back in either direction? Currently, there is some timeout mechanisms (on both the driver and the device), so as to recover from this situation. I should probably add some default timeout values in the text, either based on the current ones or by computing maybe more "optimal" values depending on the communication speed with the device. I'm not sure what you qualify as a "bad response": - if it's an status indicating "FAILURE", the error_code provides information on the reason of the failure (when possible). This can be reported by the driver to the system. - when the host or the dongle response does not match the request, the requester should detect the mismatch. If the "bad response" occurs after the cmdId, I guess there is two possibilities: the response is shorter than the expected response, a timeout will kick in, and the request will fail. If the response is of equal or longer size than the expected response, I guess it gets misinterpreted by the receiving end. So far, I haven't seen any of these two failure scenarios. > - This protocol seems terrible for throughput due to turnaround > latency. USB, for example, will necessarily introduce a one frame > (1ms) or one microframe (125μs) latency every time you're waiting > on > a direction change. The FT2232 (used in the Econotag) will also > add > a 16ms latency before flushing short transfers to the host, by > default. So any time you transmit a packet, you could end up > waiting an extra 16ms for the response. Instead of trying to tweak > those types of details on a per-device basis, it would be better to > not require a per-packet direction change in the protocol. You > could add fancy pipelining that allows multilpe outstanding > unacknowledged requests, or maybe just add some "transmit > unacknowledged" and "receive unacknowledged" style commands > that don't require waiting on a response. I don't know much about the USB protocol, so I take your word for it. I don't think the "fancy pipelining" is easily possible, and I'm not sure if it would be desirable. Currently, the kernel process only one packet at a time. It would require some internal queuing mechanism within the device. The unacknowledged requests, for both "transmit block" and "receive block" commands seems like a very good idea. Actually, I can't seem to find a scenario where the device would required a "receive block" command to be acknowledged. I'll try to implement it soon in order to check how it behaves, and I'll post the results here. Again, thank you for all your valuable comments. Regards, Tony ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
