Posts by Cartoonman

1) Message boards : News : New NBody test searches (Message 55001) Posted 4 Jul 2012 by Cartoonman Post: It appears, based on reviewing the stderr outputs of all of the users that have seen errors, that the application fails when reaching Histogram number 37 Error reading histogram line 37: massPerParticle = 0.000100 Another variant: Could not load Ktm32.dll (1815): (null)Error reading histogram line 37: massPerParticle = 0.000100
2) Message boards : News : N-body screensaver available for testing (Message 54469) Posted 20 May 2012 by Cartoonman Post: @Alexone: I had the same issue. For me, i fixed it in the appinfo.xml file. What i did was search for the number 8 (as the app is defaulted to use up to 8 cores, but for some reason doesn't run UNLESS 8 cores are present) and replace that 8 with however many cores your CPU has/however many you want the app to use up. After that the app will run again ;)
3) Message boards : News : N-body screensaver available for testing (Message 54456) Posted 18 May 2012 by Cartoonman Post: ^ ok then... Nice screensaver, but I do have some suggestions for future builds: 1. Needs more continuity. Since the WU's that are available finish for my computer in a mere 30 seconds, the graphics can only run for... 30 seconds. After that, the screensaver just stops (or rather, just stops progressing and hangs). It still functions, but it does not continue over to the next WU. In fact, when you quit the screensaver to look at the graphics for the next one that is already running, the screensaver fails to load (with the error being that it cannot attach to a running process, being the application itself) until the next WU arrives and runs. Could there be a way for the screensaver to identify when the WU finishes, stay on, and then reattach to the next WU that runs? 2. Needs more... fluidity. When I watched your demo, the particle motion seemed rather fluid and smooth. In contrast, when I viewed the same from my end, it was quite jumpy.. or rather, it just updated whenever it felt like. IN fact, i dont think it updated per .001 Gyr (as it did in the demo). It just updated all over the place, and it was slow at updating. I did not notice a regular interval. is this something that can be fixed? it would look much better if it acted the way your demo had it. 3. a little thing, but the fact that you couldn't pause the screen from rotating annoyed me. could you add an option to enable and disable screen rotation? I would really like to see the particles move on their own instead of seeing it happen while flying around ;)
4) Message boards : News : testing a new search 'ps_test_1' (Message 49069) Posted 27 May 2011 by Cartoonman Post: ps_test_4's running smoothly on my 4850. validating well too.
5) Message boards : Number crunching : Question Please (Message 46651) Posted 20 Mar 2011 by Cartoonman Post: What ATI driver/CCC version do you have?
6) Message boards : Number crunching : hey quick question (Message 46621) Posted 18 Mar 2011 by Cartoonman Post: ... before i inquire upon how it is possible to choose the name admin for a username on a forum, allow me to answer your question. I am not entirely aware of how long seperation WU's run on my CPU, but nbody applications (the one you stated is a sepeation WU) run at ~1 hour in my Phenom II x2 550 @ 3.5 ghz. As for your moving completion time, from my experience, initial runs base their estimated time of completion on your BOINC CPU benchmark(automatically done by BOINC). After your first WU however, subsequent WU's downloaded and worked on base their estimated time of completion upon the completion time of the most recent WU submitted to the server. for example, if your WU took 12 hours to complete, the next WU's estimated time of completion will be around 12 hours. if that WU finishes in 11, the next WU downloaded will have an estimated time of 11 hours, and so on. Simply put, estimations are based upon the BOINC client, and the application itself. there isn't anything wrong with your CPU, as your clock time nearly matches your CPU time (think of CPU time as a measure of CPU efficacy using the amount of time the CPU utilized 100% of it's resources verses the actual time elapsed) Thus, your CPU has no issue regarding performance. by the way, the WU saying result inconclusive just means that it's waiting for another host to submit the same WU to compare to, to check for validity of data. It's basically like waiting for validation.
7) Message boards : Number crunching : Aaargh! Servers are out of new work!(2)" (Message 46604) Posted 18 Mar 2011 by Cartoonman Post: /\ Feeder back online.
8) Message boards : Number crunching : admin response very bad (Message 46603) Posted 18 Mar 2011 by Cartoonman Post: ... for what reason exactly? what possible reason is there to not continue this project? is that single WU causing a nuclear meltdown on your computer? is it impending a system-wide disaster? will it suddenly jump from the screen and try to take over the world? simply put, the admins here are quite busy, as our support server is currently getting some major fixes and changes. and what conaway implied in his cryptic post is that the Milkyway doesn't revolve around you, and we have plenty of maps to prove it. trust me. Copernicus's theory of geocentricism was disproven long ago. ;) Have some patience, we're working it out as best as we can. btw, to make things simpler: http://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=192257020
9) Message boards : Number crunching : Aaargh! Servers are out of new work!(2)" (Message 46596) Posted 17 Mar 2011 by Cartoonman Post: Feeder, along with a bunch of other things, aren't running. can't get new tasks. 3/17/2011 5:52:19 PM Milkyway@home Scheduler request completed: got 0 new tasks 3/17/2011 5:52:19 PM Milkyway@home Message from server: Server error: feeder not running http://milkyway.cs.rpi.edu/milkyway/server_status.php
10) Message boards : Number crunching : Server Issue Recommendations (Message 46498) Posted 7 Mar 2011 by Cartoonman Post: For me, i was just sick of F@H and all the problems with ATi applications. Their applications are so inefficient; a WU that takes minutes on a GT8800 will take hours on my HD4850, mainly because of poor optimizations in the brook code for the app. Then ATi support came along for BOINC, and guess which project offered the most PPD (or RAC for BOINCers)? Milkyway@home. For my rig, i get more RAC with MW than i do Collatz, and even more than DNETC and Primegrid. For Nvidia, i would definitely agree that other projects offer more RAC than MW, but in all, it's the science that counts. personally, i find mapping the milkyway more rewarding than trying to prove (or rather, hoping to disprove) a conjecture(collatz), or trying to break a RSA key(dnetc).
11) Message boards : Number crunching : Need specific instructions on how to optimize AMD Phenom for SSEa, and Milkyway@home for X64. (Message 46276) Posted 18 Feb 2011 by Cartoonman Post: I'm not entirely sure, on terms of 32 vs 64 bit performance regarding this project, but what i can tell you is that SSE's are instruction sets, not necessarily optimizations in themselves (although the instructions themselves can serve to execute an action much faster than without) I don't believe that our wu's would have any benefit from SSE 3 or 4/4a, as the instruction sets would have to correlate with what the application is trying to achieve, in order to see a noticeable change in WU completion. Just adding them won't optimize anything, unless instructions only found in sse3 or sse4/4a greatly speeds up a necessary calculation. Compared to SSE2, SSE3 and SSE4 are merely minor updates to the SSE instruction set, and thus don't have as much of an impact on speed as compared to with and without SSE2.
12) Message boards : Number crunching : Host with WAY too many tasks. (Message 45875) Posted 29 Jan 2011 by Cartoonman Post: then allow me to restate: Our WU's in milkyway are special. each WU is not independent, rather, they are part of an evolving system. If we increase cache, we won't get WU's back as quickly as they should be back to complete the system, and hopefully improve the system as a whole (which is also why the WU's run as fast as they do) if you hoard 50 Wu's, by the time the 50th wu gets done, it might not make much of a difference anymore, as the system has moved on. aka, you missed the boat. the reason we don't have quick deadlines to correspond to the need of a quick turnaround is because the BOINC manager panics seeing such a short deadline, and tries to run all milkyway WU's as high priority, taking away resources form other possible projects running on a host. in other words, we need the Wu's to come back completed as fast as possible. the longer a WU is in a host, the less chance it will benefit the project. btw, @ CTAPbIi: the idea of caches based on GPU is a very good idea (and would make sense, because an 8 core system running an ATI 3600 probablly won't finish all 48 tasks as quickly as that system with 1 core and 4 ATi 6850's.) however, i don't believe BOINC manager has the ability to see the GPU as a separate variable in terms of caching WU's just yet, correct me if i'm wrong. however, caches need to be kept modest (not 100 WU's each GPU) as i stated above.
13) Message boards : Number crunching : NBody's and Seperations (Message 45865) Posted 28 Jan 2011 by Cartoonman Post: sorry if it had been posted elsewhere, but what does NBody WU's and separation WU's do, and are nbody's dependent on separations (or vice versa)?
14) Message boards : Number crunching : Host with WAY too many tasks. (Message 45861) Posted 28 Jan 2011 by Cartoonman Post: ... i believe BOINC bases it's "high priority" on estimates of WU estimates of completion, correlated to deadlines for each WU, to see which WU has a higher priority. in Milkyway's case, estimates are based on the completion time of the most recently completed WU. btw, relating to the original topic, if you examine blox's "computing army" you notice that as you go down, times of last contact go back about 30 min each host, meaning that every 30 min, the computer reset's it's Host ID in BOINC, where milkyway sees as a new host connected to the same user. they're all the same computer, 1 computer, just seen at different times doing the same thing, being logged as different computers
15) Message boards : Number crunching : Questionable Crunchers List (Message 45860) Posted 28 Jan 2011 by Cartoonman Post: http://milkyway.cs.rpi.edu/milkyway/show_host_detail.php?hostid=214718 http://milkyway.cs.rpi.edu/milkyway/show_host_detail.php?hostid=219638 anonymous hosts that owns no co-processors, but finishes WU's in minutes (using anon apps as well). none of which seem to validate.
16) Message boards : Number crunching : Aaargh! Server out of new work! (Message 44869) Posted 10 Dec 2010 by Cartoonman Post: once again, no more work. Plan B: collatz. OOOH! Primegrid's got a new ATI app using CL. i gotta try this.
17) Message boards : Number crunching : Aaargh! Server out of new work! (Message 41381) Posted 10 Aug 2010 by Cartoonman Post: hmm, i got some WU's, assimilation seems to be up and running. have to wait though. AFAICS, there are a small bunch ready to send.
18) Message boards : Number crunching : Aaargh! Server out of new work! (Message 41357) Posted 10 Aug 2010 by Cartoonman Post: .. well, no new Wu's again. just finished my batch now... i was wondering why there was so many Wu's waiting to report...