🚀 go-pugleaf

In article <776@duvan.UUCP>, ahi@duvan.UUCP (Anders Hillbo) writes:
> We want to connect a VAX 750, running UNIX BSD 4.2, with an Interlan
> controller and a custom made display station (Intel iSBC 186/51 & 82586
> based) to transfer image data. We decided to use Ethernet and an UDP/IP 
> implementation on the displaystation to be able to run in user mode on the
> Vax.
> 
> The problem is SPEED (on the 750).
> 
> The display station is just now capable of sending data in up to 300 kbyte/s.
> the VAX computer only send data in 33 kbyte/s
> 
> Also when sending TO the Vax the interface or something seems to drop packets
> if 4 of them arrive immediatly after each other. (I thought Interlan
> could handle back-to-back packets).
> 
> The goal is a transfer rate at about 100 kbyte/s.

I expect that the main problem is the VAX's i/o system; it can't handle the 
interrupt load quickly enough. The Interlan card can handle back-to-back
packets, but on a limited basis; it has some internal buffer space,
but it's not infinite.

I'd go for bigger packets. There's no reason not to use full ethernet
packets (1500 bytes), but you'll probably have to hack the VAX's kernel. I'm
afraid I've only done this for the TCP layer, so I can't give you exact
directions.

We never used trailers here, because we have some binary-only equipt
that doesn't understand them. I believe that the VAX only does
trailers on those sizes because that's when it uses "tear-away"
pages for buffers; tuning your packet sizes to use trailers and pages
will also help a lot (the mbuf mechanism has a lot of overhead.

Good luck,
chris

The main reason rawIP packets are SO MUCH FASTER than UDP/IP is
that the UDP layer does a big checksum on the entire data section.
This can easily be turned off (even if you have binary only) by
changing the value of a variable in the kernel called:

     "udpcksum"  (1 for checksum, 0 for no checksum)

This should increase the speed of UDP/IP to that of rawIP.  Note
that as long as you are running on ethernet the UDP checksum isn't
really needed.  Ethernet does a full packet checksum for you.

I would suggest using bigger packets to get higher speeds in
general.  You should be able to send UDP/IP packets in the 2k-8k
range (depends on the socket space limit set in udp_usrreq.c on
you VAX UNIx).  Your micro graphics station must also support IP
fragmentation to handle this.  If you can change your kernel
you can increase the UDP socket space limit even higher if you
want.  Take care when doing this.  The maximum possible with
IP fragmentation is 64k at a shot.

Tim Tucker
Gould Electronics
tucker@gswd-vms.ARPA
..ucbvax!ihnp4!uiucdcs!ccvaxa!tucker

> The main reason rawIP packets are SO MUCH FASTER than UDP/IP is
> that the UDP layer does a big checksum on the entire data section.
> This can easily be turned off (even if you have binary only) by
> changing the value of a variable in the kernel called:
> 
>      "udpcksum"  (1 for checksum, 0 for no checksum)

	WARNING!   WARNING!   DANGER, WILL ROBINSON!!!!

Quoting from RFC-817, "Modularity and Efficiency in Protocol Implementation"
by David D. Clark:

"There is one area which is generally accepted as causing noticeable and
substantial overhead as part of TCP processing. This is computation of the
checksum. It would be nice if this cost could be avoided somehow, but the
idea of an end-to-end checksum is absolutely central to the functioning of
TCP.  No host implementor should think of omitting the validation of a
checksum on incoming data."

I believe this is just as valid for UDP. The Berkeley routed is a major UDP
user. It already suffers greatly from an endearing naivete regarding
incoming datagrams, and only the end-to-end checksums protect against all
hell breaking loose should an Ethernet controller, bridge, or gateway decide
to corrupt a routing (or any other) packet.  This DOES happen.  I have seen
the buffer memories go bad in an Ethernet controller. This delightful piece
of hardware would gladly corrupt received packets without notice, or garble
outgoing packets (being careful, of course, to put a perfectly valid 32-bit
CRC on the corrupted packet before sending it).

Most recently, some garbage machine names started showing up in our ruptime
listings. The problem turned out to be a flakey Ethernet bridge, and further
investigation showed that all of our SUNs had set udpcksum to zero by
default.  I immediately patched this on as many Suns as I could find,
especially those acting as IP gateways.

The "udpcksum" (and "tcpcksum") "options" in 4.2BSD are, in my opinion,
brain-damaged hacks that should be removed as soon as possible, along with
the blind acceptance of any UDP datagram or TCP segment having a zero
checksum field.

Phil Karn