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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
