Hi all,

The new and improved abc finder application (previous announcement) is ready for testing! We would really appreciate if you could help test it. Hopefully the testing will not take long, since the new client is basically the well-tested old abc@home client code with a new algorithm inserted.


Right now we have win32, linux i686 and linux x86_64 binaries available. Mac OS X and win64 binaries will follow as soon as we have build machines for those platforms set up again, hopefully still in time for the tests.


Since our old abcbeta machine has sadly died completely, I have set up a new (very basically configured) project with about 850 randomly selected new workunits and a quorum of two results per workunit. The URL to attach to is:

http://abctest.math.leidenuniv.nl/abcbeta/


Please let me know of any issues you encounter, or things you think could be improved. I'll be online most of tomorrow and the weekend to address any problems that pop up. I added some extra comments and questions below.


Thanks!
-Willem Jan




What may need special attention:

The amount of credits:
Feedback on this is very much welcomed. Do you think the new application gives the right amount of credit?

Stability:
Does the application crash? If you pause/stop it, does it resume properly?

Progress report:
The new application first spends a couple of seconds on determining how many potential triples will be scanned in this workunit. When this scan is complete, it uses this number to estimate how much time remains. This seems to be fairly accurate, since the amount of time per triple doesn't change much inside a workunit, but please let me know if it over/underestimates the required time for you.

Total time for a workunit:
We have tried to make all workunits roughly the same
length (something in the order of 4 hours, depending a lot on CPU speed of course), and I think it should be more consistent than with the old application. However, there are still some workunits near the edges of the (two dimensional) search area that are longer or shorter than expected, because our time heuristics don't work as well in corner cases. If you run into extreme examples, or think the default length should be shorter or longer, please let
me know.




Some more technical notes:

I looked again at the possibility of a CUDA GPU version, but it doesn't seem like a good fit, since our new algorithm requires fast random memory access, and operates on large integers. GPUs seem to be more suited for localized memory access and floating point data, on the other hand. So sadly I do not think GPU support would increase performance.

The code fundamentally uses 64 bit integers since we are looking for ABC triples that don't fit in 32 bit integers. In the new code we included some fast 64 bit arithmetic that is not possible on 32 bit machines, so the speed difference between 64 and 32 bit machines will likely be larger than with the old algorithm.

There were some unexplained crashes with the old application on certain linux distributions. If my guess on what caused those is correct, they should not
occur with the new application.

I'll start off with the first bug report myself:
It seems the workunit metadata (number of triples found, total number of triples to scan and such) doesn't always get recomputed properly after aborting and resuming, which will either cause a reset of the workunit's computation, or a validation failure at the end.

I'll fix this first thing in the morning tomorrow.

Great news! :-)

Good to hear Beta is back.
Is it possible, that we can tell the stats sites to get the stats or do you think it's too early?
____________
Life is Science, and Science rules. To the universe and beyond
Proud member of BOINC@Heidelberg

Ready to test... first WUs are already running. :-)
____________
Lovely greetings from Cori

When shutting down BOINC & restarting it again on my Ubuntu Linux Box the Progession & To Completion showed nothing but the CPU Time remained the same as it was before shutting down.

When shutting down BOINC & restarting it again on my Ubuntu Linux Box the Progession & To Completion showed nothing but the CPU Time remained the same as it was before shutting down.

I suspended a task after 34 minutes runtime and 13,549% progress.
Resumed after a minute and the cpu was running @ 100%, but the progress stayed on 13,549%. To test that progress would not go on after another 34 minutes let it run to 74 minutes runtime, still no progress.
Restarted the Boinc client.
Progress restarted at 0%, but cpu went on with the initial 74 minutes.
Let it run now without interruption. Atm at 35% and 170 minutes (incl. initial 74min)
Linux64 AMD Phenom X4 2,1GHz.

I think this is the failure Willem Jan already mentioned, but here behaviour a bit extended described.

After attaching to the beta project, had numerous wu's d/l'ed. At this moment, have 4 showing 100% completion, but they are still crunching. Original completion time showed 00:48:22 & currently at 4hrs:30+. Is this to be expected?
____________

I am also seeing apps that show as 100%, but still running.
____________
Dublin, CA
Team SETI.USA

