<div><br></div><div>about Error #1 (segment fault), check if logic address range of your trace is out of that your device can take.</div><br><br><div class="gmail_quote">2011/3/23 <span dir="ltr"><<a href="mailto:disksim-users-request@ece.cmu.edu">disksim-users-request@ece.cmu.edu</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Send Disksim-users mailing list submissions to<br>
<a href="mailto:disksim-users@ece.cmu.edu">disksim-users@ece.cmu.edu</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://sos.ece.cmu.edu/mailman/listinfo/disksim-users" target="_blank">https://sos.ece.cmu.edu/mailman/listinfo/disksim-users</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:disksim-users-request@ece.cmu.edu">disksim-users-request@ece.cmu.edu</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:disksim-users-owner@ece.cmu.edu">disksim-users-owner@ece.cmu.edu</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Disksim-users digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. DiskSim 3.0/FlashSim Simulation problems (Jonathan Tjioe)<br>
2. Re: DiskSim 3.0/FlashSim Simulation problems (Alexander Lochmann)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Mon, 21 Mar 2011 19:05:06 -0700<br>
From: Jonathan Tjioe <<a href="mailto:jontjioe@gmail.com">jontjioe@gmail.com</a>><br>
Subject: [Disksim-users] DiskSim 3.0/FlashSim Simulation problems<br>
To: <a href="mailto:disksim-users@ece.cmu.edu">disksim-users@ece.cmu.edu</a><br>
Message-ID:<br>
<AANLkTinL=<a href="mailto:EwtdsFQ0_xaFquuf02J7mZGzYHf6JG2kASJ@mail.gmail.com">EwtdsFQ0_xaFquuf02J7mZGzYHf6JG2kASJ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
DiskSim users,<br>
<br>
First, let me apologize for making this email so long. I wanted it to be<br>
thorough so my problem is explained clearly.<br>
<br>
I'm running DiskSim 3.0 with FlashSim (same as the FlashSim in the DFTL<br>
paper). It's basically DiskSim 3.0 with support for SSD.<br>
<br>
I've been running the "runtest" script which basically runs a small sample<br>
test file through all 3 FTLs: Page mapped, DFTL, and FAST. The test trace<br>
that was included is very small (8-9MB) and I get the intended results as<br>
the authors of the DFTL paper did.<br>
<br>
All the runtest script does is run the same trace file on these 3 FTLs:<br>
../src/disksim pagemap.parv pagemap.outv ascii ./trace/test.file 0<br>
../src/disksim dftl.parv dftl.outv ascii ./trace/test.file 0<br>
../src/disksim fast.parv fast.outv ascii ./trace/test.file 0<br>
<br>
<br>
Upon successful completion of the simulation, I noticed that in the .outv<br>
files, I will see:<br>
<<<br>
...<br>
loadparams complete<br>
Initialization complete<br>
Simulation complete<br>
...<br>
>><br>
<br>
After this, I will see many performance statistics along with every request.<br>
I get the appropriate results when simulating DFTL, FAST, and pure page<br>
mapped FTL.<br>
<br>
However, once I tried putting any other real world trace (which is much<br>
longer) in the simulation, it does not complete successfully. It should be<br>
noted that I have not made any modifications to any of the 3 FTLs during<br>
these tests. I have verified that my format of the trace files is correct:<br>
<arrival time> <devicenum> <LBA> <size in # of sectors> <1 or 0 for read or<br>
write><br>
<br>
There are 3 different results that I get, all of which are unsuccessful<br>
simulations:<br>
1) Segmentation fault<br>
2) Simulation is stopped because of saturation<br>
3) Simulation seems like it finished, but when you check the .outv files,<br>
the last line says "initialization complete" (in otherwords it does not ever<br>
say "simulation complete"<br>
<br>
One example (Error #1) is when I run the entire finanical trace in, I get a<br>
segmentation fault simulating DFTL. Although I didn't get segmentation<br>
faults for FAST or pure page mapped, their corresponding .outv files do not<br>
look correct. They seem like they never finished simulating. In the .outv<br>
files for all 3 FTLs, it shows:<br>
<br>
<<<br>
...<br>
loadparams complete<br>
Initialization complete<br>
>><br>
<br>
But it never shows "simulation complete" and thus the results are not shown<br>
in the .outv file. The weird thing is that if I just include maybe several<br>
hundred lines of the Financial1 trace instead of the entire thing, it<br>
completes successfully with no problem, so I know my format of the file is<br>
correct.<br>
<br>
Another example (Error #2) I noticed that I the Financial2 trace did not<br>
have any segmentation faults but instead I had a different message:<br>
<<<br>
Stopping simulation because of saturation: simtime 108.435867, totalreqs<br>
10394<br>
>><br>
<br>
I did some research and found that there is a define statement in<br>
disksim_logorg.c that sets the MAX_QUEUE_LENGTH to be 10000. In each of the<br>
instances when the simulation stopped due to saturation, the totalreqs<br>
number was just over 10000. I imagine the queue length is getting very large<br>
due to the fact that I only have a device num of 0 since my GC algorithm<br>
will be a local GC algorithm, not a inter-disk algorithm.<br>
<br>
And lastly, if (Error #1) or (Error #2) occur, the simulation will never<br>
complete and no simulation summary will be in the .outv file (which is Error<br>
#3).<br>
<br>
My questions are as follows:<br>
Regarding (Error #1), I have no idea why I am getting segmentation faults.<br>
Do you think it is some type of buffer overflow issue b/c there is so much<br>
data with the real world traces? Remember, that if I just take a smaller<br>
subset of the real world data, it simulates to completion without any<br>
problem.<br>
<br>
Regarding (Error #2), I can try just increasing the MAX_QUEUE_LENGTH to<br>
maybe 100000 and see what happens, but is that the right solution or is<br>
there something else that I need to be aware of.<br>
<br>
Regarding (Error #3), I would assume that this will be solved once I find<br>
the solutions to (Error #1) and (Error #2).<br>
<br>
I really appreciate any help or hints you can offer. I will also post this<br>
to the disksims mailing list.<br>
<br>
Thanks for your valuable time,<br>
Jonathan Tjioe<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://sos.ece.cmu.edu/pipermail/disksim-users/attachments/20110321/e86aff31/attachment-0001.html" target="_blank">http://sos.ece.cmu.edu/pipermail/disksim-users/attachments/20110321/e86aff31/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Tue, 22 Mar 2011 09:09:49 +0100<br>
From: Alexander Lochmann <<a href="mailto:alexander.lochmann@tu-dortmund.de">alexander.lochmann@tu-dortmund.de</a>><br>
Subject: Re: [Disksim-users] DiskSim 3.0/FlashSim Simulation problems<br>
To: Jonathan Tjioe <<a href="mailto:jontjioe@gmail.com">jontjioe@gmail.com</a>><br>
Cc: <a href="mailto:disksim-users@ece.cmu.edu">disksim-users@ece.cmu.edu</a><br>
Message-ID: <<a href="mailto:4D88594D.2050007@tu-dortmund.de">4D88594D.2050007@tu-dortmund.de</a>><br>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"<br>
<br>
Hi!<br>
<br>
Am 22.03.2011 03:05, schrieb Jonathan Tjioe:<br>
> DiskSim users,<br>
><br>
> First, let me apologize for making this email so long. I wanted it to<br>
> be thorough so my problem is explained clearly.<br>
><br>
> I'm running DiskSim 3.0 with FlashSim (same as the FlashSim in the<br>
> DFTL paper). It's basically DiskSim 3.0 with support for SSD.<br>
><br>
> I've been running the "runtest" script which basically runs a small<br>
> sample test file through all 3 FTLs: Page mapped, DFTL, and FAST. The<br>
> test trace that was included is very small (8-9MB) and I get the<br>
> intended results as the authors of the DFTL paper did.<br>
><br>
> All the runtest script does is run the same trace file on these 3 FTLs:<br>
> ../src/disksim pagemap.parv pagemap.outv ascii ./trace/test.file 0<br>
> ../src/disksim dftl.parv dftl.outv ascii ./trace/test.file 0<br>
> ../src/disksim fast.parv fast.outv ascii ./trace/test.file 0<br>
><br>
><br>
> Upon successful completion of the simulation, I noticed that in the<br>
> .outv files, I will see:<br>
> <<<br>
> ...<br>
> loadparams complete<br>
> Initialization complete<br>
> Simulation complete<br>
> ...<br>
> >><br>
><br>
> After this, I will see many performance statistics along with every<br>
> request. I get the appropriate results when simulating DFTL, FAST, and<br>
> pure page mapped FTL.<br>
><br>
> However, once I tried putting any other real world trace (which is<br>
> much longer) in the simulation, it does not complete successfully. It<br>
> should be noted that I have not made any modifications to any of the 3<br>
> FTLs during these tests. I have verified that my format of the trace<br>
> files is correct:<br>
> <arrival time> <devicenum> <LBA> <size in # of sectors> <1 or 0 for<br>
> read or write><br>
><br>
> There are 3 different results that I get, all of which are<br>
> unsuccessful simulations:<br>
> 1) Segmentation fault<br>
Could give us some more information?<br>
Have you tried to run it with gdb und typed "bt"?<br>
> 2) Simulation is stopped because of saturation<br>
Maybe your harddisk model is too slow to serve the requests within a<br>
appropriate amount of time so the requestqueue doesn't get saturated.<br>
In a real system you've got a operating system which keeps track of this<br>
issue. Linux for example, slows down every readahead and writeback<br>
activity to reduce the number of requests if it detects congestion<br>
conditions. It has a requestqueue which is on top of the driver holding<br>
every request.<br>
Have you tried to slow down the request-ratio?<br>
<br>
Greetings<br>
Alex<br>
<br>
> 3) Simulation seems like it finished, but when you check the .outv<br>
> files, the last line says "initialization complete" (in otherwords it<br>
> does not ever say "simulation complete"<br>
><br>
> One example (Error #1) is when I run the entire finanical trace in, I<br>
> get a segmentation fault simulating DFTL. Although I didn't get<br>
> segmentation faults for FAST or pure page mapped, their corresponding<br>
> .outv files do not look correct. They seem like they never finished<br>
> simulating. In the .outv files for all 3 FTLs, it shows:<br>
><br>
> <<<br>
> ...<br>
> loadparams complete<br>
> Initialization complete<br>
> >><br>
><br>
> But it never shows "simulation complete" and thus the results are not<br>
> shown in the .outv file. The weird thing is that if I just include<br>
> maybe several hundred lines of the Financial1 trace instead of the<br>
> entire thing, it completes successfully with no problem, so I know my<br>
> format of the file is correct.<br>
><br>
> Another example (Error #2) I noticed that I the Financial2 trace did<br>
> not have any segmentation faults but instead I had a different message:<br>
> <<<br>
> Stopping simulation because of saturation: simtime 108.435867,<br>
> totalreqs 10394<br>
> >><br>
><br>
> I did some research and found that there is a define statement in<br>
> disksim_logorg.c that sets the MAX_QUEUE_LENGTH to be 10000. In each<br>
> of the instances when the simulation stopped due to saturation, the<br>
> totalreqs number was just over 10000. I imagine the queue length is<br>
> getting very large due to the fact that I only have a device num of 0<br>
> since my GC algorithm will be a local GC algorithm, not a inter-disk<br>
> algorithm.<br>
><br>
> And lastly, if (Error #1) or (Error #2) occur, the simulation will<br>
> never complete and no simulation summary will be in the .outv file<br>
> (which is Error #3).<br>
><br>
> My questions are as follows:<br>
> Regarding (Error #1), I have no idea why I am getting segmentation<br>
> faults. Do you think it is some type of buffer overflow issue b/c<br>
> there is so much data with the real world traces? Remember, that if I<br>
> just take a smaller subset of the real world data, it simulates to<br>
> completion without any problem.<br>
><br>
> Regarding (Error #2), I can try just increasing the MAX_QUEUE_LENGTH<br>
> to maybe 100000 and see what happens, but is that the right solution<br>
> or is there something else that I need to be aware of.<br>
><br>
> Regarding (Error #3), I would assume that this will be solved once I<br>
> find the solutions to (Error #1) and (Error #2).<br>
><br>
> I really appreciate any help or hints you can offer. I will also post<br>
> this to the disksims mailing list.<br>
><br>
> Thanks for your valuable time,<br>
> Jonathan Tjioe<br>
><br>
><br>
> _______________________________________________<br>
> Disksim-users mailing list<br>
> <a href="mailto:Disksim-users@ece.cmu.edu">Disksim-users@ece.cmu.edu</a><br>
> <a href="https://sos.ece.cmu.edu/mailman/listinfo/disksim-users" target="_blank">https://sos.ece.cmu.edu/mailman/listinfo/disksim-users</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://sos.ece.cmu.edu/pipermail/disksim-users/attachments/20110322/0f5c6347/attachment-0001.html" target="_blank">http://sos.ece.cmu.edu/pipermail/disksim-users/attachments/20110322/0f5c6347/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
Disksim-users mailing list<br>
<a href="mailto:Disksim-users@ece.cmu.edu">Disksim-users@ece.cmu.edu</a><br>
<a href="https://sos.ece.cmu.edu/mailman/listinfo/disksim-users" target="_blank">https://sos.ece.cmu.edu/mailman/listinfo/disksim-users</a><br>
<br>
<br>
End of Disksim-users Digest, Vol 65, Issue 7<br>
********************************************<br>
</blockquote></div><br>