I noticed in the status that splitter_throttle_sah is no longer running, but splitter throttling is still happening. I wonder what changed??

Any guesses on when the new machine will be moved from Beta to primary??

. . First it has to go online in Beta, then it has to pass a period of sufficient testing. I would not expect to see it in main for several weeks at least ...

Stephen

Nothing has been tested on Beta for several days, it is not sending out tasks. I posted this https://setiathome.berkeley.edu/forum_thread.php?id=84416&postid=2009665#2009665 nothing changed since then and I posted that because the outrage, the previous day, hadn't fixed it.

. . Eric warned there would be a period of downtime in Beta while they got things sorted with the new server.

Stephen

. .

[quote]Beta is working fine I am processing tasks and have been since yesterday.

. . Hmmm, I tried to get going in Beta after the WOW event finished but got a message saying it was not working and would not accept the new host at that time, I will give it another try ...

Stephen

? ?

I dropped a new host onto Beta last night with no problems and got a mixture of both AP & MB tasks.

---

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

I dropped a new host onto Beta last night with no problems and got a mixture of both AP & MB tasks.

. . Well that machine is now working on Beta, but it is a Linux host and all I am getting are V8.04 CPU tasks and Cuda60 for the GPU. Talk about S.L.O.O.O.O.O.W.W.W.W.W ...

. . What happened to nice v8.08(alt) and SoG? :(

Stephen

:(

Beta is NOT about speed, it is all about testing something, and we are not always privy to what is being tested.....
If they are baselining then they will want to use reference applications which have known processing and error rates. I see I've now got some work for the 8.04 & 8.05 apps, along with a few APs for the 7.00 & 7.03(sse2) apps, so it looks as if they are doing a baseline before doing something more "novel".

---

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

Anyone near the Green Bank Observatory?? They are having an open house on Sept 8.
https://greenbankobservatory.org/event-details/?ee=1811

. . Hi Unixchick

. . That is a nice piece of info, thanks! But being on the other side of the planet I don't think I will make it :(

Stephen

:)

Anyone near the Green Bank Observatory?? They are having an open house on Sept 8.
https://greenbankobservatory.org/event-details/?ee=1811

Great place to visit. I took the SETI tour a few weeks ago. Well worth the price!

---

Interesting I just picked up 100 Multibeam tasks but there is no work being split this would have been about an hour ago. It goes to show how long the queue can hold work for. I just checked and one of my old work was created at 3 Sep 2019, 22:08:57 UTC Name 30dc12aa Seems fair to say work was created about eight hours ago my time zone is currently UTC +12. Another thing to note some of the work is quite short running on 2070. Runtimes are between 3:25 and for which really short work 1:54

---

Interesting I just picked up 100 Multibeam tasks but there is no work being split this would have been about an hour ago. It goes to show how long the queue can hold work for. I just checked and one of my old work was created at 3 Sep 2019, 22:08:57 UTC Name 30dc12aa Seems fair to say work was created about eight hours ago my time zone is currently UTC +12. Another thing to note some of the work is quite short running on 2070. Runtimes are between 3:25 and for which really short work 1:54

As has been stated before, Arecibo MB work takes 6-8hrs to make it through the cue after splitting because of all the GBT work in the cue already while AP work gets its own channel from the splitters to the feeder so they come through a lot quicker.

Cheers.

It looks like they have been reallocating processes in the status page. Bruno doesn't have as many duties as he used to and Synergy is doing a lot more. I'm finding that my uploads are getting "ack"ed alot quicker now.

It looks like they have been reallocating processes in the status page. Bruno doesn't have as many duties as he used to and Synergy is doing a lot more. I'm finding that my uploads are getting "ack"ed alot quicker now.

Maybe preparing for the new upload server to take it's place.

---

Grant
Darwin NT

AP Sept 5, 2019 being split now.

Periodically, when we've got nothing better to do, we muse on what causes the different run-times of different BLC batches. Yesterday, during maintenance (when finished tasks remain on screen for longer), I noticed a clear correlation: blc36 day 58642 and blc36 day 58643 tasks were equally common in my queues, and day 58642 tasks ran in half the time of day 58643 tasks. Consistently. (on NVidia GPUs, I hasten to add: I don't think anything here applies to other apps)

