Contact us Heritage collections Image license terms
HOME ACL ACD ICF SUS DCS G&A STARLINK Literature
Further reading □ Overview33. Start of year34. Hardware35. Communications36. UNIX37. ACCENT UNIX38. Dalkeith closure39. User Support40. Software41. Assessment42. SUSSG43. PERQ - DAP44. PERQ orders45. Critique of 1983
C&A INF CCD CISD Archives Contact us Heritage archives Image license terms

Search

   
ACDSingle User SystemsPERQ HistoryPart VII
ACDSingle User SystemsPERQ HistoryPart VII
ACL ACD C&A INF CCD CISD Archives
Further reading

Overview
33. Start of year
34. Hardware
35. Communications
36. UNIX
37. ACCENT UNIX
38. Dalkeith closure
39. User Support
40. Software
41. Assessment
42. SUSSG
43. PERQ - DAP
44. PERQ orders
45. Critique of 1983

1983

35. COMMUNICATIONS

35.1 Introduction

Now that PNX was becoming available, communications support for systems in the field needed to be provided and this could be considered in four main areas:

  1. File Dumping: the ability to back-up single user system discs was an urgent requirement.
  2. Wide Area Network Access: the ability to connect single or clusters of PERQs to the wide area network allowing the complete set of file transfer, remote login etc facilities available.
  3. Local Area Network Connection: to connect PERQs together via the Common Base LAN standard, the Cambridge Ring, and to provide protocols for file transfer etc to allow use of servers on the ring.
  4. Distributed Interactive Coupling: the ability to produce a unified interactive environment as transparent as possible to the users of individual workstations.

A need for the future was to consider the preferred LAN Common Base in the light of industry developments.

35.2 File Dumping

Asynchronous connections to provide file dumping had been available very early on and these continued to be the main method of archiving files. The standard utilities provided by ICL initially had little error checking but refinements took place during the next two years. In general, small amounts of file dumping in this way could be achieved relatively simply.

At the start of 1983, the possibility of down-line loading files and new releases to PERQs via the ICF multi user PRIMEs and GECs was considered. Unfortunately, restrictions on the way this could be handled in the multi user minis made this not ideal and it was eventually decided that software releases would have to be supplied on floppy discs for the foreseeable future until the local and wide area network connections had been established.

Consequently, the main way of upgrading PERQs to PNX was by loading a large number of floppy discs (at least 10) after first unloading all the files to be kept from POS and reloading them after PNX had been loaded. Utilities were provided to make this as easy as possible and clear instructions issued. Even so, it was a traumatic move which often took several days to complete. As a result, users were reluctant to move from POS until PNX was relatively stable and showed significant advantages over their existing environment. As ICL had built up a body of useful software under POS and good compilers, it was an uphill struggle for PNX to replace POS.

35.3 Wide Area Network Access

The Computer Board and JNT strategy for local area networking was to either use Cambridge Rings or local campus networks based on X25 wide area network protocols. As about 75% of the Computer Board local area networks were based on WAN protocols, wide area network access effectively provided local area network access also for a large number of users.

The JNT had contracted the University of York to produce a UNIX wide area network connection based on an LSI11 front end which handled most of the protocol conversion. This attached to the single user system or host via either a synchronous or asynchronous line. On PNX, it was necessary to port the higher level portable code to the PERQ and, in addition, there was some low-level kernel software that had to be integrated with the PNX kernel.

Prototypes of the York-box front end were available at the start of the year and work was started in integrating the York software with PNX. This required a great deal of testing and debugging by both York and RAL. It also required cooperation from ICL which was less forthcoming than it should have been at times.

By August 1983, the X25 software (ftp, remote login, mail) was demonstrated on the PERQ using PNX Release 1.5. As a new major release, Release 2.0, was imminent, installing software and hardware on user systems was delayed until Release 2.0.

Unfortunately, the move to PNX Release 2.0 required a hardware upgrade to PERQs including the replacement of several chips. Consequently, the availability of X25 software was delayed both by Release 2.0 and by the need for hardware changes. As ICL hoped to do these at the same time as the 16K WCS upgrades, the whole upgrade was bogged down in what seemed like endless negotiations between SERC and ICL.

35.4 Local Area Network Connections

