Feel free to host it on your webserver. I am sure that several people will be willing to help you host it if you ask the community for help.

I have some free space on my burp-mirror - do you want me to host it?

- Peter

---

Feel free to host it on your webserver. I am sure that several people will be willing to help you host it if you ask the community for help.

I have some free space on my burp-mirror - do you want me to host it?

Thank you very much for your offer, Peter ! - Could you please contact me via email (seti_boinc at dotsch dot de).

Janus, is it OK, that the application uses about 230 MB memory and did not work with the CPU throtteling ?
I have also noticed, that a suspend of the application did not work.

did not work with the CPU throtteling

The CPU throttle feature was added to the BOINC core after I stopped monitoring their CVS due to time constraints, so honestly I have no idea how it is implemented. If, however, they did it by rapidly suspending and resuming the application thread multiple times per second it is bound to fail with BURP (at least until our controller stops blocking when waiting for the renderer).

I have also noticed, that a suspend of the application did not work.

As far as I know suspend-to-memory should work even on the MacOS X platform - suspend-to-disk should restart the workunit when resumed. At least the client was designed to be able to suspend-to-memory on all POSIX platforms (MacOS X, linux, BSD, unix etc.)

the application uses about 230 MB

Is this the controller og the renderer? The controller usually uses around 2MB, whereas the renderer can use any amount of memory required by the session.

The CPU throttle works by suspending the app when it is over the set preference and unsuspending when the usage drops below the set percentage. It uses a one second granuality. And yes this has caused problems with some projects, most often ones that use a wrapper type setup. Using the suspend to memory preference has been reported to reduce the problems.

---

BOINC WIKI

BOINCing since 2002/12/8

The CPU throttle works by suspending the app when it is over the set preference and unsuspending when the usage drops below the set percentage. It uses a one second granuality. And yes this has caused problems with some projects, most often ones that use a wrapper type setup. Using the suspend to memory preference has been reported to reduce the problems.

Ok, then it is as I suspected. The BURP wrapper doesn\'t support this kind of control (yet).

The CPU throttle works by suspending the app when it is over the set preference and unsuspending when the usage drops below the set percentage. It uses a one second granuality. And yes this has caused problems with some projects, most often ones that use a wrapper type setup. Using the suspend to memory preference has been reported to reduce the problems.

Ok, then it is as I suspected. The BURP wrapper doesn\'t support this kind of control (yet).

OK. Thanks.

The render had used about 230 MB memory with the WUs yesterday. With the actual WUs today it is only about 120 to 150 MB.

The binaries are now avaialable at www.dotsch.de/burp

With the new wrapper I get some compile errors on MacOS :
upper_case.C: In function \'int main(int, char**)\':
upper_case.C:126: error: expected `;\' before \')\' token
gmake: *** [upper_case.o] Error 1

Janus, I hope you have an idea to fix this.

That\'s the old client, please checkout the glue2 client instead.

That\'s the old client, please checkout the glue2 client instead.

Ups. Sorry.
Thank you.

It compiles fine on MacOS with some little changes. MacOS has a lot of libstdc++.a for PPC, but not for Intel, so I must link it dynamicly against the libstc++.

But now I get a error at the end : Unrecoverable error for result ... (process exited with code 247 (0xf7)).
And from stderr.txt :
Exception caught: Worker application apparently died prematurely
Status: -9

But now I get a error at the end : Unrecoverable error for result ... (process exited with code 247 (0xf7)).
And from stderr.txt :
Exception caught: Worker application apparently died prematurely
Status: -9

Noted and added to \"Known problems\". I\'ll get back to fixing this particular synchronization problem with the next client release.

But now I get a error at the end : Unrecoverable error for result ... (process exited with code 247 (0xf7)).
And from stderr.txt :
Exception caught: Worker application apparently died prematurely
Status: -9

Noted and added to \"Known problems\". I\'ll get back to fixing this particular synchronization problem with the next client release.

Fine. Thanks.

Is it OK from your side, to relase the unoffical MacOS and FreeBSD binaries with GLUE V.1 ?

Yes - I think the latest Blender patchset is still compatible with the first version of Glue, give it a try and see what happens.

Yes - I think the latest Blender patchset is still compatible with the first version of Glue, give it a try and see what happens.

It works.
I will release a new MacOS and FreeBSD release, as soon as I tested all. - I hope that I can finish it today...

I hope that I can finish it today...

Done...
The binaries are available at www.dotsch.de/burp

The binaries are now avaialable at www.dotsch.de/burp

no longer available

\"_________________________________________________________

Sehr geehrter Besucher,

leider ist ein Fehler aufgetreten: Die gewünschte Seite wurde nicht gefunden.

Haben Sie sich vielleicht vertippt oder eine alte URL aufgerufen? Wenn nicht, informieren Sie bitte den Webmaster dieser Homepage per Email. Um zu der vorherigen Seite zurückzukehren, verwenden Sie bitte einfach die \"Zurück\" - Taste Ihres Browser

At 0.01% the data is unpacked. Failure to unpack the data will cause the program to... act weirdly.

Make sure that you have a Mac-compatible version of the info-zip executables that are distributed along with the BURP client. You can find these here.

broken link

But now I get a error at the end : Unrecoverable error for result ... (process exited with code 247 (0xf7)).
And from stderr.txt :
Exception caught: Worker application apparently died prematurely
Status: -9

Noted and added to \"Known problems\". I\'ll get back to fixing this particular synchronization problem with the next client release.

Fine. Thanks.

Is it OK from your side, to relase the unoffical MacOS and FreeBSD binaries with GLUE V.1 ?

if any of this was actually populated at the sourceforge site for BURP, the whole open-source idea would probably help get the Mac side off the ground, and also possibly speed up the development of BURP in general...

The binaries are now avaialable at www.dotsch.de/burp

no longer available

\"_________________________________________________________

Sehr geehrter Besucher,

leider ist ein Fehler aufgetreten: Die gewünschte Seite wurde nicht gefunden.

Haben Sie sich vielleicht vertippt oder eine alte URL aufgerufen? Wenn nicht, informieren Sie bitte den Webmaster dieser Homepage per Email. Um zu der vorherigen Seite zurückzukehren, verwenden Sie bitte einfach die \"Zurück\" - Taste Ihres Browser

The BURP MacOS and FreeBSD binaries at www.dotsch.de/burp are obsolated by the release of the new blender version (2.44) support. It is not guaranted, that the old version will generate valid results. See this posting from Janus : http://burp.boinc.dk/forum_thread.php?id=843&nowrap=true#6100. So it is better not to use the old version.

According to the discusiuon about rendering for profit( http://burp.boinc.dk/forum_thread.php?id=170) I have decided not to continue my porting work.