PRPnet 2nd drive-51 bases with <= 5 k's to n=250K

[gd_barnes]

Hey guys. We have a problem. The 3 k's for S133 were incorrectly loaded in the server as R133 3-4 hours ago. As I am unfamiliar with loading/correcting PRPnet servers and have been unable to get ahold of Max since that time, can someone give me exact details on deleting the incorrect k's? Note that there are 2 correct k's for R133 already there.

I'm familiar with DB2 commands (legacy systems) and I know that SQL commands are virtually the same. More than anything I just need to know how to get to the database from the command prompt, select the incorrect k's, delete them, and then get back out of the database to restart it.

This will mean that you will get some rejected errors by the server after I delete the bad pairs. I do not believe that this will affect the server scores. The only loss of credit will be for the few pairs that are rejected.

I will not plan on loading in S133. Max should be available later today to load it in correctly. The main thing is to get the incorrect pairs out of the server to prevent further waste of CPU time.


Thanks,
Gary

[rogue]

Originally Posted by gd_barnes

Hey guys. We have a problem. The 3 k's for S133 were incorrectly loaded in the server as R133 3-4 hours ago. As I am unfamiliar with loading/correcting PRPnet servers and have been unable to get ahold of Max since that time, can someone give me exact details on deleting the incorrect k's? Note that there are 2 correct k's for R133 already there.

I'm familiar with DB2 commands (legacy systems) and I know that SQL commands are virtually the same. More than anything I just need to know how to get to the database from the command prompt, select the incorrect k's, delete them, and then get back out of the database to restart it.

This will mean that you will get some rejected errors by the server after I delete the bad pairs. I do not believe that this will affect the server scores. The only loss of credit will be for the few pairs that are rejected.

I will not plan on loading in S133. Max should be available later today to load it in correctly. The main thing is to get the incorrect pairs out of the server to prevent further waste of CPU time.

From the command line:

mysql -u<user> -p<pwd> <dbname>

You can get these values from database.ini in the directory the server is run out of.

To get rid of the bad entries, you will need three statements:

delete from candidatetestresult where candidatename like '%133^%+1";
delete from candidatetest where candidatename like '%133^%+1";
delete from candidate where candidatename like '%133^%+1";

Then start prpadmin and use option 6 to recompute server stats.

--Mark

[grueny]

you can use the prpadmin-tool and a faked factorfile to remove all incorrect candidates. the tool only checks that the line is of form "factor | candidate".
so you can set any factor.
you will need the imported candidates (sievefile) and set for each candidate to remove a line in the factorfile.

prpadmin will then cleanup all tables in the database.

when clients report work for such a candidate the server writes a errormessage to log.

i think this way is easier than cleanup the database manually.

other ways can have ugly side effects.

[gd_barnes]

Originally Posted by rogue

From the command line:

mysql -u<user> -p<pwd> <dbname>

You can get these values from database.ini in the directory the server is run out of.

To get rid of the bad entries, you will need three statements:

delete from candidatetestresult where candidatename like '%133^%+1";
delete from candidatetest where candidatename like '%133^%+1";
delete from candidate where candidatename like '%133^%+1";

Then start prpadmin and use option 6 to recompute server stats.

--Mark

OK thanks.

First, the bad pairs entered are Riesels so deleting like '%133^%+1" would delete nothing. Second, there are 2 k's in there that are correct for R133. It's the 3 most recent k's that are incorrect (they should be S133). If I deleted all base 133 pairs, that would be a bad thing. Third, I wouldn't want to affect people's stats. They should still get credit for the work on the incorrect pairs.

Knowing SQL commands as I do, if I can get into the database, I can easily delete the specific rows that I need to. I just have to specify by both base and k-value.

Unfortunately I have to leave now. I hope to get to it in the next hour.

[gd_barnes]

OK the server will be down for the next 10-15 mins. while I check closely and then delete the bad pairs. I'll edit this post when it is done.

[rogue]

Originally Posted by gd_barnes

OK thanks.

First, the bad pairs entered are Riesels so deleting like '%133^%+1" would delete nothing. Second, there are 2 k's in there that are correct for R133. It's the 3 most recent k's that are incorrect (they should be S133). If I deleted all base 133 pairs, that would be a bad thing. Third, I wouldn't want to affect people's stats. They should still get credit for the work on the incorrect pairs.

Knowing SQL commands as I do, if I can get into the database, I can easily delete the specific rows that I need to. I just have to specify by both base and k-value.

Unfortunately I have to leave now. I hope to get to it in the next hour.

That's why it is "%+1", not "%1" or "-1". "%+1" will delete Sierpinski only. As for stats, users will not lose credit for what is complete, but they will not gain credit for workunits they return after you delete the records.

If you care about specific k, then use "<k>*133%+1" instead of "%133^%+1".

[gd_barnes]

Originally Posted by rogue

That's why it is "%+1", not "%1" or "-1". "%+1" will delete Sierpinski only. As for stats, users will not lose credit for what is complete, but they will not gain credit for workunits they return after you delete the records.

If you care about specific k, then use "<k>*133%+1" instead of "%133^%+1".

lol We're still not communicating.

S133 has been entered as R133.

Deleting +1 would delete nothing. There are no +1's in the DB. Everything has been entered as -1. I should have it here shortly.

BTW, the table names are case specific with several caps in each.

[gd_barnes]

The bad pairs have now been deleted from the server. The HTML page is still showing the bad k's but I assume that it will update itself in a few minutes to remove them.

Even if there is something more to do, I can guarantee that no more bad pairs will be handed out.

You may have some results that are rejected by the server. These are just the bad pairs clearing themselves out. Future pairs will all be good.

Max will load S133 plus two more bases likely later tonight.

[mdettweiler]

Originally Posted by gd_barnes

The bad pairs have now been deleted from the server. The HTML page is still showing the bad k's but I assume that it will update itself in a few minutes to remove them.

Even if there is something more to do, I can guarantee that no more bad pairs will be handed out.

You may have some results that are rejected by the server. These are just the bad pairs clearing themselves out. Future pairs will all be good.

Max will load S133 plus two more bases likely later tonight.

Yes, all set now--nice work Gary, everything looks good. I ran a "recompute server statistics" with the prpadmin tool to clean out the (now empty) entries for the bad k's on the web page, and then reloaded S133 the right way.

Sorry about that everyone--this was my bad completely. Since the sieve files are in NewPGen format, and PRPnet reads ABC format, I need to add an appropriate header manually to each file before loading it; in this case, it needed to be "ABC $a*133^$b+1" but I typed -1 instead.

Max

[rogue]

Originally Posted by mdettweiler

Since the sieve files are in NewPGen format, and PRPnet reads ABC format, I need to add an appropriate header manually to each file before loading it; in this case, it needed to be "ABC $a*133^$b+1" but I typed -1 instead.

That's what srfile is for.

[gd_barnes]

Originally Posted by rogue

That's what srfile is for.

I had been sending him files in -G (NewPGen) format not knowing about the header issue. After an Email discussion, I will now send them to him in -w (ABC) format. That should prevent the problem in the future.