I don't have a strong opinion, and I'm not 100% sure I'm even following this correctly (I just skimmed the thread), but I think "access latency" (or "effective" or "average" access latency) would be the term that's most self-explanatory. To me "request latency" is a little ambiguous, since I believe you're really talking about request-to-response latency, so singling out requests is only one side of it. Calling it "response latency" would also be pretty descriptive (more so that "request latency" IMO). Though any of these would be an improvement, since as Korey pointed out "miss latency" is downright misleading...
Steve On Sat, Apr 23, 2011 at 5:13 AM, Korey Sewell <ksew...@umich.edu> wrote: > I'll post a reviewboard patch for the name change soon. > > On Thu, Apr 21, 2011 at 11:24 AM, Beckmann, Brad <brad.beckm...@amd.com > >wrote: > > > Ha...those latency values have been referred to as miss latencies for so > > long that I failed to realize that calling them miss latencies would be > > confusing. There is a lot of old history there, more than I care to go > > into. If you want to change the name to request latency, that is fine by > > me. > > > > Brad > > > > > > > -----Original Message----- > > > From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] > > > On Behalf Of Korey Sewell > > > Sent: Wednesday, April 20, 2011 9:24 PM > > > To: M5 Developer List > > > Subject: Re: [m5-dev] Defining Miss Latencies in Ruby > > > > > > Hi Brad, > > > Don't you think this is a misnomer and instead should be called > > > "request_latency:" , "request_latency_IFETCH", and etc.? I think this > is > > what > > > is really being measuring anyway: the request latency from when a > request > > > leaves the cpu sequencer and then eventually finishes. > > > > > > But if you are going to say a stat is "miss latencies" and it > encompasses > > both > > > hits and misses, I would think that's a bit paradoxical. Do you agree > > there or > > > do you think "miss latencies" fundamentally implies hit latencies as > > well? > > > > > > (As far as tracking miss latencies based off machine type, thanks for > the > > tip. > > > In the short term, since I just care about L1 hits/misses, I think I'll > > be able to > > > just say "if miss_latency > L1_latency" in my local tree) > > > > > > On Wed, Apr 20, 2011 at 11:37 PM, Beckmann, Brad > > > <brad.beckm...@amd.com>wrote: > > > > > > > Sure, it is recording all miss latencies, including L1 cache hits. > > > > And yes, those L1 hits will show up in the first bucket. However, I > > > > don't see how that is a bug. If you don't want to include L1 hits in > > > > the histogram, then look how the MOESI_hammer protocol tracks > separate > > > > miss latencies depending on the responding machine type. > > > > > > > > Brad > > > > > > > > > > > > > -----Original Message----- > > > > > From: m5-dev-boun...@m5sim.org [mailto:m5-dev- > > > boun...@m5sim.org] On > > > > > Behalf Of Korey Sewell > > > > > Sent: Wednesday, April 20, 2011 7:20 PM > > > > > To: M5 Developer List > > > > > Subject: Re: [m5-dev] Defining Miss Latencies in Ruby > > > > > > > > > > (comments inline) > > > > > > > > > > > I'm confused. The miss_latency calculated by the sequencer is > the > > > > > miss > > > > > > latency of the particular request, not just L1 cache hits. > > > > > > > > > > > I think I understand that, but even if it's just L1 hits, let's say > > > > > that the > > > > > L1 latency is 1 and you are running a workload with a high hit rate > > > > > in the L1s. Then doesnt the code then continuously record that L1 > > > > > hit in the 1st histogram bucket? This would definitely be the case > > > > > for L1 latencies of the more than 1, since it's hardcoded to record > > > > > everything of a latency > 0 (basically all requests), right? > > > > > > > > > > > > > > > > > > > > > > If you're seeing a bunch of minimum latency requests, I suspect > > > > > something > > > > > > else is wrong. > > > > > > > > > > For instance, is "issued_time" a cycle value or a tick value? > > > > > > > > > > > The issued_time is the cycles, as it is set in the makeRequest(), > > > > > Sequencer function when a new Request is built. > > > > > -- > > > > > - Korey > > > > > _______________________________________________ > > > > > m5-dev mailing list > > > > > m5-dev@m5sim.org > > > > > http://m5sim.org/mailman/listinfo/m5-dev > > > > > > > > > > > > _______________________________________________ > > > > m5-dev mailing list > > > > m5-dev@m5sim.org > > > > http://m5sim.org/mailman/listinfo/m5-dev > > > > > > > > > > > > > > > > -- > > > - Korey > > > _______________________________________________ > > > m5-dev mailing list > > > m5-dev@m5sim.org > > > http://m5sim.org/mailman/listinfo/m5-dev > > > > > > _______________________________________________ > > m5-dev mailing list > > m5-dev@m5sim.org > > http://m5sim.org/mailman/listinfo/m5-dev > > > > > > -- > - Korey > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
