The variability in node counts stem from the search pattern the client uses. During the stub evaluation process, the client will discover that certain portions of the stub do not need to be evaluated and will correspondingly skip over the rest of that portion. Due to this behavior, it is very difficult to provide a linearly progressing percentage bar.

Note also that the percent bar will go much faster the further you get through the stub. Generally, the first 10% may appear to take the longest amount of time.

Do not be alarmed if stubs take many hours to complete. It is not a measure of hardness, but of allocation unit size. Keep in mind that other mathematical contests such as Mersenne Primes can take several weeks to process a single allocation unit. The extremely small block size of previous RC5 contests has "spoiled" the expectations of many of us into thinking that all work units should be completed in the same amount of time, and in only a few minutes/hours. Stubs that take longer to process will also have an equivalent increase in the number of nodes credited in stats.

Clients will automatically save their progress in a stub and restart where they left off if they are naturally stopped and started. If you are concerned about losing progress, you can also enabling the check pointing option in the client to save the processing state regularly for future resumption if interrupted.

In general, stubs that have a larger numbered marks in them are "easier" than those with purely smaller numbered marks. Additionally, the node count of a stub will generally vary quite predictably with the values of the first two marks of the stub. There are also similar graphs for the old OGR-21 effort at http://www.hewgill.com/golomb/