still unclear how they determine inconclusives if it's not being compared to anything lol

I assume that's the small number of yours which are still being randomly tested? And that number drops as you get more trustworthy.

Oh, I thought you had a few of those. What are those ones you have watercooled about 4 in one PC you showed a picture of in Einstein?

i don't run that system anymore, but it was 7x RTX 2080. that system has since been dismantled, parted out, and converted to something else. I don't have any multi-GPU setups that are water cooled like that anymore. my other multi-GPU systems are air cooled at the moment.

Odd, I see it as 7.5Tflops DP, pretty much the same as all my old Tahitis together, and I get 1 maybe 1.5 million credits a day.

theoretical specs vs real world outcome. just look at the leaderboard here and you'll see MANY TitanVs in the 2-2.5M range per GPU. and with tuning you can push it more. mine should come close to 3M if i run it long enough.

---

I believe they fit each result returned into a "not unreasonable result" filter. I believe that is defined by the:
<stream_only_likelihood2>
<search_likelihood2>
values returned for each result in the stderr.txt output. If the values are reasonable, then they don't need an extra validation task, if unreasonable the result goes into inconclusive status and warrants a wingman task.

---

theoretical specs vs real world outcome. just look at the leaderboard here and you'll see MANY TitanVs in the 2-2.5M range per GPU. and with tuning you can push it more. mine should come close to 3M if i run it long enough.

I guess those specs (I get from techpowerup) are raw specs, like looking at GHz of a CPU. Your Titan presumably has a better instruction set MW can take advantage of.

I take it you're considerably richer than me :-/ https://youtu.be/qRKbX_ilsVI?t=4

I believe they fit each result returned into a "not unreasonable result" filter. I believe that is defined by the:
<stream_only_likelihood2>
<search_likelihood2>
values returned for each result in the stderr.txt output. If the values are reasonable, then they don't need an extra validation task, if unreasonable the result goes into inconclusive status and warrants a wingman task.

Sounds good, so when I stick a dodgy GPU into my good host, it'll get spotted for the charlatan it is pretty quickly.

I believe they fit each result returned into a "not unreasonable result" filter. I believe that is defined by the:
<stream_only_likelihood2>
<search_likelihood2>
values returned for each result in the stderr.txt output. If the values are reasonable, then they don't need an extra validation task, if unreasonable the result goes into inconclusive status and warrants a wingman task.

Sounds good, so when I stick a dodgy GPU into my good host, it'll get spotted for the charlatan it is pretty quickly.

Yes it should and the whole host will will then be put on 'watch' again requiring wingmen until you get 10 valid tasks in a row

Yes it should and the whole host will will then be put on 'watch' again requiring wingmen until you get 10 valid tasks in a row

I buy broken cards and resurrect. You can get a busted one for a third of the price. Sometimes just a fan is broken, or the fan controller which you can bypass, or some heatsink gunk and pads (I use the super stuff, carbon nanotubes or something) make it work again.

my boinc playlist gpu calculations all videos https://www.youtube.com/watch?v=pYVW9oA9yWk&list=PL_r97NUMjf7x4TgZT3bwQYL8KV_Vbo2J8

---

Is there a bit of a problem waiting for validation is steadily heading north to 700,000 units ?

Yes, the pendings started climbing at an alarming rate not too long ago.

https://grafana.kiska.pw/d/boinc/boinc?orgId=1&var-project=milkyway@home&from=now-7d&to=now&viewPanel=3

Even surprising the spike that happened back during the FB Sprint when one team dropped all their bunkers.

I'm currently sitting at nearly 60k pendings myself.

Does it matter? Just keep crunching and let them pile up, somebody will sort it eventually.

There's always an enormous queue waiting on us, why get upset when there's a tiny queue waiting on them?

Does it matter? Just keep crunching and let them pile up, somebody will sort it eventually.

There's always an enormous queue waiting on us, why get upset when there's a tiny queue waiting on them?

No it probably doesn’t, just making an observation..

If the admins aren't aware of the issue then the disk(s) will potentially fill up. When that happens no new tasks will be created and no tasks will be able to be uploaded. Thus, halting the progress of the project until it's sorted.

If the admins aren't aware of the issue then the disk(s) will potentially fill up. When that happens no new tasks will be created and no tasks will be able to be uploaded. Thus, halting the progress of the project until it's sorted.

Nothing we can do about it. If the admins are at work, they'll notice. Unless you know one is on vacation and you can tell him and he can fix it remotely.

If the admins aren't aware of the issue then the disk(s) will potentially fill up. When that happens no new tasks will be created and no tasks will be able to be uploaded. Thus, halting the progress of the project until it's sorted.

Nothing we can do about it. If the admins are at work, they'll notice. Unless you know one is on vacation and you can tell him and he can fix it remotely.

It usually takes a physical on site reboot of the Server to fix things, and they don't stop making new tasks, they just keep on making tasks even though the other Server is no longer validating tasks very fast.

If the admins aren't aware of the issue then the disk(s) will potentially fill up. When that happens no new tasks will be created and no tasks will be able to be uploaded. Thus, halting the progress of the project until it's sorted.

Nothing we can do about it. If the admins are at work, they'll notice. Unless you know one is on vacation and you can tell him and he can fix it remotely.

It usually takes a physical on site reboot of the Server to fix things, and they don't stop making new tasks, they just keep on making tasks even though the other Server is no longer validating tasks very fast.

I thought a remote reboot might be possible.

Presumably these tasks don't take up much disk space, if they do, they'd just queue up on our computers to send back.

It's not that many really, a similar number to how many we all have on our computers.

[quote]If the admins aren't aware of the issue then the disk(s) will potentially fill up. When that happens no new tasks will be created and no tasks will be able to be uploaded. Thus, halting the progress of the project until it's sorted.

Nothing we can do about it. If the admins are at work, they'll notice. Unless you know one is on vacation and you can tell him and he can fix it remotely.

It usually takes a physical on site reboot of the Server to fix things, and they don't stop making new tasks, they just keep on making tasks even though the other Server is no longer validating tasks very fast.

I thought a remote reboot might be possible.[/quite]

It should be but Tom the previous Admin said it almost never worked for him

Presumably these tasks don't take up much disk space, if they do, they'd just queue up on our computers to send back.

It's not that many really, a similar number to how many we all have on our computers.

Hopefully, though they did just release new N-Body runs and a couple people says they are taking days to run not hours.

I thought a remote reboot might be possible.[/quite]

Quite :-)

It should be but Tom the previous Admin said it almost never worked for him

Probably a lazy server which needed a size 10 boot. I wonder if that's where the term "booting a computer" came from.

Hopefully, though they did just release new N-Body runs and a couple people says they are taking days to run not hours.

14 minutes to 7 hours, last ones I did, February, Ryzen 3900XT 12 cores per task.

I wonder what the long ones mean. New way of calculating? Something interesting found?

I am more than happy to assist with processing any work I get especially tasks with _2 or more. Should I process a more tasks when my current work queue is clear or wait for the validation queue to drop?

I thought a remote reboot might be possible.[/quite]

Quite :-)

It should be but Tom the previous Admin said it almost never worked for him

Probably a lazy server which needed a size 10 boot. I wonder if that's where the term "booting a computer" came from.

Hopefully, though they did just release new N-Body runs and a couple people says they are taking days to run not hours.

14 minutes to 7 hours, last ones I did, February, Ryzen 3900XT 12 cores per task.

I wonder what the long ones mean. New way of calculating? Something interesting found?

Tom always said the beginning of the runs were taking longer calculate than the ends of the runs, don't know if that applies this time though.