INTEL Arc.

Paul
Paul
Joined: 3 May 07
Posts: 129
Credit: 1835442877
RAC: 491766

Ah, okay.  Yes, now I'm

Ah, okay.  Yes, now I'm getting them.  Thanks.

[AF>EDLS]zOU
[AF>EDLS]zOU
Joined: 5 May 15
Posts: 80
Credit: 389293933
RAC: 193015

ARC A750 20157  

ARC A750

20157    Einstein@Home    2/6/2025 7:35:32 PM    Reporting 442 completed tasks    
20158    Einstein@Home    2/6/2025 7:35:32 PM    Requesting new tasks for Intel GPU    
20160    Einstein@Home    2/6/2025 7:35:34 PM    Scheduler request completed: got 0 new tasks    
20162    Einstein@Home    2/6/2025 7:35:34 PM    (reached daily quota of 960 tasks)    
 

 

this sucks ....

AndreyOR
AndreyOR
Joined: 28 Jul 19
Posts: 81
Credit: 770252570
RAC: 1011332

[AF>EDLS wrote:zOU] ARC

[AF>EDLS wrote:

zOU]

ARC A750

20157    Einstein@Home    2/6/2025 7:35:32 PM    Reporting 442 completed tasks    
20158    Einstein@Home    2/6/2025 7:35:32 PM    Requesting new tasks for Intel GPU    
20160    Einstein@Home    2/6/2025 7:35:34 PM    Scheduler request completed: got 0 new tasks    
20162    Einstein@Home    2/6/2025 7:35:34 PM    (reached daily quota of 960 tasks)    
 

 

this sucks ....

Interesting, didn't know there was a limit.  At the pace the A750 gets thru BRP4's, you could do >1600 tasks a day. Excellent validation rate too.

[AF>EDLS]zOU
[AF>EDLS]zOU
Joined: 5 May 15
Posts: 80
Credit: 389293933
RAC: 193015

yes all validsI got 2k

yes all valids
I got 2k aborted CPU tasks because I was sent way too many....

 

GWGeorge007
GWGeorge007
Joined: 8 Jan 18
Posts: 3200
Credit: 5225966723
RAC: 4384156

[AF>EDLS wrote:zOU] yes all

[AF>EDLS wrote:

zOU]

yes all valids
I got 2k aborted CPU tasks because I was sent way too many....

I'll assume you're talking about Computer #13213247

You do have an <app_config.xml> file set up in your project's folder, don't you?  If not, try setting one up.

In that file you might try a statement like  --fetch_minimal_work  which means:

Fetch only enough jobs to use all device instances (CPU, GPU). Used with --exit_when_idle, the client will use all devices (possibly with a single multicore job), then exit when this initial set of jobs is completed.

If you haven't already, take a look at this website:  https://boinc.ssl.berkeley.edu/wiki/Client_configuration 

I hope this helps!

George

Proud member of the Old Farts Association

Ian&Steve C.
Ian&Steve C.
Joined: 19 Jan 20
Posts: 4155
Credit: 50084964887
RAC: 42318330

George that argument will not

George that argument will not go in the app_config file in that format. 
 

app_config is an xml file so everything in there needs to be an xml parsable element. So they need appropriate tags. The equivalent of your command will be like this in the options section <fetch_minimal_work>1</fetch_minimal_work>

 

the way you’ve written it is the syntax for use with the boinc executable startup arguments. 

_________________________________________________________________________

GWGeorge007
GWGeorge007
Joined: 8 Jan 18
Posts: 3200
Credit: 5225966723
RAC: 4384156

Ian&Steve C. wrote: George

Ian&Steve C. wrote:

George that argument will not go in the app_config file in that format. 
 

app_config is an xml file so everything in there needs to be an xml parsable element. So they need appropriate tags. The equivalent of your command will be like this in the options section <fetch_minimal_work>1</fetch_minimal_work>

 

the way you’ve written it is the syntax for use with the boinc executable startup arguments. 

Ahhh...  I see what happened.  Thanks for pointing that out for me.

George

Proud member of the Old Farts Association

AndreyOR
AndreyOR
Joined: 28 Jul 19
Posts: 81
Credit: 770252570
RAC: 1011332

[AF>EDLS wrote:zOU] yes all

[AF>EDLS wrote:

zOU]

yes all valids
I got 2k aborted CPU tasks because I was sent way too many....

 

What I think is happening is that ARC750 runs BRP4s so fast and goes thru so many of them that it significantly skews down BOINC's projections of how long FGRP5 tasks take.  So BOINC requests way too many and your aborts get into thousands.  It'd be good to find a way to avoid that as it's wasteful.  I don't think you need to adjust any configuration files; I'd say try the following ideas:

  • Significantly reduce your cache settings, maybe start with .5+0.  FGRP5 tasks have a 2 week deadline, so you can probably handle a cache of ~100 tasks per CPU thread you allow for that project.
  •  
  • Reduce resource share to E@H, maybe even to 0, so that BOINC requests only minimal amount of work. This should have a bigger effect if you have other BOINC projects crunching.
  •  
  • On the website, in Project Preferences, select only the BRP4 application, and Yes to allow non-preferred work. I think this should reduce the amount of FGRP5s you get.  If not, try other combinations of BRP4, FGRP5, & non-preferred work settings. I've noticed that different settings combinations give you different distribution of work. 
[AF>EDLS]zOU
[AF>EDLS]zOU
Joined: 5 May 15
Posts: 80
Credit: 389293933
RAC: 193015

I had to abort thousands of

I had to abort thousands of CPU tasks as E@H wouldn't give me GPU tasks any longer ... that seems fixed since I set cache to 1+0
Will try 0.5+0

mikey
mikey
Joined: 22 Jan 05
Posts: 12941
Credit: 1884483078
RAC: 27938

[AF>EDLS wrote:zOU] I had to

[AF>EDLS wrote:

zOU]

I had to abort thousands of CPU tasks as E@H wouldn't give me GPU tasks any longer ... that seems fixed since I set cache to 1+0
Will try 0.5+0

This has been a long standing problem with Boinc, they use one single cache for both the cpu and gpu tasks!!

I myself has one pc running short gpu tasks that refuses to get any cpu tasks at all, I want to run the gpu tasks so am not going to abort them but it sure is a pain.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.