When I set it to a large queue like 5-10 days, all of them turned high priority. The client then would not download more as it thought they would not be completed in time, even with no extra tasks to run. I had to lower the queue down to 3-4 days tp turn the tasks back to normal priority and work downloaded.
Markfw
Moderator Emeritus, Elite Member
- May 16, 2002
- 25,560
- 14,515
- 136
Thanks ! That fixed my problem. Most systems have a problem with 192 cores !
VirtualLarry
No Lifer
- Aug 25, 2001
- 56,343
- 10,046
- 126
Uh-oh, why is our daily production behind now? My rig still appears to be running.
I should check sleep mode though.
The ISP didn't fix it. Instead, they removed the ETA.
Are we sure we've got the right City? For a while now, I haven't seen any of the other teams around...
;-P
Attachments
Markfw
Moderator Emeritus, Elite Member
- May 16, 2002
- 25,560
- 14,515
- 136
@StefanR5R . Below is stderr.txt. Can you tell if its running avx-512 ? This is in srbase
root@EPYC-9654:/var/lib/boinc-client/slots/173# more stderr.txt
10:23:19 (85272): wrapper (7.2.26012): starting
10:23:19 (85272): wrapper: running llr2_64 ( -oGerbicz=1 -d -oPgenInputFile=input.prp -oPgenOutputFile=primes.txt -oDiskWriteTime=10 -oOutputIterations=50000 -
oResultsFileIterations=99999999 -oCpuSupportsAVX512F=1, -t1)
root@EPYC-9654:/var/lib/boinc-client/slots/173#
root@EPYC-9654:/var/lib/boinc-client/slots/173# more stderr.txt
10:23:19 (85272): wrapper (7.2.26012): starting
10:23:19 (85272): wrapper: running llr2_64 ( -oGerbicz=1 -d -oPgenInputFile=input.prp -oPgenOutputFile=primes.txt -oDiskWriteTime=10 -oOutputIterations=50000 -
oResultsFileIterations=99999999 -oCpuSupportsAVX512F=1, -t1)
root@EPYC-9654:/var/lib/boinc-client/slots/173#
The wrapper supplied the respective option to the LLR2 exe, so I suppose the exe is indeed making use of AVX512 instructions.
I can't check right now though if the
I can't check right now though if the
, sign right after the 1 is just something written to stderr.txt, or if the wrapper passed 1, instead of 1 to the LLR2 exe.
Last edited:
Still way too soon and one particular strong team hasn't arrived to the city. Actually, they haven't even showed up at the Pent yet. Kind of weird.
We are looking strong on our javelin throws. Anyone reading this, if you didn't participate in the early part of our first javelin throw and want to join in then throw CPUs on youo@home ECM tasks and GPUs on PrimeGrid AP27 tasks and let her run.
It was also 93F in my apartment yesterday when I got home from work. So hot. Not sure I'm gonna fire up the toasters since it's already toasty enough.
It was also 93F in my apartment yesterday when I got home from work. So hot. Not sure I'm gonna fire up the toasters since it's already toasty enough.
Sprint
NumberFields@homehttp://numberfields.asu.edu/NumberFields/
2 Days 05:48:10
Until startStart: 13 May 2023 00:00 UTC
End: 16 May 2023 00:00 UTC
Distracted by SRBase. Also, the computers needed to be powered down for a few hours today.
What the heck. Changed my modest rigs to yoyo. See if I can get some gpus running tomorrow
Everyone start switching GPUs over to Einstein@Home. Bunkering is preferred right now, but not required. Wingman tasks might take a few days to validate in some cases.
Switch CPUs over to NF@home if you know how to bunker. Bunkering is required, otherwise wait till it starts.
Keep CPUs or put them on yoyo@home if not. No bunkering is required, but preferred here to wait for a bonus day. Otherwise, just let the host crunch wildly.
Abort any PG tasks you may have already downloaded if you are switching.
Switch CPUs over to NF@home if you know how to bunker. Bunkering is required, otherwise wait till it starts.
Keep CPUs or put them on yoyo@home if not. No bunkering is required, but preferred here to wait for a bonus day. Otherwise, just let the host crunch wildly.
Abort any PG tasks you may have already downloaded if you are switching.
Some fineprint:
If somebody needs to abort tasks on a project with a quorum of 2 (such as PrimeGrid AP27 and Einstein), please abort as early as possible. That way, another task of the workunit is sent out by the server sooner than later, giving your (former) wingman a chance that his task still gets validated in time.
Also, avoid abortions in massive quantities. BOINC projects may be set up such that they (1.) send replica tasks from affected workunits only to hosts which fulfil certain requirements with respect to recent turnaround rates of valid results, (2.) queue replica tasks in front of normal tasks. The outcome may be that overall work distribution gets nearly to a halt when there are large amounts of aborted tasks, which could require the project admin to manipulate some arcane settings of his BOINC server to get things moving again. — Edit, on most projects, mass abortions by a single user are not likely to reach extents with noticeable effects. But if several or many users abort many tasks at once, this can easily become a problem even on larger projects.
If somebody needs to abort tasks on a project with a quorum of 2 (such as PrimeGrid AP27 and Einstein), please abort as early as possible. That way, another task of the workunit is sent out by the server sooner than later, giving your (former) wingman a chance that his task still gets validated in time.
Also, avoid abortions in massive quantities. BOINC projects may be set up such that they (1.) send replica tasks from affected workunits only to hosts which fulfil certain requirements with respect to recent turnaround rates of valid results, (2.) queue replica tasks in front of normal tasks. The outcome may be that overall work distribution gets nearly to a halt when there are large amounts of aborted tasks, which could require the project admin to manipulate some arcane settings of his BOINC server to get things moving again. — Edit, on most projects, mass abortions by a single user are not likely to reach extents with noticeable effects. But if several or many users abort many tasks at once, this can easily become a problem even on larger projects.
Last edited:
My internet connectivity is still highly unreliable, and the ISP still did not state a new ETA of a fix. If I want to do anything slightly more involved than keep my computers going with a comfortably sized work buffer, I've got a lot of hand-holding to do. Figuring out that my connection just went down (because the modem-router usually does not detect that it lost connectivity*), resetting the modem (because it usually does not attempt to reconnect itself), waiting for the connection to come back, checking if any hosts need some nudges to resume stuck transfers and such. Which I obviously can't do at workdays and don't look forward to be doing on the weekend. >:-(
Unfortunately, the other ISPs here offer worse upload bandwidth than my current ISP's, which is already dismal for some traffic-intensive DC projects.
Dual contracts would be nice, if a contract could be had for just a short time like three weeks…
________
*) i.e., often doesn't detect it neither on the IP layer nor on the DOCSIS layer. Considering this, it seems quite possible that the modem-router firmware was intentionally crippled, so that the provider's systems don't have to deal with reconnection storms from their customers after a line went back up. If so, tossing the ISP supplied modem for a 3rd party modem might ease at least this part of the pains. Maybe.
Unfortunately, the other ISPs here offer worse upload bandwidth than my current ISP's, which is already dismal for some traffic-intensive DC projects.
Dual contracts would be nice, if a contract could be had for just a short time like three weeks…
________
*) i.e., often doesn't detect it neither on the IP layer nor on the DOCSIS layer. Considering this, it seems quite possible that the modem-router firmware was intentionally crippled, so that the provider's systems don't have to deal with reconnection storms from their customers after a line went back up. If so, tossing the ISP supplied modem for a 3rd party modem might ease at least this part of the pains. Maybe.
Last edited:
A lot of issues with a bad cable internet connection could be due to bad coaxial cables at the resident or bad splitters. Splitters is usually the culprit in this situation, especially splitters that are not capped off. I assume you live in a multi family unit (IE: Apartment) and the cables are probably out of your control on how good they are, but the splitters might be in the cable box outside of your apartment and in bad shape. Unless the enclosure is locked then it wouldn't be too hard to take a look inside and ensure its in good shape and the ports not used are capped off properly. If it looks rough I'd consider replacing it, although a bad splitter could look brand new and still be faulty.
We are good on the javelin throw. No more SRBase. Abort any outstanding tasks. Set no new tasks.
Throw CPUs on NumberFields@home.
Throw GPUs on Einstein@home. Gamma-ray pulsar binary search #1 on GPUs (FGRPB1G) tasks and BUNKER them. We got a little less than 24 hours before this starts. If you can't or don't want to bunker, then just let them run. Most of them will get caught up in validation status.
If CPUs are on Yoyo@home, you can leave them there if you want. Otherwise, you can switch them to Numberfields@home. We currently have a 25% bonus day on yoyo so you might as well leave them there until then.
-25% isn't worth moving CPUs off Numberfields@Home. If you are running Numberfields@Home, leave them. If you were running SRBase on CPUs, then move them to Numberfields.
Throw CPUs on NumberFields@home.
Throw GPUs on Einstein@home. Gamma-ray pulsar binary search #1 on GPUs (FGRPB1G) tasks and BUNKER them. We got a little less than 24 hours before this starts. If you can't or don't want to bunker, then just let them run. Most of them will get caught up in validation status.
If CPUs are on Yoyo@home, you can leave them there if you want. Otherwise, you can switch them to Numberfields@home. We currently have a 25% bonus day on yoyo so you might as well leave them there until then.
-25% isn't worth moving CPUs off Numberfields@Home. If you are running Numberfields@Home, leave them. If you were running SRBase on CPUs, then move them to Numberfields.
Last edited:
Orange Kid
Elite Member
- Oct 9, 1999
- 4,328
- 2,112
- 146
Orange Kid
Elite Member
- Oct 9, 1999
- 4,328
- 2,112
- 146
- Dec 11, 1999
- 16,250
- 3,845
- 75
This, in particular, preferably on the "Gamma-ray pulsar binary search #1 on GPUs (FGRPB1G)" sub-project. We're falling behind the "GPU Users Group" team!
And see our Discord channel if you want more tips.
Orange Kid
Elite Member
- Oct 9, 1999
- 4,328
- 2,112
- 146
TRENDING THREADS
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 10K
-
Discussion Speculation: Zen 4 (EPYC 4 "Genoa", Ryzen 7000, etc.)- Started by Vattila
- Replies: 13K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes Discussion Threads
- Started by Tigerick
- Replies: 7K
-
Facebook
Twitter