ken@gvax.cs.cornell.edu (Ken Birman) (01/05/90)
John Nicols just sent me a note of possible interest to others. To summarize, he asks if we have any plans to build a stand-alone version of ISIS. Under V1.3, he would be unable to get adequate performance for a multimedia system he is working on. The answer is yes and no. The no part first. I suspect that V2.0 comes close to what you need without running on bare hardware, especially when we run on Mach. In V2.0 most communication bypasses the protocols kernel, so putting this in the kernel becomes counterproductive; if anything, it hurts performance. The user code executed to launch a multicast is about 2ms+transport costs, e.g. perhaps 2 pages of code. Same on reception side: about 2ms from receipt to dispatch of a reply, if any, + transport back. And, if you have better hardware for moving messages, you can plug in a driver in ISIS V2.0. Mach has better intra-machine IPC, and we use that too in V2.0. So, overall, I see "ISIS in the kernel" as a loser in the 1990 timeframe. Now, the "yes" part. We are working on obtaining an academic license to run the Chorus realtime operating system on our SUN facility at Cornell, and the plan is to port ISIS into Chorus. This version of Chorus is quite stripped down and comes close to support for the basic Chorus segmenting scheme and communication, but nothing else. ISIS on such a system would probably be ideal for the sort of thing John Nicols is doing, and perhaps for other sorts of process control or financial workstation applications. After all, if the machine is dedicated to some application and stand-alone, why pay for all of the timesharing code UNIX carries as baggage. I haven't even signed the Chorus license yet, so I have no idea when this version of ISIS might be released. However, the agreement with Chorus is that it will be in the public domain when it is finished... My guess is that we are talking about the 3rd or 4th quarter of 1990. Ken Birman