Yeah the estimated Flops of the GW are really low compared to GR, which gives them less credit.
GW tasks are also more bottlenecked by the CPU, so any particular GPU on a slow CPU will be slower than the same GPU on a faster CPU. Which can worsen the effect of low credits.
GR is the most consistent sub-project. Tons of participation reduces validation latency. Credit reward drives the participation for the majority of users.
GW will continue to have validation and wingmen issues due to low participation that stems from the effective 10x lower credit reward (~3.5x lower credit per task, plus longer running tasks).
I think if the Einstein project values the two sub-projects equally, they should normalize the reward given per unit time to encourage more or less equal participation
The GRP work is also more self-contained. There is only a single data file needed on all hosts for all tasks. So that file is static on all hosts. So any task sent can be computed on any host attached to that sub-project and the turnaround time for validation is very low, often less than a day.
The GW application needs specific data files for each sub-species of task. The project does not ship all possible data files to all hosts because the download bandwidth would be extremely demanding and not possible.
So the project employs a method of task assignment called locality scheduling. It needs to send the same type of sub-species of tasks you have residing on your hosts to other hosts that already have the same sub-species of task data files. That can take a lot of time finding the matching hosts that have those data files because those hosts may not be on 24/7 or only connect with the project every few days. So the turnaround time for validation on the GW project is magnitudes longer than for GRP.
The GRP work is also more self-contained. There is only a single data file needed on all hosts for all tasks. So that file is static on all hosts. So any task sent can be computed on any host attached to that sub-project and the turnaround time for validation is very low, often less than a day.
. . Hi Keith,
. . Generally that is true but there are many hosts out there set to maximum work fetch and with a 14 day dead line these hosts have errors in double or triple digits due to timeouts because they have been allotted enough work to keep them busy for 20 days. When you get 2 or 3 of these rigs as wingmen your result can still sit in pending for months.
. . The oldest task in my valid list is from the 3rd November, just because the first two wingmen defaulted on the deadline and the 3rd took over 4 days to complete because even they were sitting on almost 900 tasks in progress. Thankfully that translated to ONLY 4 days to completion. I have had 3 defaulters on some tasks.
. . The oldest task in my pending list only dates from the 5th November. ... :)
. . This was always a pet peeve of mine from over at Seti@Home but it makes no sense to hoard more work than can be completed within the deadline. So maybe restricting work fetch to 5/5 instead of 10/10 would eliminate that delay somewhat.
My oldest task is from 27 October and has been through the rounds of 3 task hoarders that never started before deadline. Currently out as a _04 to a wingman with a reasonable .75 day turnaround. That one should fall off the list in a day.
Currently pending tasks are 1/3 the count of my validated tasks. But since I carry a very low 30 task cache, my turnaround for all my PC hosts is only 1.5 hours.
You can't do anything about newbies that don't understand how BOINC works and just run a host with defaults, but I agree that BOINC has not kept up with the evolution of PC hardware. No need for a 10 day cache anymore.
Since you can't do anything about that, why worry about it?
You can't do anything about newbies that don't understand how BOINC works and just run a host with defaults, but I agree that BOINC has not kept up with the evolution of PC hardware. No need for a 10 day cache anymore.
Since you can't do anything about that, why worry about it?
I definitely agree, Keith. Here is an example of what newbies are doing; and this one happens to be anonymous:
The "ERROR (201)" are all 'not started by deadline - canceled'.
I, too, have about 1:3 pending/validated tasks with 50 in my cache.
My oldest task in "Pending" is from Nov 10, and it is waiting it's third wingman, which will probably complete and validate the task because he is NOT a newbie.
I have every expectation that I am making multiple newbie mistakes, but in my defense, whenever I run a search on these forums, the first 10 responses are for "Word Link", which seems like some sort of harmless game that has no real utility here.
Does the Einstein team have a page dedicated to optimized settings for each common hardware/OS arrangement, listed by CPU/GPU/OS? This would not be an infinite list:
Since the issues we are discussing is solely related to BOINC and not any one project, the best information or FAQs are at SETI@home since that project is the genesis of BOINC.
Generally for Einstein and most other projects you should set your cache size to a very small number. Like 0.1-0.2 days or even lower. Set additional days to zero since most everyone is running a host where network is available continuously.
This is a very stable project that always has work available and probably 99.5% uptime on its servers. There is absolutely no reason to bank large amounts of work since new work is always available. You should strive for a 1 for 1 situation, complete a task, turn it in, and receive its replacement.
None of the work here is fast running. Always on the order of minutes to hours to complete a task. The only projects I am familiar with that had tasks running in seconds was Seti with the special app and Milkyway. MW solved the short running tasks by bundling 4 or 5 together in a work unit. Those projects are the only ones that would need a larger cache of work since a host would complete its cache in a very short time.
There are no application settings for work here at Einstein. A task is what it is as delivered by the project.
... GR tasks also need
)
... GR tasks also need Wingmen to "complete" ...
Check the properties of a running task/WU and please notice the "Estimated computation size" of
GW and GR tasks.
That is difference which accounts for the more or less point/credits.
Yeah the estimated Flops of
)
Yeah the estimated Flops of the GW are really low compared to GR, which gives them less credit.
GW tasks are also more bottlenecked by the CPU, so any particular GPU on a slow CPU will be slower than the same GPU on a faster CPU. Which can worsen the effect of low credits.
GR is the most consistent sub-project. Tons of participation reduces validation latency. Credit reward drives the participation for the majority of users.
GW will continue to have validation and wingmen issues due to low participation that stems from the effective 10x lower credit reward (~3.5x lower credit per task, plus longer running tasks).
I think if the Einstein project values the two sub-projects equally, they should normalize the reward given per unit time to encourage more or less equal participation
_________________________________________________________________________
The GRP work is also more
)
The GRP work is also more self-contained. There is only a single data file needed on all hosts for all tasks. So that file is static on all hosts. So any task sent can be computed on any host attached to that sub-project and the turnaround time for validation is very low, often less than a day.
The GW application needs specific data files for each sub-species of task. The project does not ship all possible data files to all hosts because the download bandwidth would be extremely demanding and not possible.
So the project employs a method of task assignment called locality scheduling. It needs to send the same type of sub-species of tasks you have residing on your hosts to other hosts that already have the same sub-species of task data files. That can take a lot of time finding the matching hosts that have those data files because those hosts may not be on 24/7 or only connect with the project every few days. So the turnaround time for validation on the GW project is magnitudes longer than for GRP.
Keith Myers wrote: The GRP
)
. . Hi Keith,
. . Generally that is true but there are many hosts out there set to maximum work fetch and with a 14 day dead line these hosts have errors in double or triple digits due to timeouts because they have been allotted enough work to keep them busy for 20 days. When you get 2 or 3 of these rigs as wingmen your result can still sit in pending for months.
. . The oldest task in my valid list is from the 3rd November, just because the first two wingmen defaulted on the deadline and the 3rd took over 4 days to complete because even they were sitting on almost 900 tasks in progress. Thankfully that translated to ONLY 4 days to completion. I have had 3 defaulters on some tasks.
. . The oldest task in my pending list only dates from the 5th November. ... :)
. . This was always a pet peeve of mine from over at Seti@Home but it makes no sense to hoard more work than can be completed within the deadline. So maybe restricting work fetch to 5/5 instead of 10/10 would eliminate that delay somewhat.
. . Just my 2 cents worth ...
Stephen
My oldest task is from 27
)
My oldest task is from 27 October and has been through the rounds of 3 task hoarders that never started before deadline. Currently out as a _04 to a wingman with a reasonable .75 day turnaround. That one should fall off the list in a day.
Currently pending tasks are 1/3 the count of my validated tasks. But since I carry a very low 30 task cache, my turnaround for all my PC hosts is only 1.5 hours.
You can't do anything about newbies that don't understand how BOINC works and just run a host with defaults, but I agree that BOINC has not kept up with the evolution of PC hardware. No need for a 10 day cache anymore.
Since you can't do anything about that, why worry about it?
+1
)
+1
Keith Myers
)
I definitely agree, Keith. Here is an example of what newbies are doing; and this one happens to be anonymous:
The "ERROR (201)" are all 'not started by deadline - canceled'.
I, too, have about 1:3 pending/validated tasks with 50 in my cache.
My oldest task in "Pending" is from Nov 10, and it is waiting it's third wingman, which will probably complete and validate the task because he is NOT a newbie.
Proud member of the Old Farts Association
... not only newbies are in
)
... not only newbies are in for this !
I have every expectation that
)
I have every expectation that I am making multiple newbie mistakes, but in my defense, whenever I run a search on these forums, the first 10 responses are for "Word Link", which seems like some sort of harmless game that has no real utility here.
Does the Einstein team have a page dedicated to optimized settings for each common hardware/OS arrangement, listed by CPU/GPU/OS? This would not be an infinite list:
Intel/ATI/Windows, Intel/Nvidia/Windows, Intel/Intel/Windows, Intel/ATI/Linux, Intel/Nvidia/Linux, Intel/Intel/Linux
AMD/ATI/Windows, AMD/Nvidia/Windows, AMD/ATI/Linux, AMD/Nvidia/Linux
Such a page could be linked under the FAQ page, which seems to have some old information.
Thank you for your patience with my newbieness
[img]Since the issues we are
)
Since the issues we are discussing is solely related to BOINC and not any one project, the best information or FAQs are at SETI@home since that project is the genesis of BOINC.
Generally for Einstein and most other projects you should set your cache size to a very small number. Like 0.1-0.2 days or even lower. Set additional days to zero since most everyone is running a host where network is available continuously.
This is a very stable project that always has work available and probably 99.5% uptime on its servers. There is absolutely no reason to bank large amounts of work since new work is always available. You should strive for a 1 for 1 situation, complete a task, turn it in, and receive its replacement.
None of the work here is fast running. Always on the order of minutes to hours to complete a task. The only projects I am familiar with that had tasks running in seconds was Seti with the special app and Milkyway. MW solved the short running tasks by bundling 4 or 5 together in a work unit. Those projects are the only ones that would need a larger cache of work since a host would complete its cache in a very short time.
There are no application settings for work here at Einstein. A task is what it is as delivered by the project.