Strange FGRPSSE runtimes
22 Mar 2020 23:47:31 UTC
Topic 221298
(moderation:
The FGRPSSE tasks I've downloaded during about the last week all seemed to have an initial expected runtime of about 35 hours, but actually ran in about a tenth of that time.
Is there some reason why the expected runtimes are not shifting closer and closer to the actual runtimes?
robertmiles wrote:Is there
)
Probably because the correction is extremely large and BOINC may have been programmed to be cautious when an apparently large correction exists.
You are supposed to see a correction of 10% of the difference for each completed task when the correction is a reduction. For the numbers you quote that correction would amount to an estimate reduction of around 3 hours, per task. Not surprising that BOINC might be a bit cautious about doing that. I seem to recall (a long time ago) that I saw a similar reluctance to making such a large correction, under similar crazy circumstances.
I didn't persist with the problem since it's fairly straight forward to stop BOINC and edit the errant DCF (duration correction factor) in the state file (client_state.xml). From what you say, I would expect you to find a value somewhere around 5 to 10. In that case you could change the value to 10% of what it currently reads (keeping the field width exactly the same) and then restart BOINC. Be aware (depending on your work cache settings) you may get a bunch of new tasks with such a large change. It would be a good idea to temporarily reduce the cache size before shutting down to do the edit. That way you shouldn't get a nasty surprise on restart. If the DCF is not of the order I've mentioned, you should post further information before making any change.
Editing the state file has certain risks if you are not careful. It's not standard procedure. You need to use a plain text editor and be very sure of what you change. The risk is all yours :-).
Cheers,
Gary.
I've got a similar problem
)
I've got a similar problem with these tasks on my Windows machine
I'm fairly new to this project, I can't seem to find a forum Search either.
Can someone help please ?
Keith T. wrote:I've got a
)
If you look at the very top of the page on which you are reading this, you'll see the menu bar. Over on the right hand end is the search function. If you open that in a new tab you can perform a search whilst continuing to read here.
However, in this case, it may be a bit difficult for you to find something meaningful so I'll try to summarise.
Your machine has a 1.44GHz quad core Intel Atom processor. It's going to really struggle if you attempt to run GW tasks on it. You actually have one that completed and validated but it took around 2.5 days. There are several others that ended fairly quickly as compute errors. You need to deselect that search and just use the GRP search. That very slow finishing GW task will have caused the estimates for everything else to have blown out to much larger values. BOINC will correct that over time as you complete more faster finishing tasks.
You also have GRP tasks (CPU cores) and BRP4 tasks which use the internal Intel GPU. If you look at the times for the GRP tasks, they are mostly between 33ksecs and 46ksecs. There was one that got to 59ksecs before you aborted it. If you had allowed it to finish, it probably would have been quite OK, just a bit slow.
The reason why that task was slow was probably to do with the use of the Intel GPU for BRP4 tasks. The intel GPU is part of the CPU and its use will tend to slow down the CPU tasks if you try to use all cores. You have to experiment to find a suitable mix. By all means run the BRP4 tasks on the Intel GPU if you wish but then be careful about how many concurrent CPU tasks you also run. Start with just one and see what times you get. Then try two, and so on. At some point you will probably get a big slowdown effect, perhaps on both CPU task times and GPU task times. It's only by doing the experiments that you will be able to select the best combination for your hardware.
Hope some of this helps. If you haven't already seen it, there's also a sticky thread in the "Getting Started" forum with some basic information to do with transitioning to this project.
Cheers,
Gary.
Thanks for the reply Gary.I
)
Thanks for the reply Gary.
I had already tried Suspending most of the LATeah1017F tasks because I have seen the estimated run times increasing from around 11 or 12 hours to 11 or 12 DAYS !
I have used fairly low end devices previously, mainly on SETI, but also on this, and about 10 other BOINC projects. I am aware of deadlines, quorums, checkpoints, etc
My GPU tasks on Einstein have been mostly very successful, but I have seen long and erratic runtime estimates on CPU
I found the main Site Search, but most other projects also have a Forum Search as well, is that not available on Einstein ?
I got better results when I just did a Google search on the term LATeah run time.
Is the most important limitation RAM or CPU usage ? Storage space doesn't seem to be a problem, unlike some Rosetta tasks.
I have now switched Einstein to GPU only for the moment, but I will attempt to complete my remaining CPU tasks
[Edit 2] I think I now understand the Search on this site, I didn't notice the Advanced options before.
I found this recent reply https://einsteinathome.org/comment/reply/221917/176616 which seems to answer my questions better.
Keith T. wrote:I had already
)
FGRP5 tasks have been running for a long time and there's no 'history' of them doing that sort of thing. Bit of a strange one, for sure.
It's always hard to know how much detail to give. I'm always conscious of the 'lurkers' so I'd rather overdo it than under-explain. It's easier just to skip the not-needed stuff.
Probably a legacy of Einstein's single DCF.
Either or both or neither - depending on the nature of your hardware :-). There is really 'no one size fits all' type of answer. The only thing to do is experiment to see what gives the best results. In the past that was easier as tasks seemed to have fairly stable and predictable properties. With the advent of the latest GW stuff, that seems to have changed significantly.
I'm glad you found it useful. It's really nice to know that others also get some benefit by my going into extra detail on specific questions where I know the cause.
Cheers,
Gary.