[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] in-band lib, the original intention of 'tag'

From: George Nychis
Subject: [Discuss-gnuradio] in-band lib, the original intention of 'tag'
Date: Thu, 01 May 2008 13:04:26 -0400
User-agent: Thunderbird (X11/20080227)

What was the original intention of the 'tag' field in the in-band USB packet header?

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.

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.

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 :)

- George

reply via email to

[Prev in Thread] Current Thread [Next in Thread]