[ECOS] Problem compiling newnet with timing stats

[Gary Thomas]

On Mon, 2002-06-17 at 10:05, Andrew Lunn wrote:
> > I was hoping that the timing stats would shed some light on where
> > the performance bottleneck is.  Running timing stats on the OpenBSD
> > stack, I got the following results from sending 1024 UDP packets:
> 
> The stats themselves can add quite a bit of overhead for some of the
> operations. When comparing OpenBSD and FreeBSD did you have them
> turned off for OpenBSD?
> 
> > I'm not sure what the units are but the UDP and IP checksums occupy a large
> > percentage of the processing time.  I disabled the UDP checksum and was able
> > to increase the throughput to 6.0 Mbps which is still not as high as I need.
> 
> Be careful here. Things do get corrupt and passed the ethernet
> checksum. Sun Microsystems had problems with there NFS servers getting
> corrupt when they disabled UDP checksums. A better idea may be to
> rewrite the code in assembly. Also look back in the mail
> archive. There were a couple of posts about this a long time ago.
> 

The FreeBSD stack has a much better structure for improvement in just 
this area.  There are hooks for breaking the checksum calculations down 
and providing optimized code based on the architecture (currently only 
"C" code is used).

> What's your platform again? I made some saving for ARM and i82559. See
> bugzilla.redhat.com. Its not responding at the moment so i cannot give
> you an exact reference. Search for my name and it should be obvious. I
> optimized the memcpy from PCI space to normal space. The PCI space is
> none cachable, none bufferable. Doing none word aligned reads or
> writes to PCI space is very expensive compared to normal ram. So i
> wrote a special memcpy function which does some bit twiddling so that
> the PCI read/write is always word aligned. This gave between 2 and 3
> times speedup for the memcpy in the driver. The code is not
> generic. It assume little endian. Hence its not been merged into the
> eCos repository. 

Alas these changes won't help Paul much as he's working on a PowerPC 
based platform and the ethernet controller is part of the chip.

Another thing to consider is the other half of the connection.  How fast
is it?  Do you know anything about it's performance?  You can have a
blazingly fast network adapter on one end but the overall performance
ends up being miserable if it's connected to a slower device.

There may be other available tuning's, for example the number of device
send and receive buffers, etc.  

There are a whole lot of variables here, and only by examining them all 
and possibly making some adjustments can the performance be changed by 
much.




-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss