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

[George Nychis]

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.

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.  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.

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.

- George