Here's one

http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=23395067

And some more
http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=23394929
http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=23395000
http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=23394693

How many do you need?

All from the same block of the same tape:

24no10ab.19199.1707.12.46.21
24no10ab.19199.1707.12.46.100
24no10ab.19199.1707.12.46.124
24no10ab.19199.1707.12.46.146

You can manufacture the full set of, I think, 255 by running the final byte from 0 to 254 - they'll all match.

Thanks, I hope to reproduce issue with single such task.

---

News about SETI opt app releases: https://twitter.com/Raistmer

Seems Sutaru found bug in current RC apps.
I need task with AR of 1.047818 for offline benchmarking. Please find such.

My old nick? ;-)

I have the 3 tasks catched which made driver restarts on my PC. (I mentioned it... ;-)

24no10ab.15245.1707.11.45.198 - 1.0478182115056 - http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=8426107
24no10ab.15245.1707.11.45.199 - 1.0478182115056 - http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=8426108
24no10ab.15245.1707.11.45.242 - 1.0478182115056 - http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=8426151

I could send them to you.

(Finally my PC could calculate them correctly because I used -sbs 512 in cmdline.txt file (after some offline tests, 256 & 512 made it).)

Also the latest driver reboot task, a .vlar.

24no10ab.3532.161768.14.48.74.vlar - 0.010212205767369 - http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=8448261

(Despite -sbs 512 it gave a driver reboot.)


- - - - - - - - - -

My PC made 5 errors.
It's possible to download them manually?

24no10ab.3532.160950.14.48.137 - http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=8447812
24no10ab.3532.160950.14.48.144 - http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=8447819
24no10ab.3532.160950.14.48.142 - http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=8447817
24no10ab.3532.160950.14.48.132 - http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=8447807
24no10ab.3532.160950.14.48.143 - http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=8447818


I have read my client_state.xml file and found the URLs for download, but...
*download/xx/task_name
(xx for random values)
Is there a way to calculate/find out the random values? Then I would have the URLs for manually download.


Thanks.

---

I have read my client_state.xml file and found the URLs for download, but...
*download/xx/task_name
(xx for random values)
Is there a way to calculate/find out the random values? Then I would have the URLs for manually download.


Thanks.

Yes - they're not random, but derived from the MD5 hash of the workunit name.

I wrote instructions for working them out in the opening post of

WOW! Where on earth did that come from?

- many years ago now, but it hasn't changed. It's a standard feature of the BOINC server platform, so it works for the Main project (as that was written), here at Beta - just change the first part of the url - and at other BOINC projects too.

In response to a PM indicating that either my English or my maths in incomprehensible:

24no10ab.3532.160950.14.48.137 - http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=8447812
24no10ab.3532.160950.14.48.144 - http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=8447819
24no10ab.3532.160950.14.48.142 - http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=8447817
24no10ab.3532.160950.14.48.132 - http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=8447807
24no10ab.3532.160950.14.48.143 - http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=8447818

become

http://boinc2.ssl.berkeley.edu/beta/download/213/24no10ab.3532.160950.14.48.137
http://boinc2.ssl.berkeley.edu/beta/download/1b/24no10ab.3532.160950.14.48.144
http://boinc2.ssl.berkeley.edu/beta/download/13b/24no10ab.3532.160950.14.48.142
http://boinc2.ssl.berkeley.edu/beta/download/371/24no10ab.3532.160950.14.48.132
http://boinc2.ssl.berkeley.edu/beta/download/da/24no10ab.3532.160950.14.48.143

English isn't my first language, I didn't understood the instruction well enough to follow/reproduce it.

Thanks.

---

EDIT: what if BOINC will have 100% completion instead of 0.0012% after few seconds from task start? Will it be preferable than sit at 0.0012% for most of time?

I did not get answer on this still.

---

News about SETI opt app releases: https://twitter.com/Raistmer

