Well, I just had to try it with my New Linux App. The App seems to be working fine, so;
blc3_2bit_guppi_57451_19958_HIP62472_0005.15527.416.17.26.69.vlar_0
WU true angle range is : 0.010613
Run time: 25 min 7 sec
CPU time: 25 min 3 sec
26 minutes is about normal for a High Angle Range VLAR on the GTX 750Ti running the "Special" App.
I didn't notice any Screen Lag either.
I suppose everything is normal...

Well, I just had to try it with my New Linux App. The App seems to be working fine, so;
blc3_2bit_guppi_57451_19958_HIP62472_0005.15527.416.17.26.69.vlar_0
WU true angle range is : 0.010613
Run time: 25 min 7 sec
CPU time: 25 min 3 sec
26 minutes is about normal for a High Angle Range VLAR on the GTX 750Ti running the "Special" App.
I didn't notice any Screen Lag either.
I suppose everything is normal...

Back when I had my GTX 480 (a couple of years back), Joe Segur had crafted some simulated tasks based on what parameters he thought GBT tasks might have. With apps at the time, there were some limitations with dataset sizes in the way some Cuda kernels were implemented. Some minor fixes to deal with the bigger sizes (Much older X-branch) were applied and seem to cope fine, since then only the v8 specific precision and telescope changes should matter much.

Petri's code most likely wont affect/break ány of that, and probably his and even baseline code should operate more efficiently with what we'd considered VLARs before, because of the larger datasets (they can fill the larger GPUs better).

Along those lines I don't really know if what really constitutes a Guppi VLAR has been isolated down to an angle range threshold that would cause a problem for some systems or not. Probably, I'm guessing, it's kept to the traditional value/limits on main so as to keep the status-quo, while we figure it all out :)

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

The only change to the build was this App uses maxrregcount=64 whereas most of the others used maxrregcount=32. It seems the Host has a couple more tasks now.

Hmmm, this one had a little Lower Angle Range;
http://setiathome.berkeley.edu/result.php?resultid=4854499797
WU true angle range is : 0.008970
Run time: 25 min 20 sec
CPU time: 25 min 16 sec

Seems to be chewing through them like a Hound-dog on a Ham-bone.
Too bad there isn't a Preference to receive only GreenBank tasks.
Much more interesting than all these reruns.

Three tasks in and an Overflow, http://setiathome.berkeley.edu/result.php?resultid=4854542714

It would be nice if a few running GBT on stock would post some screen saver pics here.

I don't see any graphic component to the work units.

The show graphic is grayed out for these CPU work units.

I've gotten a few GBTs on my two crunchers. So far, they are all explicitly labeled VLARs.

Interestingly, the ones on the I7-4820K system have estimates of just about 2 hours, but the ones on the i7-4790K machine have estimates of 1 hour.

Checking the app details for both machines, that is approx. correct, as one has a rate of 25.xx, the other 52.xx (for V8 on CPU). So the servers seem to have gotten that correct...

---

...Along those lines I don't really know if what really constitutes a Guppi VLAR has been isolated down to an angle range threshold that would cause a problem for some systems or not. Probably, I'm guessing, it's kept to the traditional value/limits on main so as to keep the status-quo, while we figure it all out :)

Just ran a couple on the Mac which is also using an App with the maxrregcount=64. The GTX 950 is a little faster but Not much;
GTX 950 - http://setiathome.berkeley.edu/result.php?resultid=4854452589
GTX 750Ti - http://setiathome.berkeley.edu/result.php?resultid=4854579193
The 950 runs the Main Screen, didn't notice any lag.

I also ran one on the 225 Watt 6970 using the same App I've been using since early January, it was about the same, http://setiathome.berkeley.edu/result.php?resultid=4854571816
Looks like I'm fresh outta guppis...

Got one.

Syphilis now has 17 blc3 files/tasks. The other 3 crunchers do not have any at this stage, though they are picking up AP tasks.

---

Picked up a few on each cruncher, so I "promoted" them to see what it all looks like. Basically the same as any other VLAR so far, as one would expect. Just a shame they can't be tracked separately (though I understand why) as APs can. So it goes...

---

Now we just need an update to the user task list page that shows the GBT work.
Meow?

---

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

I have 2 blc3 files on Syphilis. Estimated time of 1hr 12min. It'll take a little while to get to them though...

What is the format of the filename?
Could you please paste it into a reply?

Thanks!

EDIT: Whoops, never mind. One was already posted. Thanks, Cliff!

Eric answered that in the news thread:

Could someone please explain the information in the new file names on the SSP?

blc3_2bit_guppi_57451_19304_HIP62472_0003

blc3:     Breakthrough Listen
2bit:     bits per real sample (4 bit per complex sample)
guppi:    File format (Greenbank Ultimate Pulsar Processing Instrument)
57451:    Modified Julian Date
19304:    Seconds past midnight
HIP62472: Object Name
0003:     Observation sequence number

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

