Contact us Heritage collections Image license terms
HOME ACL Associates Technology Literature Applications Society Software revisited
Further reading □ Overview19.03.6500.03.6522.04.6518.08.6614.12.6616.01.6724.01.6729.07.6811.09.7226.04.7316.10.7419.02.7528.04.7502.05.7509.07.7502.05.7522.10.75
ACD C&A INF CCD CISD Archives Contact us Heritage archives Image license terms

Search

   
ACLLiteratureCommittee MinutesACL Future
ACLLiteratureCommittee MinutesACL Future
ACL ACD C&A INF CCD CISD Archives
Further reading

Overview
19.03.65
00.03.65
22.04.65
18.08.66
14.12.66
16.01.67
24.01.67
29.07.68
11.09.72
26.04.73
16.10.74
19.02.75
28.04.75
02.05.75
09.07.75
02.05.75
22.10.75

Assessment of Atlas Performance and Future Prospects

J E Hailstone and R F Churchhouse

19.03.65

J E Hailstone

The decision to be made whether Atlas, which includes the Supervisor, is acceptable depends on meeting the formal requirements of the contract and for those features which are not defined some reasonable criteria must be applied. We must in addition satisfy ourselves that the future performance of the machine will be satisfactory.

Those features which are defined in the contract consist of the two series of performance tests. The first series are known to be outside the specified limits in some cases. The information being collected will show how frequently various classes of orders are performed and this will possibly permit the orders outside the limits to be offset against those which are shown to be faster. The comparison of the speed of Atlas with other machines is clearly of interest to us, since we need to have an idea of the potential computing power available to us. However, unless we can show definite evidence that claims have been made that Atlas was to be x% faster than machine y, then I find it difficult to see how we can include this in any case for non acceptance of the machine. Harwell will try to make more of this point than is relevant and the whole discussion will be confused by the effect of the different compilers used on the different machines and by the different programs that will be presented. I fear that a lot of time will be taken by this and in the end the way we choose to use the machine, using a Fortran Compiler, will carry little weight in the final decision for acceptance or not. Have ICT ever made any claims about compilers they would use on Atlas and what their expected eficiencies were? What were the feelings at the time that the contract was discussed, about Fortran and did AERE have any definite indications about its efficiency from ICT. It is agreed that the compiler is available later than expected but can we lay this at ICT's door? ICT have supplied compilers - EMA, Algal, and these work. I think we should be careful that comparisons are not made with too much hindsight. The lessons with the Stretch and 7090 Compilers has made everyone more aware of the difficulties. I have discussed the Compilers here because it seems the most relevant place associated with the performance specifications.

The second series of tests in which peripheral and drum activities are present during some tests of the A series are more difficult to decide upon. There is first of all the problem of whether the tests should be run with the Supervisor or not and secondly the percentage showing down is not defined for all the peripherals. I feel that the tests should be considered running under Supervisor control since this is the way they were intended to be used. The only peripheral specified is the line printer and this with one of the tests is outside the 12½% limit. The slowing down due to the other peripherals is a matter of assessment on some other grounds and I am worried about the very different order of magnitude presented in the paper "Atlas Operating System", June 1961 where it estimates that for each peripheral the central processor would be occupied dealing with peripherals for 1% of the time. This point may however have no significance for ICT in the formal contract. It could validly be said that because of the poor documentation of the Supervisor activities that ICT have not been very forthcoming with the facts about the effects of peripherals and we have not pressed them very hard for information. My overall impression. of the slowing down due to peripherals is that it is disappointing in view of the earlier promise. Clearly one has to pay for input/output but is this really making a significant contribution in view of the extra complication of hardware and the consequent extra cost.

Of the features that are undefined there is, the basic Operating system or Supervisor, the specification of reliability with its attendant problem of how much maintenance will be required, the documentation of the whole system, and the criteria for specifying reliable performance over the 12 month period before final acceptance.

