[Disksim-users] Serious problems using dixtrac extracted parameters

[Anjo Vahldiek]

Hi,

In general it is difficult to reason about differences without knowing 
how you issued the requests to disks (e.g. O_direct, by SCSI cmd, 
flushing caches, ...) and which exact models you used.

My suggest is that you look at the validation step of dixtrac. At the 
end of dixtrac it runs a validation workload and produces 4 pdfs 
showing the difference between simulated & real device. (called 
mixed(.hist).pdf and random(.hist).pdf which are part of the tar) 
Especially the mixed workload in case of 146g shows a significant 
difference. The 300g model shows less differences.  (not sure which of 
the two you used) You should be able to use the code part to prodcude 
the same pdfs using your disks instead of ours.

Hopefully this helps.

Thanks,
Anjo

On Mon 17 Jun 2013 09:39:58 AM CEST, Mujtaba Tarihi wrote:
> Dear all,
>
> I have been attempting to make use of some parameters extracted via
> dixtrac, such as the ones graciously provided by Anjo Vahldiek.
> However, I have come across very surprising results, performance-wise.
> I generated a random trace of aligned 16KB read requests and a
> sequential trace of 16KB back-to-back read requests.
> This is how long it took to run each trace (it is in milliseconds)
> For the record, are the results obtained with the 2GB HP C2490A which
> is supplied along with Disksim:
> Random: 2232995.378781
> Sequential: 624599.551791
>
> To make the comparison (somewhat) fair, I had to use the same random
> trace for the larger drives:
>
> And these are the results obtained with the 300GB Maxtor drive:
> Random: 237932.073905
> Sequential: 619900.348468
>
> And these are the results obtained with the 146GB Maxtor drive:
> Random: 345077.024293
> Sequential: 329766.817393
>
> And these results are from the 146GB Seagate drive:
> Random: 209403.240946
> Sequential: 423689.049873
>
> Basically, with the exception of *slight* difference in case of the
> 146GB maxtor file, the sequential trace takes longer to run, nearly
> 2.5x times in the worst case!
>
> I just copied the files in the tar.gz files and used them and
> layout.mappings is not necessary.
>
> My guess is that the model generated by the tool has issues with the
> modelling firmware behavior, something like the scheduling algorithm,
> or maybe it is botching up the mappings?
>
> Any help with be more than welcome :)
>
> Regards,
> -Tarihi
> _______________________________________________
> Disksim-users mailing list
> Disksim-users at ece.cmu.edu
> https://sos.ece.cmu.edu/mailman/listinfo/disksim-users