\subsection{Disk Access}
The data filtering pipeline starts with obtaining data from disk to buffer such that calculations can be performed on them. This is the slowest segment of the pipeline, which makes each disk access very costly. The disk bandwidth is typically about 70 MB per second. Comparing this to the memory bandwidth of the buffer which is typically 35 GB per second, each disk access is about 500 times slower. And when considering the vast amount of data one would expect from a seismic processing application then disk access should be done efficiently. 

Looking at the results after having used blocking across the z axes I/O time resulted in being between 1-2 \% in the case of a single core, and has the trend of being less significant as the data set grows. This means that the I/O time even through slow is still less time consuming than performing the convolution operations. This is good because it means that one can focus on optimizing computations. 

\subsection{Blocking}
The reason for such a time efficient disk access is the type of blocking performed. This is also seen in the results. When the disk is forced to perform jumps before each read or write the performance of the I/O is decreased significantly, As seen when blocking across the the x dimension of the data set. The requirement for jumps is typically evident in large multiple dimensional data sets that need to be blocked. Given the data-structure of the seismic data by reading along the z axes one would not need to jump on the disk, but rather read a whole block of data at a time, which has several positive aspects. The first is that one only needs to access the disk once for each read to buffer. The second all the data is aligned as it should be when filtered, making it faster to transfer along the bus and easier to convolute. Thirdly, it is faster to transfer because when transferring a large data set of aligned data one will use the full capability of both the bandwidth of the disk and capabilities of the bus.

Blocking across the z axes makes it easier to fill in borders, because in this way only two border need to be filled such that the necessary data is present. This is because one only has two neighboring blocks along the z dimension, and not in the other dimensions, that need to exchange data. This is of course possible until a certain size of data. Because sooner or later there will not be enough memory to fit all the data in all three dimensions at a time and therefore one would have to block along another dimension. This can also be the case if one has uneven dimensions on the cube. The rule of thumb here is to read as much aligned data from disk as possible. Given the data-structure of the seismic data one should try blocking across the z dimension first if this is not possible then a combination of blocking across the y and z dimension. Then for really large sets, for example several tera bytes of data, one could perform blocking across all three dimensions. 

\subsection{Effects of Operating System on I/O}
Some unexpected results showed up when the first tests of I/O where performed. To begin with the tested I/O time was high and as the testing contimued it got shorter and shorter for each test. When testing a sample of ten tests is taken and a median is returned as the final result. The fact that the tests got shorter gave unreasonable results. The main reason for this is that the operating system has a way of buffering its reads and writes such that it can hide disk time from the user. This can be a useful feature if one is working on a similar set and reading it several times, but for this project a standardized disk access time has to be established such that a comparison between the distribution of computation and I/O time can be established. The feature of buffered I/O is of course useful, but is undetermenistic depending on if the data read is in buffer or not. It might give an average of better reads and writes, but is harder to establish a correct estimate therefore it is not used further in the project. In a real life situation it is recommended to have this option turned on. 

\subsection{Why Use The Chessboard Pattern as A Data Set?}
The correlation between seismic data and the chessboard pattern used are. Since in this project a Gaussian filter is implemented it is easier to see the effects and test its results on data with sharp edges in all three dimensions. This is accomplished with the use of the chessboard pattern. The way in which the data is stored including the header of the file in which they are stored is a replica of the seismic data example given by Schlumberger. This means that the application can easily use seismic data instead of the chessboard pattern such that it is compatible with the data structure standards of Schlumberger. Since the result file also shares these standards it can also be used to run a second iteration for more blur effect.
  