Testing....

[mdettweiler]

Originally Posted by mdettweiler

Edit: scratch that, looks like it didn't work. I just started up the client again and it grabbed exactly the same 5 pairs that it did before--including the ones that were already done. It seems the server didn't ignore the cancellation requests on the completed ones as I thought; somehow they were thrown back into the pool to be reassigned.

The fix would be the same as the one I presented above: the only difference being that it's no longer just a cosmetic issue but a real one.

Update: it gets even messier. Apparently this confused the server to the extent that it "forgot" entirely that the 4 completed pairs had been done after receiving cancellation requests for them. Now that those pairs have been completed a second time, they're duplicated in results.txt.

[kar_bon]

wordprocessing/counting in dos-batch is not easy to do. gawk is possible to solve that problem, but another .awk to handle.

to the issue:

do again the same test, but be sure delete all files created on client/server.
what i think:
you did 'do -c' and instantly 'do' again! the server have to get (commit) the cancellation first and must given the chance to prune the knpairs and joblist!

try again:
- do
- do -c
- llrserver -s
- llrserver -s
- do

this should work!

[mdettweiler]

Originally Posted by kar_bon

wordprocessing/counting in dos-batch is not easy to do. gawk is possible to solve that problem, but another .awk to handle.

to the issue:

do again the same test, but be sure delete all files created on client/server.
what i think:
you did 'do -c' and instantly 'do' again! the server have to get (commit) the cancellation first and must given the chance to prune the knpairs and joblist!

try again:
- do
- do -c
- llrserver -s
- llrserver -s
- do

this should work!

Yes, I agree that that should definitely work. But the problem is, while it works in testing, in real use on a public server, a user is not going to be able to log on to the server and run "llrserver -s" every time he's canceled pairs. It's got to be able to work without needing any administrative action on the server. On a reasonably busy public server, somebody else is bound to connect sometime before the server does its next automatic prune--and he'll be assigned duplicate pairs.

[kar_bon]

but than how it work's now?

as i said, pruning could only be done when a command was submitted to the server like requesting new pairs or submitting results.

perhaps we should test this on an 'old' server/client to verify this!

as long the server did no pruning, the pairs just cancelled are still in the joblist as 'working' and 'CANCEL' for the same user, and the 'lowestKnPair' is determined as a pair not in status working/cancelled by another user.
that lowestKnPair is set every time a AskPair hits the server.

[mdettweiler]

Originally Posted by kar_bon

but than how it work's now?

as i said, pruning could only be done when a command was submitted to the server like requesting new pairs or submitting results.

perhaps we should test this on an 'old' server/client to verify this!

In the old client, all results are submitted as soon as they're done, so theoretically there will be no completed workunits in workfile.txt to worry about when canceling. All it has to do is cancel whatever's up next in workfile.txt, no questions asked.

[kar_bon]

so your suggestion: simulate more the normal llrclient with script!?

means:
- receive number of pairs
- test one pair
- submit that result when test complete and delete pair from workfile.txt
- next test

- if no workunits = workfile.txt empty
-> receive next pairs

so when the script is stopped, the workfile.txt only contains pairs not done yet.

perhaps this could work.

[mdettweiler]

Originally Posted by kar_bon

so your suggestion: simulate more the normal llrclient with script!?

means:
- receive number of pairs
- test one pair
- submit that result when test complete and delete pair from workfile.txt
- next test

- if no workunits = workfile.txt empty
-> receive next pairs

so when the script is stopped, the workfile.txt only contains pairs not done yet.

perhaps this could work.

No, that's not quite what I was thinking. What I was trying to say is that since the script works differently than the old LLRnet client, the old client's not going to give us any help in solving this.

Here's what I'd suggest we have it do:
-Continue to use the gawk script to process the lresults files as always.
-However, before the cancellation code sends in the newly-produced tosend file, have it count the # of lines in it first. Let this be x for the purposes of this description.
-Then, remove the first x k/n pairs from workfile.txt. Possibly a second gawk script could be used to do this.
-Then, proceed to cancel whatever's left.

That's essentially what do.pl does, but adapted to the fact that do.bat uses gawk to do the processing.

[kar_bon]

ok, i can do this the next hour, i think.

[kar_bon]

i've got a second gawk-script to delete the first processed pairs of the workfile.txt.
i also changed the do.bat for this.

i've just uploaded the new version for testing!

[mdettweiler]

Originally Posted by kar_bon

i've got a second gawk-script to delete the first processed pairs of the workfile.txt.
i also changed the do.bat for this.

i've just uploaded the new version for testing!

Tested and--it works!

Both scripts should be all set now--I believe the only thing left to do is the big stress test Gary had planned, hmm?

[kar_bon]

i have to test the new cancel-functionality with 0/5, 2/5 or 5/5 tests done from reserved and cancelling. also cancel and just get new pairs.

and the n=1-1000 test from Gary, too.