FIGURE 13 Histogram showing the distribution of 35 data-acquisition systems in total cost.
A breakdown of total costs for the 35 systems is given in Table 9, showing separately the total amounts involved in each of the four categories defined above. Evidently, about 60 percent of the cost goes for standard computer hardware, while about 40 percent goes for special hardware and software required for data acquisition. Table 10 shows separately the hardware and labor costs in the DAS item. Evidently, hardware is twice as expensive as labor in this case, on the average.
| TABLE 9 Summary from 35 "Complete" Reports | ||
| Subsystem | Cost | Percentage of Total |
| CPU's with memory and TTY | $ 3,933,000 | 38.5 |
| Standard peripherals | 2,293,000 | 22.4 |
| Data-acquisition subsystem | 3,038,000 | 30.0 |
| Systems software | 931,000 | 9.1 |
| TOTAL | $10,195,000 | 100.0 |
| TABLE 10 Data-Acquisition Subsystem | ||
| Hardware | $2,022,000 | |
| Labor | 1,016,000 | |
| TOTAL | $3,038,000 | |
FIGURE 14 Cost of standard peripheral equipment plotted against central processor costs for 36 systems.
FIGURE 15 Cost of data-acquisition subsystem plotted against central processor costs for 36 systems.
In Figure 14 the cost of the standard I/O equipment is shown plotted against the cost of the CPU for 36 different systems. The high point labeled "T" represents a system having many high-speed magnetic tape drives. The low point labeled "R" represents the Rochester system, which must be considered unbalanced, because its only "standard" I/O equipment is four Dectapes, which should, perhaps, have been defined as CPU items, since they cannot be used for communication with most computing centers. If a line printer and two IBM-compatible tape units were added, the Rochester point would have to be raised at least as high as the position R'. The straight line shown in Figure 14 was drawn with a slope of one half. It may perhaps be taken to represent a rough statistical reflection of the collective experience accumulated over the past six years or so regarding the relative costs of I/O and CPU equipment. In Figure 15 DAS costs are plotted against CPU costs for the same 36 systems. Here the spread of the points is worse than in the previous case, as expected for the reasons mentioned earlier. The exceptionally high point labeled "PHA" represents a system with three large pulse-height analyzers, two of them 20,000-channel units, in the DAS. The straight line shown has the equation y = 8.0 + 0.7x. The overall DAS cost is 77 percent of the total CPU cost.
One magnetic drum unit and 11 disks were reported to be in service (in eight different laboratories). Plans were reported for the installation of six more disk units and one drum (in five different laboratories). Recognition of the importance of rotating memory devices in display applications is evident in the reports.
Two systems were clearly stated to be in successful on-line operation with external computing centers. (At least one more example, at the University of Manitoba, is known: there a PDP-9 system is linked to an IBM 360/65.)
There are plans in various stages of development to connect nine different data-acquisition systems on-line with computing center machines, in most cases to operate on a delayed-access basis.
In cases where updating or enlarging of existing systems was said to be in progress, the costs reported were usually assigned by the reviewer to the present system, especially when money for the expansion seemed already available or very likely to become available. In many cases plans were in a less advanced state, but a fairly definite idea of the amount of money to be requested for expansion or for completely new systems was expressed. Table 11 summarizes these anticipated costs.
| TABLE 11 Anticipated Future Expenditures | ||
| For expansion of systems | $3,280,000 | |
| For additional systems | 1,455,000 | |
| TOTAL | $4,735,000 | |
C. V. Smith and George Rogosa have kindly made available approximate AEC budget figures for nine typical university laboratories chosen from those which had returned information in response to Dr. McDaniels' request. (The laboratories are Colorado, Kansas, Maryland, Minnesota, Texas, Wisconsin, Washington, Yale Linac, and Yale Van de Graaff.) After adding similar information for Rochester, it was possible to get a rough idea of the relative capital investments in accelerators and in computer systems and to compare those figures with the annual operating budgets (for 1969).
| total annual budget | = 0.33 | ||
| cost of bare accelerator | |||
| total computer cost | = 0.23 | ⇒ | 0.22 ± 0.06 by averaging separate ratios for each system |
| cost of bare accelerator | |||
| total computer cost | = 0.70 | ||
| total annual budget |
If the ratio of the total computer cost to the annual budget is calculated for each of the ten cases, and then the results are averaged, one gets 0.6 ± 0.3. If one quite unusual set of data (from a laboratory with a small AEC budget) is eliminated the last result becomes 0.56 ± 0.21, while the earlier results remain essentially unaltered. For the same nine examples we find that the average of the ratios of total computer system costs to bare accelerator costs is 0.22 ± 0.062, thus this ratio is significantly more consistent. It is emphasized that the results given in this paragraph refer only to experience at universities.
Tables 12 and 13 give a summary of present and anticipated process-control applications disclosed by the survey.
| TABLE 12 Current Process-Control Applications | ||
| Laboratory | Systems | |
| ANL | Van de Graaff accelerator; large scattering chamber setup; x-ray and neutron diffractometers; automatic plate scanner | |
| BNL | Neutron spectrometers; x-ray and neutron spectrometers, nine in all | |
| Michigan State | Cyclotron shim coils | |
| ORNL | Slow neutron time-of-flight to measure capture and fission cross sections | |
| Yale | Electron linac and beam optics; experiments with the linac | |
| TABLE 13 Future Process-Control Applications | ||
| Laboratory | Systems | |
| Michigan State | Control of entire accelerator system | |
| Minnesota | Tandem Van de Graaff accelerator and beam transport system | |
| Stanford | Nuclear reaction experiments | |
| UCLA | Limited control of cyclotron | |
The ultimate justification for assembling and using on-line data-acquisition systems must be made in terms of research output. The same considerations underlying judgments on the support of experimental research in other ways must therefore apply to computer systems. Some reasons often given for the use of on-line computer systems are these:
1. Modern experiments produce vast quantities of data which can be handled efficiently only by automatic calculating machinery. The experimenter gains greatly in effectiveness when the data are immediately converted into machine language, reduced by the computer, and presented to the experimenter in a convenient form.
Comment: Undoubtedly true. Fortunately a small system can satisfy this requirement in many cases.
2. Some experiments "cannot" be done by other means.
Comment: More likely true in practice than in principle.
3. Investment in a computer system is sometimes sound because it leads to a net reduction in the overall cost of performing experiments, either by eliminating some of the labor cost, by reducing the consumption of accelerator time, or in some other way.
Comment: True in many cases. Making estimates of projected savings is easier in ad hoc cases than in general.
4. Having facilities immediately accessible for calculating nuclear-reaction kinematics, magnetic analyzer field strengths, and other phenomena during the course of experiments saves time and promotes efficiency.
Comment: True, however, much of this work can be done ahead of time, and much of it requires only a relatively short, simple calculation which can be executed on a medium-sized computer, sometimes on a small one.
5. Given a sufficiently large computer system in the laboratory, its use for complicated data reduction and for theoretical calculations may produce an important saving of funds which might otherwise have been spent at the computing center.
Comment: This point may sometimes be valid, depending on a number of conditions, but the installation of a large computer as part of the data-acquisition system essentially on the basis of this argument is questionable, in view of the excellent facilities offered by modern computing centers.
6. Some expense for the development of computer systems and computer systems methods is justifiable as an investment in methodology.
Comment: True, although there is some question about the choice of places where such work should be done and about the correct source of funds to support it.
At the very outset of planning one should examine very closely the question of the large-scale calculating required in the overall execution of the research program of the laboratory; then, if, as usual, it turns out that a substantial amount of complex calculating is anticipated, one should consider carefully the feasibility of planning to do that part of the work at the most readily accessible computer center in the vicinity, so as to be able to concentrate one's own energies and resources, especially capital investment, on the data-acquisition system. The use of a modern computer center offers enormous advantages, and most computing centers would welcome support. If this course of action is chosen, provisions must be planned from the start for computer-language communication between the computer center and the nuclear research laboratory via a medium such as magnetic tape. (Direct wire transmission will often not prove feasible.)
Some key questions are:
1. How much large-scale computing is anticipated?
2. How much waiting time for results is tolerable?
3. Can the local computing center handle the needs, and at what cost?
4. If the local computing center can handle all the needs, but only after acquiring certain additional support for equipment or manpower, might not the better course of action be to provide that support rather than to set up separate facilities?
5. Can setting up a large system truly be justified? Have all the extra costs and complexities of the large system been taken into account, including those associated with input and output devices, operation, maintenance, programming, management, and space?
Since the ultimate criterion is research output, the role assigned to a computer system must depend on the nature of the work being planned. In some cases where a very specific use is intended, for example, in the case of a process-control application such as the Argonne plate scanner or an accelerator controller, the conditions are simple enough to make economic judgment relatively easy to apply. In the case encountered in setting up an accelerator laboratory where a wide variety of experiments is to be performed, conditions are much more complex. It is now widely accepted that any such laboratory should have a computer system, but what is not so clear is how extensive and expensive it should be. In other words, points 1-4 in B are accepted, and point 5 is conceded possibly to be applicable.
If sufficient funds are available, one sensible way to proceed is to use the accumulated collective experience outlined above. For example, one can say that experience has shown that the total investment in the computer system will be in reasonable balance with the capital investment in the bare accelerator if the ratio of costs is about one to five. Departures from the rule may then be made to adjust to special circumstances. Following this procedure means extrapolating from past experience, which may not prove a good guide, but this approach is similar to that often used in other matters bearing on the support of research. Probability is involved. It should be noted that the actual expenditures for on-line equipment for nuclear research have far exceeded those projected at the "Grossinger Conference on the Utilization of Multiparameter Analyzers in Nuclear Physics" in 1962.
In times of economic stringency it may be necessary to take a hard look at points 3-5 in B above before deciding how large a computer can be justified. A medium-sized computer is sufficient for most data-acquisition demands but not for large-scale calculations of a theoretical nature or for an occasional complicated piece of data reduction. Often it will be advisable to plan on carrying out all large calculations at the computing center, in which case a medium-sized computer will probably suffice for data acquisition, and a saving of about half in capital investment and operating expenses can be achieved.
If economic realities and good judgment should dictate the choice of a smaller system, the laboratory will still be well off. There is a tendency not to recognize the full capabilities of modern medium-sized and small computers, which, given intelligent programming, are very powerful. Although programming is in general expensive, the return for a modest amount of it in terms of data-acquisition performance may be very impressive. For example, the use of tables calculated ahead of time, stored on magnetic tape at the computing center, and read into the data-acquisition machine along with its control program offers a way to bypass the need for various sorts of calculations which might have been done on-line on a larger system. Increased efficiency of data acquisition often comes from the use of such methods, reflected in increased data-handling rates.
The system planner should try to anticipate a possible future expansion. In the case of a cut-and-dried process-control application it will often be safe to assume that the system will not have to grow, but recent history shows that in the case of general-purpose systems growth is the rule. In fact, systems have sometimes had to be replaced by entirely new ones. The system planner must beware of pitfalls. If, in anticipation of a greater future need, a much larger CPU is ordered than current use demands, the anticipated need may not develop. Or, if it happens that the money initially available for capital investment is so limited that it is all exhausted in buying the CPU, leaving the system badly short of conventional I/O equipment, then the system will remain painfully unbalanced until substantial additional funds appear. If those funds do not appear, the capability of the system will remain far less than the presence of the large CPU would suggest. (This is what happened at Rochester, where three years after the system was installed there is still no card reader, line printer, or conventional magnetic tape drive system; in fact, there is no computer-language medium for communication with the University of Rochester Computing Center.)
FIGURE 16 A data-acquisition system based on a medium-sized computer. Prices are actual costs for equipment supplied by a well-known manufacturer. This system is powerful enough to satisfy most data-acquisition needs at a typical low-energy accelerator laboratory.
The correct strategy to employ in every case should be consistent with the size of the laboratory and with the capabilities of its staff. A laboratory with a small engineering staff and with modest computing needs for the immediate future should certainly not plan to set up a large system. Instead it could sensibly begin with a manufacturer-assembled, trimmed-down version of the Comparison System (Figure 16), which could be enlarged later as occasion demanded and funds permitted.
It is no longer necessary to develop one's own system. Times have changed greatly. Many systems now exist which work well and are worth copying. Manufacturers and suppliers are prepared to deliver entire systems assembled and ready to operate, complete with all the necessary system software and varying amounts of utility software. Although it may at first sight seem more economical to assemble a system within the laboratory, by use of laboratory personnel, in most cases it is now better to buy the system from a single supplier, completely installed and operable, saving one's own resources for matters more directly concerned with research. The costs in time and effort to develop a new computer system have been much larger than predicted, in almost every case known to the authors. Large laboratories having strong engineering staffs are an exception; outside of industrial plants they are the places where new system development and assembly makes the most sense.
In general it is best to plan to do all very large-scale computing jobs (e.g., shell model and scattering theory calculations) at a large computing center and to set up in the laboratory a system which is just large enough to handle comfortably the data-acquisition jobs. Usually a medium-sized or small system will suffice. However, in some circumstances this will not be true.
Direct transmission-line coupling to a large, remote computing center may prove practical for handling occasional low-priority bursts of data processing, for example, when one can be satisfied with guaranteed access within about 100 µsec, say, and a maximum guaranteed total access duration of no more than a few percent of any day. Such a hookup may also be valuable for the handling of data input and output in the remote batch mode of operation, especially if a card reader (or high-speed paper tape or storage device) and a line printer are available for this use, in the laboratory. However, there are few if any examples of successful high-priority prompt-interrupt operation. One should be extremely skeptical about the feasibility of relying on this last mode of operation.
Rental rates have typically been set so that if the anticipated use period exceeds about three years, economic prudence suggests purchasing a computer rather than renting, providing that the necessary funds for capital investment are available. This can only be true, of course, because the life expectancy of modern computers is quite long, certainly over five years. (Also, one hesitates to trade in an old computer for which an excellent software collection exists!) The argument against renting standard peripherals is weaker, because they are electromechanical in nature and therefore have shorter lifetimes; furthermore, they tend to become outmoded. Renting can be especially attractive in special circumstances. For example, a line printer can be rented for the early period of operation of a system, while extensive program development work is in progress, and returned later, when the work has been finished.
Computers are rapidly getting better and cheaper. This month's machine is much more powerful than last month's, dollar for dollar. New machines will always be appealing, but the prospective purchaser must balance their appeal against considerations of probable delivery date, software availability, completeness of documentation for both software and hardware, and in general the manufacturer's support capability. Unfortunately, these factors usually weigh against a new machine. As a rule, even a medium-sized system based on a new model machine will not be in full operation for approximately one year after delivery, unless both the hardware and the software have been tried and proven in a previous installation. On the other hand, in the case of an older model the same factors may all be favorable, but now the machine probably gives less computing per dollar, and the advantage of an early return on the investment must be weighed carefully against the likelihood of somewhat earlier obsolescence. At some time during the life of a computer the manufacturer will very likely cease to support its software and, usually later, its hardware.
Software is all-important, and it is very expensive to develop, both in time and money; hence a system planner should favor a central processor for which a large amount of software is supplied by the manufacturer, especially system software. In general, when a particular type of machine has already been delivered to many customers the manufacturer may be relied upon to supply the essential software needed to run a system: an assembler, I/O routines for standard devices, and usually a Fortran compiler. The larger machines will be supplied with some sort of operating system (monitor), either for batch or time-shared operation. However, the specialized software needed for data acquisition will usually not be available unless it has already been developed by another user. A laboratory with limited programming resources should therefore give great weight to obtaining a system already provided with all essential software and should direct its own programming efforts to specific data-acquisition problems. Contracting with an outside company for development of the specialized software is also possible, although the cost will probably exceed the salaries of in-house personnel hired to do the same job, and communication with an outside group is inconvenient.
Many small, powerful computers are now on the market. They are inexpensive but very reliable. For many data-taking purposes they are quite sufficient, when equipped with appropriate peripheral devices and an adequate program library.
Magnetic disk and drum bulk storage devices have also undergone much development recently. Many good, small versions are now on the market at rather low prices. The capabilities of these units must not be overlooked. Attaching a modern disk unit to a modern, small or medium-sized computer produces a powerful but economical combination.
Unless an appropriate set of standard input-output devices is provided, the computer will not be used efficiently. A balanced system with a small computer is likely to prove much more useful than an unbalanced system with a medium-sized computer. What is necessary will, of course, depend upon the uses of the system. For example, if a large amount of program development is anticipated, the inclusion of a line printer should certainly be considered, because universal experience has shown that line printers are immensely valuable during program development; on the other hand, as a rule they are not so important in most data-taking operations.
It is often cheaper initially to use peripheral devices from a separate manufacturer, with interfacing provided either by the user or by an outside commercial firm. In this case difficulties lie in guessing the reliability of the devices and in achieving software compatibility. Software developed by a computer manufacturer usually takes advantage of the peculiarities of his own peripherals. If an outside device is purchased, the additional cost for programming during the lifetime of the system should be considered. If competent engineering effort is available, an interface compatible with the computer manufacturer's software may be built, with a possible saving in programming cost.
Standardized input-output bus structures designed to simplify interfacing to computers have recently been developed. Conspicuous among them is the CAMAC system already accepted as standard in many European laboratories. It is now being introduced into a few American laboratories. Before it can be accepted as a standard system here, a number of questions must be answered. For example, what types of external devices should be interfaced in this way, just ADC's data registers, counters, and the like, or should line printers, card readers, and related devices be included? Also, how much trouble will be encountered with manufacturers' I/O software, and how much will any necessary rewriting cost? Also will all computer I/O structures lend themselves to such a system; specifically, are multiport systems suitable? A national committee is now studying the CAMAC system to see if it, or something similar, should be recommended as standard in the United States. Even after being recommended as standard, however, any such system cannot be considered successful unless manufacturers accept it and market a wide variety of compatible devices. From the manufacturer's point of view the risks here may seem considerably greater than they were in the case of the NIM bins. It seems wise to keep watching for the outcome of this interesting development.
Whenever a new type of device is interfaced to a system, some form of machine-language programming must almost always be done in order to permit the handling of input-output operations involving the new device. This is true even in places such as Yale, where the design emphasizes a maximum use of Fortran. For this and other reasons, there should be at least one person on call who is skilled in machine-language programming and who understands the system.
The manpower required to maintain the hardware and software of any system naturally depends on the size of the installation and the uses to which it is put. Typically, a continuing effort must be expended on the improvement of system software and the writing of new data-acquisition programs. The existing hardware must be given preventive maintenance and repairs. Furthermore from time to time a hardware change must be made. Also, there are administrative matters; even the smallest system should have within the laboratory at least one person who will devote a large part of his time to administration, to the education of users, and to related matters. In many cases the laboratory has a contract with an outside firm, often the computer manufacturer, for maintenance of the computer, and sometimes the rest of the system as well. In other cases all or part of this work is done by laboratory personnel. Sometimes several laboratory people are competent both in machine-language programming and in diagnosing and repairing hardware ills. Such people are very valuable, especially if they are also competent to do interfacing of new devices. In some cases the experimenters do much of their own data-acquisition programming, in others essentially all programming is done by professionals. In some university laboratories much use is made of part-time student programmers, of whom there is now a considerable supply because of the growth of education in programming, both in high schools and at colleges. Students are sometimes remarkably good at this work and stand to profit later from the experience, but they are transients, and effort expended in training them is lost when they leave. Very roughly speaking, a small system will require a good fraction of the time of a technician-programmer, a medium system will require at least one full-time technician-programmer, and a full-time programmer, or some equivalent combination, assuming an active research program.
The comprehensive tables of properties of small and medium-sized computers appearing on the next 6 pages are from D. J. Theis and L. C. Hobbs, "Mini-Computers for Real-Time Applications," Datamation, Vol. 15, No. 3, p. 39 (March 1969) and are reprinted here by permission of the publisher, F. D. Thompson Publications, Inc., 35 Mason Street, Greenwich, Conn. 06830.