The Supervisor must be considered to be defined by the relevant literature issued by ICT and it is clear that some features are not available. However, in discussions with ICT we have indicated preferences for certain facilities which we considered to be of high priority to be made available when it appeared that the project was in danger of not giving us a workable system in the time available. We have of course always maintained that not enough effort was made available during 1964 to have the final version ready in time for us to use in September 1964. The present state of the Supervisor is that virtually all the facilities asked for are available, but there are still some difficulties particularly associated with the machine idling conditions when there are jobs available to the system ready to execute. A more serious difficulty is the inefficiency of the system which shows that a large amount of time is spent idling when there are jobs in execution waiting to be done. This is very much what Atlas was designed to avoid and it is to be hoped that the 12 month period to final acceptance will show that the system can be improved. I think that at this stage we should obtain from ICT a clear statement that there is or is not a good chance that these improvements will be possible. It may be that some of the idling is inherent in the concept of the swinging input/output tapes and that this can only be overcome by introducing a disc. A further reduction in idling could come about by attention to some strategy of input/output which ICT can instruct us in; the lack of documentation of the Supervisor is a serious embarrassment to us since we cannot find out what to do about such a situation and must rely on information gleaned from ICT staff. I think I should point out here that of all the large machines, Atlas has the most elaborate logging information available immediately a job is finished and that we could be using this as a rod to beat its own back. Information.about usage of central processor time on other machines is not readily available and may be unreliable and a matter of guesswork. I think we should carefully distinguish between whether the At]as System is acceptable in terms of the expectations at the time of the start of the project and whether the concept of this elaborate system and hardware has been successful now that everyone is more experienced and there are comparisons with other systems which can be made. If criticisms are to be made of the swinging tape for example and Curtis in particular asserts that he has always thought this idea to be wrong, then the evidence of the misgivings in some papers to which ICT had access must be produced.

The reliability of the system as a whole is not defined formally and my understanding of the situation at the time was that because of the advanced nature of the system no agreement could be reached and it was hedged around by a lengthy period of 12 months between handover and final acceptance, and if the system failed to work by 1968 a complete rejection could be made. The whole question of handover relies on satisfactory performance of Test series A and B and the interpretation of what is meant by the system being complete. The performance tests have already been discussed and we now have to decide on some reasonable interpretation of completeness. Certainly the hardware as specified is all available for use and the system is at least in a workable condition. ICT themselves have not had a clear idea what they would mean by completeness and we have therefore been asked to suggest and agree on some criterion which would be used as a measure of machines availability for computing work. I think that ICT should be pressed to write an account of the present state of the machine and to present if they can some justification for the handover. They have agreed that a sensible rule for performance is 80% over a four week period with no week falling below 75% and no day below 70%. The recent four week period showed that 80% was achieved if a special plea is made for 11.2.65, but I do not think that with one other day below 70% and a sequence of days with core store locked out that we could consider the conditions to have been met. Moreover on some days it was not possible to achieve the eight hours scheduled time for computing service. A further test which we have borne in mind is that of the ACL Test Job Mix which it was agreed should run three times a day and an acceptable level of performance would be achieved when at least eight successive runs proved successful. This test was not successful and indicates that we cannot guarantee a period of successful operation of more than some figure less than 35 minutes. These tests are not included in the formal contract and merely serve to indicate what we would mean by completeness. If we cannot run long jobs can the machine be considered ready and acceptable for a computing service.

A further problem is our inability to run certain jobs, for example the Met. Office job, and the rather too frequent modifications to the accumulator which have taken place during the past few months. There is now an element of doubt about whether more modifications will be necessary in the future. However taking a reasonable view I think that the 12 month period was probably intended to cover this situation and the overall impression is that the accumulator is in a workable state.

Since the test series have not reached what we consider a minimum requirement and ICT are aware of the main sources of breakdown; the faults showing symptoms of core store parities, the failure of the machine to execute jobs when jobs are available allowing it to idle with no useful work being done, the frequency of the non equivalence symptom for both tape or drum and interrupt control, the ball is clearly in their court to show what plans they have for the future and how they intend to rid themselves of these troubles. If these faults were a random mix of faults throughout the system then I think that they would be in a more difficult position, it does appear that they are specific to certain parts of the system and they should be made aware if necessary by the implementation of the penalty clauses that these faults must be cleaned up. These faults which have given us the impression that the machine is not sufficiently stable from day to day may indicate that the system is very sensitive and that it needs very careful and lengthy maintenance to keep it at a reasonable level. We can have very good days and it is certainly true that the performance has improved greatly since the beginning of February, but I am worried about the ability of the machine to stand up when the amount of maintenance which would be available when we are on three shifts is reduced to say three or four hours.

