For those who didn't recognize the name KIC8462852 in their work unit names, this data comes from GBT observations of Tabby's Star (aka Boyajian's Star, aka WTF-0001, aka the Weirdest star in the galaxy). This is not yet the full data set, which lives at Penn State, it's some test on-target/off-target observations that we're checking out.

You might also notice another change. We've doubled the size of our work units which will reduce our quantization noise by 34%, and, depending on the strength of other noise sources, could give us as much as double that as a sensitivity increase.

---

@SETIEric@qoto.org (Mastodon)

Thanks for information, Eric

---

http://boincstats.com/signature/0/user/2449327/project/sig.png
http://boincstats.com/signature/0/team/88019747/project/sig.png

Thanks Dr. Korpela,

We saw those earlier in the week and were anticipating crunching them. Roughly 30% longer to crunch than a BLC03. We are all interested in seeing how they pan out.

---

Thank Dr. Korpela,

Best Wishes,
Byron.

Got 4 of them, 3 of those ran for 13,14 and 15 seconds before finishing. Triplet count: 30.

Let's hope that it's not really 75% of them that do that.

---

Is the double size the new standard then?

@Eric, did you mean to send this?

07/09/2017 20:12:55 | SETI@home | [http] [ID#21] Sent header to server: GET /sah/download_fanout/14e/blc04_2bit_blc04_guppi_57898_17342_DIAG_KIC8462852_0019.14226.818.17.26.149.vlar HTTP/1.1
...
07/09/2017 20:12:55 | SETI@home | [http] [ID#21] Sent header to server: This is not yet the full data set, which lives at Penn State, it's some test on-target/off-target observations that we're checking out.<br />

It does this on every such task it downloads, when <http_debug> is enabled.

---

@Eric, did you mean to send this?

I'm pretty sure it's a bug in the client. I've seen it with other projects too. Haven't debugged it more than that yet, doesn't seem to break anything.

It's as if it's taking the line from the Notices, but why a line in the middle, not the line at the end?

---

Thanks for information.

---

@Eric, did you mean to send this?

I'm pretty sure it's a bug in the client. I've seen it with other projects too. Haven't debugged it more than that yet, doesn't seem to break anything.

There's nothing odd in the sched_reply from the server setting up the download:

<file_info>
    <name>blc04_2bit_blc04_guppi_57898_16862_DIAG_KIC8462852_OFF_0018.30571.0.18.27.224.vlar</name>
    <url>http://boinc2.ssl.berkeley.edu/sah/download_fanout/3c/blc04_2bit_blc04_guppi_57898_16862_DIAG_KIC8462852_OFF_0018.30571.0.18.27.224.vlar</url>
    <md5_cksum>94924adc773784ee137f2d765c3d14c6</md5_cksum>
    <nbytes>720538</nbytes>
</file_info>
<workunit>
    <rsc_fpops_est>42002102959449.984375</rsc_fpops_est>
    <rsc_fpops_bound>840042059188999.750000</rsc_fpops_bound>
    <rsc_memory_bound>33554432.000000</rsc_memory_bound>
    <rsc_disk_bound>33554432.000000</rsc_disk_bound>
    <name>blc04_2bit_blc04_guppi_57898_16862_DIAG_KIC8462852_OFF_0018.30571.0.18.27.224.vlar</name>
    <app_name>setiathome_v8</app_name>
<file_ref>
    <file_name>blc04_2bit_blc04_guppi_57898_16862_DIAG_KIC8462852_OFF_0018.30571.0.18.27.224.vlar</file_name>
    <open_name>work_unit.sah</open_name>
</file_ref>
</workunit>

Just the very long name. Buffer overflow?

That error is pretty weird. Why would it send part of a notice when getting a work_unit. I'll check the server logs to see if these "headers" are actually being received. Are downloads completing properly?

---

@SETIEric@qoto.org (Mastodon)

Is the double size the new standard then?

Double size is the new standard for both Arecibo and GBT (and eventually Parkes). Unless UC complains about the extra traffic. I don't think they'll even notice it.

---

@SETIEric@qoto.org (Mastodon)

Got 4 of them, 3 of those ran for 13,14 and 15 seconds before finishing. Triplet count: 30.

Let's hope that it's not really 75% of them that do that.

It shouldn't be. The non-L-band workunits at GBT are a bit messier (astronomy pun) than the L-band, but most of them should run to completion.

---

@SETIEric@qoto.org (Mastodon)

grazie Dr. Korpela

---

Got 4 of them, 3 of those ran for 13,14 and 15 seconds before finishing. Triplet count: 30.

Let's hope that it's not really 75% of them that do that.

It shouldn't be. The non-L-band workunits at GBT are a bit messier (astronomy pun) than the L-band, but most of them should run to completion.

There seems to be a small spattering of these noisy work units that complete within a few second and longer work units that seem to go the normal amount of time. I'm trying to see how many so far but hard to go thru all validated work

Edit..

Looks like March 04, 2008 data set also producing noisy short work units. If you just eyeball the validated results and see short run time without looking at the actual work unit name, it would be easy to confuse the 2 different data sets since run times are close.

---

That error is pretty weird. Why would it send part of a notice when getting a work_unit. I'll check the server logs to see if these "headers" are actually being received. Are downloads completing properly?

Mine did, but I'm not using v7.8.2 on this laptop yet. I'll have a proper poke around with http_debug when I get home from Paris tonight.

Is the double size the new standard then?

Double size is the new standard for both Arecibo and GBT (and eventually Parkes). Unless UC complains about the extra traffic. I don't think they'll even notice it.

You naughty boy Eric ;-)

---

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

That error is pretty weird. Why would it send part of a notice when getting a work_unit. I'll check the server logs to see if these "headers" are actually being received. Are downloads completing properly?

They downloaded OK, and as far as I can tell it ran OK

Spike count:    0
Autocorr count: 0
Pulse count:    9
Triplet count:  2
Gaussian count: 0

I must admit, the message addition only seems to have been for a couple of tasks. Since I restarted BOINC I haven't seen it again. But then again, I haven't had any more KIC8462852's either. :(

I reported the same thing to BOINC Alpha, just in case it's the client doing this. I'd love to know why it needs to send all that text back to the servers as well.

---

Good work Eric

---