I am also seeing apps that show as 100%, but still running.

On my XP x64 lappy I have one WU running @56.5% after 4 hours...
____________
Lovely greetings from Cori

On my XP x64 lappy I have one WU running @56.5% after 4 hours...

It sounds likely those are symptoms of the resume bug. I found the problem, and it was something that occurred only after it printed the (correct) numbers to stderr.txt, which was why I missed it before. New builds with a fix should be up soon.

The first bunch of workunits is still a bit variable in length I think. The workunits that have been completed so far have taken between 1.9 and 9.9 hours. Hopefully the runtime will stabilize after the first couple of dozen from the test set.

-Willem Jan

Should we abort the tasks in progress, then?
____________
Dublin, CA
Team SETI.USA

New linux i686 and x86_64 clients (version 1.01) are up that fix the resume problem. If you have a running task that has been suspended and resumed with 1.00, that has unfortunately been corrupted, so it is best to abort it.

I'll build a new Win32 binary when I get home in a couple of hours, and will try to do a Win64 at the same time.

-Willem Jan

getting through the task but there is no end date/time.

The task mentioned in my former post ended successfull as far I can see after 6.5 hours runtime. This is including the 74 minutes double running.
After 100% normal ending and uploading.

The task mentioned in my former post ended successfull as far I can see after 6.5 hours runtime. This is including the 74 minutes double running.
After 100% normal ending and uploading.

Hummmmmmm, I think I'll be moving on now if .001 Credits is all your giving for 5 Hours of Processing. Every WU I have Validated has got this amount so far ...

Task ID 4062
Name abc_sieve_wu_00002609_0
Workunit 1887
Created 4 Jun 2009 22:46:15 UTC
Sent 5 Jun 2009 7:25:54 UTC
Received 5 Jun 2009 14:29:13 UTC
Server state Over
Outcome Success
Client state Done
Exit status 0 (0x0)
Computer ID 22
Report deadline 8 Jun 2009 7:25:54 UTC
CPU time 18801.66703
stderr out <core_client_version>6.4.5</core_client_version>
<![CDATA[
<stderr_txt>
[08:35:43 ABC] starting abc client code_version 390
[08:35:43 ABC] happy fishing - the ABC-crew!
[08:35:43 ABC] detected a little endian machine at runtime
[08:35:43 ABC] retrieved parameters: id = 2609, rx in [1,1794), ry in [15835,17223), gcd(x,210) = 1, c in [1,1000000000000000000), bs 3000, sb 200000
[08:35:43 ABC] can't open abc_sieve_state to read header data
[08:35:43 ABC] starting from scratch
[13:49:41 ABC] finished with hits=8513

</stderr_txt>
]]>

Validate state Valid
Claimed credit 174.375278363863
Granted credit 0.001
application version 1.00

On my XP x64 lappy I have one WU running @56.5% after 4 hours...

I'd fire that Lappy ... ;P

... the 2 that finished in 4 hr's were on a Lappy of mine ... :)

I want at least one 'good' WU

Oops, 0.001 credits? I'm looking into that now.

-Willem Jan


P.S. Version 1.01 for Win32 is now online, fixing the resume problem.

The 4 on my workstation are close to 9hrs & still crunching.

3 on my server have completed......OUCH!!!!

2019
2019
2018

Both wu's have the same id but different task id's 4327 & 4326

Edit: - it looks like I was my own wingman :)
____________

... P.S. Version 1.01 for Win32 is now online, fixing the resume problem.

... P.S. Version 1.01 for Win32 is now online, fixing the resume problem.

Can I finsih the two old (1.0) WUs I have still chrunching, they seem to have run fine so far? ;-)

... P.S. Version 1.01 for Win32 is now online, fixing the resume problem.

Can I finsih the two old (1.0) WUs I have still chrunching, they seem to have run fine so far? ;-)

Yes, if they never suspended/resumed, everything is fine. The only change between 1.00 and 1.01 was the resume fix.

1.01 binaries for new platforms are up: Win64, OS X i686, OS X PPC.

The Win64 binary doesn't yet have all 64 bit optimizations as I haven't ported the assembly parts from gcc syntax to MSVC syntax yet. Once that is done, it should be a bit faster than 1.01. Even 1.01 should already give a very decent speed-up over the Win32 version, though.

