Return-Path: lccheung@usc.edu Delivery-Date: Wed Sep 24 22:43:31 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on merlot.usc.edu X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.3 Received: from msg-scanner2.usc.edu (msg-scanner2.usc.edu [128.125.137.211]) by merlot.usc.edu (8.14.1/8.14.1) with ESMTP id m8P5hVfr008113 for ; Wed, 24 Sep 2008 22:43:31 -0700 Received: from msg-mx2.usc.edu ([128.125.137.7]) by msg-scanner2.usc.edu (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7Q005TILLB4LI0@msg-scanner2.usc.edu> for cs551@merlot.usc.edu; Wed, 24 Sep 2008 22:51:40 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by msg-mx2.usc.edu (Postfix) with ESMTP id 583472D2E for ; Wed, 24 Sep 2008 22:51:40 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so240545rvb.15 for ; Wed, 24 Sep 2008 22:51:40 -0700 (PDT) Received: by 10.140.192.9 with SMTP id p9mr3922906rvf.114.1222321899900; Wed, 24 Sep 2008 22:51:39 -0700 (PDT) Received: from LesliePC ( [76.195.62.167]) by mx.google.com with ESMTPS id c20sm211890rvf.3.2008.09.24.22.51.39 (version=SSLv3 cipher=RC4-MD5); Wed, 24 Sep 2008 22:51:39 -0700 (PDT) Date: Wed, 24 Sep 2008 22:51:38 -0700 From: Leslie Cheung Subject: verifying your simulation To: cs551@merlot.usc.edu Message-id: <019f01c91ed2$c7acdd10$57069730$@edu> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7bit Thread-index: Acke0scOiczZDxyDQC2FZeFzYfIrNQ== Hi all, A few of you have asked me how you can verify if your simulation is "correct". Here are a few things you should try. 1) Make sure the statistics match the simulation output. If you have 2 customers, and inter-arrival time of c1 and c2 are 1 and 0.5 respectively, the average inter-arrival time should be 0.75, and not, for example, 0.743123. I recommend calculating the statistics by hand using the simulation trace, and compare them with what you output at the end. 2) Check the simulation with "real" time (e.g., a clock). During my office hour, I saw a student's simulation finished 20 customers in about a second using the default parameters. Since the average inter-arrival time is 2 seconds (the default value for lambda is 0.5/second), you should expect, on average, a customer arrives every 2 seconds in real time. That means the simulation should pause a little bit after printing a few lines to stdout. 3) Make sure your simulation clock always goes up. The simulation clock should *never* roll back. For example, 00001520.374ms: c9 arrives 00001625.541ms: c10 arrives 00001524.263ms: c8 departs, inter-arrival time = ... The time in the 3rd line (c8 departs) is earlier than the time in the 2nd line (c10 arrives), and this should never happen. If you see something like this in your simulation, you better find out why and fix it! Some students also asked me about how they can verify if there is no deadlock, or if the mutex are put in the correct places. Well, there is no easy way to do it, other than inspecting your code very carefully. As for deadlocks, you might want to try running your simulation with a large number of customers. Just keep looking at your code and/or run simulations until you convince yourself you are right! --Leslie