[Info-vax] booting vaxstation off alpha

[Johnny Billquist]

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.

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.

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

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol