Just more badly prepared non working units that crap out on both M$ and Linux this time.
and it looks like there is over a million of them to get through.

Should I resume accepting new work units so that Rosetta@home will get through those? Is there no-one there who can delete those at the server end?

HAH! Your dreaming.

This must be prepared by the same twit that made those other tasks that errored out on WIN but worked on Linux. Welcome to the RAH. I've got 8 in queue and the last time I aborted scores upon scores of them they just kept coming.

No new work means you miss out on python, at the same time if you guys just accept them and take the hits and wingman the faulty units, the faster they will get out of the queue. If you do no new work that leaves them in the queue and the rest of use get F'd over.

They die in 1 minute and a few seconds. So that is 8 minutes on my system (half my cores for 1 minute each). That's not to bad.

They die in 1 minute and a few seconds. So that is 8 minutes on my system (half my cores for 1 minute each). That's not to bad.

Ha! Ha! Ha! My machine is faster than yours: mine all die in 20 to 40 seconds!

---

They die in 1 minute and a few seconds. So that is 8 minutes on my system (half my cores for 1 minute each). That's not to bad.

Ha! Ha! Ha! My machine is faster than yours: mine all die in 20 to 40 seconds!

LMAO. I watched the ones on my system, I think it takes 30 seconds to go through all the setup and then run time was 30 seconds. Go get em tiger! lol

I just blasted RAH on Twitter (not that they will notice)....

They die in 1 minute and a few seconds. So that is 8 minutes on my system (half my cores for 1 minute each). That's not to bad.

Ha! Ha! Ha! My machine is faster than yours: mine all die in 20 to 40 seconds!

A work colleague from many years ago had a phrase for this kind of thing.

We're getting nowhere fast.
We're getting nowhere faster than we've ever got nowhere before

---

They die in 1 minute and a few seconds. So that is 8 minutes on my system (half my cores for 1 minute each). That's not to bad.

Ha! Ha! Ha! My machine is faster than yours: mine all die in 20 to 40 seconds!

A work colleague from many years ago had a phrase for this kind of thing.

We're getting nowhere fast.
We're getting nowhere faster than we've ever got nowhere before

Blame Marvin, his depression is making this system act up.
Or is it the improbability drive?

They die in 1 minute and a few seconds. So that is 8 minutes on my system (half my cores for 1 minute each). That's not to bad.

Ha! Ha! Ha! My machine is faster than yours: mine all die in 20 to 40 seconds!

A work colleague from many years ago had a phrase for this kind of thing.

We're getting nowhere fast.
We're getting nowhere faster than we've ever got nowhere before

Blame Marvin, his depression is making this system act up.
Or is it the improbability drive?

Oh, was the phrase from Hitchhiker's Guide? I must've missed it. Usually, I'm quite good at picking up quotes from that.

"Here's me, brain the size of a planet, and you want me to open a door for you?"
Maybe not such a paranoid android

---

Ha! Ha! Ha! My machine is faster than yours: mine all die in 20 to 40 seconds!

LMAO. I watched the ones on my system, I think it takes 30 seconds to go through all the setup and then run time was 30 seconds. Go get em tiger! lol

My boinc stuff, this:

/usr/bin/boinc
/usr/bin/boinc_client
/usr/bin/boinccmd
/usr/bin/boincmgr
/usr/bin/boincscr
/usr/lib/systemd/system/boinc-client.service
/usr/lib64/libboinc_api.so.7
/usr/lib64/libboinc_api.so.7.16.11
/usr/lib64/libboinc_graphics2.so.7
/usr/lib64/libboinc_graphics2.so.7.16.11
/usr/lib64/libboinc_opencl.so.7
/usr/lib64/libboinc_opencl.so.7.16.11

is all on an SSD, so those must load very quickly.

/usr/bin/boinc_client loads once when I boot up the system. When I am logged in I run /usr/bin/boincmgr but at nice level 10.

Downloading new work units is pretty fast because my Internet datalink is 75 megabits/ second. Actual are

Average upload rate 	349.60 KB/sec
Average download rate  8830.07 KB/sec

N.B.: these are given in KiloBytes/second, where my Internet speeds ae in Megabits per second.

But all the rest is in /var/lib/boinc that is a spinning 7200 rpm SATA hard drive. It is huge, but the partition with the boinc stuff is large but not huge. OTOH, there are only three partitions on there, and the other two are mainly movies that are not used much unless I am bored.

For the little test above, the only program I need to execute from the spinning hard drive is

125232600 Dec 18 14:34 rosetta_4.20_x86_64-pc-linux-gnu

Furthermore, since I have 64 GBytes of RAM, the programs actually used are probably in the disk-read cache in RAM, from which they must load almost instantly. And if they are not in the disk-read cache, the heads do not need to move very far since the records are all together in their own relatively small partition.

So the heads do not move very much.

---

Yes it was Hitchikers. Very good.
I run my windows on one SSD and because I had data storage problems early on (which turns out to be a mixup in the interpretation of the wording in BOINC) so I bought a second SSD for BOINC data and corrected my mistake. That gives me a new drive to put C: on if the other one starts to run out of life.

I have a spinner, but it's just deep storage archive.
I had this grand idea of downloading movies and music and such, but I don't have time for that and the movies download has gotten a bit more tricky.

I'm getting computation errors on all Rosetta work from today, anybody else?

You mean them dated 25th like in yesterday and yes they errored out. The ones from today are good, at least for four hours.

hello. How did I get to see such a great post? Your post has been a great help to me. I hope to see you next time with a good post. I cheer for you. :) 먹튀검증