PDP 11/23 PLUS system for sale

[Allison]

>
>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
>
>>>>>> "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.
>

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