This was a major misunderstanding on my part from the launch of AP.
Don't know quite where I got it from, but I always thought that the massive crunch times of AP compared to MB were gonna save some work on the server's part...

Work, yes (fewer work units to report means fewer database accesses).

Bandwidth, no.

---

This was a major misunderstanding on my part from the launch of AP.
Don't know quite where I got it from, but I always thought that the massive crunch times of AP compared to MB were gonna save some work on the server's part...

Work, yes (fewer work units to report means fewer database accesses).

Bandwidth, no.

Well......bandwidth always seemed to be the main problem, eh?
The database either runs or crashes due to various and sometimes unexplainable phenomena.

---

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

This was a major misunderstanding on my part from the launch of AP.
Don't know quite where I got it from, but I always thought that the massive crunch times of AP compared to MB were gonna save some work on the server's part...

Work, yes (fewer work units to report means fewer database accesses).

Bandwidth, no.

Well......bandwidth always seemed to be the main problem, eh?
The database either runs or crashes due to various and sometimes unexplainable phenomena.

Bandwidth is just the most visible component.

We don't see anything like the cricket graphs for CPU use.

---

This was a major misunderstanding on my part from the launch of AP.
Don't know quite where I got it from, but I always thought that the massive crunch times of AP compared to MB were gonna save some work on the server's part...

Work, yes (fewer work units to report means fewer database accesses).

Bandwidth, no.

Well......bandwidth always seemed to be the main problem, eh?
The database either runs or crashes due to various and sometimes unexplainable phenomena.

Bandwidth is just the most visible component.

We don't see anything like the cricket graphs for CPU use.

That would be too scary to be made public........
Even the Cricket graphs have been questioned as to public viewing....

Meow.

---

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

Bandwidth is just the most visible component.

We don't see anything like the cricket graphs for CPU use.

That would be too scary to be made public........
Even the Cricket graphs have been questioned as to public viewing....

So, because you can see bandwidth, but can't see loading on the SETI servers, it's obvious that the only possible issue is bandwidth.

---

Bandwidth is just the most visible component.

We don't see anything like the cricket graphs for CPU use.

That would be too scary to be made public........
Even the Cricket graphs have been questioned as to public viewing....

So, because you can see bandwidth, but can't see loading on the SETI servers, it's obvious that the only possible issue is bandwidth.

So, do what do you believe is the issue then?
DB queries or bandwidth?

Seen or unseen? Your thoughts?

---

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

Bandwidth is just the most visible component.

We don't see anything like the cricket graphs for CPU use.

That would be too scary to be made public........
Even the Cricket graphs have been questioned as to public viewing....

So, because you can see bandwidth, but can't see loading on the SETI servers, it's obvious that the only possible issue is bandwidth.

So, do what do you believe is the issue then?
DB queries or bandwidth?

Seen or unseen? Your thoughts?

In an earlier post in this thread, you said:

This was a major misunderstanding on my part from the launch of AP.
Don't know quite where I got it from, but I always thought that the massive crunch times of AP compared to MB were gonna save some work on the server's part...

"Work" and "Bandwidth" are different things. AP takes more bandwidth, and reduces the load on the scheduler and database.

Is it a worthwhile trade? We don't have enough metrics to know.

---

OK.....
Best for the project........in your view?

I know this is a loaded question........

Best in what respect.....

But you seem to have an opinion about everything (and that's not a problem).....

AP or no AP?

Mark.

---

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

OK.....
Best for the project........in your view?

I know this is a loaded question........

Best in what respect.....

But you seem to have an opinion about everything (and that's not a problem).....

AP or no AP?

Mark.

My view on this is that on the science side, it is a great thing for the project. A second way to analyze potential ETI signals (as an extension, since I do go off topic sometimes, are we ever going to see SETI@home data from the Southern Hemisphere, specifically from Parkes Observatory in Australia? We have many more stars here, and less light and visual pollution too).

Server side, I see a negative effect from AP's. But that is just the way I perceive it. I may be biased.

Cruncher side? I stick to the rule that I crunch what I'm given. VLAR, VHAR, MB, AP, CPU only, GPU only, I'll crunch what I'm allocated. So I don't really mind.

---

- Luke.

This was a major misunderstanding on my part from the launch of AP.
Don't know quite where I got it from, but I always thought that the massive crunch times of AP compared to MB were gonna save some work on the server's part...

You probably got it from the launch of AP. Way back then, the stock application was pretty ropey, and there were no optimised applications of any sort. AP tasks "BFN" (Before Frozen Nehi) took around 40 hours: the average download/day for AP probably was less than the equivalent for MB.

Since then, the stock AP app has had a makeover (x2 speedup, from what I've read), optimised apps have been released (another x2, making x4 over the original stock), and MB has been made more sensitive (x0.5). So that's an 8-fold shift in the download balance since your original calculation: I'm not surprised it's shifted the other way.

A lot of people thought like Mark: before the data recorder broke down last May, and all the subsequent gremlins that got in the way of AP work, there were typically ~450,000 AP tasks 'in progress' at any one time. So far, we've only reached 10% of that level, and genuine results are starting to come in (average turnround 20 hours). So the AP splitters are trying to fill a very big, but very leaky, bucket: I think we will be giving that download pipe some serious exercise for a long time to come.

I got my first AP yesterday in months! WOOHOO! Happily crunching away.

---

"Life is a tragedy for those who feel, and a comedy for those who think."

"I never get into an argument that I cannot win."

OK.....
Best for the project........in your view?

I know this is a loaded question........

Best in what respect.....

But you seem to have an opinion about everything (and that's not a problem).....

AP or no AP?

Mark.

My guess is that AP has a positive benefit -- but it may or may not benefit the servers directly.

The fact that AstroPulse is a broadband search while Multibeam is a narrowband search is a clear benefit.

The fact that AstroPulse has applications outside the search for ET doesn't hurt at all, and may even bring in some funding.

Mostly, what I'm saying is that we should not focus on just one aspect of Astropulse and pronounce it "good" or "bad" based on that one measure.

---

... I think we will be giving that download pipe some serious exercise for a long time to come.

And now we've got a fair whack of VHAR in the mix: Mark's assumption has become true again.

AP + VHAR has taken the downloads to above 95 Mbit/sec as I type. Traffic jam or traffic management? Take your pick.

I think we will be giving that download pipe some serious exercise for a long time to come.

If that's the case, I want my checkbox for AP5.05 on the SETI Preferences page. :)

---

"Life is a tragedy for those who feel, and a comedy for those who think."

"I never get into an argument that I cannot win."

I think we will be giving that download pipe some serious exercise for a long time to come.

If that's the case, I want my checkbox for AP5.05 on the SETI Preferences page. :)

So do i, I've been nudging the Project Staff every month or so, don't know if they even noticed,
It's a lot easier to get Bug fixes out of DA!

Claggy

Was wondering if anyone can help me connect my ATI GPU to get AP? I think my online settings are correct...I copied the App_info from another thread.

1/30/2010 2:16:39 AM SETI@home Message from server: No work sent
1/30/2010 2:16:39 AM SETI@home Message from server: No work is available for Astropulse v5
1/30/2010 2:16:39 AM SETI@home Message from server: No work available for the applications you have selected. Please check your settings on the web site.

---

Official Abuser of Boinc Buttons...
And no good credit hound!

Have you enabled "If no work for selected applications is available, accept work from other applications"?

Disable all apps and enable that, it's the only way to get AP 505 tasks. But you will still get MB work units.

---

Have you enabled "If no work for selected applications is available, accept work from other applications"?

Disable all apps and enable that, it's the only way to get AP 505 tasks. But you will still get MB work units.

I changed it to this?
Run only the selected applications SETI@home Enhanced: no
Astropulse: no
Astropulse v5: yes

If no work for selected applications is available, accept work from other applications? yes

---

Official Abuser of Boinc Buttons...
And no good credit hound!

Then you should be able to receive AP work units... have you get some MB work units or nothing at all?

---

Then you should be able to receive AP work units... have you get some MB work units or nothing at all?

It has MB units no problem there just noticed everyone talking about the splitters working and wondered why I haven't received any. Still getting the No work message but will let it keep trying. Thanks.

---

Official Abuser of Boinc Buttons...
And no good credit hound!