Posts by Link

1) Message boards : Number crunching : Is there any way the counts of work units could be made available so those of us that provided support could see the counts in our contribution totals? (Message 2064075)
Posted 21 Dec 2020 by Profile Link
Post:
I needed to rebuild a PC.

Well, this might not help you, but perhaps someone else who plans to rebuild his computer: you should have back up your data dirctory and restore it after the rebuild, than nothing would be lost.
2) Message boards : Number crunching : Uploads and downloads blocked for some BOINC projects using HTTPS (Message 2050689)
Posted 31 May 2020 by Profile Link
Post:
SETI is not affected by this problem

Maybe not this time, but it was couple of months (probably more than a year) ago when I had to update the ca-bundle.crt for my Xperia Ray running NativeBOINC.
3) Message boards : Number crunching : The Server Issues / Outages Thread - Panic Mode On! (119) (Message 2048567)
Posted 8 May 2020 by Profile Link
Post:
State: All (0) · In progress (0) · Validation pending (0) · Validation inconclusive (0) · Valid (0) · Invalid (0) · Error (0)
4) Message boards : Number crunching : When should SETI start canceling Unneeded Tasks, to reduce Wasted Effort and electricity ? (Message 2047946)
Posted 3 May 2020 by Profile Link
Post:
Yes, all needed options are available, I can't understand why they don't use them. They could be propably be way below 100000 results out in the field now, would not waste other peoples electricity and in many cases also not slow down useful work from other BOINC projects. This is really not a clean shutdown anymore.
5) Message boards : Number crunching : When should SETI start canceling Unneeded Tasks, to reduce Wasted Effort and electricity ? (Message 2047060)
Posted 26 Apr 2020 by Profile Link
Post:
Would be messed up to find that you seem to still have work but it was canceled on the server.

That's not how it works, on a scheduler request the server tells the client to abort the WU (either only if not started or in any condition, the project admins choose), on the next request the client confirms it and that's the moment, when the WU is not anymore "in progress" for the server, not before. Completely clean way to do it, nothing gets messed up.
6) Message boards : Number crunching : The Server Issues / Outages Thread - Panic Mode On! (119) (Message 2046808)
Posted 24 Apr 2020 by Profile Link
Post:
I'm now just crunching WUs that already have matching valids.

I'd simply abort them, on point wasting time on them.

I'd actually expect aborting such tasks by the server as part of "nice" shutdown, wasting other people's electricity and eventually slowing down science done by other BOINC projects by generating data for dev/nul isn't what I imagine as nice way to finish the project.

But somehow I've expected it, so I didn't even try to cache many WUs, just finnished what I had and moved to Einstein, there are more than enough machines who can crunch ready what's left. Perhaps even too many and that leads to the current situation...
7) Message boards : Number crunching : The Server Issues / Outages Thread - Panic Mode On! (119) (Message 2045968)
Posted 20 Apr 2020 by Profile Link
Post:
Let me guess: your host isn't sending the list of the tasks it has? Or how can it get over 17k in progress tasks for 1 CPU + 2 GPUs?
8) Message boards : Number crunching : The Server Issues / Outages Thread - Panic Mode On! (119) (Message 2045957)
Posted 20 Apr 2020 by Profile Link
Post:
I've never pushed it to the limit - it would be an interesting experiment to try some day - but I believe the server is aware of its own limits and won't send work which it's impossible to complete before deadline.

Yep, had that many years ago because of way too high DCF (caused by non BOINC applications), answer from the server was something like "No tasks send, won't finish before deadline".
9) Message boards : Number crunching : The Server Issues / Outages Thread - Panic Mode On! (119) (Message 2044898)
Posted 15 Apr 2020 by Profile Link
Post:
Multiple extra replications only work with severely truncated deadlines.

Or with canceling as soon as one of them is returned (and the other host connects to the server).

it doubles the chance of the WU being delayed to early June by an AWOL host.

Well, it doubles also the chance, that at least one of them will be returned successfully and the WU won't need to be resent again in June.
10) Message boards : Number crunching : SETI orphans (Message 2044697)
Posted 14 Apr 2020 by Profile Link
Post:
If you move the allowed task computation time while the cache has tasks you can end up with a lot of "runs longer than it should" tasks. My understanding is the "Watch Dog" timer will kick if the task runs more than 4 hours past the "current" allowed task computation.

Nope, the "watch dog" gets the info about the new target runtime, did that myself, no issues at all.
11) Message boards : Number crunching : SETI orphans (Message 2044607)
Posted 13 Apr 2020 by Profile Link
Post:
It sends data to compute as many possible protein configurations/docking configurations as length of CPU run allows.
Default is 8h. And user can change it. So, if user allows more hours to run, already downloaded database and particular protein data will be used more fully. (...) Hence, if deadline allows better to use longer run times.

Yes, the downloaded files will be used for more work. This is good to decrease the load on the servers, even I can't recall issues over there like we know from SETI. Also you are not loosing so much time for starting the tasks. OTOH if a task errors out later, more work is lost. Must see how stable your computers are running Rosetta, that's different for every computer and nobody really knows why.


If time is short, some another user gets same data to continue modeling.

Well, many users will get same data anyway, they generate (hundreds of?) thousands of models from the same data.