I have 2 blc3 files on Syphilis. Estimated time of 1hr 12min. It'll take a little while to get to them though...

What is the format of the filename?
Could you please paste it into a reply?

Thanks!

EDIT: Whoops, never mind. One was already posted. Thanks, Cliff!

Eric answered that in the news thread:

Could someone please explain the information in the new file names on the SSP?

blc3_2bit_guppi_57451_19304_HIP62472_0003

blc3:     Breakthrough Listen
2bit:     bits per real sample (4 bit per complex sample)
guppi:    File format (Greenbank Ultimate Pulsar Processing Instrument)
57451:    Modified Julian Date
19304:    Seconds past midnight
HIP62472: Object Name
0003:     Observation sequence number

Also if you wish to work out the Modified Julian date go here

http://www.csgnetwork.com/julianmodifdateconv.html

As you can see the above translates to 03-04-2016 (US) or 04-03-2016 (UK)

Time is 5.4 hours after midnight.(Around 5:24 am)

---

Now we just need an update to the user task list page that shows the GBT work.
Meow?

Agreed

---

Along those lines I don't really know if what really constitutes a Guppi VLAR has been isolated down to an angle range threshold that would cause a problem for some systems or not. Probably, I'm guessing, it's kept to the traditional value/limits on main so as to keep the status-quo, while we figure it all out :)

Traditionally, VLAR has been hard-coded as "true_angle_range < 0.12". I think that was arrived at by observation of client behaviour in the early days of CUDA - that was where the stuttering and long-running kicked in, and was the threshhold used for VLARkill - but as usual I think Joe had a scientific explanation involving a transition point in the processing paths taken at different ARs.

The code now expresses the limit as a function of beam width for both Arecibo and GBT data. The original version inadvertently halved the Arecibo limit to 0.06, and that was in use as recently as last week - I noticed a long-running task and checked it.

But on the assumption that the GBT splitters have been re-compiled in preparation for this launch (not necessarily a valid assumption), the beam width of 0.135330 in a task I've been allocated would imply a VLAR threshhold of nearly 0.325, which sounds high to me. And presumably all the other common designations we use - like "mid-AR" or VHAR "shorties" - will turn up in different places: if we ever get enough mixed data to identify them, of course.

So, minor glitch on SSP regarding GB tapes:

SSP shows 5 splitters active, but SSP only shows one tape getting split, and only 1 channel in progress on tape(dark green block) Should that not be 5 blocks, for consistency with Aricebo stuff?

Also: (not GB related)

SSP still shows "** these v7/v8 values are combined/the same" but they no longer are. Again, purely cosmetic ...

Sorry if this isn't the right place for this but, if not, perhaps someone could point me in the right direction? There doesn't seem to be a single place for these types of bug reports.

[edit] Also seems that some formatting issue have surfaced on Aricebo splitter status. [/edit]

Regards, Jim ...

---

Now we just need an update to the user task list page that shows the GBT work.
Meow?

Agreed

Would be nice, but if I get it right, the GB stuff is just more V8, and there's no attempt other than filename to differentiate once it's split?

Meows, Jim ...

---

Now we just need an update to the user task list page that shows the GBT work.
Meow?

Agreed

Would be nice, but if I get it right, the GB stuff is just more V8, and there's no attempt other than filename to differentiate once it's split?

Meows, Jim ...

Might be right about that.
Just would be nice to keep tabs on it separately.
Maybe not possible.

Meows.

---

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

1 channel in progress on tape(dark green block)

Block/channel equivalence doesn't seem to apply to GBT - I haven't counted, but there aren't 102 light green blocks in that row.

Now we just need an update to the user task list page that shows the GBT work.
Meow?

Agreed

Would be nice, but if I get it right, the GB stuff is just more V8, and there's no attempt other than filename to differentiate once it's split?

Meows, Jim ...

Might be right about that.
Just would be nice to keep tabs on it separately.
Maybe not possible.

Meows.

I'm with you. But I think I read somewhere that's a BOINC limitation, not a SETI issue, and thus harder to accomplish ...
Interesting question is, will there be GPU GB work, as most GB stuff seems to be VLAR? Since VLAR work is currently turned off for GPUs on production (I have seen a good bit of GPU VLAR on SETI Beta) will that follow suit on GB? If so, will there be enough capacity to crunch the new volume of CPU-only work?
Seems to me the issue has been getting enough GPU work, and GB doesn't seem to address that.
But then, the GPU issue had been more MB vs. AP, so perhaps that's not a fair question.
Another interesting question: Will there be such a thing as AP off GB? My impression is "No", but I guess I don't understand why, or have forgotten?
Jim ...

---

I dunno.............
The kitties will keep on trudging forward and crunching whatever kibbles the servers sees fit to send them.
I have 9 rigs running 24/7, all on Lunatics .44, so they should be ready and able to crunch whatever comes their way.

And if that changes, I know the Lunatics crew, bless their devoted hearts, shall be on top of it as soon as possible.

Meow for the Lunatics!

---

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