A colleague is working on a 64 bit Mac OS X 10.5 client, so that should be next.

-Willem Jan

What about the Credit Issue of only Granting .001 Credits ???

What about the Credit Issue of only Granting .001 Credits ???

Thanks for the help so far! On the client side, the results that have been returned all look good, except for the resumed tasks broken by v1.00.

On the server side, there is the 0.001 credit issue which I hope my last server change improved. The amount of granted credits will probably need tweaking, but let's first get it into numbers that aren't clearly wrong.

There's also still a bug in the assimilator as visible in the server status, but I hope to tackle that soon.

I'll be back tomorrow morning.

-Willem Jan



P.S. The 64 bit Mac OS X client is now up too.

I am testing now with:

64 bit leopard
32 bit leopard
PPC/tiger
____________
Dublin, CA
Team SETI.USA

As you can see from the screenshot, it looks like I'm my own wingman on numerous units. Also, will these complete or timeout?

Should they be aborted?
____________

As you can see from the screenshot, it looks like I'm my own wingman on numerous units. Also, will these complete or timeout?

Should they be aborted?

It seems the 0.001 credit issue is fixed now

As you can see from the screenshot, it looks like I'm my own wingman on numerous units. Also, will these complete or timeout?

Should they be aborted?

With which client is this? If it is with the 1.00 binary, I'm afraid it's best to abort the 100%-and-running ones.


It seems the 0.001 credit issue is fixed now, by the way. I also changed the project config settings so now it should no longer be possible to be your own wingman. I had forgotten to change this from when I was the only user on the project for early testing.

-Willem Jan

It seems the 0.001 credit issue is fixed now

Yes it has, Thanks ... :)

As you can see from the screenshot, it looks like I'm my own wingman on numerous units. Also, will these complete or timeout?

Should they be aborted?

The WU's being sent are messing up the ability to get work from other Projects because they are way over estimated on how long their going to take to run. Some say 60+ Hours & then BOINC thinks you have all this work on your Computer & won't send you any work from the other Projects.

Sorry to say I'm just going to Abort them, even the ones in Progress because I think they are taking to long to run when compared to the ones I was getting a few days ago.

Also the Credits are a mess, you get 10 Credits Per Hour for 1 WU & 25-30 for the next, using the lowest claimed is the worst way there is to give Credits. I know it keeps the Cheaters in line somewhat but is screws every body else too ... IMO

PoorBoy: I understand completely. Thanks for the computed workunits and the reports. They'll be very useful for solving this problem. Do you have the names (abc_sieve_wu_XXXXXXXX) of specific workunits that are wrong? That would help with determining the cause.


In any case, there definitely seems to be something wrong with the initial runtime estimates. One aspect of this appears to be that the number of FLOPS of a host (which BOINC bases the run time estimateon) is often not a good indicator of the actual speed, since for example 32/64 bit differences can be very large.


Does the progress counter itself work properly? I.e., does the completed percentage seem to increase smoothly?


My plan for the credits is to link that to the number of triples scanned in a work unit, but I need to work out a fair formula for that.

... Does the progress counter itself work properly? I.e., does the completed percentage seem to increase smoothly?

My plan for the credits is to link that to the number of triples scanned in a work unit, but I need to work out a fair formula for that.

... Does the progress counter itself work properly? I.e., does the completed percentage seem to increase smoothly?

From what I have seen it went pretty smooth (under all my Windows x64 OSes: XP, Vista and Win7). :-)

My plan for the credits is to link that to the number of triples scanned in a work unit, but I need to work out a fair formula for that.

Now that sounds cool! :-)
But it will only be "fair" if a WU containing less triples is running much shorter than one with many triples to be scanned... I hope I did get this right? ;-)

My plan for the credits is to link that to the number of triples scanned in a work unit, but I need to work out a fair formula for that.

Now that sounds cool! :-)
But it will only be "fair" if a WU containing less triples is running much shorter than one with many triples to be scanned... I hope I did get this right? ;-)

Yes, that's correct. And theoretically this is the case. I'll analyze the timing results from computed workunits tomorrow to see if reality matches theory :-)

...