And if deadline miss occurs user can shorten allowable task computation time to avoid deadline miss (but project will need to resend data somewhere else to get full results).

The user can even decrease the runtime after the WU has started if he might miss the deadline (or increase if he wants to, for example when server out of WUs, did that once myself and doubled my cache that way), just change it on the website, force scheduler request and restart BOINC, the task will start with new target CPU runtime or if you don't restart BOINC, all following tasks will start with it.
It is however not so critical if you miss the deadline a bit, a new task will be send out, but your accepted and validated, IIRC even if you return it after the other host. The starting points are generated randomly on the host before the actual crunching, so both results will be different and useful for the project, you just need to return the result before it's purged from the database. That's also the reason, why Rosetta uses a quorum of 1, no two results are the same anyway.
12) Message boards : Number crunching : The Server Issues / Outages Thread - Panic Mode On! (119) (Message 2044524)
Posted 13 Apr 2020 by Profile Link
Post:
Agreed, they should cancel on the server side all tasks still in the field and re-send them with much smaller deadlines. It would mean lost computation for the slowest of slow hosts (and the cheaters who consider they deserve more than the rest of us), but it would allow the last pending tasks to complete much faster. Adding a drastic limit per host is also better indeed, and should always have been added on top of the limit for CPU work and per GPU.

I don't see any reason, why slower hosts should be punnished just for being slow, I'm absolutely against doing that, I also don't really care at this point about cheaters like Ville Saari as long as they return the tasks before deadline. At least we can be pretty sure, that he will crunch them. The database is now OK, so it doesn't matter any longer, they should have done something about it before, when it was important to keep the database small. The only thing I agree with is sending resends with shorter deadlines and limit the number of tasks per host to something very low. The servers will run for couple of months more anyway, no need to do more than this.
13) Message boards : Number crunching : The Server Issues / Outages Thread - Panic Mode On! (119) (Message 2044496)
Posted 13 Apr 2020 by Profile Link
Post:
when I'm really returning 1500 to 2000 results a day.

So due to cheating you have still a cache for well over a month (currently 73055 tasks) and are surprised, that people blame you?
14) Message boards : Number crunching : NativeBOINC can't connect SETI project on some devices (Message 2044401)
Posted 12 Apr 2020 by Profile Link
Post:
Unfortunately no idea... never played much around with not rooted phone. Updating inside the APK should actually also update the CRC, just like if you repack a zip or whatever, otherwise it would be pointless to have the possibility to update APKs at all, but I have never done it myself, so this is just a guess.
15) Message boards : Number crunching : The Server Issues / Outages Thread - Panic Mode On! (119) (Message 2044365)
Posted 12 Apr 2020 by Profile Link
Post:
Once the assimilators have catched up, they should reenable the ghost resending mechanism on the servers (the full version of it), the servers should now be able to handle that additional load.

I'll second that motion.

Meow!

Perhaps you can send a message to Eric like you did in the past (IIRC).
16) Message boards : Number crunching : The Server Issues / Outages Thread - Panic Mode On! (119) (Message 2044361)
Posted 12 Apr 2020 by Profile Link
Post:
Once the assimilators have catched up, they should reenable the ghost resending mechanism on the servers (the full version of it), the servers should now be able to handle that additional load.
17) Message boards : Number crunching : The Server Issues / Outages Thread - Panic Mode On! (119) (Message 2044357)
Posted 12 Apr 2020 by Profile Link
Post:
Came across this computer: https://setiathome.berkeley.edu/show_host_detail.php?hostid=8873201
It has 15k tasks in progress (running BOINC 7.17.0). How is this possible ?

Probably cheater with faked number of GPUs (the system is claiming to have 64 GPUs, how likely is that?) to get around the limits set by the project staff to limit the load on the database. People doing this should be banned from the project IHMO, at least for a week or so. Some of the tasks can also be ghosts.
18) Message boards : Number crunching : SETI orphans (Message 2044067)
Posted 10 Apr 2020 by Profile Link
Post:
As far as I can tell, at least with "leave appilcations in memory while suspended" disabled, BOINC will not switch to another application before the currently running one has checkpointed, it will always switch directly after a checkpoint (if it thinks it's necessary to do it).
19) Message boards : Number crunching : SETI orphans (Message 2041533)
Posted 30 Mar 2020 by Profile Link
Post:
I was seeing if it would be worth it for me to run some Rosetta, generally I don't like CPU processing since it's much less efficient.

The job that Rosetta does can't be done on GPUs, so CPU's are the most efficient way to get it done.
20) Message boards : Number crunching : The Server Issues / Outages Thread - Panic Mode On! (119) (Message 2041326)
Posted 29 Mar 2020 by Profile Link
Post:
Replica is catching about 0.41 seconds per second. If it keeps doing it, It'll take almost two weeks for it to catch up.

Still better than falling behind all the time.

And all this is happening when the return rate is at half the normal value due to most of the big crunchers having run out of tasks to crunch.

Well, like I said, they should have slowed down the splitters long time ago. They know how many results the database can contain before swapping to disk starts and everything becomes slow. Don't get why after running this project for over 20 years they still let such things happen again and again.


Next 20


 
©2024 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.