Re: [Discuss-gnuradio] Packet mod/demod race condition?

[Thomas Tsou]

Hi Steven,

> If I uncomment the sleep, I never see this message. So:
> Q1) Any idea what this error is all about? Is this a race condition that
> needs to be addressed, or am I doing something wrong?

This part I'm not sure about.

> Q2) The original audio file is 350.0KB. Sometimes the resulting audio file
> is complete, other times it never gets the last few KB (ends up 341.0KB, for
> example). How do I ensure that all the bytes make it across successfully?

The benchmark loopback code makes no guarantee of delivery. In order
to do so, you need some method or higher level protocol to detect and
retransmit any dropped frames. Though in your case, I wouldn't expect
the received file to vary per run. Again, I'm not sure here.

> Q3) What is the effect of packet size? Is there an optimum size? A max size?
> For USRP, packets need to be padded to a multiple of XXX?

The optimal size depends on the given application. Latency and
overhead might be two considerations. The max packet size is limited
by the length of the whitener PN sequence. I don't believe there are
any restrictions beyond that. The USRP will view the data in a stream
form; it won't have any notion of the data packet length at that
point.

> Q4) Some examples use gr.enable_realtime_scheduling(). What is the effect of
> this, and do I need it? I note that it requires a sudo.

Realtime scheduling changes the scheduling policy of selected threads
to a priority over normal threads. In Linux, root access is required
in order to do so. It should result in more lower latencies and more
deterministic behavior.

> Thanks for your time!
> -Steven

Anytime.

-TT