What the meow???

Data Distribution State SETI@home v7 # Astropulse # SETI@home v8 # As of*
Results ready to send 0 972 37,039 0m
Current result creation rate ** 0/sec 12.7438/sec 339.5035/sec 5m
Results out in the field 0 12,939 1,984,825 0m

False data? Or what?

Meow?

not false. I think they are forcing early resends. I just got a bunch... #3 without a timeout or error.

Must be so.
I see we are back over 2 million out in the field again.
None came my way, unfortunately.

Meow.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

Results out in the field 1,998,795 As of 16 Apr 2020, 10:40:04 UTC

Results out in the field 1,900,221 As of 17 Apr 2020, 14:00:04 UTC
Results out in the field 1,899,542 As of 17 Apr 2020, 14:10:03 UTC

So it's taken around 27 hours to return 100,000

Results out in the field 2,019,818 As of 17 Apr 2020, 17:40:03 UTC

So we are back above 2mil again !

I think AstroPulse in the field has gone up too

Does someone have a link to the server graphs please ?...

[Edit] Found them

https://munin.kiska.pw/munin/setiathome-day.htmlhttps://munin.kiska.pw/munin/setiathome-day.html

What the meow???

Data Distribution State SETI@home v7 # Astropulse # SETI@home v8 # As of*
Results ready to send 0 972 37,039 0m
Current result creation rate ** 0/sec 12.7438/sec 339.5035/sec 5m
Results out in the field 0 12,939 1,984,825 0m

False data? Or what?

Meow?

not false. I think they are forcing early resends. I just got a bunch... #3 without a timeout or error.

I just got 100 forced re-sends without timeout errors...

---

We were getting extra re-sends around 24 hours before the timeouts, it looks like Eric, or whoever, has increased that to 72 Hours

https://munin.kiska.pw/munin/static/dynazoom.html?cgiurl_graph=/munin-cgi/munin-cgi-graph&plugin_name=Munin-Node/Munin-Node/results_setiathomev8_in_progress_validation&size_x=800&size_y=400&start_epoch=1587038878&stop_epoch=1587146878

Forced resends?? They trying to speed up the returns so they can turn off the servers quicker??

---

Forced resends?? They trying to speed up the returns so they can turn off the servers quicker??

They're trying to speed up the returns so that they can get the science completed quicker.

But, if they do not direct those resends to trusted computers, known for quick returns, they are not gaining anything at all, by seeding random crunchers with thousands of resends.
They must direct them to specifically trusted computers with a very low Average turnaround time.

Or, am I missing something here, while being dizzy with cabin fever?

I made the same proposal few days before and i was called elitist, etc. But is the logical way.

---

If they are sending resends early thus shortening the deadline, they don't need to send to specific machines. The resends of the resends will be sent quicker. Thus they avoid the whole who to send it to can-of-worms (you know someone would complain).

They're trying to speed up the returns so that they can get the science completed quicker.

Go give Dr. A posts on how he plans on analyzing the data a read. I have. They aren't going to have this done anytime in any kind of near future.

If they are sending resends early thus shortening the deadline, they don't need to send to specific machines. The resends of the resends will be sent quicker. Thus they avoid the whole who to send it to can-of-worms (you know someone would complain).

Unless one of them goes to a zombie machine that happens to make contact at that time.
Makes more sense to reduce the Deadline for resends, and resend ones after they've been out for a month, not just a few days before they are due to being resent after already being out there for 3 months.
But i guess every little bit does help.

---

Grant
Darwin NT

They're trying to speed up the returns so that they can get the science completed quicker.

Go give Dr. A posts on how he plans on analyzing the data a read. I have. They aren't going to have this done anytime in any kind of near future.

From what I have seen of DA's ability to write a simple web page https://scienceunited.org/trac/wiki/ProjectPeople, I'm not very confident of that !

Forced resends?? They trying to speed up the returns so they can turn off the servers quicker??

They're trying to speed up the returns so that they can get the science completed quicker.

Not convinced this will work.Looking at my tasks, if the forced resend hasn't been returned before the original deadline, the normal sequence still kicks in and sends another task out, a _3, to another host.

So now the WU is waiting for two tasks before it can be assimilated and purged.

A failure to think the problem though, again.

So now the WU is waiting for two tasks before it can be assimilated and purged.

The Minimum Quorum is still 2, But the Replication is now > Quorum

So only 1 more task is needed to reach Quorum, unless a tie-breaker is needed, which could be any of the results "in the field", including the Expired one.

This is pure speculation on my part. They did a batch of resends 24 hours before the deadline... then today they did a batch of resends 3 days before the deadline... maybe next they will do a batch of resends 5 days before the deadline etc...I'm guessing they will just do this in waves as the bunch they sent out today will ripple. There will be resends triggered from errors or non matching from this action they took today, when that dies down they can do another batch.

If they are sending resends early thus shortening the deadline, they don't need to send to specific machines. The resends of the resends will be sent quicker. Thus they avoid the whole who to send it to can-of-worms (you know someone would complain).

Unless one of them goes to a zombie machine that happens to make contact at that time.
Makes more sense to reduce the Deadline for resends, and resend ones after they've been out for a month, not just a few days before they are due to being resent after already being out there for 3 months.
But i guess every little bit does help.

Maybe Eric is taking things in "baby steps", I assume that it's probably Eric running the scripts.
He may want to see the results of increasing from 24h to 72h, before going to a larger value eg 168h or greater.

My Pendings (& to a lesser extent Inconclusives) are slowly falling. But my Valids keep increasing. They're Valid, but still waiting for another Result (or two) to be returned. Late May, early June for the vast majority before they are resent. A couple for mid June.

---

Grant
Darwin NT

My Pendings (& to a lesser extent Inconclusives) are slowly falling. But my Valids keep increasing. They're Valid, but still waiting for another Result (or two) to be returned. Late May, early June for the vast majority before they are resent. A couple for mid June.

I just looked at your computers, it looks like we have already gone up to 7 days before deadline.

https://setiathome.berkeley.edu/workunit.php?wuid=3911459894

It would be smarter to send those n days after the last scheduler contact of the pending cruncher than n days before the deadline. If a host hasn't contacted the servers after the faucets were closed, the task is unlikely to be returned and should be resent now even if its deadline is in June.