PcPerf bot

As we've mentioned earlier, we have been preparing changes to the bigadv system –– both an increase in the number of cores required (and a shortening of deadlines to match) and the release of some new bigadv projects. The motivation for the core changes is as follows: Bigadv is intentionally intended for the most powerful machines, which makes it naturally a moving target. Our goal with bigadv is to utilize the most powerful segment of (CPU-based) machines in the FAH project to work on projects that are particularly large (memory utilization, upload/download requirement) and require a large amount of computation. We are all fortunate in that processors get faster over time, so the highest-performing tier of donor machines also gets faster over time. We have a lot of exciting science being enabled by FAH donors, and it takes place at all levels of computational requirement and performance sensitivity. So it wouldn't help the project to have 50% of machines running bigadv. But it also wouldn't be a good match to have some of the older and/or bandwidth-limited machines running these most performance-sensitive projects. As previously announced, our plan is to shorten the deadlines of the BA projects. As a result, assignments will have a 16 core minimum. We've been developing the new projects for the new "bigadv-16". This development has taken a bit longer than we expected, but we are now completing internal testing and reading beta projects for bigadv-16. We are bringing a new server online for bigadv-16. It will start by offering a new class of bigadv projects, but we will soon add in a number of projects on the same server that are more similar to bigadv projects donors have already seen. We want to make these work units available for testing, but at the same time we are still examining the points yield of these bigadv projects. So the points valuation remains a work in progress; we may alter points, bonuses, and/or deadlines in the process of testing. Please expect a beta announcement soon for testing these new bigadv-16 work units. Then, after the new bigadv-16 projects stabilize, we will bring the bigadv-12 projects into line (points, deadlines) with the bigadv-16 projects and convert all projects to bigadv-16. We are not sure of the timescale for this yet, as we'd like to test the new projects in a thorough manner. We will endeavor to be as transparent as we can regarding upcoming changes in the bigadv program. Bigadv-8 projects will likely be phased out (and indeed are mostly not being assigned at this time). As a side note, we recognize that the number of cores is a somewhat crude measure for system performance. Long-term, we have some ideas on how we'd like to improve this and use better metrics. But in the near term, we are using this admittedly imperfect metric. Thank you for folding and for your support of the bigadv program and FAH more generally. Voir l'article complet

We've finished our stats recredit. It should be comprehensive, but we encourage donors to let us know in our forum if there are still problems. Voir l'article complet

We're investigating reports that donors stats were not registered into the stats system. We're working on a recredit now. Voir l'article complet

Here's our (I think) last update on this recent outage. This was a major disaster at Stanford affecting the whole campus and I'm grateful for our team coming in on Sunday to get things back up. The workservers have been up since then and work and stats have been saved. The stats updating was put on hold until we can make sure everything looked ok. We've turned it back on. Please note that there is no stats loss while we turn off updates. People should see a big bump in their stats shortly. Thanks for bearing with us through this. Voir l'article complet

The whole Stanford campus is having a major issue due to the lack of chilled water on campus. This is causing issues for many of our servers in different server rooms. As of this moment, this is still not resolved. We cannot bring servers back on line until this is resolved. It's getting late (~10:30pm PST), so we'll check back tomorrow morning to see hopefully that this is resolved. Until then, several of FAH's servers are down unfortunately. UPDATE 4:30am Pacific Time: Chilled water came back on line at 11pm, but several of our servers are still down. Our sysadmins will work to get them back up, but it may not be until Monday, depending on their availability on Sunday. UPDATE 11:30am Pacific time: Our sysadmins have been in the office getting machines back on line. We're almost there, although it looks like there are a few machines which have issues resulting from the outage. Voir l'article complet

We have a network issue at Stanford in one of our data centers. We are working on it now. Update: Everything is back up now. Voir l'article complet

We just received notice that the School of Medicine has scheduled an emergency network downtime Tonight between 5-6 pm (pacific time). Network engineers expect end users to experience a single, 30-60 second network disruption as part of their work, but I'm posting this in case there's something more significant. Voir l'article complet

Several of the FAH servers are located at Stanford Medical School. The Stanford School of Medicine Networks have reported outages last night (Thursday, Nov 17, 7:50-9:18 pm, pacific time) and this morning (Friday, Nov 18, 7:47 am, pacific time). Stanford IT is working with the vendor to diagnose the source of the problems. We have been warned that the medical school network may possibly be unstable today. However, note that many of the servers at Stanford are not on this network and moreover we have redundant systems (eg redundant assignments servers) not on this network, so work should go smoothly. There may be delays in updating stats however. Hopefully this is a resolved issue, but we are monitoring the situation in case it isn't. Voir l'article complet

The Stanford News Service recently came by to do a video for Folding@home. Here it is: Voir l'article complet

Big Advanced (BA) is an experimental type of Folding@home WUs intended for the most powerful machines in FAH. However, as time goes on, technology advances, and the characteristics associated with the most powerful machines changes. Due to these advances in hardware capabilities, we will need to periodically change the BA minimum requirements. Thus, we are shortening the deadlines of the BA projects. As a result, assignments will have a 16 core minimum. To give donors some advance warning, we are announcing this now, but the change will take place in 2 months: no earlier than on Monday January 16, 2012. We understand that any changes to how FAH works is a disruption for donors, and we have been trying to minimize such changes. For that reason, we are not changing the points system at this time. However, we want to emphasize that the BA program is experimental and that donors should expect changes in the future, potentially without a lot of notice (although we will try our best to give as much notice as we can). In particular, as hardware evolves, it is expected that we will need to change the nature of the BA WUs again in the future. Voir l'article complet

We've been working to make the behind the scenes tasks of Folding@home better communicated with FAH donors. In the last few months, there have been many recent changes, including making the beta team forum open and making our v7 client bug tracker open for all to read. Today, I wanted to talk about another experimental change, the formation of a Donor Advisory Board (DAB). We've in the past gotten lots of feedback from donors on our Forum site (http://foldingforum.org). Based on discussions with many donors, we have been working to expand these discussions to a broader group of donors and have formed a Donor Advisory Board. The DAB is currently comprised of: rjbelans (folding@evga), kendrak ([H]ardOCP), zodac (Overclock.net), ChasR (www.overclockers.com), and Michael McCord (MaximumPC), Bruce Borden (Forum Admin), and myself. The goal of the DAB is to improve communication in both directions and so far I think it's been helpful in that regard. Pasted below is the first set of agenda items that we have been working on. 1) Improving communication: What can PG do to help improve communication? 2) Beta testing plan: How to improve transparency without lowering the quality of beta testing. 3) Points consistency: How to make PPD more consistent. We've made changes in all three areas but none of these can be considered "done". My hope is that the DAB will help feedback in both directions, giving us broader perspectives of donors concerns and also to better communicate what we're doing to improve FAH and push towards greater scientific achievements. Voir l'article complet

We've been getting reports that donors can't get SMP WU's. There are plenty of SMP WUs, but they require client v6.34 (or later). The servers that can handle the older SMP client (v6.29 or later) are running low on WUs, but there are plenty of WUs for the newer clients. If you're not getting WUs, please consider upgrading your client. You can download it here: http://folding.stanford.edu/English/DownloadWinOther Moreover, it's a good time to try out the beta version of our new v7 client! https://fah-web.stanford.edu/projects/FAHClient/wiki/BetaRelease Voir l'article complet

Right now, the two most powerful supercomputers for studying protein folding are Folding@home and a very impressive special purpose computer from DE Shaw Researched, called ANTON. We're often been asked "how do they compare?" The approaches are very different, so comparisons aren't completely straightforward. ANTON takes the traditional approach to studying protein folding, where one performs a few (often 1 or 2) long trajectories to study the process. Folding@home takes a statistical approach, which has two primary benefits: 1) it can access folding on dramatically longer timescales (milliseconds, instead of microsecond folding events over a single long trajectory) and 2) it can give statistically significant results on those long timescales. The main concern about the method in FAH is that since it is such a radically new approach, does it work reliably? Previous tests of FAH have been to experiment, which is the gold standard test, but also brings in other issues, such as how good are our models of reality. Thus, while FAH's approach has done well compared to experiment, it is useful to compare FAH and ANTON directly, since they use the same models, etc. Comparison of our statistical approach (using Markov State Models, aka MSMs) directly with data from ANTON would go a long way to showing that the MSM approach works for even non-trivial systems (they have been previously tested for long dynamics on small systems). In a recently published paper, we make this comparison. By applying MSMs to data from ANTON, we find that FAH's approach (MSMs) can reproduce the long timescales in ANTON data very well. Moreover, we also find that the MSM approach can find important new features missing in the more traditional analysis approach originally applied to the ANTON data, relevant for understanding folding and function. For us, this is exciting since it shows the capabilities of the MSM method. However, I want to stress that perhaps the most exciting part is how ANTON and FAH could be used together. A run on ANTON followed by more thorough sampling in Folding@home could be the best of both worlds. PS Here's the abstract for our paper (http://pubs.acs.org/doi/abs/10.1021/ja207470h?prevSearch=lane%2Bpande&searchHistoryKey=): Two strategies have been recently employed to push molecular simulation to long, biologically relevant timescales: projection-based analysis of results from specialized hardware producing a small number of ultra-long trajectories and the statistical interpretation of massive parallel sampling performed with Markov state models (MSMs). Here, we assess the MSM as an analysis method by constructing a Markov model from ultra-long trajectories, specifically two previously reported 100 µs trajectories of the FiP35 WW domain (Shaw et. al. (2010) Science, 330: 341-346). We find that the MSM approach yields novel insights. It discovers new statistically significant folding pathways, in which either beta-hairpin of the WW domain can form first. The rates of this process approach experimental values in a direct quantitative comparison (timescales of 5.0 µs and 100 ns), within a factor of ~2. Finally, the hub-like topology of the MSM and identification of a holo conformation predicts how WW domains may function through a conformational selection mechanism Voir l'article complet

