The following contains a brief overview of the philosophy and principles behind MFCF's billing system. To help with one's understanding of the methods involved and the reasons therefor, it presents a general picture without getting into specific details until near the end.
Some things provide easy ways of determining their cost (the number of pages printed, the number of megabytes of data backed up, etc.), and so MFCF can bill directly for these services with little problem. But for other services, costs do not make themselves so obvious.
Over the last few decades, MFCF has tried various methods of charging for its services. All have had acceptability problems with those members of the faculty that felt overcharged.
Previous attempts have included more socialist systems that taxed users on their ability to pay (e.g. a percentage of their research grants), while others have taken the opposite approach and tried to charge for the exact value received for all CPU and disk usage.
If a machine has very little usage one month and heavy usage the next, it might make sense from a business perspective to charge a lot more money for the second month, since the users received a lot more value from us. Similarly a fast machine will provide more work in less time than a slow machine, so again it might make sense to charge more for CPU time on a fast machine than on a slow one.
But MFCF does not operate as a business; it has a fixed budget. And since our cost of supporting a machine does not vary significantly from one month to the next, nor between a fast and a slow machine, it makes more sense that we should charge about the same amount for the machine each month, regardless of how efficiently its users made use of it.
This latest version of our accounting system more accurately reflects the actual cost of services provided by MFCF. It produces a much more predictable value, both for MFCF and for the machine owners who will know beforehand approximately what they will have to pay and what service they will receive. We hope that it will therefore find more general acceptance among the members of the Faculty.
Many different sources may fund hardware acquisitions, almost none of which come from the budget that supports MFCF's operating cost.
One should consider equipment ownership when determining who may use it and for what purposes, but such considerations have little to do with the ongoing cost incurred by the equipment's existence.
The cost of maintaining the equipment and providing services does not depend upon who actually owns the machines, whether the Math Faculty itself or individual professors or research groups.
It costs as much to maintain old slow machines as it does newer faster ones. In some cases the older equipment might cost even more.
Which machines one uses depends upon one's preferences and upon which machines one has access to, factors that have nothing to do with how much it costs MFCF to maintain the machine.
Whether one uses a fast efficient machine or a slower inefficient one does not affect what it costs MFCF to provide the service.
In the long run, even free hardware or software ends up costing about the same as expensive products, as almost everything requires human intervention at some time or other:
and people's time costs money.
A machine might have many potential users, but only those that actually use the machine during each monthly billing period will count toward the number of users associated with the machine.
Some users might have more than one sponsor (see section 5.2 below) for their account on a machine (e.g. one for research purposes and one for teaching). Such users will count multiply as active users as the differing requirements of each sponsor tend to increase the user's requests for service.
Users that do not use the machine might still have disk usage on it, but they will not count as active CPU users if their accounts have not used any CPU during the month.
The ongoing cost of individual pieces of equipment falls into three categories.
The cost of networks has little to do with the actual equipment connected to it. Each additional IP address simply contributes to the ongoing task of such things as keeping track of what equipment connects where, monitoring network traffic, recognizing and responding to problems, and upgrading switches, routers, and cables.
For this reason, MFCF charges a single flat rate for each connection, regardless of the type of equipment.
The cost of administering equipment can vary considerably from one type of machine to another. Some equipment simply sits there doing its thing, while other machines require continual human intervention.
Once configured, a thin client for instance requires very little ongoing administration, while a PC running Windows might require considerable time for such things as software installations and upgrades, network problems, and trouble shooting.
But due to economies of scale, even very similar types of equipment can have different administration costs. The users that have chosen to have a particular architecture should pay for the overhead associated with administering it. For instance, given two versions of UNIX running on identical hardware, if dozens of machines run one version while only one or two run the other, each individual machine running the first architecture costs a smaller fraction of the overhead associated with that architecture.
For this reason, MFCF charges administration rates that depend upon the architecture type of each machine, and those rates can change with the general popularity or unpopularity of each architecture.
The costs of providing service depends upon the number of users of each machine.
A machine with very few users will generally generate far fewer requests for assistance and require far less problem intervention than a machine with dozens of users.
On the other hand, as a user community increases in size, many users can help others within that community, and many instances of intervention will solve the same problem for several users at the same time.
For these reasons, MFCF charges service rates that depend upon the number of users of a machine, but with sub-linear incremental cost. i.e. a machine with twice the number of users as another machine will cost less than twice as much as the other.
The way people use or maintain their equipment can affect each of the three costing factors. For instance, some groups may choose to give up some of their freedom of choice or to take on some of the maintenance responsibilities themselves.
The charge reductions to the three factors described below can occur independently and simultaneously. Some machine might even receive all three: have lab designation; operate within a region; and connect to a privately maintained network.
Users may choose to establish and maintain their own network, thereby reducing the cost to MFCF, and hence reducing our charges.
Generally each such subnetwork will have a connection to the rest of the campus network, so we will charge for at least one IP address per network. (Should the private network ever cause problems for the rest of the campus, we will usually not investigate the cause beyond that connection, which might as a result end up temporarily disabled, with the entire subnetwork losing connectivity with the rest of the world.)
Generally, privately maintained connections should either have all their IP addresses of the form 192.168.xxx.xxx, making them invisible to the rest of the world, or they should comprise a complete easily identifiable subnetwork,
In some special cases, privately maintained connections can have addresses corresponding to other campus networks (but should this arrangement end up causing extra work, they might lose their private status and revert to having normal network connection status).
Some equipment can have a configuration that makes it much easer to administer. Generally such machines will have little or no user-defined state, and their individual unavailability will not seriously affect anyone's ability to do their work. Often it makes no difference who actually uses the machine, and typically even the name of the machine itself does not matter. In such cases, the equipment may receive lab designation, and so have a smaller administration charge.
Machines receiving lab designation do not necessarily have to reside in a large lab setting, and could even function as personal office machines in cases where the user does not mind the inconvenience of such things as limited software and lack of configurability.
Some architectures so obviously deserve the lab designation that they already have their own categories. A thin client provides an extreme example of a lab machine, while a PC configured as a Nexus Windows system qualifies even if used as a personal workstation.
Other situations depend on their own merits.
For instance, a Windows PC may
mount all user data from elsewhere,
and have a configuration that severely limits
what software it contains.
With several such machines available, when one breaks,
a user need only hang an out of order
sign on it,
notify MFCF, and move to a different machine.
Fixing the machine might consist of nothing more than replacing
it with another machine loaded with the standard software.
Some groups of machines may have very intimate connections with each other and share a large common user community. Adding another similar machine to the group (without increasing the number of users in the community) does incur additional connection and administration costs, but shouldn't significantly increase the user service costs, since the same users will continue doing more or less the same things they would have done, though presumably with a little better response and less conflict. In fact, with the users spread out across more machines, peak loads decline and conflicts due to such problems as memory and swap space occur less often, so the entire region ends up costing less to support.
An XHIER region of UNIX machines forms such a group. They have all mailboxes, passwords, home directories, etc. mounted in common, with users simply choosing one machine over another as the most appropriate or convenient CPU to use at the moment.
Since regions can require less work to service than simply summing the individual machine costs would indicate, the charges must follow some obvious principles:
The method of billing and cost distribution has no effect on the calculation of costs associated with a machine. MFCF provides two billing methods, described below, but these do not preclude other methods should the need arise.
Each piece of equipment has a monthly cost calculated on the principles described in the previous sections. MFCF will either distribute this cost among the sponsors of the machine's users, or bill it directly to the machine's owner.
Every user of the machine has someone that sponsors their usage. Typically researchers will sponsor themselves and some grad students, MFCF and other administrative departments will sponsor their own staff, and the Dean of Math will sponsor teaching related accounts, including accounts for all students.
The sponsor of each user/sponsor combination on each machine will pay a share of that machine's cost. Since someone that uses twice as much of a resource as another user does not necessarily cost twice as much to support, charges will depend upon a sub-linear proportion of the total cost (currently we use square roots).
MFCF measures the CPU and disk usage on each machine. For machines with non-zero measured usage of both CPU and disk, part of the the cost of the machine will apply to CPU usage and part on disk usage (currently we split 50/50).
Some machines will implicitly have a single sponsor for all usage, either because the owner prefers it that way, or because the machine's architecture makes accounting for individual users difficult or impossible.
The Dean pays for some basic infrastructure. For instance, each researcher in the faculty receives their first four IP connections without charge, and each grad student receives a thin client and connection. Researchers that choose to replace the grad student's thin client with other equivalent equipment (e.g. a PC or Mac) may apply an equal amount to the support cost of that equipment.
At the discretion of the Dean, subsidies may apply to the amounts charged for various resources. Typically any member of the Math Faculty will receive a 50% subsidy for everything except printing.
To avoid nickel-and-diming people, individual items that cost less than some small amount (currently $1) and term-bills less than some other small amount (currently $10) receive a 100% subsidy.
As part of the development of this model, MFCF collected data about the time spent supporting various activities and platforms to determine how to apportion costs. Fitting those costs to mathematical functions produced the parameters and damping factors, followed by simplifications such as the use of square-root instead of the observed sub-linear scale value.
Each machine will have several associated costs:
The first cost is fixed, while the second is determined by the actual machine and its intended purpose. The user service charge depends on the number and type of users, though not linearly, and also on whether the machine is part of a region.
Note that the total user cost for all machines in a region should add up a value that would be the user cost for a single machine with the same user community. I.e. one machine with 16 CPUs should have the same user service cost as sixteen regional machines with 1 CPU each.
CH = Connection charge (e.g. $9 per IP connection)
DH = Damping factor for multiple users (e.g. 0.8)
AH = Administration charge (e.g. $25.00 for system administration on UNIX)
SH = service charge (e.g. $30.00) for user Support
The damping factor and the administration and service charges depend on the host's architecture, currently with only UNIX machines having a non-zero user service charge. At the moment we do not have active user counts for other architectures, so for those machines, the administration charge effectively includes a user service charge for one user.
NC = number of network Connections
NH = number of active CPU users on the Host (minimum 1)
NR = number of active CPU users in the Region (minimum 1)
NS = Sum of NHDH over all hosts in the region. (I.e. the sum of the adjusted number of users on each host.)
Cost = {C × NC} + AH + {SH × [NHDH]/NS × NRDH}
Note that computing the sum for all machines in a region of identical architecture will reduce the middle factor in the last term to 1, and the entire region thus has a user service cost that depends upon the number of users in the region but does not depend on the individual usage of machines within that region.
For a typical situation of one host and one connection, this formula reduces to:
Cost = C + AH + { SH × NHDH }
And for a machines with at most one user:
Cost = C + AH +SH
| Host | Active Users | NC | NH | NHD | Individual Charge | Region Charge |
|---|---|---|---|---|---|---|
| X | W, V, U | 1 | 3 | 2.41 | C + A + S×2.41 | C + A + S×(2.41/9.63)×5.28 |
| Y | U, T, S, R, Q, P | 1 | 6 | 4.19 | C + A + S×4.19 | C + A + S×(4.19/9.63)×5.28 |
| Z | V, U, T, S | 1 | 4 | 3.03 | C + A + S×3.03 | C + A + S×(3.03/9.63)×5.28 |
assuming that
DH = .8, AH = A, SH = S.
for all architectures, we have
NR = 8
NRDH = 8.8 = 5.28
NS = 2.41 + 4.19 + 3.03 = 9.63
In the first example, if considered individually the three machines collectively cost:
3×C + 3×A + 9.63×S
.In the second example, the region of three machines costs:
3×C + 3×A + 5.28×S
.Eventually MFCF may provide other methods of apportioning costs among machines within a region. In particular, one can rearrange the factors in the user service term to give this:
[ SH × NHDH ] × [ ( NRDH ) / NS ]
which represents the cost of the individual machine and a regional reduction factor.
Note that this regional factor does not depend on the machine under consideration.
Perhaps more realistically, this factor should instead have a separate value for each individual machine and reflect the degree to which that machine contributes to the overall regionality (e.g. how many of its users use how many other machines?). Doing so would also eliminate the glossed-over problem of regions in which machines have different user-service or damping factors.
Whatever happens, the regional factor for any machine would never exceed 1 (otherwise removing the machine from the region would reduce its charges).
If MFCF does not bill the equipment charges for a machine directly to its sponsor, we can distribute the cost to the sponsors of the machine's users (where such information exists).
A machine that has both CPU usage and disk quota will have its cost divided evenly between these two resources. Otherwise the entire cost of the machine will apply to the one resource.
Each user of the machine will share the cost in proportion to the square root of their CPU usage. (Thus users with no CPU usage will incur no cost.)
Each user of the region (regardless of their CPU usage, if any) will share the cost in proportion to the square root of their disk usage.
Last modified: 2009-May-06 16:18