ACM Home Page
Please provide us with feedback. Feedback
Is 99% utilization of a supercomputer a good thing?
Full text HtmlHtml (2 KB)
Source Conference on High Performance Networking and Computing archive
Proceedings of the 2006 ACM/IEEE conference on Supercomputing table of contents
Tampa, Florida
SESSION: Birds of a feather table of contents
Article No. 37  
Year of Publication: 2006
ISBN:0-7695-2700-0
Authors
Sponsors
IEEE : Institute of Electrical and Electronics Engineers
ACM: Association for Computing Machinery
Publisher
ACM  New York, NY, USA
Bibliometrics
Downloads (6 Weeks): 2,   Downloads (12 Months): 12,   Citation Count: 2
Additional Information:

abstract   cited by   index terms   collaborative colleagues  

Tools and Actions: Review this Article  
Save this Article to a Binder    Display Formats: BibTex  EndNote ACM Ref   
DOI Bookmark: Use this link to bookmark this Article: http://doi.acm.org/10.1145/1188455.1188493
What is a DOI?

ABSTRACT

This BOF will continue debate revolving around productivity metrics for supercomputers. At several recent user forums, consensus emerged that it is not possible to develop petascale applications without interactive access to thousands of processors. But most large systems are managed via a batch scheduler with long (and unpredictable) queue wait times. Most batch scheduler policies assume high system utilization as "good". But high utilization dilates average queue wait time and increases wait-time unpredictability, both of which are "bad" for application developer's productivity. What are the options to address these conflicting implications for running a supercomputer at high system utilization? Is it possible to manage a supercomputer to meet the high-throughput demands of stable applications and the on-demand access requirements of large-scale code developers concurrently? Or do these two usage scenarios inherently conflict? Participants will explain and debate several creative solutions that could enable high throughput and high availability for program development.



Collaborative Colleagues:
Allan Snavely: colleagues
Jeremy Kepner: colleagues