There are new updated applications released for almost all platforms. There are some improvements in CPU optimization (mainly for ARM processors) and a problem that caused some workunits didn't pass through validator was removed.

Radim Vančo (Kyong)

New apps show ridiculous crunching time, around 25 hours.

On my android-tablet (Cortex A8 1.0 GHz) it is also 25 hours (no change from the old one, because it probably has no hardware double precision floating point).
And so I let Einstein-at-Home to compute there (effectively - nearly the same time like on my HTC One-V (1.0 GHz Snapdragon CPU).

On my HTC One-V (Snapdragon) new asteroid WUs seem faster approx. by 12 percent. They now complete (in average) in 15.333333333 hours. Old units were nearly 17h.

---

Melwen - child of the Fangorn Forest

New apps show ridiculous crunching time, around 25 hours.

I evens out. User HA-SOFT, s.r.o. has described it perfectly:

It's not real time. Times should be same as before. Boinc client will adjust time estimation after some complete workunits.

You can find this in another thread, to be precise here: http://asteroidsathome.net/boinc/forum_thread.php?id=198

Some very quick benchmarks done on 6 machines, average CPU times in seconds:


Machine 'L' P4 XP32

v100.00 43956
v101.00 (sse2) 6054
v102.10 12853
v102.10 (sse2) 13650 SLOWER


Machine '2' Celeron XP32

v100.00 39362
v101.00 (sse2) 9920
v102.10 (sse3) 9839


Machine '5' P4 Linux32

v101.00 (sse2) 9138
v102.00 20213
v102.10 (sse2) 9101


Machine '6' P4 Linux32

v100.00 87784
v101.00 (sse2) 6989
v102.00 16181
v102.10 7416
v102.10 (sse2) 7031


Machine 'V' Celeron laptop XP32

v100.00 24582
v101.00 (sse2) 8380
v102.10 (sse2) 8397


Machine 'B' P4HT XP32

v100.00 48963
v101.00 (sse2) 9341
v102.10 18592
v102.10 (sse2) 18779 SLOWER


Basically, the new versions are at best no faster, and in 2 cases much slower.

Cheers,

Al.

There is no significant change in calculation between v101 and v102.

Some very quick benchmarks done on 6 machines, average CPU times in seconds:

Machine 'L' P4 XP32

v100.00        43956
v101.00 (sse2) 6054
v102.10        12853
v102.10 (sse2) 13650 [b]SLOWER[/b]


Machine '2' Celeron XP32

v100.00        39362
v101.00 (sse2) 9920
v102.10 (sse3) 9839


Machine '5' P4 Linux32

v101.00 (sse2) 9138
v102.00        20213
v102.10 (sse2) 9101


Machine '6' P4 Linux32

v100.00        87784
v101.00 (sse2) 6989
v102.00        16181
v102.10        7416
v102.10 (sse2) 7031


Machine 'V' Celeron laptop XP32

v100.00        24582
v101.00 (sse2) 8380
v102.10 (sse2) 8397


Machine 'B' P4HT XP32

v100.00        48963
v101.00 (sse2) 9341
v102.10        18592
v102.10 (sse2) 18779 [b]SLOWER[/b]

Basically, the new versions are at best no faster, and in 2 cases much slower.

Cheers,

Al.

To retain formating use:

[pre]

[/pre]

SSE2 CPU times to be the same as with the plain version is very unusual.
Are you sure the CPU was not downclocking (e.g. because of overheat or some powersave setting)?

---

- ALF - "Find out what you don't do well ..... then don't do it!" :)

No, nothing unusual with any of the machines, they work as expected on other projects, it's the apps that are wrong, not the hardware :) I'll just go NNW on everything that's got slower as it seems a bit silly burning the same amount of electricity to do less work.

I see none of my WUs have been validated today and I still have a huge backlog of work waiting for valiadation. Time to take a break and wait for everything to catch up I think :)

Cheers,

Al.

I see none of my WUs have been validated today and I still have a huge backlog of work waiting for valiadation. Time to take a break and wait for everything to catch up I think :)

business as usual - DB inflated due to noobs at work ;)

no offense, but there really is no need to keep old results in the DB for months.

huge DB = slow server..

I will do some improvements, but I didn't have much time now. The problem is that we do need the old results because we need backward records to know by whom which result what computed and some other minor data. I will reduce the database but I can't do that just like that. It is better to wait than to hurry up and then realize that what was needed is gone.
If anyone doesn't know the background and needs, can't say anything for sure.

I haven't had a single WU validated since: 1 Oct 2013, 23:25:12 UTC

I guess the validator must be working, or someone would have complained. Therefore it must be connected to the WUs I've run, which are all linux ones since then.

Cheers,

Al.

Just patience please, I have many things to do now and it takes a while server to validate it after some improvements.

Just out of curiosity - can you post the specs of the new server?

SETI do this on the 'Server status page' ('Hosts' at bottom):
http://setiathome.berkeley.edu/sah_status.html

(Over time they added more and more RAM to use as disk cache which as you know greatly improves the database search speed.
Of course you may need money to do that. Special 'Donate for Server RAM' thread in the News may probably help)

---

- ALF - "Find out what you don't do well ..... then don't do it!" :)

I think. Today, the lack of IO throughtput is the case. But I'm out of the box.

I will add the server specification to the server_status page.

"ChertseyAl" wrote:

Machine 'L' P4 XP32

v100.00 43956
v101.00 (sse2) 6054
v102.10 12853
v102.10 (sse2) 13650 SLOWER


Machine 'B' P4HT XP32

v100.00 48963
v101.00 (sse2) 9341
v102.10 18592
v102.10 (sse2) 18779 SLOWER


Basically, the new versions are at best no faster, and in 2 cases much slower.

It seems that this slower through hyper-threading. Limit the multicore utilization to 50% (one core).

I've got over 30 projects to report. Is the server down again?

Yes. See post http://asteroidsathome.net/boinc/forum_thread.php?id=203#1901

"ChertseyAl" wrote:

Machine 'L' P4 XP32

v100.00 43956
v101.00 (sse2) 6054
v102.10 12853
v102.10 (sse2) 13650 SLOWER


Machine 'B' P4HT XP32

v100.00 48963
v101.00 (sse2) 9341
v102.10 18592
v102.10 (sse2) 18779 SLOWER


Basically, the new versions are at best no faster, and in 2 cases much slower.

It seems that this slower through hyper-threading. Limit the multicore utilization to 50% (one core).

More like some of those larger 240 credit WUs...

More like some of those larger 240 credit WUs...

Not possible on/before 1 Oct 2013 (the original post)

Longer-running WUs sending started ~14 Oct 2013
http://asteroidsathome.net/boinc/forum_thread.php?id=206

---

- ALF - "Find out what you don't do well ..... then don't do it!" :)