From ozlemakp at gmail.com Fri Jul 15 16:24:37 2005 From: ozlemakp at gmail.com (Ozlem Akpinar) Date: Fri, 15 Jul 2005 16:24:37 -0400 Subject: [Disksim-users] Seek time calculation Message-ID: Hi, For my disk, I am using hpl seek time function. I set up the requests so that only the second part of the equation is valid. However, Avg seek distance value is not matching the avg. seek time value reported in the output file. (I am supposed to get a different avg seek time value if I plug the avg seek distance value into the hpl seek time equation) I would appreciate any comments.. Thank you. From bucy at ece.cmu.edu Fri Jul 15 16:34:51 2005 From: bucy at ece.cmu.edu (John Bucy) Date: Fri, 15 Jul 2005 16:34:51 -0400 Subject: [Disksim-users] Seek time calculation In-Reply-To: References: Message-ID: <1121459691.4523.57.camel@CATALEPSY.PDL.CMU.EDU> On Fri, 2005-07-15 at 16:24 -0400, Ozlem Akpinar wrote: > Hi, > For my disk, I am using hpl seek time function. I set up the requests > so that only the second part of the equation is valid. However, Avg > seek distance value is not matching the avg. seek time value reported > in the output file. (I am supposed to get a different avg seek time > value if I plug the avg seek distance value into the hpl seek time > equation) 1. The hpl equation is *old*. All modern disks have a seek curve too tricky to be accurately modeled by it; we use a piecewise/extracted curve ("full seek curve") instead. 2. It may be hard to make a sensible comparision between the average seek time of the disk "on paper" and under a real workload. If your workload is uniformly random across the entire LBN space, I'd think it might match up but under any other circumstances, the distribution of the trace and effects of the cache will change it. john From stein at eecs.harvard.edu Tue Jul 19 08:18:06 2005 From: stein at eecs.harvard.edu (Christopher Alexander Stein) Date: Tue, 19 Jul 2005 08:18:06 -0400 (EDT) Subject: [Disksim-users] high average I/O times In-Reply-To: References: Message-ID: <20050719081622.D90319@bowser.eecs.harvard.edu> Hi, I am using the Cheetah 9LP disksim model and seeing average I/O times as high as 100ms for a heavy workload. Might I be doing something wrong or is this reasonable in some cases? Under other workloads, it's down as low as 8ms average. Thanks Lex From bucy at ece.cmu.edu Tue Jul 19 13:22:41 2005 From: bucy at ece.cmu.edu (John Bucy) Date: Tue, 19 Jul 2005 13:22:41 -0400 Subject: [Disksim-users] high average I/O times In-Reply-To: <20050719081622.D90319@bowser.eecs.harvard.edu> References: <20050719081622.D90319@bowser.eecs.harvard.edu> Message-ID: <1121793695.4523.95.camel@CATALEPSY.PDL.CMU.EDU> On Tue, 2005-07-19 at 08:18 -0400, Christopher Alexander Stein wrote: > Hi, I am using the Cheetah 9LP disksim model and seeing average > I/O times as high as 100ms for a heavy workload. Might I be > doing something wrong or is this reasonable in some cases? Under > other workloads, it's down as low as 8ms average. Which stat are you looking at in the output? If your workload causes queueing at the disk or elsewhere in the system, you may be seeing the result of such delays in your stats. john From ozlemakp at gmail.com Thu Jul 21 10:28:03 2005 From: ozlemakp at gmail.com (Ozlem Akpinar) Date: Thu, 21 Jul 2005 10:28:03 -0400 Subject: [Disksim-users] Disk Transfer Time Message-ID: Hi, I have a question about the transfer time component of the access time in disk. For a single zoned disk, I believe for a single block request, this value is the full revolution time of the disk divided by number of blocks in a track. When I have requests with two blocks, and no caching, transfer time is higher than the twice of the number I obtain for the single block request. What exactly is included in that excess time? A possible head switch when the second block is on a different surface than the first one, and a possible cylinder switch when it is on a different cylinder? Thank you. Ozlem From ozlemakp at gmail.com Fri Jul 29 17:19:48 2005 From: ozlemakp at gmail.com (Ozlem Akpinar) Date: Fri, 29 Jul 2005 17:19:48 -0400 Subject: [Disksim-users] Waiting times Message-ID: Hi, I have a question about the disk cache hits. Does a read request wait in driver queue until all the previous requests are serviced, or is it satisfied right away if the cache contains its data? I have a highly sequential arrival stream, and when read requests are waiting very little, writes are waiting forty times the read requests. allow almost read hits, and all sneaky read hit variables are set to 0. I would really appreciate any comments. Thank you. Ozlem From ozlemakp at gmail.com Fri Jul 29 19:13:28 2005 From: ozlemakp at gmail.com (Ozlem Akpinar) Date: Fri, 29 Jul 2005 19:13:28 -0400 Subject: [Disksim-users] Sequential requests Message-ID: Hi again, I noticed that, if a request is created sequential to the previous one, it is always a read if the previous request is a read, and write if previous one was write. Is there any way to change that? Or am I missing something? Thank you very much for your help. Ozlem