[NCLUG] Software Defined Radio Application

[John L. Bass]

Joseph DiVerdi <diverdi at xtrsystems.com> writes:

> I am planning to use interrupt driven IO for this application
> because of the need to measure the phase of the incoming RF
> signals which implies a phase reference. As such I recognize
> the task I'm taking on - to craft a suitable driver (probably
> with a FIFO to address the non-real-time OS).

Interrupt and scheduling latency will probably add significant timing
jitter to your data ... maybe to the point of seriously impacting the
reliability of your data. Especially if using non-dma disks in your
system, which can burn significant numbers of cycles with interrupts
disabled.

Take a careful look to make sure you can actually generate interrupts
in the input direction. Most older printer drivers have interrupt
data output ability, but poll for status ... haven't looked to see
what capabilities a bi-directional printer port has - I suspect it's
highly variable between chipsets and system designs.

> Please advise why you suggest that single sample return vs block data
> would represent a greater load on the CPU? Is this because of context
> switching and interrupt servicing overhead?

Without linux this would probably be a piece of cake, it might even
be a good Windoze application - but I shudder at that thought.

You said the machine was a Pentium 1, which implies a 50/66mhz system
bus, and probably less than 256KB L2 cache size and memory timings that
will make the working set of a stock linux kernel a difficult bottleneck
at 250Ksps.

The critical path will include the application, system call to driver
interface, two or three trips thru the scheduler/context switch and the
top and bottom halves of the driver including the system interrupt to
kernel context code - plus the clock interrupt path and system metrics
in the clock driver. All this assumes the machine is running a staticly
linked application with minimal library support as single user - the
network is disabled, and no other processes exist. You are probably
using some form of lite threads to decouple the I/O from the processing.

Normally this path bottlenecks on memory for machines of this class
somewhere well before the mid-high tens of thousands of interrupts per
second.  More than that will probably require some careful working set
management to maintain good L1/L2 cache locality.

Dynamically linked libraries create very non-uniform address space usage
which cause significant L1/L2 cache faulting for both text and data.

John