Yes it does. My cache is set to 1.0/0.01. These take about 5 minutes to run. There's 1,440 minutes in a day so I requested 288 WUs. It sent me me 1,100 before I set Resource to zero to stop it. That's far too many and far more than BOINC should have asked for.
Yes it does. .... It sent me me 1,100 before I set Resource to zero to stop it.
There you go again - blaming the project for something the project has no control over :-).
People less experienced than you will interpret your comment as the project going rogue when it's really your boinc client that has gone rogue.
There are two broad possibilities. Either there are hard to fix bugs in BOINC that trigger repeated excess requests under certain hard to diagnose (or perhaps unusual) user configurations or somehow your work cache settings are not what you think they are. Since behaviour like you describe has been reported quite a few times in the past, I think it's most likely the first one.
I don't recall ever seeing this problem directly but I think people who did were able to fiddle with settings to avoid the conditions that seemed to trigger the excess work requests. Maybe someone might know details about that or if there is any ongoing work to fix the problem by whoever is maintaining BOINC these days.
If the problem is on one or more of your Linux systems and you have app_config.xml files for Einstein with either <max_concurrent> or <project_max_concurrent> statements, try upgrading your BOINC client to 7.20.2 or later...
There was a known problem where the client didn't properly account for existing work for projects using either of those directives - the result was that it would request more work each time there was contact with the project. OOPS!
The problem has been discussed in great detail on the forums at several projects - I'm a bit surprised you've never come across mention of it somewhere else :-)
As for Windows - I'm not sure if the fix has found its way into the current client (I am not a Windows user) -- I think it only landed in the Linux client some time relatively late in 2022...
If that isn't the cause of your problem, I don't know what else to suggest...
Yes, the current Master branch at client_release/7/7.20 contains the fix for Issue #4592 client: fix work-fetch logic when max concurrent limits are used since December 7, 2021.
Quick update: the GPU-based run O3MDF finished over the weekend.
We're trying to set up a worthy successor as soon as we can but are a bit short on (human) resources right now. Please bear with us and thanks for everyone who made O3MDF such a quick one!
Ive had over 1000 MULTI-DIRECTIONAL GRAVITATIONAL WAVE SEARCH ON O3 DATA (O3MD1/F) errors last few days. It will download, then immediately error out. AMD, Windows 11.
Gary Roberts wrote: Aurum
)
Yes it does. My cache is set to 1.0/0.01. These take about 5 minutes to run. There's 1,440 minutes in a day so I requested 288 WUs. It sent me me 1,100 before I set Resource to zero to stop it. That's far too many and far more than BOINC should have asked for.
Thanks Bernd - my host is now
)
Thanks Bernd - my host is now receiving O3MDF WUs again
getting WU too, and no errors
)
getting WU too, and no errors on Nvidia/Windows hosts.
thank you !!
Aurum wrote:Yes it does. ....
)
There you go again - blaming the project for something the project has no control over :-).
People less experienced than you will interpret your comment as the project going rogue when it's really your boinc client that has gone rogue.
There are two broad possibilities. Either there are hard to fix bugs in BOINC that trigger repeated excess requests under certain hard to diagnose (or perhaps unusual) user configurations or somehow your work cache settings are not what you think they are. Since behaviour like you describe has been reported quite a few times in the past, I think it's most likely the first one.
I don't recall ever seeing this problem directly but I think people who did were able to fiddle with settings to avoid the conditions that seemed to trigger the excess work requests. Maybe someone might know details about that or if there is any ongoing work to fix the problem by whoever is maintaining BOINC these days.
Cheers,
Gary.
Aurum,If the problem is
)
Aurum,
If the problem is on one or more of your Linux systems and you have app_config.xml files for Einstein with either <max_concurrent> or <project_max_concurrent> statements, try upgrading your BOINC client to 7.20.2 or later...
There was a known problem where the client didn't properly account for existing work for projects using either of those directives - the result was that it would request more work each time there was contact with the project. OOPS!
The problem has been discussed in great detail on the forums at several projects - I'm a bit surprised you've never come across mention of it somewhere else :-)
As for Windows - I'm not sure if the fix has found its way into the current client (I am not a Windows user) -- I think it only landed in the Linux client some time relatively late in 2022...
If that isn't the cause of your problem, I don't know what else to suggest...
Cheers - Al.
Yes, the current Master
)
Yes, the current Master branch at client_release/7/7.20 contains the fix for Issue #4592 client: fix work-fetch logic when max concurrent limits are used since December 7, 2021.
Commits in current Master branch 7.20
Have 2 tasks on 1 PC so far
)
Have 2 tasks on 1 PC so far that have error with "Errors:Canonical result is missing"
Not sure what could be causing the error after running to completion.
HOST 12885789 Einstein running under WINE Winodws emulator.
WORKUNIT 701645572
WORKUNIT 701642380
Quick update: the GPU-based
)
Quick update: the GPU-based run O3MDF finished over the weekend.
We're trying to set up a worthy successor as soon as we can but are a bit short on (human) resources right now. Please bear with us and thanks for everyone who made O3MDF such a quick one!
Cheers,
Oliver
Einstein@Home Project
Ive had over
)
Ive had over 1000 MULTI-DIRECTIONAL GRAVITATIONAL WAVE SEARCH ON O3 DATA (O3MD1/F) errors last few days. It will download, then immediately error out. AMD, Windows 11.
TASK ID WORKUNIT
)
ApplicationAll applications (1186)Gamma-ray pulsar binary search #1 on GPUs (0)Multi-Directional Gravitational Wave search on O3 (GPU) (1186)