I previously was running both Seti and Asteroids on my PC, and found that often Asteroids would take over the entire PC (4 processors) for days at a time while running work units at "high priority". My preferences were set to share work equally. I then stopped processing A@H work units because it was starving the S@H project.
-
Recently I put a new PC in service (4 more processors) and tried setting the shares to allow A@H to use 25% of the CPUs and S@H to use 75% of the CPUs.
-
I found that with just 20 work units downloaded on one PC A@H now has taken over the entire machine and is running 4 work units at "high priority" with the previously running seti work units as "waiting to run"
-
I have noticed that all the work units from Asteroids have a deadline of 4 June, just 10 days away, while the Seti work units have deadlines from 6 June to 18 July. The only thing I can see that could be reasonably expected to cause the hogging of the CPUs by Asteroids is the short turn-around time imposed by the close-in deadlines on newly downloaded work.
-
Has anyone else experienced this type of hogging of their machines by A@H when running 2 or more projects?
-
I cannot reasonably share work between 2 projects when one hogs all the CPU time and starves the other. The situation currently has me manually restricting the work being done for Asteroids -- far from ideal.

I previously was running both Seti and Asteroids on my PC, and found that often Asteroids would take over the entire PC (4 processors) for days at a time while running work units at "high priority". My preferences were set to share work equally. I then stopped processing A@H work units because it was starving the S@H project.
-
Recently I put a new PC in service (4 more processors) and tried setting the shares to allow A@H to use 25% of the CPUs and S@H to use 75% of the CPUs.
-
I found that with just 20 work units downloaded on one PC A@H now has taken over the entire machine and is running 4 work units at "high priority" with the previously running seti work units as "waiting to run"
-
I have noticed that all the work units from Asteroids have a deadline of 4 June, just 10 days away, while the Seti work units have deadlines from 6 June to 18 July. The only thing I can see that could be reasonably expected to cause the hogging of the CPUs by Asteroids is the short turn-around time imposed by the close-in deadlines on newly downloaded work.
-
Has anyone else experienced this type of hogging of their machines by A@H when running 2 or more projects?
-
I cannot reasonably share work between 2 projects when one hogs all the CPU time and starves the other. The situation currently has me manually restricting the work being done for Asteroids -- far from ideal.

Boinc doesn't work like that! Boinc tries to accommodate your 25% setting, for example, not thru actual crunching but by monitoring your recent daily credits and letting one project crunch more until it reaches that 25% setting on a daily basis. Give your pc some time and it WILL work itself out, barring any lack of units being available at one project or another, over time. Lack of units will just make the time frame longer.

The reason your units are running at 'high priority' is because Boinc thinks if it doesn't run those units NOW they won't be finished prior to their deadline. One solution would be to reduce your cache settings to just one or two days, that way with projects having a seven day deadline you should never see the 'high priority' crunching again. My pc cache settings are 0.50 for the first box and 0.25 for the 2nd box, that way I have about a one day cache and never see the 'high priority' crunching takeover.

The varying deadlines at the different projects is a long standing problem in Boinc, one project has a 7 day deadline for it's units while another project has a 3 day deadline. Trying to manage multiple projects with widely varying deadlines on a single pc is why alot of us went to multiple pc's, that way we can run one project on each pc. Or we can put all of our pc's on one project and quickly crunch alot of units.

What we want, but hasn't been made available as of yet, is the ability to crunch project A on X number of cpu cores and project B on some other cpu cores, with the cores being dormant if the project doesn't having any units. There are LOTS of other priorities right now, with the project percentage one being an ongoing work in progress.

The reason your units are running at 'high priority' is because Boinc thinks if it doesn't run those units NOW they won't be finished prior to their deadline. One solution would be to reduce your cache settings to just one or two days, that way with projects having a seven day deadline you should never see the 'high priority' crunching again. My pc cache settings are 0.50 for the first box and 0.25 for the 2nd box, that way I have about a one day cache and never see the 'high priority' crunching takeover.

The varying deadlines at the different projects is a long standing problem in Boinc, one project has a 7 day deadline for it's units while another project has a 3 day deadline. Trying to manage multiple projects with widely varying deadlines on a single pc is why alot of us went to multiple pc's, that way we can run one project on each pc. Or we can put all of our pc's on one project and quickly crunch alot of units.

