On Thu, May 01, 2008 at 01:04:26PM -0400, George Nychis wrote: > What was the original intention of the 'tag' field in the in-band USB > packet header?
I think I was thinking of something like an invocation handle. > As I play more and more the in-band stuff and MAC designs, I'm beginning to > realize we are missing one major thing: notification of packet > transmission. Packet transmission, or failure to transmit? > I think this is a missing piece. It would be extremely useful to the host > if it could determine that its packet was not transmitted. For example, > the packet was sent with an expired timestamp and was thrown away. The > host has no way of knowing the packet was not transmitted. If you're going to ack all of them, you're going to burn up ~1/2 the USB bandwidth. > I'm not sure if this was the original intention of the tag, but it would be > extremely useful. My guess is that the tag was meant to be sort of like > the invocation handle. I think this would be sufficient enough for > determining success. > > Our queue is big enough for 4 packets (off the top of my head), therefore > the tag would only need a history of size 4. The tag is 4 bits, the bottom > 3 bits could be used as a relative packet number, and the top bit notifies > success or failure. > This is an extremely important feature for our MAC enhancements, where we > implement time-critical functionality like carrier sense on the board. > Aside from timestamps expiring, if our carrier sense decides to throw away > a packet, it is important for the host to know. Therefore, we need some > feedback mechanism. I'm going to implement some feedback mechanism period, > I'm just trying to coordinate with the larger framework so it's useful for > more than just myself :) How about just reporting problems? Would a single bit do it, or do you need to know which packet/frame had the problem? IIRC there are three unused bits in the header. Perhaps you want to expand tag to 5 bits then use one of the others for an error indicator. I think you're going to want to piggy back these on any Rx data if you can, else send them by themselves. Let us know what you come up with. Eric _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
