mersenneforum.org  

Go Back   mersenneforum.org > Prime Search Projects > Prime Sierpinski Project

Reply
 
Thread Tools
Old 2009-09-12, 21:39   #1
Ungelovende
 
May 2008
Åsane, Bergen, Norway

11112 Posts
Default ERROR: Workunit not found on server

Have I been drinking too many beers with my pølsefingre or is this a bug?
Code:
[2009-09-12 18:15:29 GMT] PSPtest: Returning work to server www.psp-project.de at port 7100
[2009-09-12 18:15:47 GMT] PSPtest: ERROR: Workunit 90527*2^7912799+1 not found on server
PRPNet Server version 2.2.3 for PSP first pass test
[2009-09-12 18:15:53 GMT] Total Time: 21:23:08  Total Tests: 1  Total PRPs Found: 0
[2009-09-12 18:15:53 GMT] PSPtest: Returning work to server www.psp-project.de at port 7100
[2009-09-12 18:15:58 GMT] PSPtest: ERROR: Workunit 90527*2^7912799+1 not found on server
[2009-09-12 18:15:58 GMT] PSPtest: The client will delete this workunit
[2009-09-12 18:15:58 GMT] PSPtest: INFO: 0 of 1 test results were accepted
[2009-09-12 18:15:58 GMT] PSPtest: Getting work from server www.psp-project.de at port 7100
Ungelovende is offline   Reply With Quote
Old 2009-09-12, 21:56   #2
opyrt
 
opyrt's Avatar
 
Apr 2008
Oslo, Norway

7·31 Posts
Default

I have a theory that this is a kn-pair that has been reissued because it timed out from a user, but then that user turned prpclient back on and it was delivered.

I have no idea how the PRPNet server handles those issues, but with LLRNet ltd had made some magic stuff that redirected those to the second pass stats.
opyrt is offline   Reply With Quote
Old 2009-09-12, 22:08   #3
Lennart
 
Lennart's Avatar
 
"Lennart"
Jun 2007

25·5·7 Posts
Default

Use this file. prpserver.delay

Code:
// This file serves two purposes.  First, it tells the PRPNet server how close or
// far double-checks should be to the first tests.  Second, it tells the PRPNet
// server how long to wait before automatically expiring tests.
//
// This file can contain a variable number of lines.  The format is as follows:
//    delay=<decimal size>:<doublecheck time limit><m:h:d>:<expire time limit><m:h:d>
//
// <decimal size> is the decimal size for the candidate.  This value represents
// the upper limit for the candidates that are affected by this test.
//
// <doublecheck time limit><m:h:d> is the amount of time (in minutes, hours, or days)
// after the completion of the first test before a double-check can be sent to a client
// This must always be configured even if the server is not doing double-checks.
//
// <expire time limit><m:h:d> is the amount of time (in minutes, hours, or days)
// before the server will automatically expire tests which do not have results
//
// Note:  This file is presumed to be in decimal size order.  If this file
//        is empty or has no entries, then a delay of 1 hour is presumed.
//        If the largest number is longer than the last entry, then the
//        values for the last entry will be used.

delay=050000:30m:6h
delay=100000:2h:1d
delay=200000:8h:4d
delay=300000:1d:8d
delay=400000:2d:16d
delay=500000:4d:32d

Lennart
Lennart is offline   Reply With Quote
Old 2009-09-13, 06:50   #4
ltd
 
ltd's Avatar
 
Apr 2003

22×193 Posts
Default

@Lennart: Delay is set to 20 days but if there is need I can change it to whatever is suitable.

Checked the history of the test:

The test was issued the first time at 2009-08-19 13:43:02 GMT
Next log entry was the expired entry at 2009-09-08 13:53:50 GMT
Test was reissued to another user at 2009-09-08 14:49:55 GMT
test was accepted for user Ungelovende at 2009-09-12 18:15:26 GMT

The problem with that result is that there was no residue received.
So the error message is wrong.
This is the first time I see this behavior with the PRPnet server. That was a known issue with llrnet but so far not with the new server. Can you please check your logfile if it contains the residue and send it to me as PM.

