FW: Total Cost of Ownership and porting (was FW: Can we have a mo ment of silence (or several million dollars) . . . please?)
Many of your questions may have already been answered in earlier discussions or in the FAQ. The search results page will indicate current discussions as well as past list serves, articles, and papers.
Schilling, Richard RSchilling at affiliatedhealth.orgTue Jun 26 12:44:37 PDT 2001
- Previous message: beowulf newbie...???
- Next message: dbug site
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> -----Original Message----- > From: Greg Lindahl [mailto:lindahl at conservativecomputer.com] > > Well, yes, but it's hard to give that info to anyone else and have it > mean something. My FSL customer is in the business of writing portable One way is to create a set of standard terms and characteristics to qualify the costs. For example, the following might mean someting to everyone: PORTABILITY BASELINE COST: the amount of work required to get the code to compile. A measurement of hours for a given hardware platform and an associated level of complexity for the work (from best case to worst case): 1 - no code changes. Just recompiled and ran without modification. (e.g. ./configure -> gmake -> gmake install) 2 - configuration files needed changing (e.g. edit Makefile.in, configure.in, environment settings, etc . . .) 3 - some libraries needed installing on the target machine, but could be installed (e.g. pthreads library) 4 - some libraries needed installing on the target machine, but could not be installed. New libraries could be created. 5 - some libraries needed installing on the target machine, but could not be installed nor recreated in a way that would allow the ported application to run as intended. 6 - the software needs to be completely rewritten due to targeted hardware configuration. 7 - the software needs to be completely rewritten due to poor code quality. 8 - existing code unusable on the target machine. Number of hours to determine this would then be noted. . . . or something like this. As part of the initial data gathering for this rating system, some analysis of the hours reported would need to validate the usefulness of the ratings for level of complexity. BENCHMARKING COST: cost in hours/resources to establish a comparative benchmark between the software run on the old machine and on the new machine. For example, how much faster does pvmpov run on the new machine, compared to the older one for a given set of input files? DEPLOYMENT COST: cost in hours/resources to deploy the new software on the cluster. HARDWARE CONVERSION COST: resource outlay to get the new hardware and have it installed. TIMEFRAME: what is the timeframe for the porting? This could be set by the manufacturer (via end of life practices), or the implementer (via adoption rate practices). EMPLOYEE COST: Once the scope of the porting work is established, how many employees will be required, and what is the cost of recruitment, if necessary. DOWNTIME: The cost associated with bringing the existing system down (out of production) to perform the upgrade. I suspect that taking an itemized approach to this will get people thinking about comparative cost analysis. It's a natural step for those that do it for a living. In health care we do something similar all the time for new systems.
- Previous message: beowulf newbie...???
- Next message: dbug site
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Beowulf mailing list