Some indication from ICT on what their future plans are for maintenance is necessary so that we can be reasonably satisfied that we can meet our commitments. ICT must give us some assurances that we can expect good performance with a reduction in maintenance time. The question is could we go into full shift operation immediately and expect to obtain good performance figures? ICT have of course been aware of our plans to operate three shift working in November of this year, but I would not like to see the introduction of three shifts jeopardised by too low a standard being acceptable now. ICT have to convince us that the machine is in a suitable state for the maintenance engineers to keep it at an acceptable level without excessive effort and our recent experience makes me slightly apprehensive about this point.

In view of the difficulties recognised in the core store there are plans to replace by June the suspected 886 packages and a further exercise is thought necessary for the 967 packages. Are ICT aware of the seriousness of this? I do not want to be in this present state in September and I therefore feel that the Core Store should be the subject of some importance in discussing the plans for the next year which must inevitably be raised at the formal handover meeting. ICT must say what the problems are in a written statement and what plans they have and if possible whether they regard the core store as fundamentally sound. I realise there will be a good deal of haggling and the tactics of the handover meeting will be of some importance and that ICT may not wish to make statements beforehand, but I would not like this question to be bargained away too easily for I believe that our reasonable expectation was that the core store would be reliable and the present symptoms suggest that it is not.

A further point to be raised is the apparent need to keep the machine running continuously. This was not anticipated and we are using Atlas Laboratory staff over weekends to safety watch. Is this not really an ICT requirement and should they consider it as part of the maintenance operation? The Atlas Laboratory has been keen to assist since it is clearly in our interest but to continue until we take up four shift working is not what had been planned and it will cost us money and effort to maintain the weekend watch.

My conclusions are that the system cannot be said to be formally complete since in nearly all the subject discussed above there is invariably a qualification necessary. However I think that provided ICT can make the statements asked for in the previous paragraphs and these show a reasonable expectation of success then some form of sliding acceptance, for example, that by the earliest date they can manage,the core stores show improvement, then we can consider the handover condition as partially satisfied. The exact form this takes will be a matter for contracts. A further most important point which must be discussed in some detail is the conditions of running the computer for next year, and how the performance is to be measured, so that the criteria for final acceptance will be less vague than it is in the present contract.

J.E. H. 19.3.65

COMMENTS ON JEH's PAPER

I entirely agree with the overall tone of the paper: we must

  1. be very careful not to be led into long and irrelevant discussions; and
  2. we must be equally careful not to bargain away important points, for example, we expect a really reliable core store and can accept no substitute.

Basically there are two questions:

  1. is the machine sufficiently reliable and the Supervisor sufficiently complete for us to run a service, on three shifts if necessary?
  2. does the machine meet its speed requirements?

The answers to the first question involve:

  1. a definition of reliability (80% over four weeks etc.)
  2. isting the shortcomings (faults and deficiencies) of the Supervisor with a demand that these be removed before final acceptance;
  3. a particular set of criteria relating to the core store - the biggest single cause of hardware worry;
  4. remarks about the time required for maintenance.

On the last point we are very much in the dark but I think that JEH is right to worry about the possibility of there being too much maintenance to allow three shift working.

The second question can be answered by the Dynamic Analyses + Basic Timings. We must avoid being drawn into discussions concerning compilers and for hypothetical rewrites of the Supervisor. During the next 12 months both the Fortran Compiler and Supervisor should steadily improve in efficiency and discussion of them at this stage is likely to be wearisome and not very relevant.

Finally I also ask with JEH why ICT shouldn't cover the machine at weekends. I assumed that cover by ACL Staff was a purely temporary arrangement.

RFC 19.3.65

⇑ 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