Primenet Admin Guide to Parallel Testing
Updated 9/7/97

Primenet provides the following networked Prime95 Mersenne number test management features:

• internal time stamps to track when clients checked out test exponents and how long they were out
• online update merge for exponent database directly inputs from George's 4-byte distributed database files and creates or updates Primenet's server database while the server is running
• exponents can be manually and specifically:
  • put back into the database to be tested
  • marked in the database as test complete
  • checked out as assigned to a client
• enhanced consistency checking for exponent test assignments:
  • tested exponent is retained in database until next merged database shows the exponent is done and can be removed
  • cannot accidentally double checkout or check in exponent
• detailed server logging of events, including elapsed time of test results
• two-phase commit checkout of test exponents
• online generation of status reports for:
  • which exponents are currently checked out for testing
  • when they were checked out and how long ago in days
  • which exponents are test completed
  • counts of exponents checked out and test completed
• command line Primenet server management console application
• dll and server version verification
• separate overlapping exponent test ranges for factoring clients
• factoring client results check-ins update the database bits factored field
• results persistence between network failures and automatic recovery upon reconnection
• single configuration file for clients
• user ID/password authentication when connection to the Prime server
• separate Prime server administrator user ID/password
• multiple exponent assignment checkouts for dial-up clients (up to 10 at a time)
• timer threads to manage transactions, overdue assignments, network failure, etc.
• (2) automatic database consistency checks and repair
• (2) remote setting of LL and factoring test ranges and next test ranges
• (1) remote setting of user IDs and passwords

(1) New for Primenet 2.6 Build 9/4/97
(2) New for Primenet 2.6 Build 8/13/97

(Unofficial) Terms used in this section of the document:

• Checked out - exponent is assigned to a client Prime95 for testing
• Check-in - manually returning an exponent to the untested pool in the database
• Clear - marking an exponent as tested in the database by Prime95 or manually
• Merge - update online 8-byte format database with George's 4-byte format files

The Primenet Server Management Console Application

The Primecom.exe application remotely manages the Prime Server. The remote server reads and writes files only local to itself so generating a test status report assumes you can get to the server's files to retrieve it. The last line the Prime Server logs to PrimeSvc.log as a result of your command is echoed by Primecom. If you're a UNIX person, you'll love it.

The Primecom.exe and Primenet.dll files (or Prime95.exe and Primenet.dll) must be put together, though not necessarily in the same directory or machine as PrimeSvc.exe. Primecom.exe must first be configured the same way as a Prime95 client, including the client INI file entries, except it must use the Prime Server's admin user ID and password.

If the client Prime95.ini file is configured to connect to the Prime Server using its IP address, this client's IP address will appear between the date/time stamp and the userID columns in the PrimeSvc.log file.

Here are some examples of what you would see. Type:

primecom -?

(or without params) to see this menu:

Primenet Server Control Version 2.6 (Build 9/4/97)

-r reportfile	: generates status report to reportfile
-m inputdbfile	: merges inputdbfile into/creates online database
-i exponent	: force checkin to put test exponent back into queue
-c exponent	: clear exponent as test completed in database
-o exponent	: force checkout of test exponent from database
-t "r# low high"	: set range # to low and high
-p	: ping the remote Prime Server, return build version
-u userid^password	: set the given userid and password for access
-? (or sans params)	: this command summary

These commands and their uses are described in detail below.

Example Prime Server Log

The PrimeSvc.log file tells everything about what the Prime Server is doing and for whom. All of the results from all clients are embedded within it as well as other information about the server and database. It is one of the two primary means to managing your Primenet parallel test environment.

Here is an example set of log entries the primenet server generates followed by scenarios and commands that cause them (values are manufactured for the example):

(PrimeSvc.log:)

1997/04/17 01:30:24 [Admin] Manual check-in completed for 2813977
1997/04/17 01:31:04 [Admin] Manual check-out completed for p = 2813997, bits = 58
1997/04/17 01:32:55 [Admin] Check-in of 2813977 failed (not checked out)
1997/04/17 01:33:33 [Admin] Begin database merge with database.new
1997/04/17 01:33:45 (server) Merged - total: 94505, in progress: 3, removed: 49, retained: 1
1997/04/17 01:49:07 123.45.67.89 [UserID-usingIP] M2813977 is not prime WQ1a:00000000
1997/04/17 01:49:07 (server) Clear of 2813977 failed (not checked out)
1997/04/17 01:50:22 [FactoringClient] M2813969 has a factor 7687623421341
1997/04/17 01:50:22 (server) Clear completed for 2813969 ( 2.71 days)
1997/04/17 02:37:12 [FactoringClient] RpcGetNextExponent 2813983, 58 (factoring)
1997/04/17 02:37:12 [FactoringClient] Acknowleged receipt of 2813983
1997/04/17 05:12:01 [Dying] RpcGetNextExponent 2813987, 58
1997/04/17 05:12:03 (server) RpcAckExponent timeout: 2813987 available
1997/04/17 08:03:56 [FactoringClient] M2813983 no factor to 2^59, WQ1a: 186110E3 (factoring)
1997/04/17 08:03:56 (server) Factoring check-in completed for 2813983 at 59 bits ( 0.42 days)

 

