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

[Eric Blossom]

On Thu, May 01, 2008 at 01:40:22PM -0400, George Nychis wrote:
>
> Eric Blossom wrote
>
>> If you're going to ack all of them, you're going to burn up ~1/2 the
>> USB bandwidth.
>
> Definitely being piggy backed on RX frames.
>
>>
>> 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.
>>
>
> If you just report failure it makes the FSM of MAC's more difficult, you 
> need to wait for some amount of time before you decide that a failure 
> occurred.  If I had to pick 1, I'd say report on transmit, but I think we 
> can get away with reporting both.

OK.

> It would be extremely useful for all of this to be masked from the app in 
> usrp_server.cc, when it gets a start-of-burst, it marks the tag with a 3 
> bit value using a local wrap-around value.  It then holds all transmit 
> responses until it sees an RX packet carrying this tag in the bottom 3 
> bits, and then it checks the top bit for 0 or 1 to determine success.

You want to make sure that in adding your feature, you don't break
other usage models.  E.g., an app that is Tx only at 8 MS/s.

I don't think you should overload the tag field with the error bit.
Pick another unused bit for the error indicator.

> It then can respond with the transmission status.  All that happens now is 
> that as soon as its written to the bus, the "tx success" gets passed up.  
> In fact, i think its impossible to get a "tx failure" since you block when 
> the USB bus is full.

We'll probably have to sort that out sooner or later.  It would be
nice to be able to use something like "select" on the usrp interface.

> I should be able to get away with the 4 tag bits, unless the queue size is 
> bigger than 7 packets, which i don't think it is.
>
> Let me know if you have any suggestions, I need to implement this by next 
> week, likely over the weekend.

OK.  Please do it on a branch :-)

Eric