1 resend for the 25th UTC.

Cheers.

Another Arecibo file has turned up, AP work being split now.

---

Grant
Darwin NT

35 arrived here for the 27th UTC.

Cheers.

37 here for the 27th.

---

SETI@home classic workunits 4,019
SETI@home classic CPU time 34,348 hours

45 were picked up here for the 28th UTC.

Cheers.

Only 25 for the 28th here.

---

SETI@home classic workunits 4,019
SETI@home classic CPU time 34,348 hours

14 for the 29th UTC.

Cheers.

I thought a few years ago, Matt had mentioned something about being able to detect this kind of thing server-side and not even waste bandwidth and time with them?

2018-05-30 00:42:07 SETI@home Started download of ap_28my18aa_B3_P1_00267_20180529_18102.wu
2018-05-30 00:43:00 SETI@home Finished download of ap_28my18aa_B3_P1_00267_20180529_18102.wu
2018-05-30 00:43:00 SETI@home Starting ap_28my18aa_B3_P1_00267_20180529_18102.wu_0
2018-05-30 00:43:00 SETI@home Starting task ap_28my18aa_B3_P1_00267_20180529_18102.wu_0 using astropulse_v7 version 700
2018-05-30 00:43:03 SETI@home Computation for task ap_28my18aa_B3_P1_00267_20180529_18102.wu_0 finished
2018-05-30 00:43:05 SETI@home Started upload of ap_28my18aa_B3_P1_00267_20180529_18102.wu_0_r216410812_0
2018-05-30 00:43:08 SETI@home Finished upload of ap_28my18aa_B3_P1_00267_20180529_18102.wu_0_r216410812_0

If my understanding is correct, one of the channels of the alpha receiver is effectively a boolean on/off for when radar is present and then that boolean stream gets overlaid on the data. Which means the splitters should, theoretically, know when a WU is going to be 100% blanked before it even gets split.

I know B3_P1 has been a problem channel for many years now, but I find 100% blanked APs on B5_P0 a lot, as well, and very seldom on others, but it does happen.

The point is though.. I thought there was some kind of server-side ability to detect 100% blanked stuff before it even goes into the field. It's possible maybe Matt was just mentioning a wishlist kind of idea, but it seems like all the logic exists for it, it just doesn't end up being implemented.

---

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

That is not a constant as it seems to vary depending on where the dish is focused at the time.

Cheers.

Yeah, I know B3_P1 works sometimes.

But my understanding of the logic behind the scenes is something like..

-One of the channels for the Alpha receiver records when radar is happening
-That radar on/off data is then overlaid on the data channels
-The remove_RFI process (which isn't listed on SSP anymore, but it used to be) then fills those areas of the "tapes" with pseudo noise (as going with digital zeros suddenly would give false positives at the boundary edges of the silence during analysis)

But I know at least with AP, the blanked areas are known by the science app on our end and get skipped altogether.

So if the science app knows where the blanked areas are before crunching even starts, then that would mean that the *server* knows how much is blanked before the WU even gets sent out to anyone.

If my understanding is correct, then the feeder or scheduler would be able to pretty easily go ahead and mark those WUs as 100% blanked in the DB without clients even needing to attempt it, thus saving bandwidth and simplifying the process without any notable increase in processing server-side. WUs can be marked as 100% blanked by the splitters themselves and be logged in the DB and moved straight to the file_deleter and db_purge queues.

As a visual example, this is sort of what I mean by knowing what portions are 100% blanked in advance:

radar: -----      --- - -  --------    ------ -- - - -   ---  ---- ---   --  -
data : 001010010010101001010101101010100101010101101111100010100010010010101001
WUs  :     |     |    |    |    |    |    |    |    |    |    |    |    |    |
combo: ----+     |--- + -  +----+--  | ---+-- -+ - -|-   +--  +--- +--  |--  +
100% : =====               ======

So you can see with the 100% line there, there are two WUs that are 100% blanked, and the server-side *knows* that as soon as the splitter runs through that tape and makes WUs out of it. So the data and logic already exists to just mark them in the db and discard before it even goes to the feeder.

Unless I'm just completely misunderstanding this, which is possible.

---

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

24 randomly made their way here on the 30th UTC.

Cheers.

Well 1 resend wound up here on both the 31st and 1st while 8 turned up here for the 3rd UTC.

Cheers.

8 here as well.,

---

SETI@home classic workunits 4,019
SETI@home classic CPU time 34,348 hours

Just 6 got here for the 4th UTC.

Cheers.

Managed 15 here. Just shows the luck of the draw.

---

SETI@home classic workunits 4,019
SETI@home classic CPU time 34,348 hours

16 for the 5th UTC.

Cheers.

11 for me.

---

SETI@home classic workunits 4,019
SETI@home classic CPU time 34,348 hours

13 here for the 6th UTC.

Cheers.

Only 8 here, but I had an interesting thing happen...…..I had a fuse blow and my main computer continued on battery UPS. I turned it off. But it seems that when I recently moved computers around I left the cable from the UPS plugged into a different computer and I did not notice that it turned off that computer. More lost computer time. I really need to get that power straightened out and that computer off an extension cord (I was not thinking when I turned on the air compressor. but I was able to change the blades on the mower)

---

SETI@home classic workunits 4,019
SETI@home classic CPU time 34,348 hours

3 resends for the 7th UTC.

My rigs are all powered from separate power points so I have no such problems like that here Bill and thankfully they all powered down well when the power here went out for 3hrs in the early hours this morning.

I had to reboot the modem though as it was trying to connect before the local exchange came back online so that was a walk down to the house before the sun came up to get that sorted.

Cheers.