[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] multiprocessor flow graphs

From: Dev Ramudit
Subject: [Discuss-gnuradio] multiprocessor flow graphs
Date: Thu, 15 May 2008 15:45:02 -0400
User-agent: Mozilla-Thunderbird (X11/20070828)

Hi all,

I'm trying to modify the benchmark_ofdm_rx.py example to handle a decimation of 8 for a project I am working on. Going straight for the usrp->file works fine, so if I can handle the processing requirement I should be able to demod ofdm packets in real time. The PC I'm working with has 4 processors, but as far as I know, the gnuradio flow graphs should only be using one per program. Therefore, I took the blocks from the various files used in benchmark_ofdm_rx and put them into a single long flow graph. I then split the flow graph and am trying to do the following:

if os.fork() == 0: # child process
        {first half of benchmark_ofdm_rx.py flow graph}
        topblock.connect(middleblock, shared_memory_sink)
else:   # parent process
        topblock.connect(shared_memory_source, nextblock)
        {second half of benchmark_ofdm_rx.py flow graph}

Originally I tried this with the shared_memory_source/sink being the udp_source/sink blocks provided with gnuradio. The modified flow graph worked perfectly at high decimations, and seemed to be utilizing two processors. However, as I got closer to 8 I would "lose" packets across the udp source/sink. This happened no matter what I set the MTU to. I tried using fifos/pipes instead, but there is apparently a 64K memory limit in the linux kernel. My current idea is to use the circular buffer classes that Gnuradio has modified to use non-private shared memory source/sinks. From what I've understood from Gnuradio these circular buffers are what link up the blocks in a graph, so it should be fine for handling the interprocess throughput I need. Is the best way to accomplish what I'm trying to do?


reply via email to

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