. . Did that one happen to have an _2 or higher at the end?
. . That was the tape set with all the noise bombs ...
Stephen? ?

Yes you are right it was a _2, as far as I can see it wasn't a noise bomb ran for just over 8.5 minutes

. . They were not ALL noise bombs :) just most of them ... But many of us expect they will return to that tape set in small doses to get them processed. In the meantime some will crop as as resends as in this case.

Stephen

:)

Yesterday's (07jl19aa) Aricebo data is now splitting.

. . Did that one happen to have an _2 or higher at the end?
. . That was the tape set with all the noise bombs ...
Stephen? ?

Yes you are right it was a _2, as far as I can see it wasn't a noise bomb ran for just over 8.5 minutes

. . They were not ALL noise bombs :) just most of them ... But many of us expect they will return to that tape set in small doses to get them processed. In the meantime some will crop as as resends as in this case.

Stephen

:)

Thanks for the information. This is one of the reasons why I always try to return work with _2 on them 1st as you say these are resends.

---

yesterday's (08jl19aa) Aricebo file is now splitting.

08jl19ab is being split, and I just checked the Aricebo schedule (which changes frequently) and it says we should get daily data (sometimes 2) until the 15th.
Hopefully we can all get enough of the WUs we like for whatever reason.

blc52_2bit_guppi_58543_61810_3C147 (7-25) and blc62_2bit_guppi_58543_61810_3C147 (7-25) were added to the to be split list.

They will probably throw another set of files on before the weekend.

I think we should vote those BLC52s off the island....they truly are the pits.
If you think they are bad on Linux, you should look at how the Windoze people are dealing with them.

I think we should vote those BLC52s off the island....they truly are the pits.
If you think they are bad on Linux, you should look at how the Windoze people are dealing with them.

Can you give us an example of what you mean? I and gathering that you mean they are taking a long time to run

---

I think we should vote those BLC52s off the island....they truly are the pits.
If you think they are bad on Linux, you should look at how the Windoze people are dealing with them.

Can you give us an example of what you mean? I and gathering that you mean they are taking a long time to run

I think he means they take longer to crunch than what we are used to. Like it took 14 minutes to crunch this task on a GTX 1080 Ti with the SoG app on Windows.
https://setiathome.berkeley.edu/result.php?resultid=7849023865
Pays well at least - 185 credits

---

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

A proud member of the OFA (Old Farts Association)

I think we should vote those BLC52s off the island....they truly are the pits.
If you think they are bad on Linux, you should look at how the Windoze people are dealing with them.

. . But as with the other 'new' strains, the more we do of them the better they crunch. At first lots of really slow, long run times, but now they are down around the other run times. At least on my rigs.

Stephen

? ?

. . Ruh Roh!

. . Since M$ forced another of their (f)updates on my two Windows machines yesterday costing me most of the day in productivity, I am now getting 'computation errors' on a major percentage of Arecibo VLAR tasks running on the CPU on my Ryzen rig. After taking 1.4 hours they fail :(. I may have to abort Arecibo VLARs on the CPU or reschedule them to the GPU and make it take the hit.

Stephen

:(

Always check the error codes. Your 0xc0000374 is 'STATUS_HEAP_CORRUPTION' - unusual. I'd recommend (yet another) reboot.

(that one came from 09jl19aa.31281.63426.6.33.186.vlar_0)

I think we should vote those BLC52s off the island....they truly are the pits.
If you think they are bad on Linux, you should look at how the Windoze people are dealing with them.

. . But as with the other 'new' strains, the more we do of them the better they crunch. At first lots of really slow, long run times, but now they are down around the other run times. At least on my rigs.

Stephen

? ?

We may be running state of the art science applications, but none of them have any AI capabilities. They can't "get better" the more task types they crunch. I maintain the difference is the angle range of the very first species of a new task that is released is higher than the later ones split from the file. The reason is explained in my earlier post.
https://setiathome.berkeley.edu/forum_thread.php?id=84346&postid=2001238
and has to do with the first recorded data from the target has the scope still moving until it settles down on the final RA-DEC of the target and the scope begins sidereal tracking.

---

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

A proud member of the OFA (Old Farts Association)

Always check the error codes. Your 0xc0000374 is 'STATUS_HEAP_CORRUPTION' - unusual. I'd recommend (yet another) reboot.

(that one came from 09jl19aa.31281.63426.6.33.186.vlar_0)

. . OK, I will do that now, with windows it is always an option :)

{edit} before the restart I had another error but this time on a GBT task. I will monitor closely to see if there is any recurrence now that I have done the restart.

Stephen

:)

. . But as with the other 'new' strains, the more we do of them the better they crunch. At first lots of really slow, long run times, but now they are down around the other run times. At least on my rigs.
Stephen

We may be running state of the art science applications, but none of them have any AI capabilities. They can't "get better" the more task types they crunch. I maintain the difference is the angle range of the very first species of a new task that is released is higher than the later ones split from the file. The reason is explained in my earlier post.
https://setiathome.berkeley.edu/forum_thread.php?id=84346&postid=2001238
and has to do with the first recorded data from the target has the scope still moving until it settles down on the final RA-DEC of the target and the scope begins sidereal tracking.

. . Yep I read that message, except that when I checked the long running WUs on my rigs the ARs were very similar to the units that ran at normal times. In fact they were lower than many, the snail varieties were around AR 0.0055 while some that were running at typical times were AR 0.0097. Your theory would make sense to me if the run time variance was around 30 to 100 % increase but these silly b's take 300 to 400 % longer.

. . But I guess it would require the ability to scrutinise the raw data to be sure of any differences that would explain the run time variance.

Stephen

< shrug >

I guess my examples are different from yours. All have matched the pattern I described before.

AR = WU true angle range is : 0.010496
https://setiathome.berkeley.edu/result.php?resultid=7849028351

Credit 61.18

WU true angle range is : 0.047686
https://setiathome.berkeley.edu/result.php?resultid=7849072093

Credit 226.57

---

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

A proud member of the OFA (Old Farts Association)

Always check the error codes. Your 0xc0000374 is 'STATUS_HEAP_CORRUPTION' - unusual. I'd recommend (yet another) reboot.
(that one came from 09jl19aa.31281.63426.6.33.186.vlar_0)

. . OK, I will do that now, with windows it is always an option :)
{edit} before the restart I had another error but this time on a GBT task. I will monitor closely to see if there is any recurrence now that I have done the restart.
Stephen

. . Thanks Richard for the reminder of how Windows can bring you undone, the reboot seems to have cleared whatever was corrupted/tangled up and I have not had any compute errors since then.

Stephen

:)

They gave us 10jl19aa to split.

I'm enjoying the info on the data, and it is always nice when we can help each other and I especially like it when a simple reboot works (even if it takes a few).

edit: and 11jl19aa now

They added blc46 and blc56 that should keep us busy through the weekend.

12jl19aa was split

The system is doing the not splitting as fast, building up files to delete thing. It should resolve itself in time.