[Top][All Lists]

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

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

From: Eric Blossom
Subject: Re: [Discuss-gnuradio] in-band lib, the original intention of 'tag'
Date: Thu, 1 May 2008 10:23:01 -0700
User-agent: Mutt/1.5.17 (2007-11-01)

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.


reply via email to

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