[Disksim-users] DiskSim 3.0/FlashSim Simulation problems

[Alexander Lochmann]

Hi!

Am 22.03.2011 03:05, schrieb Jonathan Tjioe:
> DiskSim users,
>
> First, let me apologize for making this email so long. I wanted it to 
> be thorough so my problem is explained clearly.
>
> I'm running DiskSim 3.0 with FlashSim (same as the FlashSim in the 
> DFTL paper). It's basically DiskSim 3.0 with support for SSD.
>
> I've been running the "runtest" script which basically runs a small 
> sample test file through all 3 FTLs: Page mapped, DFTL, and FAST. The 
> test trace that was included is very small (8-9MB) and I get the 
> intended results as the authors of the DFTL paper did.
>
> All the runtest script does is run the same trace file on these 3 FTLs:
> ../src/disksim pagemap.parv pagemap.outv ascii ./trace/test.file 0
> ../src/disksim dftl.parv dftl.outv ascii ./trace/test.file 0
> ../src/disksim fast.parv fast.outv ascii ./trace/test.file 0
>
>
> Upon successful completion of the simulation, I noticed that in the 
> .outv files, I will see:
> <<
> ...
> loadparams complete
> Initialization complete
> Simulation complete
> ...
> >>
>
> After this, I will see many performance statistics along with every 
> request. I get the appropriate results when simulating DFTL, FAST, and 
> pure page mapped FTL.
>
> However, once I tried putting any other real world trace (which is 
> much longer) in the simulation, it does not complete successfully. It 
> should be noted that I have not made any modifications to any of the 3 
> FTLs during these tests. I have verified that my format of the trace 
> files is correct:
> <arrival time> <devicenum> <LBA> <size in # of sectors> <1 or 0 for 
> read or write>
>
> There are 3 different results that I get, all of which are 
> unsuccessful simulations:
> 1) Segmentation fault
Could give us some more information?
Have you tried to run it with gdb und typed "bt"?
> 2) Simulation is stopped because of saturation
Maybe your harddisk model is too slow to serve the requests within a 
appropriate amount of time so the requestqueue doesn't get saturated.
In a real system you've got a operating system which keeps track of this 
issue. Linux for example, slows down every readahead and writeback 
activity to reduce the number of requests if it detects congestion 
conditions. It has a requestqueue which is on top of the driver holding 
every request.
Have you tried to slow down the request-ratio?

Greetings
Alex

> 3) Simulation seems like it finished, but when you check the .outv 
> files, the last line says "initialization complete" (in otherwords it 
> does not ever say "simulation complete"
>
> One example (Error #1) is when I run the entire finanical trace in, I 
> get a segmentation fault simulating DFTL. Although I didn't get 
> segmentation faults for FAST or pure page mapped, their corresponding 
> .outv files do not look correct. They seem like they never finished 
> simulating. In the .outv files for all 3 FTLs, it shows:
>
> <<
> ...
> loadparams complete
> Initialization complete
> >>
>
> But it never shows "simulation complete" and thus the results are not 
> shown in the .outv file. The weird thing is that if I just include 
> maybe several hundred lines of the Financial1 trace instead of the 
> entire thing, it completes successfully with no problem, so I know my 
> format of the file is correct.
>
> Another example (Error #2) I noticed that I the Financial2 trace did 
> not have any segmentation faults but instead I had a different message:
> <<
> Stopping simulation because of saturation: simtime 108.435867, 
> totalreqs 10394
> >>
>
> I did some research and found that there is a define statement in 
> disksim_logorg.c that sets the MAX_QUEUE_LENGTH to be 10000. In each 
> of the instances when the simulation stopped due to saturation, the 
> totalreqs number was just over 10000. I imagine the queue length is 
> getting very large due to the fact that I only have a device num of 0 
> since my GC algorithm will be a local GC algorithm, not a inter-disk 
> algorithm.
>
> And lastly, if (Error #1) or (Error #2) occur, the simulation will 
> never complete and no simulation summary will be in the .outv file 
> (which is Error #3).
>
> My questions are as follows:
> Regarding (Error #1), I have no idea why I am getting segmentation 
> faults. Do you think it is some type of buffer overflow issue b/c 
> there is so much data with the real world traces? Remember, that if I 
> just take a smaller subset of the real world data, it simulates to 
> completion without any problem.
>
> Regarding (Error #2), I can try just increasing the MAX_QUEUE_LENGTH 
> to maybe 100000 and see what happens, but is that the right solution 
> or is there something else that I need to be aware of.
>
> Regarding (Error #3), I would assume that this will be solved once I 
> find the solutions to (Error #1) and (Error #2).
>
> I really appreciate any help or hints you can offer. I will also post 
> this to the disksims mailing list.
>
> Thanks for your valuable time,
> Jonathan Tjioe
>
>
> _______________________________________________
> Disksim-users mailing list
> Disksim-users at ece.cmu.edu
> https://sos.ece.cmu.edu/mailman/listinfo/disksim-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/disksim-users/attachments/20110322/0f5c6347/attachment.html>