Submission latency is interesting as a talking point and something we might want to discuss with DPACC as there may be kernel tuning that can improve the performance of submission. We are not showing this in the report at this time

Basic report will be read/write IOPS and average latency only

Overall need to decide how wide to go:

Determine total storage available to Cinder and divide that up with an algorithm? Autodetect might to

Probably better to have master API define how many VMs to use and how large each Cinder volume should be

Would like to get a programmatic way to show the latency wall: keep going wider on VMs hitting Cinder until latency climbs beyond 30 ms. This would be considered the practical maximum number of IOPS the Cinder back end supports.