The SERC/CB local area networking policy established by the JNT and followed by the Single User System Common Base was to base local area network connections on the Cambridge Ring running Basic Block Protocol (BBP) and Transport Service Byte Stream Protocol (TSBSP). Although not fitting into the OSI 7-layer model, they had become established UK de facto standard protocols and a number of manufacturers had included one or both protocols into firmware or hardware. The JNT had chosen the Cambridge Ring to provide support for a UK national invention, the possible involvement of British industry and the view that it offered superior performance to ethernet. Its aim was to produce UK academic standard protocols in the local area network in much the same way that the UK wide area standards had been introduced.

The PERQ, like all USA-based and European products, was targeted at ethernet as the standard local area network communications media. In the case of the PERQ, special hardware was provided for the ethernet connection. To install a Cambridge Ring connection, the only feasible short-term route was to use the GPIB interface controlled by a Z80. Some hardware developments at RAL had shown the feasibility of this route and Camtec were contracted to manufacture 50 GPIB-Cambridge Ring interface boxes. The contract to Camtec cost about £28K and provided Cambridge Ring connections at about £1.5K per interface, which was competitive with other LAN connection prices. (Ethernet connections, at that time, on PERQ1 and SUN cost over £3K.)

The major problem with this approach was the slow speed of the Z80 firmware and its lack of functionality. Adding some instructions would provide significant performance advantages when used with the Cambridge Ring.

By the start of 1983, the Ring connections were working at a data speed of about 1000 bits/see which was clearly inadequate. Changes in the Z80 firmware, it was estimated, would bring the speed up to 30-40 ki1obits/sec - hardly local area network speeds but, even so, useful.

The connection would be more reliable than the asynchronous ones available. Also, a poll of users discovered nobody with an immediate need for a high speed connection.

Slippage on the Z80 changes occurred throughout the first half of the year. All ICL's efforts were aimed at getting PNX Release 2.0 complete and in developing the PERQ2. ICL had no interest in Cambridge Ring as a technology and did not regard it as high priority.

In desperation, SERC eventually went to Three Rivers indicating all the changes that were needed. Bob Hopgood talked to Brian Rosen personally in August and he agreed that Three Rivers would make the necessary changes. These were completed by Three Rivers in October 1983 and a prototype implementation of BBP was done at RAL and available by December 1983. Intermittent hardware bugs slowed progress but the major part of the development work was complete for BBP by the end of 1983.

At the start of 1983, alternative approaches had been considered which would produce a faster Ring interface by not using the GPIB interface. Camtec proposed an in-board solution which for 50 systems would require £129K including development costs. Orbis proposed a simpler solution requiring less development but higher cost. The 50-off price was £152K. The Orbis solution might be available early in 1984 while the Camtec one was likely to be late in 1984.

Funds could not be found from the JNT for this work and RAL neither had the funds or effort within the Single User System programme. Consequently, no developments were followed up in this area.

35.5 Ethernet

The decision by ICL, with other European manufacturers, to back ethernet as the local area network strategy, together with its move towards international standardisation, meant that the future of a local area network policy based on Cambridge Ring was risky especially as the PERQ and its competitors had not been designed to run Cambridge Ring.

Throughout 1983, the Single User System programme put pressure on the JNT to change its local area network strategy to include ethernet. The Single User System Steering Group at its April meeting tried to get JNT to move towards ethernet. This was resisted on the grounds that Cambridge Ring protocols were well established whereas no similar situation existed in the case of ethernet. There was also insufficient effort in the Single User System programme to do two LAN developments and, consequently, if Cambridge Ring had to be supported, ethernet could not be.

Meanwhile, costs for ethernet equipment continued to fall markedly. The major drawback to ethernet in mid 1983 was that there was no standard set of protocols, although IEEE 802 proposals were likely to become an ISO standard and ECMA had their own proposals supported by ICL.

At the insistence of SUSSG, the Joint Network Team put a paper to the Steering Group in September 1983 reviewing its position on local area network standards. It indicated that there were problems in bringing ethernet low level protocols into line with the wide area network high level protocols. It recommended yet again that no move to ethernet should be considered at this time.

A major problem with the whole JNT philosophy was that it saw local area network developments as an extension of the wide area network rather than providing distributed interactive computing where a set of single user systems could be integrated into a single system. Consequently, undue emphasis was placed on the wide area network aspects.

At this time, universities were beginning to remove Cambridge Rings, replacing them by ethernets. The JNT project to provide Cambridge Ring interfaces to the PRIMEs had been cancelled. No fast Cambridge Ring solution for the PERQ was funded and neither ICL or Three Rivers were interested in Cambridge Rings.

