This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: ethernet performance <TCPIP guru question>
- From: Gary Thomas <gthomas at redhat dot com>
- To: David Webster <dwebster at lanergy dot com>
- Cc: 'Stephen Polkowski' <stephen at centtech dot com>,'eocs' <ecos-discuss at sources dot redhat dot com>
- Date: 26 Apr 2002 06:54:38 -0600
- Subject: RE: [ECOS] ethernet performance <TCPIP guru question>
- References: <001001c1ed15$b5324030$4103a8c0@LANERGY05>
On Fri, 2002-04-26 at 05:30, David Webster wrote:
> Hi,
> I've also started looking at the network performance of our eCos based
> product recently using ttcp to provide performance figures. I get the
> following figures:
> Ttcp Client: 2.1 Mbps (ie eCos mainly tx'ing data)
> Ttcp Server: 4.0 Mbps (ie eCos mainly rx'ing data)
>
Would you be willing to share/contribute these? They would make very
good test/examples to put into the networking code.
> The inconsistency and some of the poor performance can be put down to
> our Ethernet hardware interface - we're using a Realtek 8019 which we
> have to access thru a slow 16bit fifo.
>
> But there are others areas of the network stack that seem to introduce
> inefficiencies, namely the number of memcpy's that occur in the stack.
> I've noticed the following happen when I perform a socket write with an
> 8K buffer:
>
> sosend() - allocates 4 2K mbuf's and calls uiomove() to memcpy()
> the data from the buffer supplied in write to the mbuf.
>
> Each of these 2K mbufs is passed to tcp_output(). Tcp_output()
> creates 2 TCP segments for this data by allocating 2 mbufs and calling
> m_copydata() to memcpy() the data from the original mbuf into the mbuf
> to be used by the TCP segment. This results in two Ethernet frames, one
> with 1448 and the other with 600 bytes of data, for each of the 2K
> mbufs.
>
> So there are two memcpy's within the TCP stack.
> Has anybody looked at providing a socket write function that actually
> provides the data already in an mbuf and bypasses uiomove()?
> Equally providing a function that performed the memcpy in addition to
> calculating the checksum might also provide an efficiency improvement.
>
> There's a similar number of memcpy's on a socket read - but I've not
> really looked at this path - I image that a read that could bypass
> uiomove and pass the mbuf with the received data would also be more
> efficient.
We know about the extra data sloshing :-( Someday, perhaps Providence
will smile on us and provide the time necessary to do something about
it.
>
> I've also noticed that by default the tcp_do_rfc1323 flag (in
> tcp_subr.c) is set. This results in TCP using the Window Scale and
> TimeStamp options. The timestamp option in particular is sent in every
> segment and "wastes" 12 bytes of each Ethernet frame and adds additional
> overhead?. My understanding of rfc1323 is that the timestamp option only
> really helps over Long Fat Pipe connections and I'm not sure it's really
> necessary on 100 Mbps Ethernet - definitely not on 10 mbps. So disabling
> that might help a (tiddly) bit.
>
Have you experimented with this at all?
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss