15 Jun
2005
15 Jun
'05
4:36 p.m.
Subject: RE: PDP 11/23 PLUS system for sale
From: Paul Koning <pkoning at equallogic.com>
Date: Wed, 15 Jun 2005 16:02:43 -0400
To: cctalk at classiccmp.org
That's about the story. One little bit was that doing a checksum
was really a CRC and the code to do that apparently was slow on uVAX.
They didn't want the impact of that in the OS driver when hardware
could do it far faster.
Allison
>>>> "Allison" == Allison
<ajp166 at bellatlantic.net> writes:
>> From what I remember (very blurry now)
DEQNAs were known to
>> corrupt
> data. That was very obvious on VAXclusters, which is why VMS
> eventually took them off the supported device list permanently.
> But it's an issue for any application (except, *maybe*, when
> running TCP since the TCP layer checksum may help -- or may not,
> it's not that strong...). That applies just as much for PDP11s.
>
> paul
Allison> No they _could_ corrupt data, not they did all the time.
Allison> The differnce was the error rate was not what DEC wanted for
Allison> transactions. The VAX people put pressure to not have to
Allison> test the data as LAVCs (Local Area VAX Clusters) were
Allison> popular to a point and required a very high level of data
Allison> (code!) integrety. The frequency of the failure was related
Allison> to the traffic level on the local loop.
"pressure not to have to test the data" -- hm. That's an interesting
way of looking at. The way I would look at it is that ALL DEC network
protocols put the responsibility for data integrity in the network
devices; NONE of them had upper layer checksums the way TCP does.
That's why DEC Ethernet bridges always had end to end CRC. And that's
why DEC insisted on 32 bit CRC for Ethernet -- 16 bit CRC isn't good
enough at those data rates. The expectation (and probably the
expressly stated requirement, though I don't remember for sure) is
that Ethernet NIC devices were required to deliver that level of data
integrity to the host.
So in fact the QNA was failing to deliver the data integrity that
everyone expect it to deliver. The VAXcluster people were the most
vocal and had the most pull, so they were the ones who actually had
the power to say "we will not accept that device". But plenty of
other people cheered when that happened. Certainly the network
architecture group, responsible for standards, did.