Newsgroups: uk.org.epsrc.hpc.discussion From: P.H.Welch@ukc.ac.uk (phw) Subject: Efficiency again ... Organization: University of Kent at Canterbury, UK. Date: Thu, 05 Oct 95 15:40:25 GMT Message-ID: <176@cypress.ukc.ac.uk> In article 35 of uk.org.epsrc.hpc.discussion, Lyndon Clarke (lyndon@epcc.ed.ac.uk) also writes: |* Efficiency of HPC resources - perhaps I have an unconventional opinion, but | I do think that in the case of research council HPC resources the important | thing is the research and publications that arise from use of the resources. | Really, its a question of how much science (or other, as appropriate) one | obtains for the money invested ...Yes ...
| ... and what the money happened to be invested | in is largely neither here no there. Are there any data on research | publications arising from use of HPC and other central resources in | the UK? | |* Efficiency of scarce resources - this was also a theme in the | conclusions. The point made was that we must use the resources | efficiently in order to increase the response time of resources. - | ie so that ou jobs spend less time waiting in queues. Now, if all | of our programs ran, say, four times faster on the T3D then I do | think we would all submit four times as much work, and our jobs | would spend just as long waiting in queues as they do today.
But this admits the case that efficiency matters. Raising efficiencies from 17% to a (modest?) 68% means that we would be getting four times as much science (or whatever) for our money. Unless, of course, the extra work unleashed on the machine was not really necessary - but there ought to be ways of discouraging that!
As far as the turn-around times for individual jobs remaining the same, this can be discouraged by some `fair' queue management - for example, by preventing one person being on a queue more than once. Then, we can still get through four times the work, with individual waiting times quartered - especially for those who need to use the machine less often (possibly because they need to analyse the results from one run before deciding on the next).
Cheers,
Peter.