[Info-vax] booting vaxstation off alpha

[Chris Scheers]

Johnny Billquist wrote:
> On 2013-02-12 23:10, Chris Scheers wrote:
>> Johnny Billquist wrote:
>>> On 2013-02-11 13:44, Stephen Hoffman wrote:
>>>> On 2013-02-11 07:54:11 +0000, Hans Vlems said:
>>>>
>>>>> DECnet over DSSI works fine, provided you get the incantations right.
>>>>> All I tried was CTERM and FAL and both worked as expected (reliable
>>>>> albeit slow).
>>>>> Another example of an undocumented, unsupported feature that works
>>>>> alright.
>>>>
>>>> Not that there is even a remote chance of seeing DSSI gear around, nor
>>>> any likelihood of IP over FC nor connections, but...
>>>>
>>>> If you ran any tests[1] with that, how well does that "albeit slow"
>>>> connection perform as compared with slow Ethernet?  CI wasn't known for
>>>> its network performance, as compared with DECnet over even then-current
>>>> 10 Mb Ethernet, and usual recommendations back then had CI at higher
>>>> cost as a backup connection.  I can't see DSSI being much better in 
>>>> that
>>>> regard.
>>>
>>> That sounds weird. Do you know why?
>>> I mean, CI was after all two redundant full duplex 70 Mbit/s channels,
>>> compared to the half-duplex 10Mbit/s ethernet. Not to mention the fact
>>> that the MTU of CI is much larger.
>>
>> IIRC, CI is a form of token ring.  In particular, it has various "slots"
>> that circulate that are allocated to applications.
> 
> Nope. CI works similar to ethernet. It just checks if the line is free 
> before starting to transmit.
> However, it is also different than ethernet in that each node has an 
> individual delay once the path goes silent, and you can only grab the 
> path if it's been silent "long enough", which is different for each 
> node. And collisions are detected by the fact that all messages on CI 
> are expected to be ACKed by the receiver. If no ACK comes back, you 
> retransmit.

That's interesting.  I had been told it was a "token ring" type bus. 
Actually, now that I think of it, the description was more of a TDM type 
bus, but I don't remember if that term was common back then.

So CI is a full blown collision system?  Interesting.  Do you known of 
any technical documents on the net describing this?


> As for allocation of traffic by type, this is totally up to the OS, and 
> CI itself don't give a damn. DEC defined SCA as the communications layer 
> on top of CI, and SCA have datagrams, messages and block data.

It could very well be a VMS/driver construct.  I do know that when we 
did some trivial throughput tests, DECnet on the CI was slower than the 
Ethernet.  Of course, since we were doing disk to network to disk 
copies, the disk traffic also went over the CI.


> DECnet uses datagrams. Datagrams are unreliable packet service. Much 
> like UDP. Messages are also packets, but reliable, while block data is 
> used by MSCP.
> 
> All requests are placed in the same queue, and the CI controller works 
> through it from head to tail. So no difference of preference or anything 
> is done based on type. However, there are actually four queues, 
> representing priorities. The priority 1 queue is always served before 
> anything in the priority 2 queue, and so on...
> 
>> Again, from memory, DECnet, if configured, got about 10% of the
>> bandwidth. So DECnet had a theoretical bandwidth of 7MB/sec on the CI
>> vs. 10MB/sec on the Ethernet.
> 
> That would, in such a case, be something that VMS did. It's not 
> something that CI can do for you.
> 
>> Also, you needed to have Ethernet available to boot your cluster. DECnet
>> on CI was configured after you had booted.
> 
> Hmm. Good point.
> 
>> We used to have a 780/785 cluster where we configured the DECnet channel
>> on CI.  It had lower priority than the Ethernet.  It did save us a few
>> times when "stuff happened" on the Ethernet that disrupted
>> communications.  We would loose our terminal servers, but the DECnet/CI
>> was enough to keep the cluster from crashing.  When the Ethernet came
>> back, everything could continue.
> 
> :-)
> 
>     Johnny
> 


-- 
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360            Internet: chris at applied-synergy.com
   Fax: 817-237-3074