Oh, look. My mac just got pulled back to normalcy... I guess it's probably on the brink of being affected by whatever issue is plaguing my main rig.

Now that 4.20 is officially out for Macs, I've adjusted my target runtime to the default value. If my theory on the issue is correct, the ARP for Rosetta 4.20 x86_64-apple-darwin should be about 2.9Gflops, and the number of credits per task should be around 270, which is still higher than what my main rig gets for 36-hour tasks.

https://boinc.bakerlab.org/rosetta/host_app_versions.php?hostid=2263735

Taking a look at my hosts, all seem to be getting right around 150-420 credits for 12 hours of work done. There is no rhyme or reason - the one getting over 400 credits per task isn't the most powerful, and the one getting the least is the most powerful, per core anyway.
My Xeon 2660 is pulling in more than my Ryzen 1800x per task.
https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=4274833

Then, there's the Ryzen. Which downloaded an amazingly huge number of tasks for a reason known only to Boinc, unless my keep more than 0.5 days didn't take effect in time. :( so probably means going over deadline. I wish I knew why this machine has some of the worst credits per task - less than 100? Is it Windows vs. Linux/mac? Is it the ridiculously high initial benchmarks on Linux for drystone? Can I abort these tasks without work being lost?
https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=4270228

Then, there's the Ryzen. Which downloaded an amazingly huge number of tasks for a reason known only to Boinc

There have been new Applications released, so they have no processing history. And as the Estimated completion times for new work & new applications are seriously broken, so if you have a cache of much more than 0.2 days & 0.002 days extra, you will end up with more work than you can possibly do before they reach their deadlines.

---

Grant
Darwin NT

if any one bothers to run it on a Threadripper 3990X it would be a mind boggling 128 concurrent threads lol

Oh, look. My mac just got pulled back to normalcy... I guess it's probably on the brink of being affected by whatever issue is plaguing my main rig.

Now that 4.20 is officially out for Macs, I've adjusted my target runtime to the default value. If my theory on the issue is correct, the ARP for Rosetta 4.20 x86_64-apple-darwin should be about 2.9Gflops, and the number of credits per task should be around 270, which is still higher than what my main rig gets for 36-hour tasks.

https://boinc.bakerlab.org/rosetta/host_app_versions.php?hostid=2263735

Taking a look at my hosts, all seem to be getting right around 150-420 credits for 12 hours of work done. There is no rhyme or reason - the one getting over 400 credits per task isn't the most powerful, and the one getting the least is the most powerful, per core anyway.
My Xeon 2660 is pulling in more than my Ryzen 1800x per task.
https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=4274833

Then, there's the Ryzen. Which downloaded an amazingly huge number of tasks for a reason known only to Boinc, unless my keep more than 0.5 days didn't take effect in time. :( so probably means going over deadline. I wish I knew why this machine has some of the worst credits per task - less than 100? Is it Windows vs. Linux/mac? Is it the ridiculously high initial benchmarks on Linux for drystone? Can I abort these tasks without work being lost?
https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=4270228

Look at your Average Processing rate under application details. That may give hint to the seemingly random nature of things.
Also, set your cache to 0.1 days with at most 0.1 days extra. Rosetta@home tasks with no processing history default to an estimated completion time of stupidly little hours (there has been a new release)

if any one bothers to run it on a Threadripper 3990X it would be a mind boggling 128 concurrent threads lol

Well, given the fact that the new 4.20 tasks on my end claimed to have a completion time of 57 minutes when downloaded, it may be MUCH worse.

Good thing I decided to reduce the target runtime to 8 hours (as an experiment on APR and credits per task) and stopped getting new tasks (to update the project URL) before things got completely out of hand.

Oh, look. My mac just got pulled back to normalcy... I guess it's probably on the brink of being affected by whatever issue is plaguing my main rig.

Now that 4.20 is officially out for Macs, I've adjusted my target runtime to the default value. If my theory on the issue is correct, the ARP for Rosetta 4.20 x86_64-apple-darwin should be about 2.9Gflops, and the number of credits per task should be around 270, which is still higher than what my main rig gets for 36-hour tasks.

https://boinc.bakerlab.org/rosetta/host_app_versions.php?hostid=2263735

Taking a look at my hosts, all seem to be getting right around 150-420 credits for 12 hours of work done.

Well, I'm getting 237 - 2000 for 36 tasks on my Ryzen 5 3600. 2000 immediately after Admin made a tweak, around 237 before the tweak and theses days, now that my APR is hilariously low.

BTW, aborting tasks won't result in work being lost.

Oh, look. My mac just got pulled back to normalcy... I guess it's probably on the brink of being affected by whatever issue is plaguing my main rig.

Now that 4.20 is officially out for Macs, I've adjusted my target runtime to the default value. If my theory on the issue is correct, the ARP for Rosetta 4.20 x86_64-apple-darwin should be about 2.9Gflops, and the number of credits per task should be around 270, which is still higher than what my main rig gets for 36-hour tasks.

https://boinc.bakerlab.org/rosetta/host_app_versions.php?hostid=2263735

Taking a look at my hosts, all seem to be getting right around 150-420 credits for 12 hours of work done. There is no rhyme or reason - the one getting over 400 credits per task isn't the most powerful, and the one getting the least is the most powerful, per core anyway.
My Xeon 2660 is pulling in more than my Ryzen 1800x per task.
https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=4274833

Then, there's the Ryzen. Which downloaded an amazingly huge number of tasks for a reason known only to Boinc, unless my keep more than 0.5 days didn't take effect in time. :( so probably means going over deadline. I wish I knew why this machine has some of the worst credits per task - less than 100? Is it Windows vs. Linux/mac? Is it the ridiculously high initial benchmarks on Linux for drystone? Can I abort these tasks without work being lost?
https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=4270228

Oh
For your Ryzen.
Measured floating point speed 4465.37 million ops/sec
Rosetta 4.15 windows_x86_64
Number of tasks completed 15
Max tasks per day 498
Number of tasks today 1
Consecutive valid tasks 0
Average processing rate 1.80 GFLOPS
Average turnaround time 2.46 days

For your Xeon
Measured floating point speed 3373.2 million ops/sec
Rosetta 4.15 x86_64-pc-linux-gnu
Number of tasks completed 79
Max tasks per day 579
Number of tasks today 7
Consecutive valid tasks 79
Average processing rate 1.90 GFLOPS
Average turnaround time 1.19 days

Let me make a wild guess, you have a longer target runtime for your Ryzen?
If so, try setting them both to the same target runtime, preferably shortening the target runtime on the Ryzen to match the Xeon. I'm curious how this affects your APR and credits.

My theory is that Rosetta is using the BOINC credit new system to calculate the claimed credits, which if I understand things correctly relies on the APR of the host, and has their own credit system which the validator uses and awards credits based on actual work done (decoys generated). Once the validator's calculated credits exceed the claimed credits by a large enough margin, it thorws out the calculated credits and awards you the claimed credits.

The problem appears to be with the APR calculations. It appears the APR calculations do not take into account that longer running tasks mean more work on the same CPU. That means all things equal, the longer your target runtime, the lower your APR and the more likely the credit to be absurdly low. That also means that more powerful CPU cores are more likely to be affected by this problem since a more powerful CPU is more likely to have their calculated credits exceed their claimed credits by a wide margin.

If this is true, I see two fixed to this problem.
1) Fix the APR calculations
2) Disregard the claimed credits entirely when awarding credits to hosts.

Oh, look. My mac just got pulled back to normalcy... I guess it's probably on the brink of being affected by whatever issue is plaguing my main rig.

Now that 4.20 is officially out for Macs, I've adjusted my target runtime to the default value. If my theory on the issue is correct, the ARP for Rosetta 4.20 x86_64-apple-darwin should be about 2.9Gflops, and the number of credits per task should be around 270, which is still higher than what my main rig gets for 36-hour tasks.

https://boinc.bakerlab.org/rosetta/host_app_versions.php?hostid=2263735

Taking a look at my hosts, all seem to be getting right around 150-420 credits for 12 hours of work done. There is no rhyme or reason - the one getting over 400 credits per task isn't the most powerful, and the one getting the least is the most powerful, per core anyway.
My Xeon 2660 is pulling in more than my Ryzen 1800x per task.
https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=4274833

Then, there's the Ryzen. Which downloaded an amazingly huge number of tasks for a reason known only to Boinc, unless my keep more than 0.5 days didn't take effect in time. :( so probably means going over deadline. I wish I knew why this machine has some of the worst credits per task - less than 100? Is it Windows vs. Linux/mac? Is it the ridiculously high initial benchmarks on Linux for drystone? Can I abort these tasks without work being lost?
https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=4270228

Oh
For your Ryzen.
Measured floating point speed 4465.37 million ops/sec
Rosetta 4.15 windows_x86_64
Number of tasks completed 15
Max tasks per day 498
Number of tasks today 1
Consecutive valid tasks 0
Average processing rate 1.80 GFLOPS
Average turnaround time 2.46 days

For your Xeon
Measured floating point speed 3373.2 million ops/sec
Rosetta 4.15 x86_64-pc-linux-gnu
Number of tasks completed 79
Max tasks per day 579
Number of tasks today 7
Consecutive valid tasks 79
Average processing rate 1.90 GFLOPS
Average turnaround time 1.19 days

Let me make a wild guess, you have a longer target runtime for your Ryzen?
If so, try setting them both to the same target runtime, preferably shortening the target runtime on the Ryzen to match the Xeon. I'm curious how this affects your APR and credits.

My theory is that Rosetta is using the BOINC credit new system to calculate the claimed credits, which if I understand things correctly relies on the APR of the host, and has their own credit system which the validator uses and awards credits based on actual work done (decoys generated). Once the validator's calculated credits exceed the claimed credits by a large enough margin, it thorws out the calculated credits and awards you the claimed credits.

The problem appears to be with the APR calculations. It appears the APR calculations do not take into account that longer running tasks mean more work on the same CPU. That means all things equal, the longer your target runtime, the lower your APR and the more likely the credit to be absurdly low. That also means that more powerful CPU cores are more likely to be affected by this problem since a more powerful CPU is more likely to have their calculated credits exceed their claimed credits by a wide margin.

If this is true, I see two fixed to this problem.
1) Fix the APR calculations
2) Disregard the claimed credits entirely when awarding credits to hosts.