Edit: After checking the debug log I found that the client did try to send the result several times. So the error comes from the fact that the result was already accepted.

I will check if the newest PRPnet releases already have a fix for this.

Last fiddled with by ltd on 2009-09-13 at 07:01
ltd is offline   Reply With Quote
Old 2009-09-13, 06:54   #5
ltd
 
ltd's Avatar
 
Apr 2003

11000001002 Posts
Default

After the issue was raised I checked the PRPnet logfile and found another five tests with the same problem.

Could the following users please check their local log files and send the residues by PM if they find them

User Steinrar:
222113*2^7978581+1

User runesk: Client: 1337:
225931*2^7973816+1
79817*2^7973879+1

user whizbang: client: WORK5:
237019*2^7979686+1
90527*2^7979711+1

Thanks.

Last fiddled with by ltd on 2009-09-13 at 07:20
ltd is offline   Reply With Quote
Old 2009-09-13, 07:08   #6
ltd
 
ltd's Avatar
 
Apr 2003

22×193 Posts
Default

And another reply.

Checked the prpnet version history and found that the no residue issue was fixed with version 2.2.4. We were running version 2.2.3.

I will update the servers to the latest version (2.3.0) today.

Sorry for not checking this earlier.

By the way I will also raise the expire to 28 days to make it compatible with the llrnet behavior.
ltd is offline   Reply With Quote
Old 2009-09-14, 16:05   #7
ltd
 
ltd's Avatar
 
Apr 2003

22·193 Posts
Default

Received the residues from Ungelovende, steinrar and runesk so far.

Thanks for the additional effort.
ltd is offline   Reply With Quote
Old 2009-09-14, 16:22   #8
mdettweiler
A Sunny Moo
 
mdettweiler's Avatar
 
Aug 2007
USA (GMT-5)

792 Posts
Default

Quote:
Originally Posted by ltd View Post
And another reply.

Checked the prpnet version history and found that the no residue issue was fixed with version 2.2.4. We were running version 2.2.3.
Actually, it wasn't fixed entirely in 2.2.4. The problem was alleviated some, though blank residues will still occur occasionally, and unfortunately there's no way to recover the residual except by going through the client logs (or, of course, by re-doing the test, though for numbers this big that would be a big wallop).

Mark and I are currently doing alpha testing on version 2.4.0, which should fix these problems. There are a few other smaller problems that will have to be nailed down, so I don't know when Mark's planning to release it, but I'd guess it will probably be sometime within the next week or two.
mdettweiler is offline   Reply With Quote
Old 2009-09-14, 18:00   #9
rogue
 
rogue's Avatar
 
"Mark"
Apr 2003
Between here and the

19·313 Posts
Default

Quote:
Originally Posted by mdettweiler View Post
Actually, it wasn't fixed entirely in 2.2.4. The problem was alleviated some, though blank residues will still occur occasionally, and unfortunately there's no way to recover the residual except by going through the client logs (or, of course, by re-doing the test, though for numbers this big that would be a big wallop).

Mark and I are currently doing alpha testing on version 2.4.0, which should fix these problems. There are a few other smaller problems that will have to be nailed down, so I don't know when Mark's planning to release it, but I'd guess it will probably be sometime within the next week or two.
2.4.0 is going to be a big release, not just for the changes to affect this, but also to support genefer for PrimeGrid. That is a much bigger change than you can imagine.
rogue is online now   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Possible error in PRP calculation or server display alpertron Software 4 2017-11-08 16:07
confusing server error messages ramgeis PrimeNet 2 2013-06-09 23:53
Found Factors not recognised by server CCol PrimeNet 19 2010-10-27 03:25
Workunit diet ? dsouza123 NFSNET Discussion 5 2004-02-27 00:42
Prime95 Windows NT Error [b]SHLWAPI.dll [/b]not found stealthaxe Software 3 2003-05-11 05:53

All times are UTC. The time now is 00:29.

Sun Oct 25 00:29:58 UTC 2020 up 44 days, 21:40, 1 user, load averages: 1.51, 1.73, 1.85

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.