Thanks for the reply.

I will try reducing the cache to one day and see if that changes the behavior.
I was previously in an area where I had only intermittent connectivity and to keep the machine busy I set the cache to 6 days. Now that I have much better connectivity I can try lowering the setting and see what happens.

Your comment about the deadlines seems to support what I had already surmised in that it was the likely cause of the problem. The size of my cache both earlier and now would seem to support that premise. However, I will have to process and reduce the current cache before I can really see what the usage balances out to. Will see what happens and let you know.

The reason your units are running at 'high priority' is because Boinc thinks if it doesn't run those units NOW they won't be finished prior to their deadline. One solution would be to reduce your cache settings to just one or two days, that way with projects having a seven day deadline you should never see the 'high priority' crunching again. My pc cache settings are 0.50 for the first box and 0.25 for the 2nd box, that way I have about a one day cache and never see the 'high priority' crunching takeover.

The varying deadlines at the different projects is a long standing problem in Boinc, one project has a 7 day deadline for it's units while another project has a 3 day deadline. Trying to manage multiple projects with widely varying deadlines on a single pc is why alot of us went to multiple pc's, that way we can run one project on each pc. Or we can put all of our pc's on one project and quickly crunch alot of units.

Thanks for the reply.

I will try reducing the cache to one day and see if that changes the behavior.
I was previously in an area where I had only intermittent connectivity and to keep the machine busy I set the cache to 6 days. Now that I have much better connectivity I can try lowering the setting and see what happens.

That is a problem for alot of people, the lack of a good consistent connection, I am glad yours is not much better!

Your comment about the deadlines seems to support what I had already surmised in that it was the likely cause of the problem. The size of my cache both earlier and now would seem to support that premise. However, I will have to process and reduce the current cache before I can really see what the usage balances out to. Will see what happens and let you know.

You could abort some of the units if it is causing a huge problem, but just crunching thru them is best if you can. I am interested in the outcome of this.

An update on this, though still far from stabilized.
I let it crunch through the units already here, and today, after working through about 3 days of Seti work units already on the system, this machine finally downloaded 4 Asteroids units, promptly put the 4 Seti units already in progress on hold, and is now working through the new Asteroids units, using all 4 processors.
Oh, did I mention that one of the processors is dedicated to the VM I have running, so it actually is running 4 work units on 3 processors -- go figure. Sure does keep all the processors busy though - LOL. Don't know what effect that will have on averages or total throughput yet.

An update on this, though still far from stabilized.
I let it crunch through the units already here, and today, after working through about 3 days of Seti work units already on the system, this machine finally downloaded 4 Asteroids units, promptly put the 4 Seti units already in progress on hold, and is now working through the new Asteroids units, using all 4 processors.
Oh, did I mention that one of the processors is dedicated to the VM I have running, so it actually is running 4 work units on 3 processors -- go figure. Sure does keep all the processors busy though - LOL. Don't know what effect that will have on averages or total throughput yet.

There is just no way to make Boinc crunch some of both kinds of units all the time, it is trying to even out the Recent Daily Credits and with different deadlines, credits being awarded etc, etc what you are seeing is normal.

Now why it's crunching 4 units on 3 cores I have no idea, unless you have Boinc setup to use all of your cpu cores and start the VM after Boinc is up and running. IF that's what you are doing trying changing Boinc to only use 3 of the 4 cpu cores, in the Boinc Manager, and then next time you reboot the pc only 3 units should run at a time, reserving the other core for your VM.

Can you help me to understand something more about this?

It has been my understanding that boinc is supposed to balance CPU usage to the percentages configured in a users preferences.
I have mine set for 75% seti and 25% asteroids, and it shows as such on the projects screen. I also have it saving only one day cache, so it should be in balance even on the daily credits.

Yet after over a week of running with this machine at those settings, boinc is still downloading and giving priority to asteroids. Asteroids is far ahead of seti on total credits, almost 500,000 for asteroids, compared to only 340,000 for seti; and has moved ahead by a more than a 2:1 ratio on user and host averages as well.

