One of the major flaws of Windows, is if an application requests XXX amount of RAM to use, Windows reserves that XXX amount of RAM, even if the application never actually uses that XXX amount of RAM, but only X amount. And you don't have any control over what the application requests for RAM reservation requested. That comes from the task generator template values the admin/scientist sets up for the tasks to use for work generation.

OTOH, Linux does not do this and only allocates on the fly how much memory to reserve only at the request of the application when it actually runs. This issue is a big problem for tasks that need a huge amount of RAM reserved. The Windows users over at GPUGrid run into this issue all the time. The solution for Windows users is to set up a VERY large pagefile on the order of 50-64GB in size so that so that the when the application tells Windows to reserve 30GB of memory, it can actually do as requested by utilizing the pagefile.

BTW: My cache is configured for 1+1. As long as computer is running 24h there soul be a day of reserve.

Setting it that way may not give you what you might expect it to.
If you want 2 days worth, then set it to 2+ 0.01.

Those additional days are just that- additional days. They will only be added on when the cache gets low enough to reach the "Store at least value" and it needs to be topped up. Then it will also top up the additional day, which will then run down again until the "Store at least value" is reached again.


With it set to 1+1 you will get one day's worth, plus another day's worth, but then the cache will run down to just under 1 day's worth, then it will refill the 1 day & then re-fill the second additional day.
With it set to 2+ 0.01 as it returns a Task, it will download another to keep the cache at the 2 days level.

Also only three days of deadline?

Which has been the case for years now, and which is why you don't return a large amount of the work you download- you miss the deadline almost 50% of the time.

Your initial Estimated completion times are set by the project at 8 hours, but your actual Target CPU time appears to be 12 hours. So even with a small cache, you would miss deadlines. You need no cache, or at the very most a very small cache to avoid missing deadlines (1 day or less).
Running more than one project there is no need for a cache at all. If one project doesn't have work, the other will make up that gap, till the first project has work again. No missed deadlines, no not getting work from one project because the other has filled the cache with work.

Ideally

           Store at least 0.02 days of work
Store up to an additional 0.01 days of work

But if you really feel the need for a cache

           Store at least 0.35 days of work
Store up to an additional 0.01 days of work

would be plenty.


If all of your projects have server issues/lots of periods with no work, then "Store at least xx days of work could be set to 1 day (or 1.5 days if you go with the default Target CPU time of 8 hours).

So that explains why WUs are failing on one of my computers. 20 threads and only 16GB of RAM and fairly small paging file. They could have warned us...

It's been the general rule of thumb since i've been here (a bit over 4 years)- 1.5GB of RAM per core/thread is needed in order to do Rosetta work.
It's only been recently with the Beta application that Tasks have used less (there were batches of Rosetta 4.20 work that have Tasks that used 2- 4GB each).


Edit-
Interestingly- on one system all running tasks are using up to 1.6GB of RAM, on the other only 2 are using more than 1GB of RAM, the rest 400-700MB.

Glitch fixed, and lo and behold- new work!


And an interesting batch it is- It's Beta 6.06 work, but they're using 1.4 to 1.7GB of RAM each, and it looks like their target Runtime is 8 hours (unlike the usual 200-400MB of RAM and 3 hrs runtime of previous Beta Tasks.

Hi there. Apologies if this is posted in the wrong area, but I am unable to get work.
I bought this new computer about a month ago. it has an Intel(R) Arc(TM) A770 Graphics card and a 13th Gen Intel(R) Core(TM) i7-13700F processor.
I hope you can help.
I've tried attaching to several boinc projects, and I'm not getting any work.
Is this just bad luck or is something else wrong?

Try PrimeGrid and Einstein, Asteroids also has cpu and gpu tasks but I don't know if they can use your Intel Arc gpu or not

Is Rosetta@home still running? I've been a member of this project for years, and I'm not getting any tasks. I looked at my Projects page and it says "Won't get new tasks." What did I do? How do I get new tasks?

It's time for SSEx/Avx support??

Are there even any x86-64 CPUs without at least SSE2 support?

SSE2 from Wiki:

Introduced by Intel with the initial version of the Pentium 4 in 2000... AMD added support for SSE2 in 2003

[snip]

Yes, smt/hyper threading is off. The point is though, on my Intel laptops, the speed has remained the same between 4.07 to 4.12. On my tr it's dropped over 60% regardless of what I try, I can't put it much simpler than that.

Note that all of your Intel laptops have a much lower number of cores, and will therefore have much less of a problem with too many cores trying to share the limited speed path to main memory. I can't put it much simpler than that, either.

4.07 is the reference yes. 4.12 is 60% slower than that, I don't know what is so difficult to understand, it's has nothing to do with memory or anything else. You dont have a 64/128 chip to only run it on 5 cores to keep the same productivity because of a software change. Is there a mod/developer that can possibly comment on this issue?

So maybe allow repeated attempts to download for a maximum 24hrs, else abort? But could be a loss of connectivity at the user end, or at the project end?

Yes, some means for BOINC to give up is required. Perhaps it should wait even longer if the file is "particularly large" (intentionally left for others to define). The other issue is that in the case here at R@h the problems seemed to be with small files, but the small file was required to run a given WU. That WU might have had many GBs of other required files that came down ok. So the actual size of the particular file having problems is not really the only consideration. If you abort the WU, all of the WU files are being lost (unless other WUs your machine has on-board use them as well).

I should think the BOINC Manager can see the difference between a lack of connectivity being the cause, and a dropped frame. So that info. could be used. If there was a loss of connectivity, then perhaps you double the maximum timeout.

...all good discussion for BOINC message boards.

Connectivity detection is also partially broken in BOINC clients:
If BOINC client can not download file or contact project server it contacts "reference site" which is google.com for last few years.
If it get "HTTP 200 - OK" response from google - all work as expected: BOINC understands there are problem with particular project but Internet connection is OK and proceeds with other projects.

But if google return any other response(not "200 OK") - BOINC stupidly interprets it as connectivity issues (no internet connection) and temporarily ceases all internet activity and increase "back-off" timer each time.
And Google often returns other codes - because a lot of such similar automated requests from thousands of computers around the world running BOINC often trigger the anti-bot filters of Google (it blocks such requests and offers to solve CAPTCHA to continue work). BOINC of course can not understand it and react to this by declaring "connectivity issues".

Although the fact that it was able to get an error message from Google (no matter which and for what reason) means the exactly opposite - that the Internet connection is working OK.

I was surprised when I saw a comment from someone who had queue for a couple of days. I joined the project about 10 days ago and I usually got 2-3 extra tasks besides the 12 running tasks. My tasks take 7-8 hours to complete so I never got a large queue. Wonder why there's such a big difference.

Also since yesterday I didn't receive any new tasks and I'm now running the last 5 tasks.

Klimax, why don't you go ahead and take a dump and EMail it to me, along with details on what you observered with it as it ran. I will forward it to the Project Team.

Hello.
Following task (http://boinc.bakerlab.org/rosetta/result.php?resultid=225859224) is suspended as it has produced "accepted energy": QNAN(Not a Number?) and RMSD: QO.Model number 25 step 9518. Running time: 20h 2min 21sec.
Set runtime 24h.
For now suspended.No crash before.
OS:Windows 7 beta.I can create dump file using task manager.

Should I let it try to finish?

Thanks

I'd suggest allowing it to run normally. Was it still using CPU time? If you want to kind of cut it off, but get it to report in, let it run, then exit (not close) BOINC and restart it, let it run about 2 minutes, then exit again and restart, until you've done that 5 times and the task should be ended and report in with "too many restarts".