sns@deimos.caltech.edu (Sam Southard Jr.) (06/05/91)
I am developing an application which needs to acheive the maximum possible
throughput via the ethernet. For this reason, I chose to use the UDP protocol
with a large packet size (currently 32000 bytes - I used setsockopt to increase
the maximum packet size from the default of 9000). I realize that I need to
implement my own protocol to make sure I get all the data across. I'm not
being unfriendly to other systems, since this will be the only application
running on the network. The application first transmits a header (<1KB), then
a large amount of data (~32MB), and then the two ends talk to each other to
make sure that the entire 32MB was received.
The machines in use are currently a SPARCserver 470 and a SPARCstation 1+, both
running SunOS 4.1.1B. The SPARCstation will eventually be replaced with a
SPARCengine 1E running VxWorks.
If I send data from the SPARCstation to the SPARCserver, any packet size over
some amount (I forget exactly what - I don't think it was 1518 bytes) results
in a message:
vmunix: le0: Babble error - packet longer than 1518 bytes
No problem, I said. Since I'm just using the SPARCstation as a development
site, I'll just go the other way. That was fine, except that if I don't put
in a delay, I get all sorts of messages like:
vmunix: mbuf map full,
vmunix: le0: out of mbufs - packet dropped,
and
vmunix: ie0: WARNING: if_snd full
Since the initial test was mainly to get a maximum acheivable throughput, I
decided to add in a little delay.
When I try to increase the packet size from 32000 closer to 32768, the
SPARCstation prints a message:
vmunix: le0: Receive: giant packet from 8:0:20:9:35:59
vmunix: le0: Receive: STP in rmd cleared
Now, how do I take care of these errors? Is there a way I can increase the
amount of memory available for mbufs? Is there a way to increase the size
of the if_snd area? Is there a way for me to change the size of the packet
which the SPARCstation believes is a giant packet?
Note that the goal of this is to acheive a sustained ethernet throughput as
close as possible to the theoretical maximum. Anything (short of purchasing
additional hardware) is permissible. The machines will essentially be
dedicated to this application. If you have suggestions as to a different
approach to this goal, please let me know.
--
Sam Southard, Jr.
{sns@deimos.caltech.edu|{backbone}!cit-vax!deimos!sns}