On the Impact of Interference from Concurrent Jobson Checkpointing Performance [Dataset]

In this repository, we present the main artifacts generated in the work entitled "On the Impact of Interference from Concurrent Jobs on Checkpointing Performance". This paper investigates how checkpoint operations are impacted by the characteristics of concurrent applications in terms of I/O. Specifically, we explored aspects such as scale, number of processes, operation type, number of files, and more. We conducted a large experimental campaign on two systems with different parallel file systems (BeeGFS and Lustre). Among our main findings, we show that the scale (i.e., number of computing nodes) and the file access strategy (sequential or random) of the interference code are the most important predictors of checkpoint performance. Moreover, our results demonstrate that sharing the I/O infrastructure with an application that issues random requests can degrade the global I/O performance of the system. The artifacts, publicly available, are organized into two categories: Datasets, comprising all the data generated throughout our study Produced Code, including the code used to generate the Random Forest model (presented in Section~V of the paper), as well as a series of scripts to process the data, collect the results, and generate plots The datasets were produced by defining an execution protocol where two applications, one representing a checkpointing application and the other an interference application, were executed concurrently (for more details see Section III in the paper). To emulate these applications, we used the IOR benchmark (version 4.1.0). Each IOR execution generates an output file containing information about the execution parameters and I/O performance metrics, such as the average I/O bandwidth and the number of I/O operations per second (IOPS). We organized all these metrics, along with their parameters, into CSV files, each representing an execution scenario. In total, four scenarios were considered per platform (PlaFRIM and Eulab). The files are organized into subdirectories as follows: dataset/ plafrim/ <scenario1>.csv <scenario2>.csv ... eulab/ <scenario1>.csv <scenario2>.csv ... In the CSV file, each test case is identified by the field jobid, which represents a complete execution involving the two applications, along with their repetitions. Both applications are executed concurrently and perform a series of I/O iterations. Thus, the same jobid in the CSV encompasses all repetitions and iterations for both applications, and each row corresponds to one specific application iteration, including its associated execution parameters and performance metrics. The produced code}artifacts are organized into two main folders: toolbox, which contains Python classes for processing, validating, and plotting the data, and ior_scripts, which contains the code used to generate the test cases. In addition, all our data analyses were conducted using Jupyter notebooks, provided in the root folder of the project. More details on how to reproduce the tests on other platforms can be found at https://gitlab.inria.fr/hpc_io/interference_benchmark