cfwritegettimeofday

Bandwidth readings increase while writing large file


We've been measuring the bandwidth of two external HDDs in class using gettimeofday.

Surprisingly enough, and after several repeats (three measurements per execution, executed three times), we found that writing a 2500MB file was faster than writing a smaller one on both HDDs.

Bandwidth chart

This is our C code. It is called from a python script to generate some charts.

//argv[1] = path, argv[2] = size in MB (2500 in this case)

#include <stdio.h>
#include <sys/time.h>
#include <time.h>
#include <unistd.h>
#include <fcntl.h>


struct timeval tv0;
struct timeval tv1;

int main(int argc, char *argv[]){
    unsigned long size=atoi(argv[2])*1000L*1000L;
    int f = open(argv[1], O_CREAT|O_WRONLY|O_TRUNC, 0777);
    char * array = malloc(size);
    gettimeofday(&tv0, 0); //START TIME
    write(f, array, size);
    fdatasync(f);
    close(f);
    gettimeofday(&tv1, 0); // END TIME 
    double seconds = (((double)tv1.tv_sec*1000000.0 + (double)tv1.tv_usec) - ((double)tv0.tv_sec*1000000.0 + (double)tv0.tv_usec))/1000000.0;
    printf("%f",seconds);
}

The teacher didn't know, so I'm asking here: is there a reason why this might happen?


Solution

  • Your benchmark is severely flawed:

    Either of those could easily invalidate your benchmark results if your assumptions turn out not to be satisfied, and at least the second is fairly likely to turn out that way.

    Note in particular that write() returns the number of bytes written, as a ssize_t. ssize_t is a signed integer type whose specific width is system dependent. If yours is 32 bits in size, then write() cannot write all of a 2500MB buffer in a single call, because that's more bytes than a signed 32-bit integer can represent (the limit being a bit over 2100 MB).

    Additionally, your program assumes that it can successfully allocate very large blocks of memory, which may easily turn out not to be the case. If this assumption fails, though, you will probably be rewarded with a crash.