Predictor@Home Project News

News and project updates which haven't been added to yet.

Moderators: Jwb52z, CedricVonck, kpearson, Honza, Lupine1647

Predictor@Home Project News

Postby Jwb52z » Tue Sep 13, 2005 5:38 pm


File uploads have been enabled.


System crashed because of failed root drive over the weekend. The scheduler will be offline until the new drive arrives.
Posts: 997
Joined: Tue Aug 30, 2005 10:56 pm

Postby Jwb52z » Sun Mar 12, 2006 11:18 pm


There is a new scientific update under current progress.
Posts: 997
Joined: Tue Aug 30, 2005 10:56 pm

Postby Jwb52z » Sun Apr 29, 2007 5:08 am


Homogeneous Redundancy has been turned back on. The t0348_lng workunits are almost done. On Monday there will be 5 new sets of 2000 workunits. I will leave H/R on for the entire set.


For now homogeneous redundancy has been turned off. We are looking into making the validator accept results from different CPU types.


If you are having problems with t0348_lng workunits the first thing you should check is the version of dTASSER you are using. It should be version 0.30 or greater.

The daily quota has been reduced because of the longer duration of the new workunits.

t0348_lng workunits have been created.

The new versions of dTASSER are available now. Work should be avail soon.

The Linux version of dTASSER will only work on machines with 2.6 kernels. We hope to have version 0.31 available tomorrow which should run on both 2.4 and 2.6 kernels.

New work should be ready this evening. The 0.3x version of dTASSER for the Intel and PowerPC Mac are ready. The new application has checkpointing. In tests the new work units took just over 6 hours on a new dual core machine to 18 hours on a single cpu hyperthreaded machine. The new and old applications do not mix. You need to make sure that you are running dtasser-0.30 before you start any new jobs or the work will not validate. If you still have any t0348 or t0377 jobs please cancel them. New jobs will require 70Mb RAM for the first 80% and 770MB for the last 20%. We have seen an issue on Windows dual core where the client halts a job with 'Waiting for Memory' and that job never recovers. The same job on the same machine running Linux does not stop the job. If you have a dual core/ dual processor machine running Windows you may want to change your preferences so that you use at most 1 CPU.
Posts: 997
Joined: Tue Aug 30, 2005 10:56 pm

Postby Jwb52z » Sun May 06, 2007 11:26 pm


A problem has been identified with the t0XX series of workunits. There is a default maximum amount of disk space built into each workunit. These workunits will use more than the default. If you are running a t0xx workunit you can keep it from failing by doing the following.

1. stop the boinc client

2. Edit the client_state.xml file

3. Change the line for the workunit that look like:rsc_disk_bound 100000000.000000 /rsc_disk_bound so that is looks like rsc_disk_bound 157286400.000000 /rsc_disk_bound

4. Restart the boinc client.

The deadline for the t0xx series of workunits has been extended from 1 week to 3 weeks.


We've decreased the memory requirement to 768MB RAM.

The estimated number of FLOPs for the new workunits was too short. It has been increased.


The pending and inconclusive credits have been issued for results during the Homogeneous Redundancy testing.

5 new sets of work have been created. Each set has 2,000 workunits which is approximately 6,000 results. Homogeneous Redundancy has been turned on. The memory requirement has been set back to 1GB RAM.
Posts: 997
Joined: Tue Aug 30, 2005 10:56 pm

Return to New News

Who is online

Users browsing this forum: No registered users and 3 guests