Both are set to 12 hours, though will probably be changing that very soon as these new 56 minute estimations are making things very difficult.

Oh, look. My mac just got pulled back to normalcy... I guess it's probably on the brink of being affected by whatever issue is plaguing my main rig.

Now that 4.20 is officially out for Macs, I've adjusted my target runtime to the default value. If my theory on the issue is correct, the ARP for Rosetta 4.20 x86_64-apple-darwin should be about 2.9Gflops, and the number of credits per task should be around 270, which is still higher than what my main rig gets for 36-hour tasks.

https://boinc.bakerlab.org/rosetta/host_app_versions.php?hostid=2263735

Taking a look at my hosts, all seem to be getting right around 150-420 credits for 12 hours of work done. There is no rhyme or reason - the one getting over 400 credits per task isn't the most powerful, and the one getting the least is the most powerful, per core anyway.
My Xeon 2660 is pulling in more than my Ryzen 1800x per task.
https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=4274833

Then, there's the Ryzen. Which downloaded an amazingly huge number of tasks for a reason known only to Boinc, unless my keep more than 0.5 days didn't take effect in time. :( so probably means going over deadline. I wish I knew why this machine has some of the worst credits per task - less than 100? Is it Windows vs. Linux/mac? Is it the ridiculously high initial benchmarks on Linux for drystone? Can I abort these tasks without work being lost?
https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=4270228

Oh
For your Ryzen.
Measured floating point speed 4465.37 million ops/sec
Rosetta 4.15 windows_x86_64
Number of tasks completed 15
Max tasks per day 498
Number of tasks today 1
Consecutive valid tasks 0
Average processing rate 1.80 GFLOPS
Average turnaround time 2.46 days

For your Xeon
Measured floating point speed 3373.2 million ops/sec
Rosetta 4.15 x86_64-pc-linux-gnu
Number of tasks completed 79
Max tasks per day 579
Number of tasks today 7
Consecutive valid tasks 79
Average processing rate 1.90 GFLOPS
Average turnaround time 1.19 days

Let me make a wild guess, you have a longer target runtime for your Ryzen?
If so, try setting them both to the same target runtime, preferably shortening the target runtime on the Ryzen to match the Xeon. I'm curious how this affects your APR and credits.

My theory is that Rosetta is using the BOINC credit new system to calculate the claimed credits, which if I understand things correctly relies on the APR of the host, and has their own credit system which the validator uses and awards credits based on actual work done (decoys generated). Once the validator's calculated credits exceed the claimed credits by a large enough margin, it thorws out the calculated credits and awards you the claimed credits.

The problem appears to be with the APR calculations. It appears the APR calculations do not take into account that longer running tasks mean more work on the same CPU. That means all things equal, the longer your target runtime, the lower your APR and the more likely the credit to be absurdly low. That also means that more powerful CPU cores are more likely to be affected by this problem since a more powerful CPU is more likely to have their calculated credits exceed their claimed credits by a wide margin.

If this is true, I see two fixed to this problem.
1) Fix the APR calculations
2) Disregard the claimed credits entirely when awarding credits to hosts.