So I grabbed a couple of data files, and diff'd them. They were task 8036728928 (blc36_2bit_guppi_58642_05316_HIP55285_0021.29677.0.22.45.94.vlar_0, fast) and task 8036540320 (blc36_2bit_guppi_58643_48014_HIP5944_0015.8690.0.24.47.234.vlar_0, slow). They ran in 13 min 15 sec and 22 min 12 sec, respectively, with the same SoG app on the same GTX 750 Ti GPU.

These seem to be the main differences in the workunit header.

			58642					58643
<true_angle_range>	0.048421307				0.02054784

<receiver_cfg>		
<s4_id>			22					24
<name>			Green Bank Telescope, Rcvr4_6, Pol 1	Green Bank Telescope, Rcvr2_3, Pol 1
<beam_width>		0.022842759				0.105538443
<center_freq>		7262.695424				1989.843712

<analysis_cfg>
<pot_min_slew>		0.0018					0.0041
<pot_max_slew>		0.0089					0.020300001

<subband_desc>		
<number>		94					234
<center>		7263771057				1989591980
<base>			7263771057				1989591980

I think the one which intrigued me most was <beam_width>, because I thought that was a geometrical constraint of the telescope itself?

I think we last discussed this just before my recent trip to America, so when I


met Eric and Jeff at the Breakthrough Listen office on Berkeley campus, I asked them.

It didn't seem to be a question that either of them had given much attention to, but after thinking about it a bit, the general consensus was it was likely because we were looking at different parts of the frequency band (much wider than the Arecibo bandwidth), with higher frequencies potentially carrying more data and hence requiring more analysis. So that would be the <center_freq> in the table above, but the converse is true: it's the lower frequency tasks which took much longer. So I'm none the wiser.

I have the complete workunit headers side-by-side in a spreadsheet, if anyone would like to look at them in more detail?

met Eric and Jeff at the Breakthrough Listen office on Berkeley campus.

Argh - brainfade, and too late to edit. I did meet Jeff, but the picture shows Matt (L) and Eric (R). It was those two that I asked about the processing times, though.

Periodically, when we've got nothing better to do, we muse on what causes the different run-times of different BLC batches. (on NVidia GPUs, I hasten to add: I don't think anything here applies to other apps)

So I grabbed a couple of data files, and diff'd them. They were task 8036728928 (blc36_2bit_guppi_58642_05316_HIP55285_0021.29677.0.22.45.94.vlar_0, fast) and task 8036540320 (blc36_2bit_guppi_58643_48014_HIP5944_0015.8690.0.24.47.234.vlar_0, slow). They ran in 13 min 15 sec and 22 min 12 sec, respectively, with the same SoG app on the same GTX 750 Ti GPU.

It didn't seem to be a question that either of them had given much attention to, but after thinking about it a bit, the general consensus was it was likely because we were looking at different parts of the frequency band (much wider than the Arecibo bandwidth), with higher frequencies potentially carrying more data and hence requiring more analysis

. . This was my original supposition, largely because I had thought that the higher channel numbers were recording higher frequency bands. That was knocked into a hat when I read that the reverse is actually the case. But then, I also thought that the channel recorders were tied to a receiver channel, but those headers seem to say 'no' to that as well. One thing though, is that the slower running task has a much greater beam width.

Stephen

< scratching head >

They've just started splitting a batch of BLC35 tapes, with the same mix of 58642 and 58643 recording 'dates' (although I think we're all getting a little suspicious of that value). It will be interesting to see if they show the same distribution of runtimes.

The first few BLC35-58642 tasks have reached the head of my cache, and it's clear they are following the faster processing route. But the splitters haven't even started on BLC35-58643 yet, so it will be much later this evening or tomorrow morning before I can comment on runtime or run the diff.

. . Well 58643 tasks have started to trickle through now and so far the few I have seen have followed that same relationship. 58642 tasks take 1.85 mins and 58643 tasks take 2.85 mins.

Stephen

. .