[Disksim-users] Disksim-users Digest, Vol 65, Issue 7

Tue Mar 22 20:41:59 EDT 2011

about  Error #1 (segment fault), check if logic address range of your trace
is out of that your device can take.

2011/3/23 <disksim-users-request at ece.cmu.edu>

> Send Disksim-users mailing list submissions to
>        disksim-users at ece.cmu.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://sos.ece.cmu.edu/mailman/listinfo/disksim-users
> or, via email, send a message with subject or body 'help' to
>        disksim-users-request at ece.cmu.edu
>
> You can reach the person managing the list at
>        disksim-users-owner at ece.cmu.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Disksim-users digest..."
>
>
> Today's Topics:
>
>   1. DiskSim 3.0/FlashSim Simulation problems (Jonathan Tjioe)
>   2. Re: DiskSim 3.0/FlashSim Simulation problems (Alexander Lochmann)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 21 Mar 2011 19:05:06 -0700
> From: Jonathan Tjioe <jontjioe at gmail.com>
> Subject: [Disksim-users] DiskSim 3.0/FlashSim Simulation problems
> To: disksim-users at ece.cmu.edu
> Message-ID:
>        <AANLkTinL=EwtdsFQ0_xaFquuf02J7mZGzYHf6JG2kASJ at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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
> 2) Simulation is stopped because of saturation
> 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://sos.ece.cmu.edu/pipermail/disksim-users/attachments/20110321/e86aff31/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Tue, 22 Mar 2011 09:09:49 +0100
> From: Alexander Lochmann <alexander.lochmann at tu-dortmund.de>
> Subject: Re: [Disksim-users] DiskSim 3.0/FlashSim Simulation problems
> To: Jonathan Tjioe <jontjioe at gmail.com>
> Cc: disksim-users at ece.cmu.edu
> Message-ID: <4D88594D.2050007 at tu-dortmund.de>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
> 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://sos.ece.cmu.edu/pipermail/disksim-users/attachments/20110322/0f5c6347/attachment-0001.html
> >
>
> ------------------------------
>
> _______________________________________________
> Disksim-users mailing list
> Disksim-users at ece.cmu.edu
> https://sos.ece.cmu.edu/mailman/listinfo/disksim-users
>
>
> End of Disksim-users Digest, Vol 65, Issue 7
> ********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/disksim-users/attachments/20110323/6e782ba5/attachment.html>