> On May 30, 2014, 9:19 a.m., Ahmad Hassan wrote: > > Hi Andreas, > > > > According to the literature, both tCL and tWR should be independent of the > > memory technology because they are buffer constraint timings and they > > reduce the bandwidth (Source: http://dl.acm.org/citation.cfm?id=1555758). > > So tCL and tWR should not be used for distinguishing between read or write > > operation access latency. > > > > Instead, the correct parameters to model read and write access delays in > > DRAM are tRCD and tRP respectively (Source: > > http://dl.acm.org/citation.cfm?id=1555758). But in the current SimpleDRAM > > DDR3 model of GEM5, I changed the following parameters to represent PCM > > read and write latency but I see almost no difference on the CPI. > > > > 1) Increased the tRCD from 13.75ns to '61ns' (PCM is 4.4 times slower than > > dram for read operation) > > 2) Increased tRP from 13.75 to '165ns' (PCM is 12x times slower than dram > > for write operation) > > > > As I see no impact on CPI, does this mean these parameters are not modeled > > correctly in GEM5? However, if I change these parameters in DRAMSim2, then > > I see the difference in average access latency. > > > > Thanks > > Andreas Hansson wrote: > Hi Ahmad, > > This is probably better suited for the mailing list. > > I agree with tCL, but when it comes to tWR I disagree with the statement > that it is technology independent. > > That aside, as you point out, tRCD and tRP are likely to change. I am > rather surprised that you see no impact in your experiments. Are you using a > recent version of the model (it is not called SimpleDRAM any longer). Also, > are you running in timing mode (sorry if this is a stupid question, but I > have to check). Finally, are you suggesting you see no difference in the > average latency with these changes? > > Andreas Hansson wrote: > I ran a quick latency sweep and there is a tremendous change (as you > would expect). I am not sure what is going wrong in your experiments, and I > would suggest to start a thread on the mailing list if you don't manage to > work it out. > > Perhaps we should just close this patch? Sophiane, could you sort that > out? > > Ahmad Hassan wrote: > Hi Andreas, > > I am using changeset 9975:6d17ec8df4c7. It seems to have new DDR3 model. > What benchmark are you using to validate the increase in CPI? Can I try that > benchmark to validate my configuration please? > > Thanks. > > > Andreas Hansson wrote: > Hi Ahmad, > > I would suggest to pop your patches and update to a more recent revision > as a lot of changes have been made to the DRAM controller recently. > > I am using a simple synthetic test with a TrafficGen that sweeps the > requested bandwidth (10% to 100% of the offered DRAM bandwidth), and the > sequential stride size (64 bytes to the page size), and then looking at the > read latency distribution using a CommMonitor. I'll see if I can somehow make > the script available. > > > > Ahmad Hassan wrote: > ok Thanks. I will try the latest upstream and modify tRCD and tRP to see > an impact on CPI. How can I plot the read/write latency distribution using > commonitor please? Shall I put commoniter between Last level cache and memory > controller? Then how can I get the latency distribution plot? > > Ahmad Hassan wrote: > Hi Andreas, > > I have tried the latest gem5 trunk revision 10230. But the results are > not so representative. I have set MyDDR3 configuration tRCD = '61ns', tRP = > '165ns' and tRAS = '83ns' > > For a benchmark that generates 550036 read and 50016 write dram > accesses, the avgMemAccLat for above dram configuration only increases by a > factor of 1.24x of default DDR3. > > For default DDR3: > avgMemAccLat 22133.24 > totMemAccLat 12166996811 > > For MyDDR3 > avgMemAccLat 27473.08 > totMemAccLat 15104591550 > > Shouldn't this avgMemAccLat for MyDDR3 be a lot higher? > >
Hi Ahmad, I would still suggest we move this to the gem5-users mailing list for any follow ups. Just in case :-). The impact on the average latency depends a lot on the bank distribution and how many page hits you have. If you look at the "bytesPerActive" I would imagine you have got pretty good locality in your accesses. I will see if I can make my "sweep" script available, as it plots the latency as a 3D plot with the X axis being the number of banks and the Y axis the bytes per active. The resulting surface very clearly shows the impact of the changed timings. - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2109/#review5110 ----------------------------------------------------------- On Dec. 6, 2013, 11:09 a.m., Sophiane SENNI wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2109/ > ----------------------------------------------------------- > > (Updated Dec. 6, 2013, 11:09 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > This patch allows specifying different SimpleDRAM latency for read and write > access. (In the code, tCL parameter if for read latency and tCL_write is for > write latency). > > Any feedback is welcomed^^ > > > Diffs > ----- > > src/mem/SimpleDRAM.py 5e8970397ab7 > src/mem/simple_dram.hh 5e8970397ab7 > src/mem/simple_dram.cc 5e8970397ab7 > > Diff: http://reviews.gem5.org/r/2109/diff/ > > > Testing > ------- > > > Thanks, > > Sophiane SENNI > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
