A couple of "good" examples of CrditScrew in action.....

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Wow! 5 minutes on a 1070 with the special app. They had better award 3X credit. I see a BLC35 has a Peak swap size around 27GB. Your BLC41 has a Peak swap size around 70GB. Should be 3X credit in my opinion.

Depends on the CPU run time. If it has 3 times the amount of processing to do, then it will. If not, it won't. And then you've got the effects of Credit New and what it does to actually determine credit.
Expect to be disappointed.

---

Grant
Darwin NT

Swap size is a very poor metric for determining "credit due" - different applications* running on the same task may well have very different swap sizes.

* "applications" in this context includes command lines and parameters passed by BOINC "automagically" to the application.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Of the validated BLC41 WUs, the non-vlars here run normal times and pay normally.
The vlars take 3 times longer and payment has been over 3 times more.

---

Humans may rule the world...but bacteria run it...

I have two in my cache. Haven't gotten to them yet, but they're in the pipeline.

my two 41s: 3522928769 and 3522843580
...
Looking through how the higher the BLC number, the longer it takes.. the 41s could possibly be around.. 4300 or so, but i'll see in a few hours when those get crunched and returned.

Well the first one listed there is next-up to start crunching. The second one has already been returned and came in at 2253 seconds.. about half of what I was anticipating, and gave half the credits as normal, too.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

I only caught a few before the splitters changed tapes, but one was WU 3522701971

Mine is the second (run on a slow-running GTX 750Ti, despite what the host record says): ran over 50 minutes (normal is less than half that), but credit is also high.

I only caught a few before the splitters changed tapes, but one was WU 3522701971

Mine is the second (run on a slow-running GTX 750Ti, despite what the host record says): ran over 50 minutes (normal is less than half that), but credit is also high.

I also notice that there is almost the difference of 4 minutes between run-time and CPU time, run-time being longer

---

I have two in my cache. Haven't gotten to them yet, but they're in the pipeline.

my two 41s: 3522928769 and 3522843580
...
Looking through how the higher the BLC number, the longer it takes.. the 41s could possibly be around.. 4300 or so, but i'll see in a few hours when those get crunched and returned.

Well the first one listed there is next-up to start crunching. The second one has already been returned and came in at 2253 seconds.. about half of what I was anticipating, and gave half the credits as normal, too.

Second one finished and reported.
Completed and validated 6,440.44 6,439.09 145.26

twice as long as normal, little less than twice the credits. A quick visual average of the valid results seems to be 75-85 for a normal/WU, so getting 145 is roughly double.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

I only caught a few before the splitters changed tapes, but one was WU 3522701971

Mine is the second (run on a slow-running GTX 750Ti, despite what the host record says): ran over 50 minutes (normal is less than half that), but credit is also high.

I also notice that there is almost the difference of 4 minutes between run-time and CPU time, run-time being longer

Anytime that run_time is longer than cpu_time indicates the cpu is overcommitted. A 4 minute deficit over 50 minutes is acceptable in my opinion.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

I only caught a few before the splitters changed tapes, but one was WU 3522701971

Mine is the second (run on a slow-running GTX 750Ti, despite what the host record says): ran over 50 minutes (normal is less than half that), but credit is also high.

Wow. 50 minutes and then it Overflowed... Meaning, it would have taken longer if it would have finished. How much longer? Probably would have taken an Hour, based on My 750 Ti and the longer 41s. My 750 Ti takes over 20 minutes on those longer ones running CUDA, and that is about 3 Times faster than OpenCL in Windows. An hour to run a single GPU task on a 750 Ti? Pretty discouraging considering My 750 Ti is finishing the BLC 24s in about 7 minutes. Those longer 41s are pretty brutal. Fortunately, some of the 41.vlars run normally, such as the ones with PSR in the name. People looking at the run-times should note if the task OVERFLOWED. Aborted tasks will Not give an accurate indication of run-time, and many of the longer 41s are Overflowing.

BTW, CPU run-times don't mean much on GPU tasks, as long as it's around 10% or higher, it really depends on the App and the settings.

I only caught a few before the splitters changed tapes, but one was WU 3522701971

