I’m reading sector-aligned chunks from a file using ReadFileEx (opened with CreateFile and the FILE_FLAG_NO_BUFFERING flag), recording a start time before the call, and an end time in the completion routine (times from QueryPerformanceCounter).
The size of my chunk reads is constant, regardless of the size of the overall file. Chunk offsets are queued sequentially, so ReadFileEx is always reading a point further in the file than the last one. I’m noticing some strange behaviour, such that a smaller file records a significantly quicker chunk read time than a larger file.
In this case, the size of the larger file is double that of the smaller one – I shouldn’t expect this to matter at the raw data reading level, as I’m reading the same size chunks regardless. What I’m seeing is the smaller file reporting 160mb/s read, and the larger file reporting 110mb/s.
I am still working on the assumption that it’s something else in my code causing the problem. I also expect the read operations to begin at some operating system defined point after ReadFileEx + GetLastError returns ERROR_IO_PENDING.
edit: My timing inaccuracy has been further confirmed by tweaking my read thread so it has more time to wait in an alertable state for the completionHandler notifications. This increased the reported read speed, indicating that part of my problem is that the completion handler does not get called immediately after the read is completed (and so my end time is later than it should be). However, doing this increased the reported speed proportionally for both the larger and smaller file.
TL;DR My question is, can I measure the actual time of the read operation, and not the time between calling ReadFileEx (which may not start the read straight away) and the completion routine?
Probably not from user-mode code.
There are too many variables outside your control. You don’t know what seeking may be required (e.g., one file may be fragmented, the other may not). The file map (file segments to disk blocks) may or may not already be cached. Even without read buffers, there’s still clustering, on-drive seek reordering, on-drive caching, etc. With asynchronous operations, you also have the scheduler coming into play.
With a driver, you could do some precise measurements, but you’d still need to run a lot of experiments and compute averages to get a statistical result that factors out all the strange things that happen inside the drive (retries, reordering, using spares, on-board caching, zone-bit recording, thermal recalibration, etc.).