We've released the latest v7 client (7.1.38) in our forum. I've pasted the update from Joseph Coffland (lead programmer), outlining the progress so far. Documentation Installation and user guides can be found here: FAHControl -> The Graphical User Interface (GUI) what controls the Slots. FAHViewer -> It shows the protein being folded, if applicable. Pictorial Installation Guide (Windows) -> A detailed pictorial guide on the V7 installation. Installation Guide (Windows) -> A brief guide on Windows installation. Installation Guide (Linux) -> A guide for Linux installation. Installation Guide (OSX) -> A guide for OSX installation that is in progress. Client Remote Interface -> Documentation for 3rd party developers. Main Page -> Main page of the V7. Getting Help Aside from the documentation the best place to get help is in this forum. If you do have a problem post a message. There are many knowledgeable people ready and willing to help. Keep in mind, we greatly appreciate thorough reports delivered by patient people who can keep a cool head even when things go wrong. Bugs/Tickets Open Tickets Ordered by Milestone and Priority Active Tickets by Change Time Note: Some tickets may be closed because they are fixed in an upcoming alpha release but are not yet fixed in the beta release. _______________________________________________________________________________________ Beta Testers, I've been focusing on addressing the issues which most affect v7 client users and which may help those still running v6 clients to make the decision to upgrade to v7. Your feedback has been very important, not only in finding and solving bugs but in prioritizing development time. One donor had these concerns with using v7.1.33: Jesse_V wrote:I'd be happy to try out v7.1.33 and its upgrades if I was confident that my participation wouldn't hurt science. I am concerned with a number of bugs in v7, things such as FAHClient taking up way too much CPU time and slowing things down. I also am concerned about v7 not being able to talk to the servers right, especially when errors occur. Although the issues Jesse_V mentioned only affected a small portion of the v7 users they were legitimate concerns. I made sure these issues were thoroughly addressed in this release. Concerns like this are exactly what we need to hear about. If you are also concerned about v7 affecting the science of Folding@home I have this to say. v7 is more likely to increase your contribution but if you do have a problem, and you report it, you are potentially helping thousands of users donate computing time to Folding@home so it's more likely a net gain. However, beta testers often have to be satisfied with peer recognition and praise rather than points. If you've been on the fence about v7 now is a great time to upgrade. Here are some of the other comments we've been getting: jimerickson wrote:i am running windows 7 ultimate 64bit and windows 8 developer preview release. everything went smoothly. . .keep up the excellent work. DarkFoss wrote:The upgrade from v7.1.24 to 7.1.33 went flawlessly. . .install took less than a minute and it resumed folding the wu's they finished without issue. . . OEOTS wrote:Congrats on the new release guys. with V7 you've made it all so much easier. soya_crack wrote:Wow, that is one of a big advance. That was what F@H just needed. It's awesome. Easy to understand and just kickin' ass, the slot thing is what I was missing from BOINC. WhiteLion wrote:Awesome! The best client i ever use, perfect for newbies, easy setup. . . There are still several issues that need to be addressed before we go to the front page with the v7 client. Specifically the tickets listed in Milestone Open Beta Phase 2 under ticket report 3. Log filtering (#157), better ETA calculation (#395) and better handling of cores that don't terminate cleanly (#563) are the top three items. There is more work to do but we are getting ever closer to a front page release of the v7 client. Thanks for all your bug reports and feedback. Keep telling us what issues are most important to you and we will do our best to address them. Joseph Coffland Folding@home Developer Cauldron Development LLC Documentation Installation and user guides can be found here: FAHControl -> The Graphical User Interface (GUI) what controls the Slots. FAHViewer -> It shows the protein being folded, if applicable. Pictorial Installation Guide (Windows) -> A detailed pictorial guide on the V7 installation. Installation Guide (Windows) -> A brief guide on Windows installation. Installation Guide (Linux) -> A guide for Linux installation. Installation Guide (OSX) -> A guide for OSX installation that is in progress. Client Remote Interface -> Documentation for 3rd party developers. Main Page -> Main page of the V7. Getting Help Aside from the documentation the best place to get help is in this forum. If you do have a problem post a message. There are many knowledgeable people ready and willing to help. Keep in mind, we greatly appreciate thorough reports delivered by patient people who can keep a cool head even when things go wrong. Bugs/Tickets Open Tickets Ordered by Milestone and Priority Active Tickets by Change Time Note: Some tickets may be closed because they are fixed in an upcoming alpha release but are not yet fixed in the beta release. Here are the change logs: v7.1.38: Fixed network connection dropping. v7.1.37: Added missing wraplabel.py file to FAHControl. Changed socket error message verbosity. Fail WU on UNSTABLE_MACHINE immediately & return for partial credit. #615 v7.1.36: Fixed a potential socket connection bug. Maybe related to #734. Added several NVidia cards to GPUs.txt. #737. Improved Linux on battery detection. #738. Print WU error state on WU status line. Emit correct exception on FAH transaction failure. #615. Fixed debian package install core permissions problem. #732. Removed core byte order warning. #602. Added GPL link to FAHControl about. #736. Ask user, team, passkey and mode during .deb package install. #739. v7.1.35: Added 'Enchanter' theme. #731 Renamed 'Wimp' to 'Windows-Default'. #731 Unminimize FAHControl window on unhide. #567 Better core download failure message. #161 Cleaned up project descriptions using html2text.py. Store project data in client DB. Use system default font size. #733 Added project info to viewer. #575. Added clickable buttons to viewer. Fixed FAHViewer crash introduced in v7.1.34. Fixed mouse wheel scrolling in FAHControl. #463. Fixed color difference for text boxes. #698. Changed FAHControl window name. #711. v7.1.34: Fixed CPU consumption in client connections. #702 Really fixed "Wrong architecture" bug on 32-bit Ubuntu. #599 Only warn on config errors. #722 Log error and continue of command server fails to initialize. Fixed Slot configuration text. #717 Use -1 or 0 for CPUs default to be consistent with GPU options. #717 Disabled no longer supported AMD X1300 - 1900 GPUs. Added "OpenGL Render" to info in FAHViewer. (For blacklisting) Added 'override-blacklist' option to FAHViewer. (Nothing black listed yet) 'OK' -> 'Save' in FAHViewer preferences window. #724 Fixed NVIDIA_DEV.1244.01 = "NVIDIA GeForce GTX 550 Ti" detection. Added the 'Wimp' theme and win32 theme engines. #723 Made 'Wimp' theme the default in Windows. #713 Added heartbeat to viewer<->client connection to timeouts dead connections. Stop trying FAILED, FAULTY and DUMP reports if WS connection was made. #728 Check WS server versions for unreasonable values. #728. Here are the highlights and some of the technical details of the changes in this open-beta: Improved network handling: A number of networking related issues were solved. The run away CPU usage problem was caused by incorrectly handling dropped connections. Periodic connection loss on Windows machines was caused by not correctly handing a quirk in the Windows sockets API which was the cause of the greyed out FAHControl that some people were experiencing. Also, dropped connections are now being cleared out of the client much more quickly. This keeps dead connections from accumulating which caused problems in a few cases. Improved communication with older WS: Several problems with communication with older WS were fixed. This version does a better job of detecting older WS and aborts the error loops that the previous client got into when incorrectly trying to upload DUMP reports to the old servers. This was the cause of the repeated upload errors many people saw in their logs. Also, a bug was fixed in the handling of UNSTABLE_MACHINE core return code which was the start of many of these DUMP communication loops. GPU detection: More cards were added to the whitelist and some older, no longer supported, GPUs were removed. Debian package improvements: A permissions problem was fixed that was causing WU loss after reinstall. The installer also now asks for user, team and passkey if /etc/fahclient/config.xml does not already exist. RPMs and OSX packages still need this feature. Added a native Windows theme (Wimp): The Wimp (Windows Implementation) theme was added to FAHControl. This theme gives a true native look on all Windows platforms because the theme engine actually uses the Windows system to render the GUI components. This is now the default theme for Windows platforms. Still need something like this for OSX. Voir l'article complet

I filmed a new interview about Folding@home, which gives some potentially interesting details about FAH especially for those who are new to the project. The show is Futures in Biotech 85: Modeling Life With The World's Most Powerful Computer System. Dr. Vijay Pande, Stanford's Director of Folding@home, details how the World's most powerful system models Alzheimer's and other human diseases. Voir l'article complet

I have some good news. Due in large part to the work we've done with Folding@home, I've been named the recipient of the 2012 Michael and Kate Bárány Award for Young Investigators from the Biophysical Society for "developing field-defining and field-changing computational methods to produce leading theoretical models for protein and RNA folding." This was just annouced in the Biophysics Society newsletter and their web site hasn't been updated just yet for the 2012 awards. As with all of the accolades coming to our work, this is very much a team effort, and I'm excited that our collective work is being well-recognized. Voir l'article complet

We have made a major update to the Results page on the Folding@home web site. We now list 95 papers that have directly resulted from Folding@home, although we note that there are 193 papers from the Pande group in general. There are many new results to talk about, but I will just highlight a few below. One major result is in the area of Alzheimer's Disease (paper #95). It is believed that Alzheimer's Disease results from the misfolding of the Abeta peptide. Understanding how Abeta misfolds could give us some key insights into how to cure Alzheimer's Disease. This paper experimentally tests a key prediction made in an earlier paper (paper #58: "Simulating oligomerization at experimental concentrations and long timescales: A Markov state model approach" by Nicholas W. Kelley, V. Vishal, Grant A. Krafft, and Vijay S. Pande. J. Chem. Phys. 129, 214707 (2008); DOI:10.1063/1.3010881). In this paper, we show experimentally that there appears to be a beta turn in the Abeta as predicted. This leads to a very stable form of misfolded Abeta which could be used as a starting point for a new Alzheimer's therapy. We are heavily pursuing this research direction at the moment. Another key result is in the area of methods (paper #93). We are constantly honing our methods to improve Folding@home's ability to predict the behavior of proteins. This paper demonstrates the current state of the art in terms of both sampling and analysis. When compared to detailed TTET experiments, we show that our methods can piece out even fairly detailed aspects of folding. However, we also see the ways in which our models are not perfect, suggesting how we can improve our methods even further. We'll highlight other papers as time goes on. I'm particuarly excited about these results. In particular, the results from paper #95 were first discovered several years ago, but we carried out several followup studies to verify them, etc. As always, I'm most excited about what we're doing now and hope to get some of our current key results in theses areas out from peer review soon. Voir l'article complet

We've developed a new serverstat page, which we're now suggesting as a replacement for the old one. The new one is more asthetically pleasing but also has a lot of changes under the hood to allow for more reliable and faster updates. We're keeping the old serverstat page link pointing to the old page (i.e. no change) in case there were scripts that were parsing the old page. However, we've set the new page to update every 10 minutes and the old one to only update every hour. We will keep the old page up for at least two months to give 3rd party utilities a chance to update their code and to give us feedback (please post feedback to http://foldingforum.org ). Voir l'article complet

For new bigadv WUs, we have changed how the points are calculated to bring them back into balance with the rest of the points in Folding@home. There are more details in this post: http://foldingforum.org/viewtopic.php?f=24&t=19059 The main jist of the change is that we are decreasing the points associated with bigadv WUs, from 50% over SMP to 20% over SMP. As with previous points changes, this deals with only new WUs to go out, not with WUs that have be collected, etc. I want to stress that the bigadv program is still continuing, but that, as we've mentioned before, this is an experimental program and subject to changes. It's clear that any change to the points system is controversial, but this one has been raised as a very serious problem by many donors. After investigating the issues raised, we agreed that this was significantly out of balance, and made this change. Moreover, the feedback we have gotten is that we make a change soon and do so quickly, like "removing a bandaid" rather than drag out the pain. I'm sorry to have to make any changes at all, since any change is disruptive, but we (and many donors) felt very strongly that this change was very important. The other change that we have in mind to do is to bring all classic and GPU WUs into the Quick Return Bonus (QRB) system. This would help further bring all FAH projects into balance. There may be some issues with GPUs and QRB, so we are looking to see what we can do to minimize problems with that before making a change in the points for GPU WUs. Finally, I would like to remind all that we do listen to donors and take their input very seriously. There has been extensive discussions about the problems with the points system with the huge PPD's seen with bigadv (sometimes reaching 500,000PPD) and the lack of QRB for GPUs being major shortcommings. Considering the great variety of donor opinions on this matter, it is no surprise that we agree with some donors and disagree with others. Moreover, with points, there will never be any system which makes everyone happy, but our goal is to try our best to balance the project as a whole, taking donor input seriously, and making hard calls when we feel it is necessary. This was definitely a hard call, but hopefully in time donors who disgaree now will come to understand the issues raised by the other donors and appreciate their point of view. Voir l'article complet

The stats db hung last night around midnight pacific time. We saw that it was down this morning (we get emails from the stats system when there hasn't been an update in over 2 hours) and we restarted the stats db. A stats update is now in progress and should continue to run. We will keep an eye on this over the weekend in case there's some greater systemic problem here. Please note that we have a reduced admin staff on the weekends, so response will be a bit slower. Voir l'article complet

We have been making changes to the donor ranking on the Stanford stats pages to work to reconcile them with the 3rd party stats. The central issue at hand is how does a given stats system handle accounts with multiple passkeys. A more detailed discussion can be found in this discussion thread. We are working directly with 3rd party stats to come up with a solution that works for all. For now, we have made one change which brings them closer, but not completely in agreement. However, donors who pay close attention to the Stanford site will likely see a big change in their ranking. We're posting this blog post to give donors a heads up on this issue and some information of what's going on behind the scenes. Voir l'article complet

It's been a little while since our last v7 beta release (v7.1.24) and so I wanted to give donors some sense of what's going on. We've been working on internal testing of two releases past the current beta release and fixing bugs along the way. While we could in principle release v7.1.25 to open beta, there are enough todo items that we've decided to hold off a bit until it's a bit cleaner and further along. However, we're not going to hold off forever of course, just long enough for our developers to make some significant progress, especially since doing a release generates a lot of feedback, which takes developers away from coding. To give some sense of where we are, here's the internal release notes for two recent builds (v7.1.25 and v7.1.26). Note that v7.1.26 is still in progress. Also, the #'s after the comment refer to our bug tracker. We have opened up the bug tracker, so one can see progress directly there on a daily basis if you're interested. v7.1.26 (still under development): * Failed upload attempt could cause WU to dump before it was expired. #679. * Added AMD Radeon HD 6600 Series to GPU white-list. * Fix failure to restart FAHControl in OSX when 'start minimized'. #649. * Fixed a socket bug that could cause the loss of the end of a message. * Build OSX client in 32-bit mode with Intel compiler. v7.1.25: * Hide 'Quit on window close' option in OSX. * Fixed some problems with WU assign time and time offset calculations. * Detect and ignore invalid assign time from older WS. * Log computed WS time offset. * Removed warning from Slot configuration about changing threads mid-run. * Catch and log error accessing battery info in /sys on Linux * Fix grayed out name and IP in client add after viewing local client. #640. * Remove 'RS480 PCI-X Root Port' from GPU whitelist. #635 * Added a few new Radeon HD 6xxx cards. * Added Nvidia GTX 590 device ID 0x1088 to whitelist. * Increase Radeon HD 5xxxx and 6xxxx GPU type level by one. #653. * Don't fail WS connections if all data was recieved even on net error. * Print IP Address with 'Uploading' message. * Fixes for OSX minimize and quit bugs. #649 & #659. * Limit max CPUs per slot to system count. #652. * Attempt to fix #654. * Release system resources when querying OSX battery status. #650. * Don't send 'auth' command from FAHControl if empty. #658. * Fixed 'slot-add' NULL pointer exception. #666. * Fixed 'log-updates start' error. #671. * Fixed FAHClient script parsing bug. #676. * Show 'Remote Access' tab in advanced mode. #648. * Don't allow minimizing to sys-tray if it is not there. #670. * Also print core return code numbers in hex. #677. * Print times in ISO 8601 format. #664. * Expire WUs in sending status. Voir l'article complet

Folding@home (FAH) is a major scientific endeavor, but is also a kind of contest for some donors to see who can donate the most points. In order to keep a sense of fair competition, we asked donors to help us establish a list of rules, summarized on this FAQ page: http://folding.stanford.edu/English/FAQ-BestPractices . These rules are stated below to engender the spirit of competition in a way that is impartial for all donors. We thank everyone for their contributions and hope they will enjoy competing and donating to the project. Voir l'article complet

One physical machine (vsp09) is down, bringing down all of its related VM's (vsp09*). We're working on it and hopefully will be able to get it back up today, unless there's a more serious issue. UPDATE: The machine is now back up and the main CS (vsp09a) is running. We are keeping the other CS's down, since the other CS's are now obsolete and have been integrated into vsp09a. Voir l'article complet

For 10 years, we have rolled out Folding@home work units (WUs), Cores, and client software using a Quality Assurance (QA) protocol that involves several steps, including internal testing (int), closed beta testing (bet), open beta testing (adv), and full release (fah). The goal of this gradual rollout is to try to keep problematic WUs and software from getting released and to allow donors to have some choice in terms of how bleeding edge they’d like to be. However, this does mean that a great deal of work is done in closed testing, which has several disadvantages. First and foremost, all the work that beta testers, Forum Moderators, and the Pande Group does to QA WUs is never seen. This also means the rationale for releasing WUs in their current form is not broadly visible. And while entry to the team of donors working on closed beta testing was always available, that is a large bar to cross just to see what's going on. On the other hand, there are many upsides to closed testing however, including having a tight knit group of knowledgable donors giving useful feedback for strong QA of WUs. While there are pros and cons of closed testing, I've decided that it is a good time to push for much more transparency in Folding@home in general, including closed beta testing. So, from now on, closed beta testing (bet) forum will be open for all to see. However, in order to keep strong QA, only beta team members can write in this forum (but as always, membership is open to those who are interested and dedicated to testing WUs). My hope is that this will show all of the hard work that is done in testing WUs and will help answer questions about specific WUs that often come up. Also in this spirit, we have opened our v7 client bug tracker for read-only access so donors can see our progress with client development. There's a tremendous amount of activity that goes on behind the scenes and I'm excited to open that up so the hard work that's been going on for a decade can now be much more visible (and hopefully better understood and appreciated). Voir l'article complet