stephenbrooks.orgForumMuon1Bug ReportsBack to b - d-version queue problems
Username: Password:
Search site:
Subscribe to thread via RSS
[DPC]TeamNWW - Huub
2003-10-21 01:42:17
I am back at the 4.32b version. 

Stephen, it looks like you forgot something when rewriting your code for version d..

situation 1: normal running.
When i let muon run normally it will not create a queue.txt if it produces a score higher then what is in the .dat - that score will just be added to the .txt file with no rechecking done and a new run will start.  (9.62 was highest in .dat; 9.63 was new score with only about 330Mpts)

situation 2: manual seed.
If i create a queue.txt, version d now just keeps rechecking that queue, putting every run in results.txt.  queue.txt is not updated (no 'runs=x' at end of line 1, 'TEST'-line just stays where it is; no results added)

I'm no programmer, but it seems you forgot to tell muon to write/update the queue.txt file..

btw.  this is on a P4 with WinXP..

(i already posted this in the 'Odd queue behavior' thread but was not sure if still checked that thread)

Just noticed something else.. the highest rechecked result in the sample500.txt file (2003-Oct-21, 11:00 UTC) is a 9.24 by [DK]Abyss.. should not at least the highest current result (9.68 by DoD_[]) have a "#runs=5;" at the end??

[This message was edited by [DPC]TeamNWW - Huub on 2003-Oct-21 at 14:17.]
Stephen Brooks
2003-10-21 08:00:33
The sample500.txt file also contains a non-rechecked result from 4.32b:
tantalumrodz=500;tantalumrodr=182;s1l=999;s1f=999;d1l=000;s2l=990;s2r=799;s2f=998;d2l=000;and so on
9.656156 (323.7 Mpts) [v4.32b] {09581767} <SolenoidsTo15cm> by [DPC]HekjeLindon perhaps you're not safe with that either.  What I'll do first is to try and make the sample-files program only take rechecked results.  Then I'll test the queue here with v4.32d.

It doesn't make any sense: that's why they call it "virtual"
[DPC]TeamNWW - Huub
2003-10-21 08:26:22
Yes, but that should be a legit result if it was calculated after HekjeLindon updated his results.dat file..
Stephen Brooks
2003-10-21 08:42:25
The 4.32d results are "legitimate" in that sense too, it's just that some of them haven't been rechecked.  Anyway, the sample files have been changed to only include the checked results for now.
My version of muon here is producing queue.txt OK it seems.

It doesn't make any sense: that's why they call it "virtual"
Stephen Brooks
2003-10-21 08:47:14
Another solution I've just added to the code: the client rechecks any results that are greater than the highest _rechecked-at-least-5-times_ result.  So when I release v4.32e people's machines will go back to rechecking anything that needs to be, even if some single-run results have gone higher in the past.

It doesn't make any sense: that's why they call it "virtual"
Stephen Brooks
2003-10-22 03:05:54
I've found and fixed a memory allocation error in v4.32e, but although it does have some relation to the results-handling module, I'm not sure if it was the cause of this error.  In my tests, the queue works properly.  Can you e-mail me ( the exact queue.txt and results.dat files that are causing your error?  Then at least I can analyse what is going on.

It doesn't make any sense: that's why they call it "virtual"
[DPC]TeamNWW - Huub
2003-10-23 04:18:44
I'm sorry Stephen, but I deleted the queue.txt and updated the results.dat the evening of the first post in this thread (21st) without making a backup.. pretty stupid, will not happen again..

I will just move to version e now.. see what happens.. i notice weird behaviour i'll make sure to save all relevant files..
: contact : - - -
E-mail: sbstrudel characterstephenbrooks.orgTwitter: stephenjbrooksMastodon: strudel charactersjbstrudel

Site has had 17310820 accesses.