DRAMSim2 Trace Mode not using all transactions

[sfx1999]

I am having a small issue with DRAMSim2. It does not seem to be processing all transactions. I tried running my memory trace (converted) and the sample MASE trace as follows (I matched number of cycles to the maximum in the file):

./DRAMSim2/DRAMSim -s ./DRAMSim2/system.ini.example -d DRAMSim2/ini/DDR3_micron_64M_8B_x4_sg15.ini -t mase_art.trc -S 4096 -c 14712444 -v ./blah.out > blah

The histogram data comes out like so:

20=5187 30=43 40=20 50=18 60=8 70=15 80=12 90=14 100=14 110=10 120=12 130=10 150=1

There are 38374 lines in the original. It was worse in my trace; I had over 20,000,000 transactions but only around 35000 registered. What might be going on? There are no error messages in the output, but there are a lot of NaN values.

[dramninjasUMD]

One thing that might be happening is that if AddTransaction() fails due to a backup in the memory system, the transaction has to be stalled and so the number of cycles required to complete the simulation is much larger than the number of cycles that are specified in the trace file.

If you try doubling the number of cycles you run for, do the number of completed transactions in the histogram increase?

[dramninjasUMD]

Actually, I took a look at the code and I remembered what the issue was. The latency histogram only counts reads and not writes. I added a quick patch (here: https://gist.github.com/dramninjasUMD/7310314 ) that enables transaction tracking in tracebased sim and the results are as expected:

$ ./DRAMSim -s system.ini.example -d ini/DDR3_micron_64M_8B_x4_sg15.ini -t traces/mase_art.trc -S 4096 -c 30712444 -v blah.out > blah.txt
Transaction Receiver: Got back 5365 reads and 33009 writes; Still pending: 0 reads and 0 writes

[sfx1999]

I checked again with the patch. It does not process all transactions for the large file. I believe I have found the issue, though. Number of cycles is read into an unsigned integer using atoi, but the number I am entering is too large to be represented by that type. I will try to modify it to use an unsigned long long and report back.

[dramninjasUMD]

Ah, yes, I see. That optparse code is ancient; I thought I'd changed all the string->int conversions to stringstream ... Did this end up fixing the problem for you?

[sfx1999]

It seems to have fixed the problem. I had to change a loop counter as well. Unfortunately, I forgot to enable output while it was running to see if it was making progress and had to terminate. I will try again later.