Both are set to 12 hours, though will probably be changing that very soon as these new 56 minute estimations are making things very difficult.

Yeah, I've learned the hard way that you should set as small a cache as possible with Rosetta@home since new app releases have a tendency to make things somewhat unpleasant.

Hmm, I set the target run-time to 8 hours and the APR jumps to 3.02 GFLOPS, an increase from the APR I got with a target run-time of 36 hours by a factor of 4.65.
https://boinc.bakerlab.org/rosetta/host_app_versions.php?hostid=2263735
I've set the target run-time back to 36 hours, so I expect my APR to drop soon...
Just to make sure it isn't a problem between different versions, I've left my main rig untouched.

Rosetta 4.16 x86_64-apple-darwin (All of these ran with the target runtime set to 36 hours)
Number of tasks completed 29
Max tasks per day 519
Number of tasks today 0
Consecutive valid tasks 19
Average processing rate 0.65 GFLOPS
Average turnaround time 1.96 days

Rosetta 4.20 x86_64-apple-darwin
Number of tasks completed 1
Max tasks per day 501
Number of tasks today 0
Consecutive valid tasks 1
Average processing rate 3.02 GFLOPS
Average turnaround time 0.41 days

That means the problem IS the target runtime. For each version, I had different target runtimes. 6 hours before 4.12, 24 hours on 4.12, 36hours after 4.12. Since your data suggests software version has very little effect on APR than that leaves only target runtime.
Why does increasing the target runtime to 24 hours from 6hours cause a decrease in ARP by a factor of around 4? Why does increasing the target runtime cause the ARP to drop even further?