P.S. There was a serious performance problem in the Mac OS X clients. Version 1.02 for OS X fixes this. (i386/ppc are up now; x86_64 will hopefully follow soon.)

PoorBoy: I understand completely. Thanks for the computed workunits and the reports. They'll be very useful for solving this problem. Do you have the names (abc_sieve_wu_XXXXXXXX) of specific workunits that are wrong? That would help with determining the cause.


In any case, there definitely seems to be something wrong with the initial runtime estimates. One aspect of this appears to be that the number of FLOPS of a host (which BOINC bases the run time estimateon) is often not a good indicator of the actual speed, since for example 32/64 bit differences can be very large.


Does the progress counter itself work properly? I.e., does the completed percentage seem to increase smoothly?


My plan for the credits is to link that to the number of triples scanned in a work unit, but I need to work out a fair formula for that.

I am testing now with:

64 bit leopard

32 bit leopard

PPC/tiger

I am testing now with:

64 bit leopard

Seems to have worked just fine. Waiting for my wingman to return his.

http://abctest.math.leidenuniv.nl/abcbeta/result.php?resultid=5255

32 bit leopard

Works, but credits are mush less than claimed:

http://abctest.math.leidenuniv.nl/abcbeta/result.php?resultid=5298

PPC/tiger

It appears to be working. But it will not complete in time. After 26 hours, it is only 6% complete, and sill not complete by the deadline tomorrow. So I have aborted it. With longer due dates, I think it would work.

http://abctest.math.leidenuniv.nl/abcbeta/result.php?resultid=5384

Looked like all was ok with the client on Ubuntu x86_64, BOINC v 6.6.20

but the 'test' server has issues:

Mon 08 Jun 2009 22:09:17 EST abcbeta Message from server: Server error: can't attach shared memory

Thanks for the report. There was a rather serious performance problem with the OS X clients that has been solved now. The new clients (1.02) are likely 5 times as fast as the old ones.

New versions 1.03 are up for linux i686, linux x86_64, win32, windows x86_64.

They have a fix for a bug that could cause computation errors in corner cases. Also, the search range in which they can work has been expanded a bit.

The 1.03 win64 version now has improved arithmetic (using MSVC's arithmetic intrinsics) to match the other 64 bit clients. It gives a very nice 10% speed boost over 1.01.

Mac OS X versions for 1.03 will follow soon.

Cool! I've downloaded fresh WUs on my Vista and XP hosts (both x64). :-)

Only little problem: BOINC was downloading way too much work because the estimated time to completion was a bit too 'ambitious' (~30 minutes at the beginning)...
So I had to abort about the half of the new WUs to make sure BOINC won't start panicing. ;-)
I hope my cancelled WUs will be resent to someone else?

PS. Will we be able to notice the speed increase? I mean are the WUs the same as before so we will have shorter runtimes now?
____________
Lovely greetings from Cori

PS. Will we be able to notice the speed increase? I mean are the WUs the same as before so we will have shorter runtimes now?

Only little problem: BOINC was downloading way too much work because the estimated time to completion was a bit too 'ambitious' (~30 minutes at the beginning)...
So I had to abort about the half of the new WUs to make sure BOINC won't start panicing. ;-)
I hope my cancelled WUs will be resent to someone else?

Wow, the new 64-bit app for Windoze is really fast!!
Have completed several WUs in under 3 hours!

Maybe I should have kept my big load of WUs instead of cancelling the half of them.
But when I received almost 50 tasks at once (with a really low cache of 0.5 days) I was a bit worrying...
Well, next time I'm going to watch the WUs better before cancelling. ;-)))



EDIT: Ok, before I'm getting all too excited: there's some WU which will need ~3.5 or 4 hours but that's still quite an impressive speed improvement IMHO.
Guessing from a quick comparison with my older WUs I would say the new x64 app is ~30% faster than before.
____________
Lovely greetings from Cori

That's nice to hear. Been getting no work from ABC for over 36 hrs & run out of wu's, so switched rigs over to beta. XP X64 rig got plenty, but the rest keeps getting "shared memory error"
____________

Ooops, the "shared memory" error keeps me from reporting finished WUs! *sniff* ;-)))
____________
Lovely greetings from Cori