Example Management Session Commands and Server Results

Setting Prime Server User IDs

You can remotely set Primenet user ID and password combinations, or change the password of an existing user.

For example, say you want to add a new user to the list of clients the Prime Server will recognize, called 'kermit' and kermit wanted the password 'the_frog'. Type:

primecom -u kermit^the_frog

The server responds in the log:

1997/09/4 09:30:24 [Admin] Set userid "kermit"

The password is not shown in the log, but at the command console, Primecom shows:

Server: Set userid="kermit", password="the_frog"

Note: Admin user IDs cannot be set this way. User IDs must be removed manually. To inactivate a user ID, set the password to 20-byte random string of digits and letters, then delete the entry later.

Setting Prime Server Test Ranges

You can remotely set any of the four test range settings the Prime Server uses for client test assignments. These settings are numbered this way:

• 0 sets RangeLow and RangeHigh, for LL tests,
• 1 sets NextRangeLow and NextRangeHigh, for LL tests,
• 2 sets FactoringRangeLow and FactoringRangeHigh, and
• 3 sets FactoringNextRangeLow and FactoringNextRangeHigh.

The low and high exponent values of a range are always set at the same time. Choose the range setting you want to change and use the -t 'test' parameter. For example, say you want to set the next LL test range to 3550000...3554000. Type:

primecom -t "r1 3550000 3554000"

where the 'r1' selects the NextRangeLow and NextRangeHigh setting. The server responds in the log:

1997/08/13 01:30:24 [Admin] Set NextRangeLow = 3550000, NextRangeHigh = 3554000

and at the command console:

Server: Set NextRangeLow = 3550000, NextRangeHigh = 3554000

Type again:

primecom -t "r3 4650000 4654000"

and the server responds in the log:

1997/08/13 01:31:19 [Admin] Set FactoringNextRangeLow = 4650000, FactoringNextRangeHigh = 4654000

and at the command console:

Server: Set FactoringNextRangeLow = 4650000, FactoringNextRangeHigh = 4654000

 

Manual Exponent Check In

Say exponent 2813977 has been out far too long and you want to put it back on the test list. Type:

primecom -i 2813977

and the server responds in the log:

1997/04/17 01:30:24 [Admin] Manual check-in completed for 2813977

and at the command console:

Server: [Admin] Manual check-in completed for 2813977

Type again:

primecom -i 2813977

(oops! did it twice! ;-), and the server responds in the log:

1997/04/17 01:32:55 [Admin] Check-in of 2813977 failed (not checked out)

and at the command console:

Server: [Admin] Check-in of 2813977 failed (not checked out)

Manual Exponent Check Out

Say exponent 2813997 was already being tested by a machine you've just added to the Primenet network test. You want to tell the server the exponent has been assigned, so you type:

primecom -o 2813997

The server responds in the log:

1997/04/17 01:31:04 [Admin] Manual check-out completed for p = 2813997, bits = 58

and at the command console you see:

Server: [Admin] Manual check-out completed for p = 2813997, bits = 58

Manual Exponent Clearing (Marking as Test-Complete)

Say exponent 2813969 was already tested before you started using Primenet and you don't want it assigned again. You want to tell the server the exponent has been tested by typing:

primecom -c 2813969

The server responds in the log with:

1997/04/17 01:50:22 [Admin] Manual clear completed for 2813969

and at the command console you see:

Server: [Admin] Manual clear completed for 2813969

 

Online Exponent Database Merge

Primenet uses an 8-byte datebase record format to accomodate time stamp information. The file database.bin is the exponent assignment database used by the Prime Server.

Let's say you've been testing a while and have a batch of exponents completed. You sent George the results.net file some time ago and download his latest database.zip file and extract the updated 4-byte format database. Your Primenet Server status report shows 50 exponents are done so you figure it's a good time to refresh the database.

You then type:

primecom -m database

The merge facility in the server knows to keep tested exponents if George Woltman's database is not yet current, and also to keep entries for any exponents you have checked out to clients. If George's latest database does not have your completed exponent in it, he has received the results for it and the merge facility can finally remove the exponent record.

If there were 94505 exponents in the database update and you had 3 exponents checked out and 1 exponent completed that George's database still lists as untested, the server responds in the log with:

1997/04/17 01:33:33 [Admin] Begin database merge with database
1997/04/17 01:33:45 (server) Merged - total: 94505, in progress: 3, removed: 49, retained: 1

and at the command console:

