[kwlug disc.] any folks using tricks for better linux performance?

[Andrew Kohlsmith]

On Sunday 26 August 2007 2:20:23 am Robert P. J. Day wrote:
> i've known about XIP for a while but, with the cheapness of RAM these
> days, i'm not convinced that it's all that useful anymore.  perhaps
> once upon a time, but not now.  and, certainly, only in the context of
> embedded systems, if even that.

You'd be surprised; if you can slim your RAM requirements in half, (32M to 
16M) there's about a USD$9 per unit cost reduction, in quantities of 1000.  
When your BOM cost is $125, that's not insignificant.

Similarly, if you can optimize your code paths such that it works on a slower 
part, the MCF5282 goes for ~$23 for 80MHz, and $18 for 64MHz.  If you can 
eliminate the need for on-chip Flash (i.e. boot externally), that drops to 
$12.

The benefits of optimization are real enough, but 
again, -O3, -funroll-loops, -fomit-frame-pointer and so on (not necessarily 
all at the same time) don't give you real optimization.

If you're looking for another real example, I recently completed a contract 
for a Blackfin BF537 DSP driver which took 288 channels of TDM (phone) data 
and transferred it to an Asterisk PC.  Asterisk already has this capability 
with the Zaptel driver, but the ztd-eth driver absolutely CHOKED at anything 
above about 40 channels on Blackfin.  A load average of 10 on the DSP left 
the thing completely unresponsive, and audio quality was obviously seriously 
affected.  For a DSP which could execute either 400 or 700MIPS (I can't 
remember which it is now), something was clearly not right.  Was it GCC which 
couldn't optimize for the DSP?  Was it too much memory copying?  We didn't 
know, but my spidey sense was tingling; this damn chip should be able to do 
it with absolutely no problem.  Hell, that DSP should be able to not only 
transfer the data, but fully echo-cancel all channels as well.

After analyzing what was really needed and determining that zaptel was trying 
to do far too much with the data, I was able to write a custom 
zaptel-compatible driver which not only had no problem at all with 288 
channels, but we are now working on taking that from 288 to 1152 channels on 
the same hardware.  Ethernet bandwidth is now the issue, and we're looking at 
fitting the design with GigE to give us enough bandwidth (about 74Mbps 
sustained in each direction, not including ethernet frame overhead)

-A.