This preview has intentionally blurred sections. Sign up to view the full version.View Full Document
Unformatted text preview: CS-350: Fundamentals of Computing Systems Page 1 of 7Lecture Notes © Azer Bestavros. All rights reserved. Reproduction or copying (electronic or otherwise) is expressly forbidden except for students enrolled in CS-350. Performance Evaluation of Computing SystemsIntroduction The various performance metrics we have examined so far enable us to speak of many aspects of a system’s performance (e.g., utilization, response time, jitter, fairness, availability, etc.) However, given a system, how do we obtain these metrics? Post-Mortem Evaluation (a.k.a. Prototyping and Characterization) Of course, if the system is already “built” or developed, we can just simply measure these metrics. Indeed, once a system is designed and implemented, it is customary to characterize its performance by providing “data sheets” that would give those using such systems a good idea of what to expect of the system. Obtaining performance metrics from a developed “real” prototype (implemented instance) of the system will clearly give us the most accurate quantification of these metrics, but it may not be so useful or practical after all!1In particular, if the purpose of evaluating these performance metrics is to choose between competing designs, then it is not practical to go ahead and develop all competing designs in order to measure their performance! Instead, what we need is the ability to “predict” what the system’s performance will be withoutactually building it. Predictive Evaluation (a.k.a. Modeling, Analysis, and Simulation) Rather than implementing the system, we may study its performance by simulating its behavior. In order to simulate a system, we must have a fairly good model of the system (e.g., what are the various processes involved, how they interact, etc.) Clearly, the ability of a simulator to predict the behavior of a system hinges on the accuracy of the models used for that system. Models may be quite simplistic—reflecting very rudimentary behaviors—or they may be quite elaborate—reflecting significant details. In practice, not all aspects of a system are modeled at the same level of details. For instance if we are building a simulator to study network performance, we may opt to have a very detailed model of how packets are queued, scheduled, and transmitted through a given router in the network. But, we may also elect to have a fairly simplistic model of other aspects of the system—say, what happens at other routers on the path between the sender and receiver. In general, any simulation model will be detailed with respect to the parts of the system “under the microscope,” while simplifying assumptions will be made about other parts of the system....
View Full Document
This document was uploaded on 04/14/2011.
- Spring '09