Client major revision change

Message boards : Client : Client major revision change
Message board moderation

To post messages, you must log in.

AuthorMessage
Profile Janus
Volunteer moderator
Project administrator
Avatar

Send message
Joined: 16 Jun 04
Posts: 4574
Credit: 2,100,463
RAC: 8
Message 5207 - Posted: 31 Mar 2007, 16:25:31 UTC
Last modified: 31 Mar 2007, 16:36:46 UTC

An entirely new client-side wrapper is under construction. It addresses all known issues except suspend-to-disk (which is excessively hard to solve and isn\'t a planned feature so far).

In particular it has the following changes compared to the currently available official client:
- Non-blocking multithreaded design elliminating BOINC communication issues
- Instant action system allowing CPU throttling to the following set {0%, 20%, 40%, 60%, 80%, 100%}
- The terminator has been replaced by a configurable ProgressMonitor that takes laptop/desktop suspend and hibernation into consideration
- ProgressMonitor feature: progress estimation interpolation (updates progress every sec based on better estimated total time)
- Exception-based error system that picks up errors and failures much better than before
- Priority control on both process and thread level
- Instant reaction on missing heartbeat - elliminating the orphaned renderer issue.
- Less issues on systems set to suspend-to-disk, no longer leave BOINC in a confused condition.
- Heavily increased portability
- Timer that analyses the CPU usage instead of wall-time and doesn\'t randomly wrap to 0.
- Designed to allow development of screensaver during beta
- Almost purely OO code instead of mixed c, flat c++ etc.

[...] more features to appear as soon as I get more time to write them here.

The client is built in such a way that it isn\'t really targetted at any operating system in particular. That\'s also the reason why there\'s still some work left on adding the interface to Windows which will allow it to run on the majority of the systems available to BURP.

I\'m currently working on building a compile-farm to compile future client releases. So far there\'s only a Windows x86 32bit system in the farm. The hope is to slowly add systems to the farm as required by the project milestones (ie. at least linux 32bit and possibly Mac OS X (intel) during alpha - more systems during beta).

It\'s still going to be several weeks before anyone actually get their hands on a binary of this new client (no, hehe, it\'s not in CVS either) - it has to go through the same extensive testing as the previous versions. Sorry, but it is ready when it is ready.

This post is simply a heads-up on what is going on since this can sometimes be hard to see.
ID: 5207 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile AndyK
Project donor
Avatar

Send message
Joined: 2 Apr 05
Posts: 137
Credit: 20,063
RAC: 0
Message 5208 - Posted: 31 Mar 2007, 16:37:21 UTC

Thank you very much for information.

You\'re doing an awesome job!!

Andy
ID: 5208 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Janus
Volunteer moderator
Project administrator
Avatar

Send message
Joined: 16 Jun 04
Posts: 4574
Credit: 2,100,463
RAC: 8
Message 5212 - Posted: 31 Mar 2007, 19:47:34 UTC

- Instant detection of render crash (No need to wait for the Terminator aka. ProgressMonitor anymore)
- CPU-time process monitoring moved from renderer to wrapper (this may fail on other systems than Windows and Linux at the moment)
- Renderer is forcibly killed on POSIX systems on abort rather than just asked to quit (SIGKILL vs SIGTERM)

[...]
ID: 5212 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Janus
Volunteer moderator
Project administrator
Avatar

Send message
Joined: 16 Jun 04
Posts: 4574
Credit: 2,100,463
RAC: 8
Message 5213 - Posted: 31 Mar 2007, 21:54:17 UTC

- Better self-crash debug when dying due to an error inside the wrapper (this will, however, stil leave an orphaned renderer running)

[...]

Good news: Everything compiles on the Windows host and initial tests show very good results. Although - as stated in a previous post - there\'s still an awful lot of testing to do.
ID: 5213 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Zanthius
Project donor

Send message
Joined: 24 Mar 05
Posts: 94
Credit: 1,627,664
RAC: 0
Message 5216 - Posted: 1 Apr 2007, 2:31:42 UTC - in response to Message 5213.  

Good news: Everything compiles on the Windows host and initial tests show very good results. Although - as stated in a previous post - there\'s still an awful lot of testing to do.


You cant tell me that in the 5hrs since the first post, you have written and compiled all that???
ID: 5216 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Janus
Volunteer moderator
Project administrator
Avatar

Send message
Joined: 16 Jun 04
Posts: 4574
Credit: 2,100,463
RAC: 8
Message 5218 - Posted: 1 Apr 2007, 6:29:16 UTC - in response to Message 5216.  

Good news: Everything compiles on the Windows host and initial tests show very good results. Although - as stated in a previous post - there\'s still an awful lot of testing to do.


You cant tell me that in the 5hrs since the first post, you have written and compiled all that???

Hehe no, I spent the two days (almost literally) before the first post writing it (and an entire year thinking about what to do). Yesterday was spent setting up the compile farm system and the Windows 32 bit host and utilities as well as researching hardware and software requirements until the end of alpha.
Today is going to be testbed-day. It is also the last day in this dev-cycle.

In the very unlikely event that no issues are found today it may be remotely possible to release the first official version for testing already today; but I wouldn\'t count on that.
ID: 5218 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Janus
Volunteer moderator
Project administrator
Avatar

Send message
Joined: 16 Jun 04
Posts: 4574
Credit: 2,100,463
RAC: 8
Message 5233 - Posted: 1 Apr 2007, 16:14:49 UTC
Last modified: 1 Apr 2007, 18:23:58 UTC

- Full 32 entry threadsafe message queue to avoid slowing down renders (compared to the old one-message-at-a-time system)

Things are still a bit messy but it actually works now.
There\'s an issue with the thread-control (suspend/resume) for the renderer. It should have been instant but in fact is quite slow (2-3 secs). This is still much better than the old client (that could spend minutes before reacting) but isn\'t acceptable since one of the design criteria were \"Support for CPU throttling\" - which requires suspend/resume to be instant.

Some research will have to go into this, and this also means that even though the client almost works there will be no official release today.
[edit:] Solved the thread issue but created another one... I just love the Windows Thread API...
ID: 5233 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
PovAddict
Avatar

Send message
Joined: 25 Apr 05
Posts: 347
Credit: 4,618
RAC: 0
Message 5241 - Posted: 2 Apr 2007, 0:50:50 UTC - in response to Message 5233.  

[edit:] Solved the thread issue but created another one... I just love the Windows Thread API...

I was going to comment on that... but I would have got banned for language :P
ID: 5241 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Fischer-Kerli
Project donor

Send message
Joined: 24 Mar 05
Posts: 70
Credit: 78,553
RAC: 0
Message 5243 - Posted: 2 Apr 2007, 1:30:49 UTC

I\'d like to add one important and hopefully not-too-hard-to-implement point to the wish list: no fake checkpoints. At present, there is no suspend-to-disk support, but for some reason the wrapper tells BOINC there are checkpoints each time the progress percentage is updated (visible if you put task_debug in your cc_config.xml). BOINC 5.8 only switches projects if the application has checkpointed. If there were no fake checkpoints, each BURP WU would be computed until the end without the risk of BOINC switching tasks in the middle of a BURP WU and starting it over from the beginning the next time.
ID: 5243 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Janus
Volunteer moderator
Project administrator
Avatar

Send message
Joined: 16 Jun 04
Posts: 4574
Credit: 2,100,463
RAC: 8
Message 5250 - Posted: 2 Apr 2007, 18:48:46 UTC - in response to Message 5243.  
Last modified: 2 Apr 2007, 18:54:24 UTC

I\'d like to add one important and hopefully not-too-hard-to-implement point to the wish list: no fake checkpoints. At present, there is no suspend-to-disk support, but for some reason the wrapper tells BOINC there are checkpoints each time the progress percentage is updated (visible if you put task_debug in your cc_config.xml). BOINC 5.8 only switches projects if the application has checkpointed. If there were no fake checkpoints, each BURP WU would be computed until the end without the risk of BOINC switching tasks in the middle of a BURP WU and starting it over from the beginning the next time.

Yup, that\'s actually already in the new client - I just forgot to add it to the list. Here goes:

- No longer does accidental checkpointing when reporting CPU time
- Better redirection of debug output from wrapper
- Formatting of renderer output
- No longer outputs grab\'ed renderer progress reports to debug out (not that useful anyways and took up a lot of space in the database)
- Reporting of time-skew enabled (to capture possible issues with suspend/resume on laptops and hibernation)

I also finally got the CPU-throttling working (I think). It sounds really stupid on my laptop due to the 1sec granularity used by BOINC - 1 sec the fan spins at full speed, the next it stops, etc. etc.
It is going to be interesting to see if all the stuff works for lengthy workunits too (2 lengthy WU sessions scheduled by Thamir, so going to be tested rather soon).
ID: 5250 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Janus
Volunteer moderator
Project administrator
Avatar

Send message
Joined: 16 Jun 04
Posts: 4574
Credit: 2,100,463
RAC: 8
Message 5267 - Posted: 3 Apr 2007, 7:57:02 UTC

There\'s now a release schedule for the new client: It is due to be released shortly after the easter holidays (Hopefully next tuesday afternoon UTC).
ID: 5267 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Janus
Volunteer moderator
Project administrator
Avatar

Send message
Joined: 16 Jun 04
Posts: 4574
Credit: 2,100,463
RAC: 8
Message 5268 - Posted: 3 Apr 2007, 15:57:13 UTC

Apart from a weird issue where the progress sometimes goes downwards in the progress display everything is looking pretty fine on lengthy units too. Unfortunately the old clients seem to choke on units longer than a few hours so I have to temporarily suspend 368 until the new client has been rolled out.
ID: 5268 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Achim

Send message
Joined: 17 May 05
Posts: 183
Credit: 2,642,713
RAC: 0
Message 5327 - Posted: 11 Apr 2007, 5:05:57 UTC

I had one (only one out of 8) result which terminated.
Message is:
|Fra:18 Mem:24.96M Blur 8 Sce: 1.001 Ve:173904 Fa:153746 La:0
|MBLUR 16(9 + (8-1) * 9) / (9 * 16)
|
|6462890

---------------------------
Exception caught: ProgressMonitor kills
Status: -10
---------------------------

Others finished the result, so the WU seems to be fine.

Any Idea what happend on my system?
ID: 5327 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Janus
Volunteer moderator
Project administrator
Avatar

Send message
Joined: 16 Jun 04
Posts: 4574
Credit: 2,100,463
RAC: 8
Message 5329 - Posted: 11 Apr 2007, 8:22:23 UTC - in response to Message 5327.  

Any Idea what happend on my system?

You wouldn\'t happen to have run other CPU intensive programs alongside BOINC at the time this happened? Like a computer game for instance?
ID: 5329 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Achim

Send message
Joined: 17 May 05
Posts: 183
Credit: 2,642,713
RAC: 0
Message 5331 - Posted: 11 Apr 2007, 8:31:45 UTC - in response to Message 5329.  

To be honest I was sleeping.

So I hope nothing happened.
I\'m not so sure when my daily virus scan is starting.
I assume this is CPU intensive as well.
I can check only when I\'m back to the box.
ID: 5331 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
PovAddict
Avatar

Send message
Joined: 25 Apr 05
Posts: 347
Credit: 4,618
RAC: 0
Message 5335 - Posted: 11 Apr 2007, 14:41:27 UTC

I run CPU-intensive apps along with BOINC now and then, so BURP better behaves when I do!

My record with 7-zip is over 12 hours (it was 8 GB to compress and on Ultra mode, got them to 10% of original). Then there is POV-Ray, WinOSi, compiling stuff, antivirus weekly scan, BitTorrent doing a full re-check when download finishes, some games unfortunately use all CPU as well (because of bad programming, always at 100%; constant polling in a busy loop instead of waiting, I guess).
ID: 5335 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Janus
Volunteer moderator
Project administrator
Avatar

Send message
Joined: 16 Jun 04
Posts: 4574
Credit: 2,100,463
RAC: 8
Message 5339 - Posted: 11 Apr 2007, 17:39:35 UTC - in response to Message 5335.  

The way that infinite loops are detected has changed a bit in the current client release. The next few releases will be used to finetune this (so it may currently kill too many results without any reason.)
ID: 5339 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Achim

Send message
Joined: 17 May 05
Posts: 183
Credit: 2,642,713
RAC: 0
Message 5343 - Posted: 11 Apr 2007, 19:02:36 UTC - in response to Message 5331.  

I\'m not so sure when my daily virus scan is starting.

Well it starts at 02.30, so does not look like it was the virus scan.
ID: 5343 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote

Message boards : Client : Client major revision change