NED@YMIR.BITNET (Ned Freed) (08/05/88)
The DEQNA is known to have trouble operating on heavily loaded ethernets.
VMS 4.7 and 5.0 have special code in them to perform additional checksumming
on incoming packets. Under VMS 4.7 this is enabled by default on LAVC
configurations. The SYSGEN parameter that controls it is PE5. See page
3-21 of the 4.7 release notes for information about this. Under VMS 5.0
the same stuff is there but there's no indication of the SYSGEN parameter
that contols it. See page 8-20 of the VMS 5.0 release notes for information
about this one.
I have spent some time trying to figure out just what the PE5 parameter
actually does under 4.7. There don't seem to be any references to it
in SYS.EXE or in XQDRIVER.EXE (at least none that I can find). There's
a routine to calculate a checksum, but I have not been able to track
down any use of it.
I have a theory as to what goes wrong and why. Its only a theory; I have no
proof of it and I have not been able to think of a way to test it. There's
a structure in a DEQNA called a receive ring buffer. Its a list of linked
buffer that the DEQNA fills up with packets that come in. There's a bit
in the header of each buffer that indicates whether or not its valid. When
this bit is set (valid) the DEQNA will use the buffer, when its clear the
DEQNA won't use it. The DEQNA stops receive processing when it first
encounters an invalid buffer. But here's the catch; the DEQNA does not
clear the bit itself! It does write a length value into the buffer, but that's
the only indication that the buffer has been used. The DEQNA does not look
at the length field itself. Of course, the DEQNA signals an interrupt when
a packet arrives so the VAX can deal with the packet.
So here is my theory. Suppose the VAX is a wee bit slow at servicing its
interrupts and the DEQNA manages to make it all the way around the ring.
There's nothing to stop it from clobbering a buffer that contains valid
data that the VAX has not processed yet. Worse, it could be in the process
of filling a buffer when the VAX tries to read the previous packet out of
it. And that would lead to corrupted data.
There's a note in the DELQA documentation that implies that it actually checks
those length fields as well as the valid bit, but it does not actually come
out and say this in so many words. (Sorry, I don't have the DELQA documentation
at the ready to cite a page number for this.)
Now, all this is very nice, but its only a theory. I would be EXTREMELY
interested in anything that anyone could contribute to an understanding of
this problem.
So, in response to the original posting, I don't think that the dropping of
support for the DEQNA is an attempt by DEC to get people to buy new hardware,
unless you seriously think that they engineered the DEQNA badly in the first
place as part of a deliberate plan. Me, I'm not that paranoid.
Ned