Anything I can do to get it to run on linux? I have more/better linux assets than windows.

We are working on a wine version for linux.

Announcing: Srbsieve_mthd version 2.1.

The biggest updates are changes to how the k's are handed out to workers, more flexible data entry, and headings on the main menu pages.

Enhancements:

1. Will send 5% more k's to worker 1, 2% more k's to worker 2, with the remainder of the k's divided equally among the remaining workers when mink < 100,000. The k's remaining must be > 5X workers. If mink >= 100,000 or k's remaining <= 5X workers, the # of k's will be divided equally among all workers. The problem with workers 1 & 2 often finishing long before the others mostly only exists for workers with very small k's. This should equalize work better.

2. In the final srbsieve.log in the Step 1 and Output folders, it will print a completion date/time for each phase that is the latest time that a worker completed the phase in a manner that is similar to the fbncsieve steps. This gives a better of idea of how long each phase took for the slowest worker allowing for better future job time estimates.

3. Added more flexible data entry on the screens. If you've chosen an option and not yet entered something, just hit cancel or Ctrl-C and it will return to the menu.

*******

Changes to defaults and values allowed:

1. Changed default maxKsrsieve2 to 200000, phases to [100, 250, 500, 1000], and workers to 4.

2. Changed the minimum workers allowed from 1 to 2. If only one worker is desired, srbsieve.exe should be run standalone.

3. Check if maxk > mink before beginning process. Previously this was not checked and it attempted to execute srbsieve.exe causing a program failure.

4. Check that phases are all >= 10 and differ by 2 from one another. Previously it only looked for unique positive integers. The smallest phase cannot be <= the maximum n for fbncsieve and srsieve2 cannot handle n-values closer together when sieving.

*******

Cosmetics:

1. Added a menu title at the top of each screen.

2. On the first two menu options (Switch to XXXXX) of all 3 menus, removed the default suffix labels of (new) or (resume) or (extend). These were not applicable for what the menu options are for.

3. Changed the help menu option from '?' to 'h' for ease of use.

4. Added the program and version number at the bottom of each of the 3 help menus.

5. On the help screens at the end of some descriptions, removed the incorrect suffix of "NONE".

*******

Error checking fixes: The program previously failed in the following situations. They are now handled as noted.

1. If the Update Programs option is chosen on the Resume or Extend menus and the Step 1 folder is missing, an error message is displayed.

2. If option 0 is chosen on the Resume screen, run_config.json exists, and pl_remain.txt in the Step 1 folder (or the folder itself) is missing, an error message is displayed.

3. If Ctrl-C is hit anytime while running step 1 including the fbncsieve steps, an error message is displayed.

4. If Ctrl-C is hit on any of the menus where it is asking for an Option, it will cleanly exit the program.

5. If Ctrl-C is hit after a menu option is chosen, it will return to the menu.

srbsieve_mthd version 2.1.1. There are 3 changes that impact very few situations...

1. Write a concatenation of any pl_unknown files from the Worker folders as a single file to the Output folder. This was requested by Reb and was needed to better isolate problems with PRP's that could not be definitely proven as prime or composite. Both pl_missing and pl_unknown files will now be in the Output folder if the problem happens.

2. Allow the script to run with 1 Worker. With version 2.1, I had changed this to a minimum of 2 but decided to revert it back to 1 for two reasons:
(a) Oftentimes during testing, running only 1 Worker is easier.
(b) When populating the New Bases screen with an initial run_config.json file, this value was not checked so it was possible to override the minimum and choose 1.

3. Because of the possibility of overriding the minimum of 2 Workers from #2 (an override that I had not been aware of), there was a bug from version 2.1 only when 1 Worker was chosen from the .json file. This came about as a result of the changes to better distribute the k's across the workers that caused it to not send all k's to Worker 1 it there was only 1 Worker. That has now been fixed.

#1 is a rare situation that seems to have come up when k's are very large (k=~1e9) on bigger bases. As of yet, it hasn't seemed to have impacted the huge k's on base 7.

#3 previously only came up if you chose 1 worker from the .json file (now can be chosen from the New Bases screen). Hopefully people would normally not be running with 1 worker (except during testing) when running a multi-thread script. srbsieve.exe can be run standalone for one thread.

new bugfixes...

I have posted srbsieve version 1.9.1 and srbverify version 1.8.4 in the first post of this thread. Please download them at your convenience.

These updates fix a problem when the k-range is > 2^32 (4,294,967,296). This does not impact large k-values, only large k-ranges. When one or more of the categories of k's remaining is > 2^32, they were not displayed properly in srbsieve.log when running srbsieve or in the output from srbverify. The values would be off by 2^32.

The fix expanded some variables and print displays from 32-bits to 64-bits. A recent example is the k=10G range for Riesel base 7 k=21G-31G. In both the srbsieve.log file and the srbverify output, it showed the "Odd k and base" category with 705,032,704 k's removed. It should have been 5 billion (half of the k-range), a difference of 2^32. Also in srbsieve.log, the k's remaining at the end of the preliminary steps also printed incorrectly.

Fortunately this is only a display/print problem. Recently run k-ranges of 10G and 20G do not have their important files impacted. Only the displayed/printed counts are/were wrong.

If you are running the multi-thread script but not currently running a job, you should replace the srbsieve.exe and srbverify.exe files in your Base and Step 1 folders, if applicable.

If you are in the middle of running a job either with or without the multi-thread script, the following would apply:
1. If your k-range is < than the above, wait until your job is done before updating anything.
2. If your k-range is > than the above, replace srbverify.exe in your Base and Step 1 folders (or where applicable if not running the script) right away. Wait until your job is done to update srbsieve.exe. Your srbsieve.log file will be incorrect but that will be expected. Srbverify should run correctly at the end.

Notice: Trying to get property of non-object in /home/boincadm/projects/sr5/html/user/forum_thread.php on line 56
Unable to handle request
Bad thread ID

Looks like link to reservation page is broken?