Mine is the second (run on a slow-running GTX 750Ti, despite what the host record says): ran over 50 minutes (normal is less than half that), but credit is also high.

Wow. 50 minutes and then it Overflowed... Meaning, it would have taken longer if it would have finished. How much longer? Probably would have taken an Hour, based on My 750 Ti and the longer 41s. My 750 Ti takes over 20 minutes on those longer ones running CUDA, and that is about 3 Times faster than OpenCL in Windows. An hour to run a single GPU task on a 750 Ti? Pretty discouraging considering My 750 Ti is finishing the BLC 24s in about 7 minutes. Those longer 41s are pretty brutal. Fortunately, some of the 41.vlars run normally, such as the ones with PSR in the name. People looking at the run-times should note if the task OVERFLOWED. Aborted tasks will Not give an accurate indication of run-time, and many of the longer 41s are Overflowing.

BTW, CPU run-times don't mean much on GPU tasks, as long as it's around 10% or higher, it really depends on the App and the settings.

Completely out of curiosity does anybody know at what percentage this task overflowed

---

No Panic, just caution...

The results received in the last hour is on the rise. Not a big deal at 124k, but could be a warning sign of an incoming shorty storm. I'm running 2+ days behind with my cache, so I can't tell if this is an issue, or just a small blip.

I'm really liking the data discussion. The guardian published an article about breakthrough listen project. Basically said we haven't found anything yet. It is very quiet except for the noise that we make. Still thinking we should make a separate thread for data discussion, so this thread can be for warning signs and true panics.

I picked up 11 new WUs, then after not seeing a resend for almost a month, I managed to pick one of them up as well.

---

Grant
Darwin NT

I picked up 11 new WUs, then after not seeing a resend for almost a month, I managed to pick one of them up as well.

Those were AP WUs, as for MB I've yet to see any from file 06my19ad.

18dc09aa is still there.

---

Grant
Darwin NT

as for MB I've yet to see any from file 06my19ad.

I've got one. It's a VLAR.

as for MB I've yet to see any from file 06my19ad.

I've got one. It's a VLAR.

Just got a few myself in the last 10min.
Just posting about something on the forums often seems to be the best way to get something happening.

Edit-
And the last couple of work requests have resulted in all Arecibo WUs.

---

Grant
Darwin NT

as for MB I've yet to see any from file 06my19ad.

I've got one. It's a VLAR.

Just got a few myself in the last 10min.
Just posting about something on the forums often seems to be the best way to get something happening.

Edit-
And the last couple of work requests have resulted in all Arecibo WUs.

It usually takes about 7hrs from the time Arecibo work is split until the time they start getting delivered.

Cheers.

[quote]It usually takes about 7hrs from the time Arecibo work is split until the time they start getting delivered.
Cheers.

. . Yay! It looks like someone finally kick started 18dc09aa .. at least it seems to have made some progress though I am not seeing any WUs from it. As for Arecibo work in general I have only about 2 dozen tasks on this machine (out of 300) But all Arecibo work is welcome :)

Stephen

:)

The first VLAR I got was

created 21 Jun 2019, 2:35:58 UTC
sent 21 Jun 2019, 8:51:38 UTC

That's where the six hours goes - in the 'ready to send' cache. No wait, no cache. It's what buffering is for.

It usually takes about 7hrs from the time Arecibo work is split until the time they start getting delivered.

Yep.
Depends on the runtime for the WUs already out there- Return rate varies between 95k-140k per hour.
Roughly 630k WUs in the ready_to_send buffer.
So roughly 6.5 to 4.5 hours for currently being split work to start coming through.


Another point of work flow interest- looking at the Haveland graphs for the AP received_last_hour numbers.
An initial surge and peak of work coming in, then a large drop, with a slight rise then gradual tapering off over several hours. Then a similar (though not quite as steep) a surge in returned work to a new high, a slight drop then back to the previous peak & now the gradual tapering off in work being returned again.
Interesting to see the effect of the combinations of large and small caches, high and low throughput systems, and project resource settings has on work being returned.

---

Grant
Darwin NT