 |
| [ARS]odessit 2002-07-25 20:16:33 | HI all, I've found this DC project on http://www.aspenleaf.com/distributed/ and interested in it. From a newbe prespective I did not find some of the answers in FAQ, like Which CPU is the fastest? Current state of optimisations (possibility of 3DNow, MMX, SSE, SSE2 optimisations) Effect of L2 and L3 cache (speed and size) and Effect of RAM (throughput and latency) I also have some sugestions (haha, silly me) based on my previous and current experiences with DC projects. Biggest attraction to any DC project is stats system based on teams (will bring big guns into play, get ready to get fat pipe) Very robust client is a must. Best examples are Prime95, RC5-64(best client) and ECCp-109 Different free OSes must be fully supported. Namely Linux. Easy benchmarking would help a lot to fully optimise the client as well as the % done output in a window without graphics. Just look at the most sucsessfull projects out there and visit forums of the best DC teams for feedback. ARS Technica HardOCP Anandtech Dutch Power Cows (dunno the link, but they are major player in RC5 and some other projects) All you need is two major forums to join and you've got yourself a frenzy over the 1st place in a project. Prime95 team "Team Prime Rib" of ARStechnica is the prime (no pun intended) example. From the birth of the team, and very late start at the last position, this team inched up to a first place in under a year. Many members contributed their own $ to the project to build farms of computers spesifically for a project of their choice. See "Monster Farms" thread on ARStechnica including me ("measy" 4.97 GHz devoted to P95)  Just some thoughts for a discussion. If this has been discussed already, pardon my silly talk Odessit (ARStechnica.com) |
| scottsaxman 2002-07-26 12:48:19 | Odessit, Glad you stopped by! I also came here after visiting Aspenleaf's site. I don't pretend to know everything that goes on here at this project site (I'm not Stephen Brooks!), but here's what I can tell so far. The client isn't optimised for any particular processor, but like most other projects, it runs a little faster on AMD processors than on Pentiums. I don't think boosting the memory would substantially affect the client, as it doesn't seem to use all that much memory. W2K task manager reports about 4MB used by the client. Stats here aren't updated on an overly strict schedule, because apparently the computer that takes the data and calculates the stats isn't always on. Teams have been discussed a little, but I guess I haven't seen that capability yet. The client seems very stable, from my experience. It starts, runs, shuts down without so much as a hiccup. All that being said, I don't know that it is currently nearly as refined or diversified as many of the bigger, perhaps corporate, projects. Maybe it isn't to that point where thousands will join because of all the cool features and progress display tools. However, the science behind it is very interesting, and could prove very useful in the future. Further, I don't know if anyone here has the skill and time to port the client for all the different systems, though I have read about people working on a linux client. I hope that this information doesn't deter you from running the client, but maybe will get some more techie types involved to make it better. Hope to see you around, Scott PS - I hope this does start a good conversation! |
| Stephen Brooks 2002-07-27 10:23:31 | quote: Well AMD appears to be faster than Intel (although that's old news for anyone who's tried plotting fractals on equal-clockspeed processors of both types and seen the difference!). Further down in this forum there's a "GHz benchmarking" thread where we figured out that the current AMDs give about 45% more juice per clockcycle with this project. There are several ways in which this project differs from others that are currently around (and this may go some way to answering why certain things are not 'supported'). A lot of DC projects are 'brute force' search efforts, in which computers methodically and exhaustively search a very large dataspace. This can take years to do, so while the calculation itself stays essentially the same, the authors of the program can spend much time porting it, optimising it, tweaking the code and adding features to streamline the user's experience. This project is not 'exhaustive' - it uses an intelligent algorithm (OK, well an algorithm at least - it's not _that_ bright  ) to try designs based on previous ones in that user's results.dat file. Then after many users have explored different ascending-efficiency paths in the design space, I go around picking out the best results from different people and produce a 'seed' file that users can then download so that they benefit from the results of others.In previous runs, the optimiser has taken about 2 months to start levellng off and approaching the 'best' design quite closely (as far as I can tell). Then once we've found one optimal design, we can go onto simulating entirely new components of the accelerator. Version 3.x only simulated the solenoids (cylinder things in the 3D view), but 4.x has included a new component called the chicane. Later versions will simulate and optimise still different things, but I'm still working on the engine for making the program general enough to do this. I suppose what I'm trying to say is that while you are running this, I am still in an active research environment with people every now and then saying "Could you try this new magnet data?" or "What if we put a linear accelerator on the end?", so the program is continually being developed in that way, leaving less time for me to optimise or squeeze the last 20% speed out of the program. In some cases, optimising the code would be at odds with its future flexibility, and in those cases speed has to take second place to usefulness. Having said this, I increased the speed by 6% in a recent version (I think 4.13) without de-generalising the code. --[Biggest attraction to any DC project is stats system based on teams (will bring big guns into play, get ready to get fat pipe)]-- This has been suggested a couple of times before - it is feasible for me to put team stats in - in fact I think I could do this with a PHP script without rewriting any of the results-database code back here! I'll think about it some more. In some ways I don't need 200`000 people running this - 200 seems to be about fast enough and sometimes I feel that adding too many more people would produce more problems than benefits. However, the new version 4.2 that's just come out is designed to be a challenging optimisation and as such it will take advantage of having a large amount of CPU power. I'm giving the program a vast space to designs to explore (137 parameters!) and seeing what you all come up with... --[Very robust client is a must. Best examples are Prime95, RC5-64(best client) and ECCp-109]-- It seems that some people have endless trouble with Muon1 and others run it without any trouble. Admittedly I sometimes upload a version with a memory leak or something, but I usually fix those! This goes back to what I said above about the code always being redesigned to do new things - it's difficult to keep it rock-stable, although I do my best. --[Different free OSes must be fully supported. Namely Linux.]-- Someone said they'd done a Linux port, although I haven't seen it. One thing I could do is try to get a version of the source that compiles as a commandline C program, and as such would be fairly portable. "As every 11-year-old kid knows, if you concentrate enough Van-der-Graff generators and expensive special effects in one place, you create a spiral space-time whirly thing, AND an interesting plotline" |
| Bluumi [SwissTeam.NET] 2002-07-29 14:27:13 | Stephen, ONE of the "Big" things in your Project are YOU, and the change... If the Muon project go so lonley like RC5-64 or a Prime, where all day the same run, its nothing for me.... On the other hand... i don't like Projects like DistributedFolding where the Client need a update every week  You do a good job, i want say. Most of the bugs you fixed fast. And some time all results a bad, but we have our stats Happy working and crunching cya Bluumi |
| Michael H.W. Weber 2002-07-30 15:59:16 | Hi Stephen, I have just started this project and one thing is for sure - the graphical version is the most entertainig dc client I have ever seen. All the best, Michael. Folding@Home / Genome@Home team Germany, supported by www.Rechenkraft.net Now participating with Rechenkraft.de in CASP5 by supporting www.distributedfolding.org. -------------------------------------------------------------- Proteins are Nanomachines or Nanomachine Building-Blocks. Examples: The Ribosome, RNA-Polymerase Holoenzyme. -------------------------------------------------------------- |
| bradsercombe 2002-08-01 18:36:20 | The reason I'm participating in this is that SETI has appeal but all that work might never find a result (let's face it, not finding an ET signal is not a conclusive answer). Folding is great- not for profit and a result is being produced which will benefit society, but downlaoding many clients and the associated info costs my company $$ (another reason why I ditched SETI- I was downloading 1Gb a month of work units which could have been compressed to be half their size). I've got an office full of 40-50 computers that probably only use 5% of CPU on average and are mostly 1Ghz pentiums or better, I'm only running Muon on about 5 of them. But as Stephen says, he doesn't need oodles of power so I don't feel compelled to install Muon as a service on 50 odd computers. The three versions of muon have I've used been stable running 2 instances on Dual 1Ghz servers for days on end. Compared with many of the other DC projects who have many software developers, more resources and bandwidth I can't find any fault with the design, implementation and support afforded to Muon project members. What amazes me is that Stephen has time to organise all this, be doing heaven only knows what else (day job, and/or leisure) and still have time to be a strong presence on these forums. |
| kpearson 2002-08-12 16:49:29 | quote: Hi Stephen, I would really like to see a command-line version of the source code: then I could port it to Solaris, as I did with the version 3 client. I have not been successful with porting the Windows source code (minus the graphical bits) to Solaris so far. |
| GP500 2002-08-12 23:55:16 | quote: This is true, and that is the reason I put that feature in. I also expect some of the workunits later in this project to take much longer (hours), so an auto-save is necessary. quote: I don't understand what why you think 1000 seconds would be better, because it would mean you'd potentially lose more work on restarting the program. [This message was edited by Stephen Brooks on 2002-Aug-13 at 11:18.] |
| Pascal 2002-08-13 02:08:47 | @GP500: Does it really make sense to set 180 seconds? Is there anyone with a computer that produces a result with a top yield within 180 secs? I would rather go further and say something like 1000 secs is ok, better would be to have large and small work units, but thats not possible at this project. If you loose 180 secs it's equal if your computer is fast or not.  ___________________________ 1: Athlon TB-C, 1.2 GC/s, 256 MB DDR-RAM, Erazor x², ADSL-Flatrate, NIC Intel, Win 98 SE Mainboard MSI-6380 Rev. 1 2: Pentium III, 600 MC/s, 256 MB RAM, NIC Intel, Win 98 SE |
| [SG] DOA 2002-08-13 04:19:34 | Anothher thing: Would it be - or is it even and I just did not founf it - possible to implement another line into your config.txt which allows you to set the data limit for autotransfer? Or even better, gives you the possibility to set a time frame? Gerald *curious* |
| Stephen Brooks 2002-08-13 04:20:04 | Erm... I just pressed "edit" instead of "reply" to GP500's post, so my reply to him ended up overwriting his post. "As every 11-year-old kid knows, if you concentrate enough Van-der-Graff generators and expensive special effects in one place, you create a spiral space-time whirly thing, AND an interesting plotline" |
| Stephen Brooks 2002-08-13 04:21:47 | quote: I prefer not to let users control that because the size of the results-file when sent is useful for controlling the load on the server in some ways. If you want to upload your results at a particular time and it has not auto-sent yet, you can run "manualsend.exe", which will force a send to occur. "As every 11-year-old kid knows, if you concentrate enough Van-der-Graff generators and expensive special effects in one place, you create a spiral space-time whirly thing, AND an interesting plotline" |
| GP500 2002-08-13 05:22:12 | quote: i like this kind reply, now i don't have to search for it T E A M: Grutte Pier [Wa Oars] / Fryslân wer mei Kening \ |
| [SG] DOA 2002-08-13 06:08:23 | [QUOTE]Originally posted by Stephen Brooks: I prefer not to let users control that because the size of the results-file when sent is useful for controlling the load on the server in some ways. If you want to upload your results at a particular time and it has not auto-sent yet, you can run "manualsend.exe", which will force a send to occur. Okay, can understand that.  And thx for the fast answer...And I guess a timed sending (like from 11 pm to 1 am) won't be possible too because of varying result-file size? My problem's just that I'm currently switching a few *gg* of my slower boxen off S@H and onto your project. Here on work it's not a real problem, my testing lab's on 24/7. But at home it's a bit different. Still got channeled ISDN dialup there and I'd like to prevent myself hopping from machine to machine each eve performing autosends... So... Is there an upper limit for the result file? In size, age or something? If not it could simply sit and be emptied once a week or so. And how frequently does the automtic uploader try to get them results up when it left the 100 KByte border behind? Once an hour? Every 10 minutes? Once a day...? would it be sufficient to be online every day for a two hours period or so to let the programm check it and perform the upload? Thanx, Gerald |
| [SG] DOA 2002-08-13 07:14:59 | Okay, a part of my question have been gone... Sometimes it IS indeed more clever to read the part about submitting first and theh shoot questions... *g* So the programme tries to connect after every finished result wenn it result-file exceeded 100 KByte. Guess that mirror's small enough.  Anyway, your sight on the timed option stillinterests me. And a chummer of mine had another question: Can you connect via a proxy or is there a proxy command? I said no, out of my "knowledge", but... ya know... ;D And? Is there a proxy functionality? Gerald |
| Stephen Brooks 2002-08-13 07:42:19 | That depends on whether your proxy allows FTP connections to go through it. As for only sending while online - most dialup users should find the program will connect at some stage while they are on the internet. When autosend is turned off in the config.txt file, the results.txt will keep getting bigger (over 100K  and you can manualsend whenever is convenient. Once a week is OK."As every 11-year-old kid knows, if you concentrate enough Van-der-Graff generators and expensive special effects in one place, you create a spiral space-time whirly thing, AND an interesting plotline" |
| [SG] DOA 2002-08-13 07:46:19 | Thanks. were I correct saying Proxying won't work...? |
| Stephen Brooks 2002-08-13 12:41:27 | I've never used a proxy, so can't be of much help there. |
| [SG] DOA 2002-08-13 21:53:23 | Okay, thanx anyway. |
| dudi 2002-08-30 16:27:33 | @Stephen Brooks To support a ftp-proxy with ftp.exe is very simple. You simply have to modify the first 2 lines written into the file scripts.ftp by your sendresults.c to: open <proxyaddress> <proxyport> <username@destinationFTP> without proxy (now) they are: open <destinationFTP> <username> What about an option to choose a FTP proxy and FTP-Port in your Config.txt? I think to do this should be pssible during less than one hour of effective work. Yours sincerely Juergen |
| Stephen Brooks 2002-09-01 15:15:27 | Thanks for the FTP idea. I could certainly implement that in a future version - maybe the next one, or maybe the one after that. "As every 11-year-old kid knows, if you concentrate enough Van-der-Graff generators and expensive special effects in one place, you create a spiral space-time whirly thing, AND an interesting plotline" |
