Could you tell us which GNU/Linux distro are you running, which X server, which kernel ?
This way, Bernd can have a better view on which systems 'albert' crashes.
Sure thing :)
The machine is an Intel Celeron 2.4 with 512MB RAM running Debian kernel 2.4.27-2-686. I am running it in command line only with no GUI/X server components installed.
I have completed 2 units and have checked the results page.
My first unit ran in 4hrs 30min and the second ran in 4hrs 4min. The results page show that the 2 units ran in 8745 and 7918 seconds respectively.
So for some reason the E@H page stats is showing a much shorter processing time than the time it actually took. The time showing is +-45% of the time it actually took.
I checked the stats of another user who is also running the same client and the E@H time stats are also out by around a similar amount to the actual time it took to process.
I have completed 2 units and have checked the results page.
My first unit ran in 4hrs 30min and the second ran in 4hrs 4min. The results page show that the 2 units ran in 8745 and 7918 seconds respectively.
So for some reason the E@H page stats is showing a much shorter processing time than the time it actually took. The time showing is +-45% of the time it actually took.
I checked the stats of another user who is also running the same client and the E@H time stats are also out by around a similar amount to the actual time it took to process.
Any ideas?
Thx
Richard
You're running Trux's calibrating client. Look at the details for one of the results that ran to completion:
5.3.12.tx36 16210
8745
631.9
Read Trux's documentation again, or have a browse of the thread over on SETI: it's normal for that client to start off by underclaiming for the first few results. Then it'll reverse, and the credits will start slowly climbing - it should finally settle down after 30 WUs or so.
Then you'll see that some of the increased credit claim comes from a modest increase in the claimed runtime, and a rather higher proportion from an inflated reported benchmark speed.
I compiled a 64-Bit version of it and mailed to truxa, but didn't get an answer so far. If he's interested, this version will be available for download in the future.
cu,
Michael
Hi Michael !
I couldn't connect to the site, it is offline for the moment. I'll check later, thanks.
Anyway, I got Keck Komputer's answers to my complaints on the BOINC core client forum.
I believe that the proper solution is not to tweak the BOINC client (which I have also been doing - compiling for SSE and whatever optimizations came to my mind), but to let the Albert app tell BOINC how much work has been completed.
This would represent a fair, platform-independent credit.
So far, all my results computed with albert_455 excepted 24588564 were successfully validated.
The message that failed reports a problem with graphics (I tried to startup the graphics, but my boincmgr doesn't correctly support graphics).
Thanks for the big performance improvement.
As for the credits ranting, is the albert app going to support the 'operations count' hook provided by the BOINC core client sometimes in the future ?
I compiled a 64-Bit version of it and mailed to truxa, but didn't get an answer so far. If he's interested, this version will be available for download in the future.
cu,
Michael
Hi Michael !
I couldn't connect to the site, it is offline for the moment. I'll check later, thanks.
Anyway, I got Keck Komputer's answers to my complaints on the BOINC core client forum.
I believe that the proper solution is not to tweak the BOINC client (which I have also been doing - compiling for SSE and whatever optimizations came to my mind), but to let the Albert app tell BOINC how much work has been completed.
This would represent a fair, platform-independent credit.
Regards.
-rg-
Hi rg,
did you recognise we're in the same team? Come on and visit our forum. :)
Well the calibrating client of truXoft does not overclaim in any way, but starts with low cc and after about 30 WUs will claim about 38 to 40 credits on a long WU. So this already a way to get nearly equal credits, independent of OS, speed or any optimized app. See this and this post (an interesting thread anyway), where I allready expressed my opinions.
So I agree with you and hopefully we will get a payback-system that counts the fpops or something simular. But because of performance, I dont believe the counting should be done in the app but rather at the servers. If someone tries to speed up the app, this will often require to avoid fp-ops, so the chance of cheating on this side will be not too big.
So far, all my results computed with albert_455 excepted 24588564 were successfully validated.
The message that failed reports a problem with graphics (I tried to startup the graphics, but my boincmgr doesn't correctly support graphics).
Hi,
This is no client error (outcome=success), just the validator threw your result away, because he thought it wasn't exact enough.
I got such a "0" result too today and I think the app must be modified again.
This is no client error (outcome=success), just the validator threw your result away, because he thought it wasn't exact enough.
I got such a "0" result too today and I think the app must be modified again.
I think the reason if this problem the low-precision sin/cos lookup table.
I will suggest to Brend the usage of my interpolation algorithm.
It gives about ~2300000 times more accurate sin/cos values an the speed is about the same.
RE: Could you tell us which
)
Sure thing :)
The machine is an Intel Celeron 2.4 with 512MB RAM running Debian kernel 2.4.27-2-686. I am running it in command line only with no GUI/X server components installed.
Cheers
Richard
Another WU rejected by the
)
Another WU rejected by the scheduler.
http://einsteinathome.org/task/24629438
A64 3000+ SuSE Linux 9.3 64-Bit, fully patched.
cu,
Michael
I have completed 2 units and
)
I have completed 2 units and have checked the results page.
My first unit ran in 4hrs 30min and the second ran in 4hrs 4min. The results page show that the 2 units ran in 8745 and 7918 seconds respectively.
So for some reason the E@H page stats is showing a much shorter processing time than the time it actually took. The time showing is +-45% of the time it actually took.
I checked the stats of another user who is also running the same client and the E@H time stats are also out by around a similar amount to the actual time it took to process.
Any ideas?
Thx
Richard
RE: I have completed 2
)
You're running Trux's calibrating client. Look at the details for one of the results that ran to completion:
5.3.12.tx36
16210
8745
631.9
Read Trux's documentation again, or have a browse of the thread over on SETI: it's normal for that client to start off by underclaiming for the first few results. Then it'll reverse, and the credits will start slowly climbing - it should finally settle down after 30 WUs or so.
Then you'll see that some of the increased credit claim comes from a modest increase in the claimed runtime, and a rather higher proportion from an inflated reported benchmark speed.
RE: RE: Waiting for
)
Ok, thre results validated and all three canonical.
Average time 6,448.76 seconds (short runtime tasks)
Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
Douglas Adams (1952 - 2001)
RE: RE: ... but this
)
Hi Michael !
I couldn't connect to the site, it is offline for the moment. I'll check later, thanks.
Anyway, I got Keck Komputer's answers to my complaints on the BOINC core client forum.
I believe that the proper solution is not to tweak the BOINC client (which I have also been doing - compiling for SSE and whatever optimizations came to my mind), but to let the Albert app tell BOINC how much work has been completed.
This would represent a fair, platform-independent credit.
Regards.
-rg-
Hi ! So far, all my
)
Hi !
So far, all my results computed with albert_455 excepted 24588564 were successfully validated.
The message that failed reports a problem with graphics (I tried to startup the graphics, but my boincmgr doesn't correctly support graphics).
Thanks for the big performance improvement.
As for the credits ranting, is the albert app going to support the 'operations count' hook provided by the BOINC core client sometimes in the future ?
Regards.
-rg-
RE: RE: RE: ... but
)
Hi rg,
did you recognise we're in the same team? Come on and visit our forum. :)
Well the calibrating client of truXoft does not overclaim in any way, but starts with low cc and after about 30 WUs will claim about 38 to 40 credits on a long WU. So this already a way to get nearly equal credits, independent of OS, speed or any optimized app. See this and this post (an interesting thread anyway), where I allready expressed my opinions.
So I agree with you and hopefully we will get a payback-system that counts the fpops or something simular. But because of performance, I dont believe the counting should be done in the app but rather at the servers. If someone tries to speed up the app, this will often require to avoid fp-ops, so the chance of cheating on this side will be not too big.
cu,
Michael
RE: Hi ! So far, all my
)
Hi,
This is no client error (outcome=success), just the validator threw your result away, because he thought it wasn't exact enough.
I got such a "0" result too today and I think the app must be modified again.
cu,
Michael
RE: This is no client error
)
I think the reason if this problem the low-precision sin/cos lookup table.
I will suggest to Brend the usage of my interpolation algorithm.
It gives about ~2300000 times more accurate sin/cos values an the speed is about the same.