{'fraction_non_alphanumeric': 0.019041365725541694, 'fraction_numerical': 0.0013131976362442547, 'mean_word_length': 5.245901639344262, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Reducing the Checkpointing Burden of Condor : Analysis and Implementation Computer Sciences

The original idea to investigate Condor checkpointing came from Jim Basney, and Doug Thain and Rajesh Raman answered many of our questions. Finally, we thank Remzi Arpaci-Dusseau for his guidance and criticism of our work. Figure 1: Most users' programs are consistent in the percentage of their data segment pages that they update. Figure 2: Percentage of clean pages by user. Note that this is highly user dependent because different users run different kinds of jobs. Also note that these are generally higher than synthetic benchmark figures generated Condor is a distributed system that harnesses the power of users' unused workstations to deliver large amounts of computing to CPU intensive projects. Because users can and do claim their machines at unforeseeable times, Condor checkpoints programs' state periodically and migrates interrupted jobs to new host machines. Additionally, Condor checkpoints a job when it detects user activity at the terminal; this is called a vacate checkpoint. As enrollment in a Condor pool is usually voluntary, the Condor system must strive to minimize user disruptions. In particular, this necessitates finding a balance between shipping as little data across the network as possible (to avoid saturating it), while vacating computers as quickly as possible. Our research represents an attempt to make Condor more user-friendly by improving vacate speeds while reducing network bandwidth.