I stand by my initial comment, and the title of this thread, that A@H is hogging the CPU time. I have determined that (at least in my case) it cannot be run concurrently with seti on the same machine. The two projects do not play nice in the same sandbox.

It seems your earlier comment about using different machines for each project is almost a necessity and since I cannot dedicate one machine to each I have to select one as priority. SETI wins.

BTW. the forum seems to allow posting images, but I have not figured out the trick yet. Were I able to do so I would post the images that show the manager stats revealing the hogging in real time.

Can you help me to understand something more about this?

It has been my understanding that boinc is supposed to balance CPU usage to the percentages configured in a users preferences.
I have mine set for 75% seti and 25% asteroids, and it shows as such on the projects screen. I also have it saving only one day cache, so it should be in balance even on the daily credits.

Yet after over a week of running with this machine at those settings, boinc is still downloading and giving priority to asteroids. Asteroids is far ahead of seti on total credits, almost 500,000 for asteroids, compared to only 340,000 for seti; and has moved ahead by a more than a 2:1 ratio on user and host averages as well.

I stand by my initial comment, and the title of this thread, that A@H is hogging the CPU time. I have determined that (at least in my case) it cannot be run concurrently with seti on the same machine. The two projects do not play nice in the same sandbox.

It seems your earlier comment about using different machines for each project is almost a necessity and since I cannot dedicate one machine to each I have to select one as priority. SETI wins.

BTW. the forum seems to allow posting images, but I have not figured out the trick yet. Were I able to do so I would post the images that show the manager stats revealing the hogging in real time.

Is BU running on the cpu too? All of this on the same machine? That could be the problem. I too run BU but only use miners, but still need to keep a cpu core free just to feed them, just like I do for the gpu's I have.

When I look at your average credit it says Seti is at 5162, BU is at 5147 and Asteroids is at 2670, are you running them all on the same machine? If so your 75% and 25% numbers are being skewed by BU.

sorry I clicked post twice

Can you help me to understand something more about this?

It has been my understanding that boinc is supposed to balance CPU usage to the percentages configured in a users preferences.
I have mine set for 75% seti and 25% asteroids, and it shows as such on the projects screen. I also have it saving only one day cache, so it should be in balance even on the daily credits.

Yet after over a week of running with this machine at those settings, boinc is still downloading and giving priority to asteroids. Asteroids is far ahead of seti on total credits, almost 500,000 for asteroids, compared to only 340,000 for seti; and has moved ahead by a more than a 2:1 ratio on user and host averages as well.

I stand by my initial comment, and the title of this thread, that A@H is hogging the CPU time. I have determined that (at least in my case) it cannot be run concurrently with seti on the same machine. The two projects do not play nice in the same sandbox.

It seems your earlier comment about using different machines for each project is almost a necessity and since I cannot dedicate one machine to each I have to select one as priority. SETI wins.

BTW. the forum seems to allow posting images, but I have not figured out the trick yet. Were I able to do so I would post the images that show the manager stats revealing the hogging in real time.

Is BU running on the cpu too? All of this on the same machine? That could be the problem. I too run BU but only use miners, but still need to keep a cpu core free just to feed them, just like I do for the gpu's I have.

When I look at your average credit it says Seti is at 5162, BU is at 5147 and Asteroids is at 2670, are you running them all on the same machine? If so your 75% and 25% numbers are being skewed by BU.

NO. BU is running on a windows box that only has one processor and has been kept separate from both seti and asteroids. I found that BU would not even get or run any units on my linux boxes, so have one dedicated only to BU.

I think you reversed the credits there for seti and asteroids. :-)
As of today my averages are
Bitcoin Utopia 8,055
Asteroids@home 5,765 6,398*
SETI@home 2,821 2,917*
the number with the * is shown as recent averages on my accounts.

With all the testing/changing/etc that I have done, I have one machine limited to seti only (4 processors), one running both seti and asteroids (4 processors) and one dedicated to BU only.
My laptop running seti only seems to always hog the processors for asteroids if I allow it to run both.
The desktop running both (that machine I just started using about a month ago) has settled down and recently is playing nice and uses one core for asteroids and 3 for seti, just as I would expect with the 25/75% split I configured, except it seems to be based on cpu cycles on that machine, not related to total credits, machine averages, user averages, or anything else that would seem logical.

