I have 2 of my 8 hosts that I haven't updated to a GPU cruncher yet so I run the Grav S6's on and since we ran out of them I ran the BRP4's w/CPU
But it is almost done and after a few tries before that and right now I have no luck getting any of the new FGRP2 and I have the pref. set to recieve the Grav.'s and GRP's....couple more tries and I guess I will reset and get a couple days worth of BRP4's
As I am typing......I just got 16 tasks of the Grav. S6's (1.13)
So it will have work to do along with the T4T X2 that I have it running for some reason.
Maybe next time one of my CPU hosts will grab a few FGRP2
There shouldn't be a shortage of GW tasks just yet - the work generator is running, there are a few thousand ready to send and 600K units before the run is finished. It'll be the new year before the 'end game' is upon us and even then there will be some work available over the days and weeks after that.
Nobody can get FGRP2 tasks just yet - there are zero ready to send and the work generator is disabled. Hopefully it will be turned on RSN :-).
I took a look through a task ID link of a failed task and found
7.0.28
process exited with code 22 (0x16, -234)
execv: No such file or directory
]]>
Is this a 64 bit OS and do you have the 32 bit libraries installed?
I think that might be the problem. Perhaps it's looking for 32 bit libs and can't find them. In a shell run 'ldd path/to/executable' without the quotes. That will list any 'not found' libs.
As I indicated in a message during the test run, tasks are crunching really fast. A back-of-the-envelope estimate says that the actual crunch time will be 6x to 10x (or more) faster than the estimated time, which, I guess, is based on the prior run.
This is going to play havoc for people maintaining large caches and/or supporting multiple projects because of fairly wild see-sawing in DCF (duration correction factor) as BOINC tries to cope with the variations between the FGRP2, BRP4 and S6LV1 tasks in the overall task mix. It is quite important that the new FGRP2 tasks should be delivered with a more accurate time estimate and presumably this should happen as the new run gets established.
In the meantime, it would be very prudent to turn down your cache size substantially so as to avoid BOINC running in high priority mode later on if a series of short running FGRP2 tasks causes over-fetching of the other two types of tasks. People (quite rightly) tend to get upset if the 'equilibrium' between projects gets disturbed to the point that other projects are 'shut out' by any one project going into 'panic' mode like this. Sometimes it's the participant's unwise choice of (too large) cache size for the number of projects in the mix, but this time I think even moderate cache sizes could be adversely affected.
Is this a 64 bit OS and do you have the 32 bit libraries installed?
If that is the problem it means that the detection of the 32Bit compatibility libs still doesn't work with 7.0.28. Pitty. If it would, the client should detect the absence of these libs and you shouldn't get such tasks at all.
New FGRP2 tasks will run a bit longer (~ twice as long) now, and will have the FLOPs estimation reduced to 1/4. Flops estimation and Credit will be fine-tuned when we have more data (i.e. tasks returned), but possibly not this year anymore.
Is this a 64 bit OS and do you have the 32 bit libraries installed?
If that is the problem it means that the detection of the 32Bit compatibility libs still doesn't work with 7.0.28. Pitty. If it would, the client should detect the absence of these libs and you shouldn't get such tasks at all.
BM
Yeah, that was the problem. I installed the ia32-libs package, and now the Gamma Ray app runs fine.
RE: I was expecting you to
)
That would be a "Hannover, we have a problem" type of reply then anyway. ;-)
I have 2 of my 8 hosts that I
)
I have 2 of my 8 hosts that I haven't updated to a GPU cruncher yet so I run the Grav S6's on and since we ran out of them I ran the BRP4's w/CPU
But it is almost done and after a few tries before that and right now I have no luck getting any of the new FGRP2 and I have the pref. set to recieve the Grav.'s and GRP's....couple more tries and I guess I will reset and get a couple days worth of BRP4's
As I am typing......I just got 16 tasks of the Grav. S6's (1.13)
So it will have work to do along with the T4T X2 that I have it running for some reason.
Maybe next time one of my CPU hosts will grab a few FGRP2
2am.....goodnight
There shouldn't be a shortage
)
There shouldn't be a shortage of GW tasks just yet - the work generator is running, there are a few thousand ready to send and 600K units before the run is finished. It'll be the new year before the 'end game' is upon us and even then there will be some work available over the days and weeks after that.
Nobody can get FGRP2 tasks just yet - there are zero ready to send and the work generator is disabled. Hopefully it will be turned on RSN :-).
Cheers,
Gary.
I hate to be the bearer of
)
I hate to be the bearer of bad news, but. . .
All of the new Gamma-Ray workunits on this machine of mine ended in an error condition.
It's Lubuntu 12.10 running with the stock kernel. Am I going to have to compile my own non-preemptive kernel, again?
I took a look through a task
)
I took a look through a task ID link of a failed task and found
process exited with code 22 (0x16, -234)
execv: No such file or directory
]]>
Is this a 64 bit OS and do you have the 32 bit libraries installed?
I think that might be the problem. Perhaps it's looking for 32 bit libs and can't find them. In a shell run 'ldd path/to/executable' without the quotes. That will list any 'not found' libs.
Cheers,
Gary.
As I indicated in a message
)
As I indicated in a message during the test run, tasks are crunching really fast. A back-of-the-envelope estimate says that the actual crunch time will be 6x to 10x (or more) faster than the estimated time, which, I guess, is based on the prior run.
This is going to play havoc for people maintaining large caches and/or supporting multiple projects because of fairly wild see-sawing in DCF (duration correction factor) as BOINC tries to cope with the variations between the FGRP2, BRP4 and S6LV1 tasks in the overall task mix. It is quite important that the new FGRP2 tasks should be delivered with a more accurate time estimate and presumably this should happen as the new run gets established.
In the meantime, it would be very prudent to turn down your cache size substantially so as to avoid BOINC running in high priority mode later on if a series of short running FGRP2 tasks causes over-fetching of the other two types of tasks. People (quite rightly) tend to get upset if the 'equilibrium' between projects gets disturbed to the point that other projects are 'shut out' by any one project going into 'panic' mode like this. Sometimes it's the participant's unwise choice of (too large) cache size for the number of projects in the mix, but this time I think even moderate cache sizes could be adversely affected.
Cheers,
Gary.
Ugh! I'm a dolt. I just
)
Ugh! I'm a dolt.
I just installed this system a few days ago, and completely forgot to install the 32-bit libraries.
Oh well, I guess I'll do that now.
RE: 7.0.28 Is this a 64
)
If that is the problem it means that the detection of the 32Bit compatibility libs still doesn't work with 7.0.28. Pitty. If it would, the client should detect the absence of these libs and you shouldn't get such tasks at all.
BM
BM
New FGRP2 tasks will run a
)
New FGRP2 tasks will run a bit longer (~ twice as long) now, and will have the FLOPs estimation reduced to 1/4. Flops estimation and Credit will be fine-tuned when we have more data (i.e. tasks returned), but possibly not this year anymore.
BM
BM
RE: RE: 7.0.28 Is this
)
Yeah, that was the problem. I installed the ia32-libs package, and now the Gamma Ray app runs fine.