The SUSSG were unimpressed by the JNT arguments and agreed to add ethernet to the Common Base with ECMA Class IV as the most likely protocol. JNT were asked to comment on the SUSSG decision at the next meeting before it finally went to the Central Computing Committee for ratification.

The JNT were unhappy with this decision and in October 1983 said it was not a good idea to add more unproven technology, with the associated non-existent products, to the Common Base. The JNT were pressing that ethernet not be added to the Common Base, although recommending that some pilot developments under ethernet be undertaken. With the lack of funds and manpower, this was a route that was difficult to take.

In October, Bob Hopgood wrote to the JNT saying that this sit-on-the-fence attitude was unacceptable. You cannot suggest connecting PERQs via ethernet is acceptable and at the same time say it is not sensible to have it in the Common Base (which only applies to Single User Systems). It was clear that JNT muddled up their UK standardisation activities with the SERC single user system Common Base.

As a result, JNT, in conjunction with Ken Robinson, finally put a paper to SUSSG in December 1983, recommending that Ethernet with IEEE 802.3 protocols should be added to the Common Base. No support could be provided due to lack of manpower. In particular, JNT refused to commit to an ethernet-X25 gateway until the protocol issue was resolved.

By March 1984, ICL were offering ethernet support - ECMA Class IV on top of IEEE 802.3 protocols - in PNX 2.0.

35.6 Distributed Interactive Computing

To provide full distributed interactive computing, there is a need to provide a very fast local area network (at least 1 Mbit/sec real data) connection, servers for functions such as printing and files tore , and a distributed UNIX environment allowing file and processor access to all allowed systems on the network.

ICL had two approaches to achieving this. The first was based on Accent and depended on replacing the basic PERQ operating system in the future by Accent and running UNIX as a subsystem. The SERC work in 1982 had demonstrated this was a feasible route and, given performance improvements, would give all the required functionality.

A second approach was to adopt the Newcastle Connection, a development of Newcastle University which effectively put a set of individual UNIX systems together as a single large UNIX system. Changes were needed to UNIX system libraries to effectively intercept functions such as filestore access and direct them to the appropriate host. As originally implemented, it did not require kernel changes.

Calls on local services are passed on to kernel by normal system calls. Calls for remote services give rise to remote procedure calls to server processes on the remote machines.

The original Newcastle Connection was based on Cambridge Ring hardware connecting DEC equipment.

Remote procedure calls and their responses are transmitted as datagrams, but do not use a communications transport service and so reliable delivery cannot be guaranteed. The reason advanced for this was efficiency. A remote procedure call and its response can be handled by a single pair of messages over the network. Much of the Newcastle work had been directed at building a reliable RPC (remote procedure call) mechanism on this unreliable base. The inherent reliability of local area networks compared with wide area networks meant that this lightweight protocol route was a viable approach and was probably essential if high performance of a distributed interactive computing environment was to be achieved. Thus, over the Cambridge Ring, Newcastle Connection did not use TSBSP. This meant that the Newcastle Connection has a different philosophy from the JNT one where the emphasis was on using the local area network as an extension of the wide area one.

ICL decided to support Newcastle Connection over ethernet as a product, and developments with Newcastle University took place to achieve this.

35.7 Summary

To a large extent, many users were mainly concerned in 1983 with getting single user systems up and running. Consequently, they were not inhibited by lack of progress in the LAN area. Work on the WAN connections proceeded satisfactorily and, although expensive, the York box solution is not an unreasonable method for single systems.

In retrospect, the decision to proceed with Cambridge Ring work was probably unjustified. It was clearly never going to solve the major performance issues without more money and effort, and neither was available. A decision to take any one of the short-term ethernet solutions would have brought us into line with ICL's own developments and could have produced results in this area more quickly. However, there was no consensus as to what protocols should be used on the ethernet. The USA were using TCP/IP while ICL were using ECMA-based protocols. We may have just had a different problem.

Decisions of this type were impeded by the JNT who had the authority for imposing standards in both the wide and local area network areas. Unfortunately, the JNT never saw the needs of distributed interactive computing as the main emphasis. Instead, they concentrated on the need for wide and local area networks to coexist.

⇑ Top of page
© Chilton Computing and UKRI Science and Technology Facilities Council webmaster@chilton-computing.org.uk
Our thanks to UKRI Science and Technology Facilities Council for hosting this site