I have no clue how long a time period is used to determine the resource share, but it must be considerable since the other machine refuses to share, and I don't have the patience to wait it out and see if it would eventually stabilize. I did wait a full week and that machine only ran asteroids units the entire time. It had a seti unit that it put on hold (waiting to run) that just sat there until I stopped asteroids again on that machine.

Notice both averages are climbing and that the spread between the averages is still growing even with only one core running asteroids and 7 running seti. That by itself makes it clear that credits have no bearing on how boinc figures resource share.

Can you help me to understand something more about this?

It has been my understanding that boinc is supposed to balance CPU usage to the percentages configured in a users preferences.
I have mine set for 75% seti and 25% asteroids, and it shows as such on the projects screen. I also have it saving only one day cache, so it should be in balance even on the daily credits.

Yet after over a week of running with this machine at those settings, boinc is still downloading and giving priority to asteroids. Asteroids is far ahead of seti on total credits, almost 500,000 for asteroids, compared to only 340,000 for seti; and has moved ahead by a more than a 2:1 ratio on user and host averages as well.

I stand by my initial comment, and the title of this thread, that A@H is hogging the CPU time. I have determined that (at least in my case) it cannot be run concurrently with seti on the same machine. The two projects do not play nice in the same sandbox.

It seems your earlier comment about using different machines for each project is almost a necessity and since I cannot dedicate one machine to each I have to select one as priority. SETI wins.

BTW. the forum seems to allow posting images, but I have not figured out the trick yet. Were I able to do so I would post the images that show the manager stats revealing the hogging in real time.

Is BU running on the cpu too? All of this on the same machine? That could be the problem. I too run BU but only use miners, but still need to keep a cpu core free just to feed them, just like I do for the gpu's I have.

When I look at your average credit it says Seti is at 5162, BU is at 5147 and Asteroids is at 2670, are you running them all on the same machine? If so your 75% and 25% numbers are being skewed by BU.

NO. BU is running on a windows box that only has one processor and has been kept separate from both seti and asteroids. I found that BU would not even get or run any units on my linux boxes, so have one dedicated only to BU.

I think you reversed the credits there for seti and asteroids. :-)
As of today my averages are
Bitcoin Utopia 8,055
Asteroids@home 5,765 6,398*
SETI@home 2,821 2,917*
the number with the * is shown as recent averages on my accounts.

Sorry

With all the testing/changing/etc that I have done, I have one machine limited to seti only (4 processors), one running both seti and asteroids (4 processors) and one dedicated to BU only.
My laptop running seti only seems to always hog the processors for asteroids if I allow it to run both.
The desktop running both (that machine I just started using about a month ago) has settled down and recently is playing nice and uses one core for asteroids and 3 for seti, just as I would expect with the 25/75% split I configured, except it seems to be based on cpu cycles on that machine, not related to total credits, machine averages, user averages, or anything else that would seem logical.

I have no clue how long a time period is used to determine the resource share,

DAILY

but it must be considerable since the other machine refuses to share, and I don't have the patience to wait it out and see if it would eventually stabilize. I did wait a full week and that machine only ran asteroids units the entire time. It had a seti unit that it put on hold (waiting to run) that just sat there until I stopped asteroids again on that machine.

Boinc was never designed to be run 24/7 at 100% of the cpu usage in a pc, it was designed to use SPARE cpu clock time, NOT be the primary program running on a pc. Therefore it doesn't act like we want it too all the time. And no Dr A isn't going to change that anytime soon, he is still trying to get grant monies based on his original model as I described it.

Notice both averages are climbing and that the spread between the averages is still growing even with only one core running asteroids and 7 running seti. That by itself makes it clear that credits have no bearing on how boinc figures resource share.

Again DAILY average credits, not anything the stats sites come up with. As for one cpu core running Asteroids and 3 running Seti, that is just a right now thing, it will change again. Percentages is NOT related to cpu core usage.

As I think I said before as you are doing with your BU machine, the best thing is to put each project on its own machine, that way each can run at the 100 percent with no interference from the other projects. That's how people like me end up with 15 pc's in our home running Boinc.