Anybody running these things, I have close to 24,000 Pending Credits piled up so far ... Getting the Shared memory message too when trying to connect ...

Same here: "shared memory"... Waiting for reporting the WUs!
____________
Life is Science, and Science rules. To the universe and beyond
Proud member of BOINC@Heidelberg

Woo-hoo, servers are back! Just reported all my WUs! :-))
____________
Lovely greetings from Cori

PPC/tiger

It appears to be working. But it will not complete in time. After 26 hours, it is only 6% complete, and sill not complete by the deadline tomorrow. So I have aborted it. With longer due dates, I think it would work.

abc_sieve_1.02_powerpc-apple-darwin is 80% through the first WU after 30 hours of computation, I've aborted all but the two WUs in progress.
____________

Server down again.
____________

I ran a new one, with the *much* faster app 1.02. It validated.

http://abctest.math.leidenuniv.nl/abcbeta/result.php?resultid=6715

Credits are still much less than claimed.

Server down again.

Server down again.

The feeder seems to lose its connection to the mysql server from time to time, which is strange since it's an unmodified BOINC one. I'll try to add a keep-alive to hopefully prevent the mysql connection from dropping.

-Willem Jan

I ran a new one, with the *much* faster app 1.02. It validated.

http://abctest.math.leidenuniv.nl/abcbeta/result.php?resultid=6715

Credits are still much less than claimed.

It looks to me like you finished the wu in 19 hours, is that correct? If so, I wonder why mine are running slower on a faster G5.

Your task finished faster than mine. Compare the times.
____________
Dublin, CA
Team SETI.USA

Your task finished faster than mine. Compare the times.

Your task finished faster than mine. Compare the times.

I guess I've been reading the times wrong. BOINCManager said I had 40 hours on each of my first two work units, but the two results I've finished were about 15.5 and 17.75 hours according to the results. Is BOINCManager really that far off in it's elapsed time calculations?

Elapsed time in BOINC manager should be correct but estimated time to completion can be way off. ;-)

Only other scenario I can think of is that the wall-clock time needed for the WUs was for some reason much higher than the CPU time.
Hm... did you run some AQUA mt-WUs on that host, too?

Elapsed time in BOINC manager should be correct but estimated time to completion can be way off. ;-)

Only other scenario I can think of is that the wall-clock time needed for the WUs was for some reason much higher than the CPU time.
Hm... did you run some AQUA mt-WUs on that host, too?

No, I'm not familiar with AQUA mt, do they have a PPC Mac application?

Elapsed time in BOINC manager should be correct but estimated time to completion can be way off. ;-)

Only other scenario I can think of is that the wall-clock time needed for the WUs was for some reason much higher than the CPU time.
Hm... did you run some AQUA mt-WUs on that host, too?

Hi

I download 1 task and it showed 38 minutes to finish it ran for over 3hours and was only 30% complete so it looked like at least a 9 hour run but you only had 2 days to do it today you download another 10 so that could have been about 100 hours to complete in 2 days.

I think they should either be quicker or more time given to complete and as I run a lot of other projects I had to abort all 11 of these as there was no time to do anything else otherwise.

Paul

Can we get am Update on how/where the ABCbeta Project is doing/going ??? I'm sitting on over 50,000 Pending Credits for the ABC BETA Project & if the Projects Dead I'll divert the Resources to some place else. Not Complaining but just asking on how it's going ???

A status update:

The plan is to wait until the weekend, and then analyze the timing results from all returned workunits. Hopefully a pattern will emerge in the running times, so that we can fix the expected run time of new workunits.

After that, I'll re-generate a set of new workunits for the beta test with the new heuristics. From the current results, it looks like I should make them a lot shorter than they are now. Does 2 or 4 times as short sound reasonable to you?

I am having to abort lots of WUs for the beta app because the actual runtime is so much longer than the estimated runtime. Is there any way either the deadlines can be extended or the estimated runtime be made more accurate?
____________

A status update:

The plan is to wait until the weekend, and then analyze the timing results from all returned workunits. Hopefully a pattern will emerge in the running times, so that we can fix the expected run time of new workunits.

After that, I'll re-generate a set of new workunits for the beta test with the new heuristics. From the current results, it looks like I should make them a lot shorter than they are now. Does 2 or 4 times as short sound reasonable to you?