Server: [Admin] Merged - total: 94505, in progress: 3, removed: 49, retained: 1

This is how you create the Primenet 8-byte format database the first time if you are installing Primenet from scratch.

Prime95 Client Test-Complete Exponent Check In

When Prime95 returns either of these messages:

• M(exponent) is not prime...
• M(exponent) is prime ... (cause for hooting and hollering)
• M(exponent) has a factor...

it is checking a tested exponent back into the database, or "Clearing" it.

Say a Prime95 client reports back:

M2813969 has a factor 7687623421341

the server responds in the log with the verification message and elapsed time:

1997/04/17 01:50:22 (server) Clear completed for 2813969 ( 0.71 days)

This is important to trap against double check-in errors. What if you thought a machine was removed from the network because the results were long overdue and then manually checked in its assigned exponent, only to have Joe bring the machine back from home and reconnect it unbeknownst to you. A few days later his NT workstation reports:

M2813977 is not prime WQ1a:000000

The server responds in the log:

1997/04/17 01:49:07 (server) Clear of 2813977 failed (not checked out)

Note that the reported results still get logged in results.net. For the most part this kind of exponent management helps you track your testing distribution more accurately and prevents accidental exponent losses.

Prime95 Client Intermediate Factoring Result or
Factoring-Only Client Test Exponent Check In

When Prime95 returns the message:

M(exponent) no factor to 2^(bits) bits...

the (bits) value indicates to how many bits no factors have been found and is updated in the database.

Say a 'regular' LL (non-factoring-only) Prime95 client reports back:

M2813983 no factor to 2^59, WQ1a: 186110E3

the server responds in the log with the verification message and elapsed time:

1997/04/17 08:03:56 (server) Factoring check-in completed for 2813983 at 59 bits ( 0.42 days)

after which the server still expects the prime/not-prime test result for that exponent later and will clear it then.

However, if a factoring Prime95 client reports back:

M2813983 no factor to 2^59, WQ1a: 186110E3 (factoring)

the server responds in the log with the clearing check-in verification message and elapsed time:

1997/04/17 01:50:22 (server) Clear completed for 2813983 ( 0.71 days)

If the Prime95 client is only performing factoring, this message checks a tested exponent back into the database, or "clears" it again in case a second factoring client or LL test client later checks it out for further testing.

Assignment Timeout Management

Primenet expects a client to respond that it received an assignment very soon after issuing it. If for some reason the client called 'Dying' asked for and was sent assignment 2813987 but the network crashed at that moment, the server will timeout the transaction and 'unassign' the exponent again. The default in the Primenet.ini file is 2 seconds (2000 milliseconds).

1997/04/17 05:12:01 [Dying] RpcGetNextExponent 2813987, 58
1997/04/17 05:12:03 (server) RpcAckExponent timeout: 2813987 available

Primenet also returns exponents that are long overdue back into the untested pool. The default in the Primenet.ini file is 129600 minutes (90 days). The server reviews the database for these overdue assignments once daily, but this can also be adjusted in the Primenet.ini file settings.

Primenet Server Status Reports

Improved Report Format!

This is the second major means to managing your parallel testing environment. To get an instant online report showing what exponents are checked out for testing, duration in days since checkout, the actual checkout time, plus what exponents are completed awaiting the next database merge to verify, type

primecom -r status.txt

The status.txt file can be almost any name you want but keep in mind it is generated in the server's relative home file path.

This is key to tracking which exponents are on time, overdue or test complete. Here's an example report using manufactured data:

(status.txt:)

Mersenne Primenet Server 2.6 (Build 8/13/97)
Status Report Thu Aug 14 00:29:44 1997

Exponent test range is 3240400 ... 3242700
Exponent factoring test range is 4967000 ... 4969000

*** Exponents in test ***

prime exponent --------	no factor through ---------	testing run time -----------	date/time assignment checked out to test ------------------------
3240491	59 bits	26.94 days	Fri Jul 18 01:49:09 1997
3240767	59 bits	18.79 days	Sat Jul 26 05:27:25 1997
3240877	59 bits	18.79 days	Sat Jul 26 05:27:26 1997
3240917	59 bits	18.79 days	Sat Jul 26 05:27:26 1997
3240959	59 bits	15.75 days	Tue Jul 29 06:24:20 1997

Exponents checked out in test : 5
Exponents remaining to be tested : 1
Exponents remaining for factoring: 55

*** Exponents completed (cleared) ***

prime exponent --------	no factor through ----------
3028841	(factored), composite
3240407	59 bits, composite
3240467	59 bits, composite
3240471	*** ****** PRIME *** ;-)
3240479	59 bits

Exponents completed (cleared): 5

*** Exponents in test range : 51
*** Exponents in test factoring range: 59

~ HOME ! PARALLEL TEST CHALLENGE @ INSTALLATION # ADMIN GUIDE $ TIPS & HELP %