[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: George Nychis
Subject: Re: [Discuss-gnuradio] in-band lib, the original intention of 'tag'
Date: Thu, 01 May 2008 13:40:22 -0400
User-agent: Thunderbird (X11/20080227)

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

reply via email to

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