Edit: And since I'm no longer able to edit that post I can't fix it. If a mod would like to correct it feel free to do so!
No idea who did it but the original links got fixed in the meantime.
I'm a full time carer these days since my wife has been diagnosed recently with fairly aggressive metastatic lung cancer. I visit the boards much less frequently than I used to, but I just happened to be wandering through not long after Holmis issued the 'invitation to fix'. I decided to experiment with how to edit another person's post - not having ever done that previously .
I can really sympathize with the comment by Holmis that these sorts of mishaps are probably likely to keep recurring. I'm rather surprised that this is the way it is and that people just have to remember to 'find and fix' before posting. I actually find posting stuff with links to other stuff quite a chore these days, compared to the relative ease of what it used to be. It's probably just me (the old dinosaur) not coping well with drastic change and the loss of some things I was really comfortable with in the old system.
One of my NVIDIA equipped machines running CUDA will not pick up BRP4G units and has only been picking up stray BRP6 units. I recently upgraded to CUDA 8.
This is what the log says:
Sun 02 Oct 2016 xx:yy:zz PM CDT | Einstein@Home | Binary Radio Pulsar Search (Arecibo) is not available for your type of computer.
It's got an NVIDIA GeForce GT 650M and has been running Binary Radio Pulsar Search (Parkes PMPS XT) v1.56 (BRP6-cuda55-Lion) x86_64-apple-Darwin on Mac OS Sierra.
I'd like to fix this before I run out of recycled BRP6 units.
For several days now BRP4G work availability seems to have been pretty consistent. The number of tasks ready to send noted by the Einstein server status page seems to fluctuate in a pretty tight range of about 2500 +/- 1000, and the tasks in progress number has gradually climbed from the 83k of three days ago to 159k as I write. While some machines with configuration conflicts are not getting work, the general availability problem seems for the moment quite well solved. We've been warned, however, that there are pipeline stages upstream of Einstein which may not flow continuously with this particular work.
Now if only the cuda55 version were made available (there is circumstantial evidence that the 32-bit version might very likely work as-is on both 32 and 64-bit platforms) I'd be rather happy.
One of my NVIDIA equipped machines running CUDA will not pick up BRP4G units and has only been picking up stray BRP6 units. I recently upgraded to CUDA 8.
That's your problem, BRP4G is not sent out to host with higher than CUDA 6.49.
That's kind of weird, because I have a machine running Windows 10 and another running Ubuntu that are both pulling BRP4G units consistently with CUDA 7.x on each of them.
It is. People just need to
)
It is. People just need to pay attention and sanitize URLs before quoting/posting them.
Oliver
Einstein@Home Project
Holmis wrote:Edit: And since
)
No idea who did it but the original links got fixed in the meantime.
Einstein@Home Project
There's seems to be plenty of
)
There seems to be plenty of BRP4G tasks available now.
edit: Well, not anymore.. but bursts were larger and more frequent already. Looks promising.
The # of tasks in progress
)
The # of tasks in progress has gone up considerably though. I saw as low as 47k and now its 73k.
mmonnin wrote:The # of tasks
)
I think that is a good number to watch. When it climbs they are sending out more new work than is getting returned.
I think I spotted it as low as 37k before work dispatch resumed, and it has now inched up to 83k.
Oliver Bock wrote:Holmis
)
I'm a full time carer these days since my wife has been diagnosed recently with fairly aggressive metastatic lung cancer. I visit the boards much less frequently than I used to, but I just happened to be wandering through not long after Holmis issued the 'invitation to fix'. I decided to experiment with how to edit another person's post - not having ever done that previously
.
I can really sympathize with the comment by Holmis that these sorts of mishaps are probably likely to keep recurring. I'm rather surprised that this is the way it is and that people just have to remember to 'find and fix' before posting. I actually find posting stuff with links to other stuff quite a chore these days, compared to the relative ease of what it used to be. It's probably just me (the old dinosaur) not coping well with drastic change and the loss of some things I was really comfortable with in the old system.
Cheers,
Gary.
One of my NVIDIA equipped
)
One of my NVIDIA equipped machines running CUDA will not pick up BRP4G units and has only been picking up stray BRP6 units. I recently upgraded to CUDA 8.
This is what the log says:
Sun 02 Oct 2016 xx:yy:zz PM CDT | Einstein@Home | Binary Radio Pulsar Search (Arecibo) is not available for your type of computer.
It's got an NVIDIA GeForce GT 650M and has been running Binary Radio Pulsar Search (Parkes PMPS XT) v1.56 (BRP6-cuda55-Lion) x86_64-apple-Darwin on Mac OS Sierra.
I'd like to fix this before I run out of recycled BRP6 units.
For several days now BRP4G
)
For several days now BRP4G work availability seems to have been pretty consistent. The number of tasks ready to send noted by the Einstein server status page seems to fluctuate in a pretty tight range of about 2500 +/- 1000, and the tasks in progress number has gradually climbed from the 83k of three days ago to 159k as I write. While some machines with configuration conflicts are not getting work, the general availability problem seems for the moment quite well solved. We've been warned, however, that there are pipeline stages upstream of Einstein which may not flow continuously with this particular work.
Now if only the cuda55 version were made available (there is circumstantial evidence that the 32-bit version might very likely work as-is on both 32 and 64-bit platforms) I'd be rather happy.
Jonathan Jeckell wrote:One of
)
That's your problem, BRP4G is not sent out to host with higher than CUDA 6.49.
This is the relevant line from your last contact log:
2016-10-10 16:52:36.6359 [PID=6477 ] [version] CUDA version required max: 6049, supplied: 8000
That's kind of weird, because
)
That's kind of weird, because I have a machine running Windows 10 and another running Ubuntu that are both pulling BRP4G units consistently with CUDA 7.x on each of them.