WU cache, <flops>?
11 Oct 2016 3:01:39 UTC
Topic 201839
(moderation:
I would like to crunch 100% Einstein and 24/7 on my PCs now...
I have not much experiences with Einstein...
How big should be the WU cache, that my PCs will crunch 24/7 - for to bridge over unplanned server failures or if no WUs or rarely WUs are available for download?
It's possible to insert/use <flops> in app_config.xml file (at least with which BOINC version?) for to adjust the estimated WU process times of the different apps?
My PC crunched already much BRP4G GPU WUs, the time is now correct shown, the BRP6 GPU WU times are 2/3 of the real crunch time, and the FGRPSSE CPU WU times are just 1/8 of the real crunch time.
So the request of new WUs for GPU and CPU are not correct.
If I would let it automatically, the GPU get ~ the set WU cache, but the CPU get very much too much WUs.
So currently I need to set low WU cache, just let ask BOINC for WUs for CPU...
After I need to set a higher WU cache, just let ask BOINC for WUs for GPU...
So that BOINC have enough CPU and GPU WUs for similar time - but that's annoying.
Thanks.
Dirk Sadowski wrote:How big
)
This is normally a quite stable project with very few server problems and good work availability. Recently though there have been some problems with GPU work availability but hopefully the project will release a new GPU search soon that will help lessen the load on BRP4G where work might be sporadic.
I would recommend keeping a relatively small cache of work of up to say 3-4 days to bridge any problems arising on a Friday evening and lasting the weekend until the staff can fix it the next week. I myself gambles a bit and only have my cache set at 0.5 + 0.1 = 0.6 days and hardly ever run out of work.
No that's not possible to do with a app_config.xml file. See the documentation here about what that file is for and how to use it.
What you're thinking about is a app_info.xml file and that's normally used when you want to provide the science app yourself. I do not recommend using a app_info.xml file unless necessary to run a specific app as it makes the user responsible for keeping the science app updated when new versions are released by the project or new searches are started. And to my knowledge there are no CPU or GPU apps for PCs available beside the ones provided by the project. (There is an optimized app for the RPi3 but that's not relevant here.)
This is because Einstein@home is still relying on the single "Duration correction factor" or DCF per project in BOINC. This doesn't work well with multiple science apps and give the observed effects. As the deadlines around here usually are 14 days then keeping a relatively small cache should not put you in deadline trouble. Try to make an estimate of how many days your CPU work will last and if it's getting to close to 14 days then lower your cache a bit.
Dirk Sadowski wrote:I would
)
It depends on your internet and how you pay for it, some people pay less at night time so they would want a cache that gets them into those hours so it's cheaper. others pay the same all the time so it then depends on whether you have high speed cable or not, if you are on dial-up you would need a bigger cache than an always on high speed cable internet. I keep mine set at 0.5 for the first box and then -.25 for the 2nd box, that gives me just about a one day cache, more or less.
I don't know.
This will adjust over time as you crunch more workunits, but in some cases the workunits are hardwired by the programmers thinking they will take x amount of time and may never be real close to being exact.
It's a process that over time with the more units you crunch will get better, but it may never be perfect until the Boinc programmers separate the caches for the cpu's and gpu's. They have showed no interest in doing that though.
mikey wrote:It's a process
)
That's not quite true as "Credit new" incorporates a new way of keeping track of the performance of different apps on different hosts so will get the estimates quite right after the learning period is over. There are other problems with that system that prevents Einstein@home amongst others implementing it. So the problem has been addressed and the developers have shown an interest in fixing it. Then challenge now is getting Credit New fixed or replaced by a working system. Work on that is ongoing but sadly very slow.
Thanks to you both. Does
)
Thanks to you both.
Does this mean that Einstein have, or will get 'CreditNew' of SETI?
I'm an 'advanced' SETI user, have much experiences with app_info.xml file editing/usage.
I'm a perfectionist and would like (need to have - a 'must have'
) to have the real/correct estimated times in BOINC, that the work request and the WU cache are correct. 
I have one PC with CPU, Intel iGPU and NVIDIA GPU.
The other PC with CPUs and AMD GPUs.
Please could someone help me to make this two app_info.xml files?
Or it's just so easy to copy/paste the part out of the client_state.xml file?
BTW., I allowed 'beta apps' in the prefs - so I let run the 'beta apps'.
Thanks.
Dirk Sadowski wrote:Does this
)
Judging from the tests run on Einsteins test project Albert@home a couple of years ago, Einstein will not implement Credit New unless it's fixed or remade. There's just to many problems with the system as it is. Albert is still running Credit New but as that's a test project I would focus my crunching power here at the main project.
I'll have to defer that question to someone else as I'm not comfortable with writing app_info files.
Dirk Sadowski wrote:I'm an
)
And you're asking us to write one for you??
There has been very little need to write one of these here for many years unless you really do have an unsupported platform. If you're using one at SETI, you should know a lot more about what to do than most of us here. Good luck with that when app versions change quickly - as is very likely to happen here soon.
Just lose your perfectionism!
If you run ONLY one science app, DCF will achieve that but with two or more differerent apps (particularly mixed CPU and GPU) it will be impossible. However, there are strategies that can be used to minimise the difference between estimated time and true crunch time. These depend quite a lot on the exact nature of your hardware and how things are configured - eg is your CPU HT capable and do you have HT enabled? - do you run multiple concurrent GPU tasks? - do you tweak the number of CPU cores BOINC is allowed to use? - if so, exactly how do you do this? Your computers are hidden so it's impossible to give a firm suggestion without you telling us in a fair bit of detail, information about your systems. Unhiding them (at least temporarily) or telling us the host IDs would make things a lot easier.
Cheers,
Gary.