LINUX Beta Test App 4.55 available

RDPearson
RDPearson
Joined: 20 Oct 05
Posts: 15
Credit: 75,152
RAC: 0

RE: Could you tell us which

Message 27852 in response to message 27851

Quote:
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.

Cheers
Richard

M. Schmitt
M. Schmitt
Joined: 27 Jun 05
Posts: 478
Credit: 15,872,262
RAC: 0

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

RDPearson
RDPearson
Joined: 20 Oct 05
Posts: 15
Credit: 75,152
RAC: 0

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

Richard Haselgrove
Richard Haselgrove
Joined: 10 Dec 05
Posts: 2,042
Credit: 809,719,864
RAC: 1,223,604

RE: I have completed 2

Message 27855 in response to message 27854

Quote:

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.

tekwyzrd
tekwyzrd
Joined: 25 Feb 05
Posts: 49
Credit: 2,922,090
RAC: 0

RE: RE: Waiting for

Message 27856 in response to message 27847

Quote:
Quote:

Waiting for validation of first result from my computer running albert v4.55

Dual P3 Coppermine 700 @ 933

Initial estimate: 11,811 seconds
Actual time: 6449.03 seconds

I'd call this a major performance improvement.

OK so far. Result 24636950 for this work unit validated and is the canonical result.

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)

kami4ligo
kami4ligo
Joined: 15 Mar 05
Posts: 48
Credit: 16,105,651
RAC: 0

RE: RE: ... but this

Message 27857 in response to message 27846

Quote:
Quote:

... but this also means 1.8 times smaller credits. I started a thread on the BOINC core client forum, maybe they can also produce miracles there ...

You can use the calibrating client from truXoft:

http://boinc.truxoft.com/core-cal.htm

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-

kami4ligo
kami4ligo
Joined: 15 Mar 05
Posts: 48
Credit: 16,105,651
RAC: 0

Hi ! So far, all my

Message 27858 in response to message 27842

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-

M. Schmitt
M. Schmitt
Joined: 27 Jun 05
Posts: 478
Credit: 15,872,262
RAC: 0

RE: RE: RE: ... but

Message 27859 in response to message 27857

Quote:
Quote:
Quote:

... but this also means 1.8 times smaller credits. I started a thread on the BOINC core client forum, maybe they can also produce miracles there ...

You can use the calibrating client from truXoft:

http://boinc.truxoft.com/core-cal.htm

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.

cu,
Michael

M. Schmitt
M. Schmitt
Joined: 27 Jun 05
Posts: 478
Credit: 15,872,262
RAC: 0

RE: Hi ! So far, all my

Message 27860 in response to message 27858

Quote:

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).


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

Akos Fekete
Akos Fekete
Joined: 13 Nov 05
Posts: 561
Credit: 4,527,270
RAC: 0

RE: This is no client error

Message 27861 in response to message 27860

Quote:
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.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.