*Note, I just edited my previous message*

In short, whatever method is used for credits, consistency or coherence isn't going to arrive.
There might be consistency within Junior_Halfroid tasks, or r4k or r3x (or might not - they change so often) but you get what you get and any time you spend worrying about it is wasted.

But a 6X different in ARP isn't normal in any sense. Why am I getting not much more, if not fewer credits per tasks for 36-hour tasks than 6-hour tasks? (I used to get around 150 per task, now I'm getting 230-240 per task, on a faster CPU, with a 36-hour run-time) It almost appears as the project thinks 36-hour tasks have a similar amount of work done as 6-hour ones, and your computer must be 6X slower because it took 6X the time for completion. If it was a 10% difference I wouldn't worry. If it is a 6X difference than something seems wrong.

have a look at this host, an Ryzen 7 2700X achieving an ARP of 10.33 GFLOPS. How's that even possible? Look at the typical runtime of the tasks, and you'll realize that the user has a pretty short target runtime.
https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=3684192

Besides, after Admin's tweak, I consistently got around 2000 credits for r4k tasks, but now I'm getting 230-240 credits per tasks most of the time (again). It's not a problem with consistency.

Once 4.20 drops, I may shorten my target runtime to 8 hours, just to prove a point.

Your Ryzen 5 is a good example of my point. 3x36hr tasks. One gives 800, one 1100, one 1900.
You're trying to make something rational that isn't going to reward you for your effort.
If I could spend credits somewhere I might agree it was worth obsessing over. But I can't.
Have you ever tried learning to play the guitar?

---

Both are set to 12 hours, though will probably be changing that very soon as these new 56 minute estimations are making things very difficult.

Yeah, I've learned the hard way that you should set as small a cache as possible with Rosetta@home since new app releases have a tendency to make things somewhat unpleasant.

To be fair, we haven't had a program update for a pretty long time so it was only ever a temporary problem before, forgotten after a week.
Someone will come up with a "Things we should thank our new virus overlords for" in the café soon.
I live quite close to an airport and the air is so much cleaner recently. That's number one.
Leading to a resolution of Boinc initial runtimes and credits will be about number 536.

---

That means the problem IS the target runtime. For each version, I had different target runtimes. 6 hours before 4.12, 24 hours on 4.12, 36hours after 4.12. Since your data suggests software version has very little effect on APR than that leaves only target runtime.
Why does increasing the target runtime to 24 hours from 6hours cause a decrease in ARP by a factor of around 4? Why does increasing the target runtime cause the ARP to drop even further?

*Note, I just edited my previous message*

