Hi, I am back after a pretty long time on the road, and without net access.
Very interesting things to consider, Gary and Gavin. I simply love it when someone explains in detail, so that anyone can understand, without being a specialist, or a pro. Thank you so much!
I am considering both ways, upgrading and adding a few "oldies but goldies".
You were both right about "the best bang for buck", I was looking to be as efficient as possible with the old comps ha ha Yap, the list was a sort of "guideline", but now I see the pitfalls. Thanks for the tips!
About the increasing the number of cores, Gary it was again a very detailed answer, many, many thanks. How did this come about? A few months ago (I believe after a BOINC update?) the tasks were automatically downloaded for 2 days' work. Before that I used to set the "working time" to about 7 - 10 days. Mostly because of short power failures, which cut the net, but the comp stayed on. So if you're not around, it keeps on working. And in 24-48 hours you have a connection anyway, so it can send the results. Someone told me it was too much to have 10 days. Anyway, when you have stable power and net connection I think 2 days work is fine too :)
So I think now it's pointless to try to fine-tune it so much, at least for me, now.
Still in a bit of a hurry, I will come back with more ideas these days. Thank you again for the details.
... how does one go about setting up this mechanism?
If by "this mechanism" you are referring to simulating extra cores, the procedure was described in this thread.
kb9skw wrote:
... two RX 570 GPUs each running 2x and I find it idle in the morning.
Did you work out why it was idle? Were there no tasks remaining so the machine had nothing to crunch or were there tasks available but crunching wasn't happening for some reason? It would really help if you gave some details.
Since the current tasks are the standard slow variety, it is unlikely to be your normal quota being inadequate. Have you checked if you are returning valid results? Have you looked for messages in the event log for "... exceeded daily quota of nnn tasks", or something along those lines? If nnn is a fairly low number, maybe you have a reduced quota due to errors?
kb9skw wrote:
...I suspect running four workunits at once on a dual core CPU is the issue.
Why? Are you actually saying that your machine wasn't "idle" but rather that it was overloaded and had crashed in some way?
I have a couple of hosts with dual core CPUs supporting 4 GPU tasks. There should be no particular problem with that setup if the hardware is in proper working condition, since the CPU support required by RX 570s is quite modest.
So no I never worked out why it was idle, but that problem seemed to of solved its self. The host has been running the past week and has been downloading workunits with no issue. To answer Gary's question, there were no tasks available to crunch. Don't know why but but all is well now.
Gary how steady should a daily workunit return be on a dedicated system?
... how steady should a daily workunit return be on a dedicated system?
I'm not really sure what you're asking. If by 'steady' you mean crunching continuously without having 'idle' spells, then yes, there is no reason (outside of setting preferences to pause crunching) for a machine to stop processing tasks, and 'have a break', so to speak :-)..
If you are asking about the numbers of completed tasks returned per day, it depends on the nature of the data being crunched. There appear to be at least 3 categories of data and/or template files which can lead to significant changes in crunch times. At the moment, we are crunching work that is in the 'slowest' category so this would lead to the fewest number of returned tasks per day. This is probably (based on past experience) the most common category.
There is a second category that is somewhat faster and a third, which is significantly faster again. For any given category, the individual task crunch times do change by a small amount, depending on the pulsar spin frequency being searched for. These small changes wouldn't really be noticeable when looking at the number of tasks returned per day.
So, at times, the "daily workunit return" (and hence your RAC) can undergo significant changes depending on the nature of the data.
Hi, I am back after a pretty
)
Hi, I am back after a pretty long time on the road, and without net access.
Very interesting things to consider, Gary and Gavin. I simply love it when someone explains in detail, so that anyone can understand, without being a specialist, or a pro. Thank you so much!
I am considering both ways, upgrading and adding a few "oldies but goldies".
You were both right about "the best bang for buck", I was looking to be as efficient as possible with the old comps ha ha Yap, the list was a sort of "guideline", but now I see the pitfalls. Thanks for the tips!
About the increasing the number of cores, Gary it was again a very detailed answer, many, many thanks. How did this come about? A few months ago (I believe after a BOINC update?) the tasks were automatically downloaded for 2 days' work. Before that I used to set the "working time" to about 7 - 10 days. Mostly because of short power failures, which cut the net, but the comp stayed on. So if you're not around, it keeps on working. And in 24-48 hours you have a connection anyway, so it can send the results. Someone told me it was too much to have 10 days. Anyway, when you have stable power and net connection I think 2 days work is fine too :)
So I think now it's pointless to try to fine-tune it so much, at least for me, now.
Still in a bit of a hurry, I will come back with more ideas these days. Thank you again for the details.
kb9skw wrote:... how does one
)
If by "this mechanism" you are referring to simulating extra cores, the procedure was described in this thread.
Did you work out why it was idle? Were there no tasks remaining so the machine had nothing to crunch or were there tasks available but crunching wasn't happening for some reason? It would really help if you gave some details.
Since the current tasks are the standard slow variety, it is unlikely to be your normal quota being inadequate. Have you checked if you are returning valid results? Have you looked for messages in the event log for "... exceeded daily quota of nnn tasks", or something along those lines? If nnn is a fairly low number, maybe you have a reduced quota due to errors?
Why? Are you actually saying that your machine wasn't "idle" but rather that it was overloaded and had crashed in some way?
I have a couple of hosts with dual core CPUs supporting 4 GPU tasks. There should be no particular problem with that setup if the hardware is in proper working condition, since the CPU support required by RX 570s is quite modest.
Cheers,
Gary.
I finally have some time to
)
I finally have some time to catch up, yay.
So no I never worked out why it was idle, but that problem seemed to of solved its self. The host has been running the past week and has been downloading workunits with no issue. To answer Gary's question, there were no tasks available to crunch. Don't know why but but all is well now.
Gary how steady should a daily workunit return be on a dedicated system?
kb9skw wrote:... how steady
)
I'm not really sure what you're asking. If by 'steady' you mean crunching continuously without having 'idle' spells, then yes, there is no reason (outside of setting preferences to pause crunching) for a machine to stop processing tasks, and 'have a break', so to speak :-)..
If you are asking about the numbers of completed tasks returned per day, it depends on the nature of the data being crunched. There appear to be at least 3 categories of data and/or template files which can lead to significant changes in crunch times. At the moment, we are crunching work that is in the 'slowest' category so this would lead to the fewest number of returned tasks per day. This is probably (based on past experience) the most common category.
There is a second category that is somewhat faster and a third, which is significantly faster again. For any given category, the individual task crunch times do change by a small amount, depending on the pulsar spin frequency being searched for. These small changes wouldn't really be noticeable when looking at the number of tasks returned per day.
So, at times, the "daily workunit return" (and hence your RAC) can undergo significant changes depending on the nature of the data.
Cheers,
Gary.