Beyond the question of how much funding should be invested in high performance computing resources, it is also important to strive for the optimum funding model: how funding is tied to the service and how it enables and drives user behavior. As it turns out, these models are wrapped up in an IT culture that is often at odds with the way HPC is used.
This article was inspired by recent topical discussions on funding and charging models for HPC in academic institutions in both the UK and the USA, including particularly a series of blog posts by Brock Palen. The issues are by no means limited to academic institutions, and in fact are equally pressing for industry users and providers of HPC resources.
For many of the biggest supercomputers in the world, there is always a separation between the big lump of cash for the machine and funding for the on-going operation, which is often due to different funding routes for each. However, the reality for most HPC systems outside the national supercomputing services, especially academic institutional and industry HPC systems, is that the funding and the service delivery are intricately linked.
To start, let’s constrain this discussion to in-house HPC resources. (I’ll come back to discuss cloud computing and other external models in a future article). The discussion takes in funding, measurement, professional experts, and finally culture changes.
Where does the funding come from?
Beyond the lump sum donation, there are essentially three models for funding HPC resources: through overheads, usage fees, or a combination of these two. I often call this latter model “baseline-plus.” Under the overheads model, the corporate or departmental HPC facility is provided to users as part of the infrastructure of the business or university and is including in the overheads of the business. There may be accounting, i.e., recording usage of the resources by each user, but not charging. Under the usage fees model, accounting leads directly to the users being billed for their actual consumption of resources.
Under the baseline-plus model, some elements of the service, like storage, may be included in the overheads whereas others, like CPU-cycle, may be charged according to consumption. Or the combination may be applied to everything, essentially subsidizing the usage fees by partially including the costs in overheads. Or a combination may be used to provide a service free of charge for “normal” consumption levels but apply charges for extreme usage, such as large storage requirements, large memory jobs, high core-count jobs, and so on.
Finding the model that keeps everyone happy
To see the benefits and issues of each model, let’s start with the viewpoint of the user – always a good place to start. The preferred model for users is almost always going to be “free,” that is, the overheads model. On the face of it, this offers the least burden on the user’s part. They just do whatever science or engineering simulations they need and pay as much attention to the costing of the HPC resources as they do to the company internet connection or the office lighting. However, this can also lead to tension when some users may suspect others of consuming an “unfair” share of the common resource.
At the other extreme, the “charge for everything” model is likely to be least favored by most users, simply because it creates a culture of having to justify every usage of the resource. That may be seen as a good thing by senior management, since the HPC resource is likely to represent a significant investment. However, it might limit the freedom of the researcher or engineer to “just try this,” that is, engage in speculative work that isn’t tied to a clear goal, but which may spark significant innovation.
In theory, the baseline-plus model allows the best of both worlds, enabling speculative work and reduced attention to monitoring consumption, whilst ensuring users who dominate consumption are seen to contribute. However, the potential complexity of the model – what is included in the core service and what is charged at usage – can lead to both confusion and debate amongst users about the “right” way to configure the complexity.
Shifting to the HPC manager’s viewpoint, the instinct is often to prefer the overheads model, as this usually works in practice as a predictable way to budget the resource. The usage fees model is often seen as least desirable because it turns every HPC manager into a sales person trying to keep their customers coming back for more, and involves an uncertain budget.
Allowing for growth and innovation
In all of this discussion so far, we have assumed a static size budget and resource. In reality, the critical aspects of these models is one in which the HPC provision evolves.
Under the overheads model, growing the resources, for example, buying a larger supercomputer or providing more support staff, usually means going back to management with a case to increase the budget. Without a direct link between the end users and the resource provided and consumed, that case is harder to make.
With usage accounting (not necessarily charging) this becomes easier. Changing the balance of the HPC provision, such as providing more large memory nodes, or more cores instead of storage space, is almost impossible because each user will see a different need.
The usage fees model solves this problem. As usage grows, the resource can be increased with the fee income. The type of resource provided can also be changed to meet the needs of users as they direct their fee-paying usage onto different elements of the service.
However, the pure usage fees model creates other problems. What about the resources that the HPC manager knows users will need but which users are resistant to paying directly for? Code performance expertise is a common example of this, as is interconnect bandwidth.
What gets measured is what gets the focus
This leads to another key aspect of the models, namely what to measure (and thus charge for in the fees or baseline-plus models).
The most common unit of consumption to measure is CPU usage. Users are accounted for how many CPU-hours they consume and are charged appropriately. The price of the CPU-hour includes the cost of running the system, but to many users, that’s not fair. For example, why should I pay a high price per CPU-hour when I don’t need that fast interconnect that is driving the price up? Or, I’ve never used the support team, so why can’t I have a discount price? That other user consumes way more memory or disk than me, surely he should pay more? And so on.
It’s temptingly easy to respond by having separate charges for different elements of the service – CPU-hours, support staff, disk usage, high memory nodes, etc. However, this rarely works well in practice for either users or HPC managers.
Measuring CPU-hours alone is horrendously bad practice though. The processors are often the cheapest part of the supercomputer to buy — behind memory and interconnect and maybe disk — and certainly small compared to operating costs, like power and staff salaries.
Idle processor cores are seen as “a bad thing,” but the memory probably cost as much to buy and nearly as much to sit there consuming electricity. Yet few HPC services monitor memory utilization. Or interconnect utilization.
Science and business output, not busy CPUs
And, speaking of utilization, there are competing interests of users and HPC managers. For users, high utilization means more contention for resource, for example, longer job queues, and is a bad thing. For HPC managers, high utilization means demand and provision are, in theory, closely matched, which is an efficient use of budget.
But efficient use of the budget should be tied to the science or engineering outputs achieved, not to the detailed consumption of the resource that enables that innovation. Which is better budget use, a low utilization system that is available on the timescales of the researchers’ or engineers’ needs (and gives them freedom to try out new ideas or support customer requests at short notice) or a high utilization system that means only planned business can be done?
The complexity of matching the model to the needs of the business, both funders and users, means that the strategy for HPC provision is rarely as simple as assumed. That’s why there is a role for professionals who have experience in finding the best model for a given situation. “HPC manager” or the equivalent is a valuable and distinct role within the organization, as is the potential support from independent experts available to provide consulting advice.
The wrong culture?
Perhaps a key part of the answer is that HPC is not really IT. It is built using computer technology but it is really a scientific instrument or engineering facility. I have written about this before. So maybe we need to move away from the funding, measuring and user cultures inherited from traditional IT.
The success of an optical telescope in astronomy might be measured by what new objects are observed, not by the amount of time an eyeball is attached to the end of it. The success of a wind tunnel might be measured by the quality and quantity of the design information gained, not necessarily the amount of time the fan is spinning. It is expected that the instrument or facility will be supported by experts whose profession is the technology of the instrument and that this will be a fundamental part of the funded resource, not an optional extra.
What can you see as cultures from the traditional IT world that are holding back HPC’s potential?