A status update:

The plan is to wait until the weekend, and then analyze the timing results from all returned workunits. Hopefully a pattern will emerge in the running times, so that we can fix the expected run time of new workunits.

After that, I'll re-generate a set of new workunits for the beta test with the new heuristics. From the current results, it looks like I should make them a lot shorter than they are now. Does 2 or 4 times as short sound reasonable to you?

Yes that sounds good, a lot of the Wu's ere running 8-10 hr's on my Quads, so shortening them by a factor of 3 or 4 would put them in the 2-3 hr range.

A status update:

The plan is to wait until the weekend, and then analyze the timing results from all returned workunits. Hopefully a pattern will emerge in the running times, so that we can fix the expected run time of new workunits.

After that, I'll re-generate a set of new workunits for the beta test with the new heuristics. From the current results, it looks like I should make them a lot shorter than they are now. Does 2 or 4 times as short sound reasonable to you?

A status update:

The plan is to wait until the weekend, and then analyze the timing results from all returned workunits. Hopefully a pattern will emerge in the running times, so that we can fix the expected run time of new workunits.

After that, I'll re-generate a set of new workunits for the beta test with the new heuristics. From the current results, it looks like I should make them a lot shorter than they are now. Does 2 or 4 times as short sound reasonable to you?

Will doing this cause BOINC to simply DL more WUs causing effectively the same situation?

A status update:

The plan is to wait until the weekend, and then analyze the timing results from all returned workunits. Hopefully a pattern will emerge in the running times, so that we can fix the expected run time of new workunits.

After that, I'll re-generate a set of new workunits for the beta test with the new heuristics. From the current results, it looks like I should make them a lot shorter than they are now. Does 2 or 4 times as short sound reasonable to you?

Will doing this cause BOINC to simply DL more WUs causing effectively the same situation?

Server error:

Mo 29 Jun 2009 16:22:50 CEST|abcbeta|Message from server: Server error: can't attach shared memory

cu,
Michael

Status update: after analyzing a number of workunits, it seems the speed heuristic actually does quite well, but the code that builds workunits makes many workunits much longer than intended.

Together with lowering the target size, I hope fixing that will make the new workunits behave much more reasonably.

This work unit stopped progress at about 12%, I paused and continued it in hopes it would finish but at 59:41 (elapsed, not CPU) I aborted it. It was about 8 hours past due at that time and still at 12% completed.
____________

It looks like this work unit had similar issues. No mention of permission errors but it failed to detect a heartbeat several times before erroring out. Both are on my 06/2005 G5 2.0 DP.

(edit) And this work unit also errored out on my G5 Power Mac. I don't see any bad work units for either of my G4s, is there a particular issue with the PPC970?
____________

(deleted)
____________

The only thing I am seeing, both Windows and Linux machines, is that the time to completion starts out at wildly different numbers. I have several that think they will take 70 hours to finish and some that think they will only take 15 hours to finish. I don't know where to go to see how long they actually took though. My ABC account stats only shows the non beta units.
____________

... I don't know where to go to see how long they actually took though. My ABC account stats only shows the non beta units.

I have another work unit that appears to be doing the same thing. It ran up to 15% in a few hours, now it's seemingly stuck at 15% after 12 hours. I am going to abort it and take my G5 off the beta program until there is a fix.
____________

... I don't know where to go to see how long they actually took though. My ABC account stats only shows the non beta units.

You can see them at your ABC Beta account: http://abctest.math.leidenuniv.nl/abcbeta/home.php ;-)

I found several WUs which were successfully completed but didn't get granted - only my wingmen got credits.
Example: http://abctest.math.leidenuniv.nl/abcbeta/workunit.php?wuid=3053

Were my results really 'wrong' or why did this happen?
I noticed that my box needed longer to crunch the affecetd WUs than my wingmen but does this mean my results are not matching either?
____________
Lovely greetings from Cori

I have a question...when will be new wu's available?

为什么开始时上面显示剩余时间是6小时，可我运行了两天了，还没完成那个任务，才完成25%，而且剩余时间还是显示为7小时
____________

I have a question , if I fisihed my program, what will happen?
____________

I have a question , if I fisihed my program, what will happen?