Another new one to test.

REMINDER TO ALL ALPHA TESTERS:
It's far easier for us to fix problems if you send message logs with the appropriate flags set. The main flags are:

<cpu_sched_debug>: problems involving the choice of applications to run.
<work_fetch_debug>: problems involving work fetch (which projects are asked for work, and how much).
<rr_simulation>: problems involving jobs being run in high-priority mode.

Use these flags from the cc_config.xml file.

Report any problems you get with it to the Alpha email list. This list needs registration.

The change logs since 6.10.25...

Change Log:

6.10.26

- client: add missing dlsym of cuMemGetInfo() on non_Windows platforms.

- MGR: fix another bug due to changes for Snow Leopard compatibility: on OS 10.4.11 (Tiger) and perhaps others, when Automatic Login is set, getlogin() returns "root" for a time after the system is first booted, causing the Manager to think the user is not a member of group boinc_master. So check "USER" environment variable instead.

- Mac MGR: Call Mac accessibility calls GetViewDisplayName() instead of GetViewName() to announce localized tab names.

- client: Eliminate x86_64 Mac client; i386 client determines if system supports x86_64 applications and sets HOSTTYPE and platform accordingly. This allows us to link with the 32-bit CUDA libraries. The one other effect is that the benchmarks are run in 32-bit mode even on a 64-bit capable Mac.

- client: Async get_state RPC was not updating state.have_ati field.

- MGR: Rebuild Advanced Menu and Taskbar Menu after connecting to client, so GPU Activity and Snooze GPU items are displayed if needed.

- Mac: Fix bug in backtrace code which showed up only under OS 10.6.

- Mac installer: Add CUDA information to Mac ReadMe files.


6.10.27

- client (Mac): it's DYLD_LIBRARY_PATH, not DYLIB_LIBRARY_PATH

- client: ATI available RAM wasn't being detected correctly


6.10.28

- client sandbox: set LD_LIBRARY_PATH and DYLD_LIBRARY_PATH in switcher.

For unknown reasons, the these 2 environment variables are not passed in to switcher, though all other environment variables do get propagated.


6.10.29

- client (Mac): append /usr/local/cuda/lib to LD_LIBRARY_PATH and DYLD_LIBRARY_PATH

- client: show <cpu_sched> message when suspend/resume GPU activity

- client: there are oddball cases where the client has an app for which avg_ncpus > ncpus. Allow such jobs to run; otherwise nothing runs.

- client: in computing "anticipated" STD, scale by ninstances (from John McLeod)

- MGR: Deconflict menu item IDs.

- manager/client: show PID in task properties; add PID to RESULT structure in GUI RPC

- client: when parsing cc_config.xml, clear vectors so we don't end up with duplicates

- client: divide LTD deltas by ninstances, same as for STD.

This is cosmetic - it won't affect work fetch, but it will prevent LTD from changing faster than real time

- client: add logic to work fetch so that each project will have enough jobs to use its share of resource instances.

This avoids situations where e.g. on a 2-CPU system a project has 75% resource share and 1 CPU job, and its STD increases without bound.

Did a general cleanup of the logic for computing work request sizes (seconds and instances).

- client: Unix: if can't create client lock file,
report ERR_OPEN rather than ERR_ALREADY_RUNNING. fixes #970

- client: fix format strings for ninstances (can be fraction now)

- client: scheduling problem:

- a project overestimates job FLOP counts

- the client starts jobs in EDF mode

- as job progresses and fraction done increases, its completion time estimate decreases until it's no longer a deadline miss.

- job gets preempted by other job from that project; you end up with lots of partly completed jobs.

Solution (I hope): if an app version has running jobs, compute a "temp DCF" for the app version, which is the min of dynamic/static estimates for its jobs.

Apply this scaling factor to completion time estimates for unstarted jobs in RR simulation

- client: the estimation of remaining time of running jobs was wrong (how did this bug survive so long?)

- client: bug in ACTIVE_TASK::est_dur()

- client: work fetch fix: avoid sending null request in certain cases.

- client: add <stderr_head> config option; sends the first rather than last 64KB of stderr to server.

This doesn't belong here; this choice should come from the server. I may take this out later.

- client: small tweak to work fetch: if project has crazy DCF, don't automatically request 1 sec; only request work if there's a shortfall.

---

BOINC blog

For those with Macs and an Nvidia GPU you may be able to start running Collatz ... there is a thread over there discussing this if you are interested.

Another new one to test.

REMINDER TO ALL ALPHA TESTERS:
It's far easier for us to fix problems if you send message logs with the appropriate flags set. The main flags are:
....

Don't you think that this is getting out of hand now ?

Almost every project message board is full with your ALPHA BOINC posts, which do not belong here or elsewhere at all, except the boinc alpha test or boinc message board.

Don't you think that we already have enough trouble here with "stable" releases of the client and the server software and getting things sorted out ?

---

Join Support science! Joinc Team BOINC United now!

Don't you think that this is getting out of hand now ?

Almost every project message board is full with your ALPHA BOINC posts, which do not belong here or elsewhere at all, except the boinc alpha test or boinc message board.

Don't you think that we already have enough trouble here with "stable" releases of the client and the server software and getting things sorted out ?

Just because you may not be interested in the alpha versions doesn't mean others aren't. They are clearly labeled in the subject line as to being development versions, so you can ignore the message thread if you wish.

---

BOINC blog

Almost every project message board is full with your ALPHA BOINC posts, which do not belong here or elsewhere at all, except the boinc alpha test or boinc message board

Very few people are like me and run 10-50 projects, so, posting on most of the major boards is still appropriate as a lot of folks are still pretty focused on single projects or only a select few.

As an example, GPU Grid has a real good up time and a person might only be doing GPU Grid to the exclusion of MW and Collatz and were it not posted there they might miss the information.

Last point, most people don't follow the mailing lists and even fewer know of the BOINC boards... and since Jord left there is no one that would be monitoring that board for inputs ... and for that reason those boards are beyond useless ...

Almost every project message board is full with your ALPHA BOINC posts, which do not belong here or elsewhere at all, except the boinc alpha test or boinc message board.

I don't look into too many boards and this is just one thread in this board which I could ignore or, as I find useful, to look into. I may not contribute much to the tecnical posts in this or other borads, but I sure do read a lot of them and I do so because I find them useful and interesting.

I hope MarkJ continues to post this useful info here and I doubt if I ever will have the time or 'that' much technical interest to seek it out in the boinc message board if he doesn't.

---