No way. That's one craptastic CPU. No way. Decimal points?!

???

---

.

Anyway, there are still many powerfull machines using 32-bit OS, example host 1651904, currently with a RAC of almost 5000 on rank 250, ist using Windows 7 x86. That's not really slow.

??
1) A dual core five-years-old Atom has 5k? Just between 2 8-core I7??
2) All wus of this cpu are "computational error".
Smells like a cheater, like this...a transmeta single core :-O
This is much more credible: host 1204986, with 2k of rac

You might want to explain how exactly you get this number.

Example: top 10 hosts have 210000 of rac. 10% is 21000, like a 24 core Xeon or 10 pc like the Q9550 above. And these are only the first ten, think the first thousand.

Every year the number of 32bit OS falls, so it's time to change

---

Anyway, there are still many powerfull machines using 32-bit OS, example host 1651904, currently with a RAC of almost 5000 on rank 250, ist using Windows 7 x86. That's not really slow.

??
1) A dual core five-years-old Atom has 5k? Just between 2 8-core I7??
2) All wus of this cpu are "computational error".
Smells like a cheater, like this...a transmeta single core :-O
This is much more credible: host 1204986, with 2k of rac

OK, I haven't check it good enough, my fault.

You might want to explain how exactly you get this number.

Example: top 10 hosts have 210000 of rac. 10% is 21000, like a 24 core Xeon or 10 pc like the Q9550 above. And these are only the first ten, think the first thousand.

Every year the number of 32bit OS falls, so it's time to change

So just a guess of someone, who like to have a 64-bit application? Not good enough. You'd have to add up the RAC of all 32-bit hosts and all 64-bit hosts, I thought you found some stat site, which does that. What RAC the first 10 hosts have doesn't matter at all if we don't know what all other hosts have and what they are (32 or 64-bit).

Using 64-bit has also nothing to do with using SSE or other instruction sets and does not need to lead to a faster application, in fact it can lead even to a slower one because of the higher overhead.

All (or at least most, not sure right now) SETI optimized apps are BTW 32-bit. Nothing to gain from 64-bit, so no reason to not support all 32-bit hosts with optimized apps. It simply depends on the type of calculation wether you gain something from 64-bit or not. Collatz is a good example, where 64-bits really helps, simply because the large numbers they are working with don't fit into 32-bit registers.

---

.

Using 64-bit has also nothing to do with using SSE or other instruction sets and does not need to lead to a faster application, in fact it can lead even to a slower one because of the higher overhead.

As a matter of fact, we had a 64-Bit Ralph application with a speedup of about ~ 13% - remember?

No real answer was given why they withdrew it. Besides of course the fact that people like to crunch with ancient CPUs and Windows XP 32-Bit.

Their host database is full with corpses anyway. Purge it.

They can't even uprade their BOINC infrastructure so they could serve the fitting app for different clients.

They are all to busy. Good.

As a matter of fact, we had a 64-Bit Ralph application with a speedup of about ~ 13% - remember?

No, since I don't crunch on Ralph.

Besides of course the fact that people like to crunch with ancient CPUs and Windows XP 32-Bit.

Even Windows 10 is available as 32-bit and you can be sure, it will be used by some people (Microsoft didn't release it just for fun).

---

.

Even Windows 10 is available as 32-bit and you can be sure, it will be used by some people (Microsoft didn't release it just for fun).

There's always an excuse, huh? Let 'em die.

What RAC the first 10 hosts have doesn't matter at all if we don't know what all other hosts have and what they are (32 or 64-bit).

I, obviously, don't know how many 32 bit hosts are in this project, but my example shows how top 64 bit hosts can overshadow 32 bit with a little 10% of optimization.
The first 32 bit client is over 2000 rank and the others are worst.
We are almost at the end of 2015: 32 bit will not be the future, and clients with old OS (and OLD hw) are destined to die (Ubuntu 16.04 will be ONLY 64 bit).
For example, if you want to use 8 core cpu, you need 64 bit, cause the high usage of ram by rosetta.

Using 64-bit has also nothing to do with using SSE or other instruction sets and does not need to lead to a faster application, in fact it can lead even to a slower one because of the higher overhead.

But admins have only one branch code to develop and to test, not two (32/64).
Now they are using a not-native 64 bit application, so we don't know how the code will be.

---

Their host database is full with corpses anyway. Purge it.
They can't even uprade their BOINC infrastructure so they could serve the fitting app for different clients.

The update of rosetta's servers is something not to be put off, i think.

---

Anyway, there are still many powerfull machines using 32-bit OS, example host 1651904, currently with a RAC of almost 5000 on rank 250, ist using Windows 7 x86. That's not really slow.

??
1) A dual core five-years-old Atom has 5k? Just between 2 8-core I7??
2) All wus of this cpu are "computational error".
Smells like a cheater, like this...a transmeta single core :-O
This is much more credible: host 1204986, with 2k of rac

You might want to explain how exactly you get this number.

Example: top 10 hosts have 210000 of rac. 10% is 21000, like a 24 core Xeon or 10 pc like the Q9550 above. And these are only the first ten, think the first thousand.

Every year the number of 32bit OS falls, so it's time to change

"Cheater" is rather a harsh term.

I do, however, find it humorous that a the 1.66GHz Atom N450 gets 300 credits for a short "CPU time 522.6033 second" INVALID run result which about 5x the credits I get for a valid crunch on my machines that take 20x the time. The "Atom INVALID result" premium equals a 5x * 20x = 100x reward for zero production.
Granted credit 300.



Atom machines for BIG Rosetta credit. Prices starting at $10.

8-)

I do, however, find it humorous that a the 1.66GHz Atom N450 gets 300 credits for a short "CPU time 522.6033 second" INVALID run result which about 5x the credits I get for a valid crunch on my machines that take 20x the time. The "Atom INVALID result" premium equals a 5x * 20x = 100x reward for zero production.
Granted credit 300.

The guy (or girl?) most likely doesn't even know that his computer produces crap all day long. He probably thinks to himself:

"Hey, every bit counts, right? So here is my ancient machine doing all the glorious work to make the world a better place".

LOL.

"Cheater" is rather a harsh term.

Unintentional cheater is better :-)

I do, however, find it humorous that a the 1.66GHz Atom N450 gets 300 credits for a short "CPU time 522.6033 second" INVALID run result which about 5x the credits I get for a valid crunch on my machines that take 20x the time.

As i say, it's server fault.
Time to upgrade.

---

I do, however, find it humorous that a the 1.66GHz Atom N450 gets 300 credits for a short "CPU time 522.6033 second" INVALID run result which about 5x the credits I get for a valid crunch on my machines that take 20x the time.

As i say, it's server fault.
Time to upgrade.

Even the most recent versions of BOINC server software, like the one used on SETI for example, are far away from being good (not to mention perfect) on detecting bad machines and not sending work to them. Upgrading server software will improve many things, but for sure not that.

---

.

Are the FFD* tasks OK now? I've got one on my machine...

---

.

Are the FFD* tasks OK now? I've got one on my machine...

Yep, I have a few that have passed just fine:
694494363
694493875

The issues outlined in this thread were fixed with the update to 3.65

Are the FFD* tasks OK now? I've got one on my machine...

Yep, I have a few that have passed just fine:
694494363
694493875

The issues outlined in this thread were fixed with the update to 3.65

OK, thanks a lot.

---

.