In short, whatever method is used for credits, consistency or coherence isn't going to arrive.
There might be consistency within Junior_Halfroid tasks, or r4k or r3x (or might not - they change so often) but you get what you get and any time you spend worrying about it is wasted.

But a 6X different in ARP isn't normal in any sense. Why am I getting not much more, if not fewer credits per tasks for 36-hour tasks than 6-hour tasks? (I used to get around 150 per task, now I'm getting 230-240 per task, on a faster CPU, with a 36-hour run-time) It almost appears as the project thinks 36-hour tasks have a similar amount of work done as 6-hour ones, and your computer must be 6X slower because it took 6X the time for completion. If it was a 10% difference I wouldn't worry. If it is a 6X difference than something seems wrong.

have a look at this host, an Ryzen 7 2700X achieving an ARP of 10.33 GFLOPS. How's that even possible? Look at the typical runtime of the tasks, and you'll realize that the user has a pretty short target runtime.
https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=3684192


Besides, after Admin's tweak, I consistently got around 2000 credits for r4k tasks, but now I'm getting 230-240 credits per tasks most of the time (again). It's not a problem with consistency.

Once 4.20 drops, I may shorten my target runtime to 8 hours, just to prove a point.

Your Ryzen 5 is a good example of my point. 3x36hr tasks. One gives 800, one 1100, one 1900.
You're trying to make something rational that isn't going to reward you for your effort.
If I could spend credits somewhere I might agree it was worth obsessing over. But I can't.
Have you ever tried learning to play the guitar?

What do you mean? I am not obsessing over credits. If that were the case, I would have set my target run-time to 8 hours and be done with it. Something is wrong with the credit system, and that problem affects those with long target run-times way more than those with shorter one. There is a problem, so it needs to be fixed. That's my logic.
If NOBODY tries digging into the problem, it will never be fixed. If it there turns out the problem isn't actually real, fine. However, the Admin DID tweak something which did fix the problem for a quite a while. Read the Admin's posts here, they do suggest something really weird is going on (my main rig was claiming a really low amount of credits).

That means the problem IS the target runtime. For each version, I had different target runtimes. 6 hours before 4.12, 24 hours on 4.12, 36hours after 4.12. Since your data suggests software version has very little effect on APR than that leaves only target runtime.
Why does increasing the target runtime to 24 hours from 6hours cause a decrease in ARP by a factor of around 4? Why does increasing the target runtime cause the ARP to drop even further?

*Note, I just edited my previous message*

In short, whatever method is used for credits, consistency or coherence isn't going to arrive.
There might be consistency within Junior_Halfroid tasks, or r4k or r3x (or might not - they change so often) but you get what you get and any time you spend worrying about it is wasted.

But a 6X different in ARP isn't normal in any sense. Why am I getting not much more, if not fewer credits per tasks for 36-hour tasks than 6-hour tasks? (I used to get around 150 per task, now I'm getting 230-240 per task, on a faster CPU, with a 36-hour run-time) It almost appears as the project thinks 36-hour tasks have a similar amount of work done as 6-hour ones, and your computer must be 6X slower because it took 6X the time for completion. If it was a 10% difference I wouldn't worry. If it is a 6X difference than something seems wrong.

have a look at this host, an Ryzen 7 2700X achieving an ARP of 10.33 GFLOPS. How's that even possible? Look at the typical runtime of the tasks, and you'll realize that the user has a pretty short target runtime.
https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=3684192

Besides, after Admin's tweak, I consistently got around 2000 credits for r4k tasks, but now I'm getting 230-240 credits per tasks most of the time (again). It's not a problem with consistency.

Once 4.20 drops, I may shorten my target runtime to 8 hours, just to prove a point.

Your Ryzen 5 is a good example of my point. 3x36hr tasks. One gives 800, one 1100, one 1900.
You're trying to make something rational that isn't going to reward you for your effort.
If I could spend credits somewhere I might agree it was worth obsessing over. But I can't.
Have you ever tried learning to play the guitar?

From the Admin:

What was happening with your jobs was that there is a check that makes sure that (the credit/model average from our server) * (the number of models your computer generated) is not greater than X*(claimed credit reported back from your BOINC client) where X is a parameter we have set. Since your computer was reporting back relatively low credit (like < 300), and was thus not passing the above criteria, our validator was just giving you the claimed credit.

Finally, some normalcy (as in, not 10X difference between tasks on the same computer) again. Hope it stays

I believe the credit on specific WUs you are looking at varies due to the type of work you are doing. With the fragments that bcov mentioned, there are only a few WUs created for each of thousands of fragments. So for any of the fragments, the odds of you being the first to report a result for that specific fragment is much much higher than other types of tasks.

