Slow I/O with GNU Radio compared to C implementation

Question

I made a device driver on Linaro running off a zedboard to control the switches and LEDs from Linux.

They are mounted as /proc/zedLeds and /proc/zedSwitches

When iteratively reading and writing to the respective drivers from a C-generated program there is next to no delay. When a switch is flipped the associated LED is illuminated immediately.

I built GNU Radio modules (switch source and led sink) to do the same thing from GNU Radio. They are connected by a 32k sample throttle. When running this design the longer it runs the longer the delay becomes from switching --> illumination.

My method is essentially the same as using the C method so I'm not sure where the extreme delay is coming from. I've tried it both with and without the throttle.

Could it be that using GNU is just taking up too many resources lagging the operations?

Here is the github with all project files.

https://github.com/minersrevolt/zedboard_gnuradio

Structure:

├── gr-zedboard                   # gnu radio blocks 
    ├── lib                       # GRC Block source code
        ├──led_sink_impl.cc       # source code for LED Sink block
        ├──switces_source_impl.cc # source code for Switch Source block            
├── switch_led_drivers            # dev drivers for switch and leds
    ├── BOOT                      # files for BOOT partition of SD Card
    ├── led_driver                # contains LED device driver
    ├── switch_driver             # contains Switch device driver
    ├── testLED_SWITCH_DRIVERS.c  # C code showing functionality of dev drivers
├── switch_led_test               # example GNU Radio Companion build

I think the problem is most likely how often i have to open and close the respective drivers... I don't know a way around this from the context of GNU Radio blocks though. — gutelfuldead, May 06 '16 at 22:51
You should not add this as a comment, but improve your code instead. — Marcus Müller, May 07 '16 at 20:02

Marcus Müller · Answer 1 · 2016-05-07T20:05:26.757

As usual, open the file once, save the file handle as private member of your block impl, and use that. We discussed this in every Question you asked. I don't really understand why you're still doing this. I do think this is going to be the last GR-related question I answer that includes you following this pattern. It's simply bad design, and we've explained this multiple times. You're an embedded developer, so act like one.

Could it be that using GNU is just taking up too many resources lagging the operations?

No. You're probably not realize what having a throttle block does – it makes sure that the average rate of samples going through is about the set rate. However, GNU Radio processes samples in "chunks", i.e. a source will always fill as much buffer as it can. Now, the throttle block is handed let's say 10,000 samples at once; it therefore calculates that it has to wait 1/3.2 s until it copies these from in- to output. While the throttle blocks its operation, the source is again and again asked to produce samples, as fast as possible. These samples accumulate, until the output buffer of your switch source is full, which means that throttle is immediately after processing your first chunk of samples, is greeted with a lot of samples, hence waits for a long time, and so on.

In the meantime, you're sink block's work method is called; in your case, it consumes 1 of these 10,000 items, and is then immediately called again with 9,999 and so on.

You can reduce the "chunk size" by setting a maximum number of output samples on the throttle block. However, that won't work down to a granularity of 1 – that's simply not what GNU Radio was designed for.

If you need rate limiting, you should implement that in your source, or sink, or both, either in userland, or in a driver. Throttle is really just a tool for flow graphs that are pure simulations, with no hardware in- or output limiting the rates.

Marcus, I took your scolding to heart and spent a few days going through a crash course on C++ and getting familiar with classes. Everything I was doing before was an attempt to sort of shove how I would achieve this in C in C++ -- not effective. I created class constructor and deconstructor functions to keep the driver open throughout the duration of the flow. It's currently reading/writing the first value then every subsequent values gets an all zero output. Anyway just wanted to say thanks for the previous help and the tough-love push; it helped. Still working on it. — gutelfuldead, May 14 '16 at 16:39

Slow I/O with GNU Radio compared to C implementation

1 Answers1