EDIT: what if BOINC will have 100% completion instead of 0.0012% after few seconds from task start? Will it be preferable than sit at 0.0012% for most of time?

I did not get answer on this still.

Your turn to go back and re-read what Jimbocous and Tutankhamon wrote in first drawing our attention to the specific difficulties at VVVHAR:

About 15 minutes into task, Progress percentage will jump from~50% to .001 percent complete. At same time, time remaining will change from 1-2 minutes remaining to over 20,000 hours remaining.
After another minute or so, task will show complete and upload normally. Don't see anything in Stderr raising an issue, and tasks seem to validate OK, but something in the last minute or two of processing blows away the percentage and time statuses.

On SoG, all WU's with extremely high ARs behave exactly like that. Something I pointed out on main from the very beginning of SoG. They start out, counting up to something like 45% done, and then falls back down to 0.001% or so, where they sit, until they all of a sudden finish, after a couple of minutes, poof, 100%. They go to high priority, when they fall back to 0.001%, and time remaining can go up as high as 600 days :-)

I think your suggestion of going instantly to 100% and - presumably - zero time remaining, then sitting there for maybe 15 minutes with no sign of life, is at least as bad. People will notice tasks "stuck at 100%": the intelligent ones will complain on the boards, everyone else will simply abort them.

You need to provide a number to satisfy the needs of Reporting progress.

Then I don't see how to fix that at current state. There is no communication between GPU and CPU between checkpoints. And, cause all data queued to GPU for execution it's 100% done from CPU point of view. Gradual progress reporting means gradual communication between devices - the very same thing that should be avoided at all cost for high-end GPUs.

---

News about SETI opt app releases: https://twitter.com/Raistmer

There is no communication between GPU and CPU between checkpoints.

Since there doesn't seem to be any communication until the last couple of seconds, does that mean there's no checkpointing either in this extreme case?

There is no communication between GPU and CPU between checkpoints.

Since there doesn't seem to be any communication until the last couple of seconds, does that mean there's no checkpointing either in this extreme case?

New build will answer this question cause I added progress report update directly in GPU-communication function that called from checkpoint.
For now you could check that with checkpoint interval changing.

---

News about SETI opt app releases: https://twitter.com/Raistmer

OK, I can re-run the tests with my modified client then.

For some reason the file_upload_handler was creating files in read only mode. So an incomplete upload would cause this error on retries. I had to manually reset the permissions on the files in the upload directory in order to fix it.

I've seen this error multiple times on beta but never on main. Currently, I've one of them again:

30.03.2016 21:45:10 | SETI@home Beta Test | Started upload of 24no10ab.15245.67.11.45.33_0_r750092019_0
30.03.2016 21:45:16 | SETI@home Beta Test | [error] Error reported by file upload server: can't open file
30.03.2016 21:45:16 | SETI@home Beta Test | Temporarily failed upload of 24no10ab.15245.67.11.45.33_0_r750092019_0: transient upload error

If anyone who can help is monitoring these boards, can we have some more work please? No new work issued since the weekend.

Thanks

If anyone who can help is monitoring these boards, can we have some more work please? No new work issued since the weekend.

Thanks

Nah, we're supposed to do Beta testing without any WU's. We should just sit and watch the .exe files, and imagine in our mind, how well or bad it will crunch if there was any real work to crunch.

LOL

If anyone who can help is monitoring these boards, can we have some more work please? No new work issued since the weekend.

Thanks

Nah, we're supposed to do Beta testing without any WU's. We should just sit and watch the .exe files, and imagine in our mind, how well or bad it will crunch if there was any real work to crunch.

LOL

Takes away all the fun of getting abuse for finding problems :)

---

If I can help out by testing something, please let me know.
Available hardware and software is listed in my profile here.

I've posted a request for more work on the equivalent thread over on main, so we'll see if they read that any quicker than here :-)

They've heard our plea - new work available :-)