For most tasks, there are thousands of WUs created. The credit for the very first one to report back is based on the credit claim of the host that returns it. But every report after that is based on the average of the credit claims that precede you. So, for these tasks, the credit per model stabilizes very quickly and is awarded very consistently. With the fragment tasks, not so much.

---

Rosetta Moderator: Mod.Sense

I believe the credit on specific WUs you are looking at varies due to the type of work you are doing. With the fragments that bcov mentioned, there are only a few WUs created for each of thousands of fragments. So for any of the fragments, the odds of you being the first to report a result for that specific fragment is much much higher than other types of tasks.

For most tasks, there are thousands of WUs created. The credit for the very first one to report back is based on the credit claim of the host that returns it. But every report after that is based on the average of the credit claims that precede you. So, for these tasks, the credit per model stabilizes very quickly and is awarded very consistently. With the fragment tasks, not so much.

Alright, that makes a lot of sense. Thanks! I guess the fact that my target run-time is so long makes this process particularly jarring for me. For me, it's a sudden dip to 200 credits, before quickly shooting back up to around 2000...

I believe the credit on specific WUs you are looking at varies due to the type of work you are doing. With the fragments that bcov mentioned, there are only a few WUs created for each of thousands of fragments. So for any of the fragments, the odds of you being the first to report a result for that specific fragment is much much higher than other types of tasks.

For most tasks, there are thousands of WUs created. The credit for the very first one to report back is based on the credit claim of the host that returns it. But every report after that is based on the average of the credit claims that precede you. So, for these tasks, the credit per model stabilizes very quickly and is awarded very consistently. With the fragment tasks, not so much.

Alright, that makes a lot of sense. Thanks! I guess the fact that my target run-time is so long makes this process particularly jarring for me. For me, it's a sudden dip to 200 credits, before quickly shooting back up to around 2000...

This is what I meant when I wrote:

I'd suggest the average credit for newer tasks might be lower on recent tasks because of a very different profile of users since they came out, with so many powerful machines transferring from Seti.

I was actually referring to average credit from newer Rosetta program versions rather then tasks, but it's not so different

---

WTH is this?! Took my overclocked Ryzen 3900x over SIX hours to get SIX........SIX credits?! Is this a credit error, or the norm? What a waste of electricity...

Did I get a batch of bad WU's?! Can someone please look into the following?

TASK: 1165850138 WORK UNIT: 1045787673 SENT: 30 Apr 2020, 22:27:22 UTC REPORTED: 3 May 2020, 19:02:13 UTC Completed and validated TOTAL TIME: 23,504.78 CPU TIME: 22,564.69 CREDIT= 7.06 Rosetta v4.15
windows_x86_64
1165798670 1048233647 30 Apr 2020, 21:57:15 UTC 3 May 2020, 19:02:51 UTC Completed and validated 24,268.53 23,202.55 CREDIT= 6.46 Rosetta v4.15
windows_x86_64
1165774723 1048213014 30 Apr 2020, 21:23:53 UTC 3 May 2020, 18:07:52 UTC Completed and validated 22,475.43 21,490.02 CREDIT= 7.65 Rosetta v4.15
windows_x86_64
1165751409 1048192909 30 Apr 2020, 20:50:56 UTC 3 May 2020, 16:42:29 UTC Completed and validated 22,156.37 21,163.57 CREDIT= 6.22 Rosetta v4.15
windows_x86_64
1165779858 1048149788 30 Apr 2020, 20:42:40 UTC 3 May 2020, 16:41:20 UTC Completed and validated 23,246.45 22,230.59 CREDIT= 6.32 Rosetta v4.15
windows_x86_64
1165742379 1048185110 30 Apr 2020, 20:37:25 UTC 3 May 2020, 22:31:38 UTC Completed and validated 31,895.94 30,596.40 CREDIT= 45.84 Rosetta v4.15
windows_x86_64
1165733818 1048177553 30 Apr 2020, 20:25:06 UTC 3 May 2020, 22:32:28 UTC Completed and validated 34,077.06 32,814.71 CREDIT= 39.39 Rosetta v4.15
windows_x86_64

Those were all crunched by computer 4246752. Measured floating point speed: 4958.25 million ops/sec
Measured integer speed: 19723.67 million ops/sec

---

I took a look and it appears your host was successfully returning results but then became unstable. Might there be an issue with the host?

---