(Answer) (Category) distributed.net Faq-O-Matic : (Category) Project: OGR (Optimal Golomb Rulers) : (Answer) Why do some stubs go faster than others? My stub OGR stub takes too long! My OGR stub has stopped progressing at 1 or 2%!
By their nature, OGR stubs vary greatly in the number of nodes that must be checked by your client. Therefore, some stubs may complete much more rapidly than others. Additionally, it may sometimes appear that no progress has been made on a stub, even after many minutes or even hours, when in reality progress has been made, but it is simply not expressable as a change in percentage. The slow performance of a portion of a stub should not be considered to represent the performance of the rest of the stub.

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/

Other popular answers from other categories:
(Xref) Packets take too long to complete on my computer. They should be smaller!
(Xref) Why did I receive a very large/small OGR-25 stub?
This document is: http://faq.distributed.net/?file=76
[Search] [Appearance] [Show Expert Edit Commands]
This is a Faq-O-Matic 2.721.test.

© Copyright distributed.net 1997-2013 - All rights reserved