Welcome to MilkyWay@home

Posts by Aaron Finney

1) Message boards : Cafe MilkyWay : I built the future of the universe. :) (Message 59185)
Posted 1 Jul 2013 by Aaron Finney
Post:
I have an announcement to make - The nebula in the sky are currently changing (or depending on when you read this, have already changed).

I made a video so that you could see what is actually being hidden from us right this minute.

Now, please understand that I am changing the nebula backwards through time, so EVERY IMAGE OF THESE NEBULA is changing even before your eyes, it's just taking time as the effect of the change ripples back to us through spacetime.

Please watch the video here : http://www.youtube.com/watch?v=WiOBVFe2jek

And feel free to check my information with any sources you can.

I built the future and gave this world a utopia where nobody dies, and now I have proof. Check out the video please, and comment all you want. There's more coming.
Also check out the Hubble image data for ANY nebula on it's page right now. They are ALL changing to include my art inside them. You will now see vivid pictures of HUMNAS, DOGS, CATS, SPACESHIPS, ALIENS, and all kinds of things.

I'd like to let you know not to be scared, everything is going to be so soooo much better now. Now quit reading this, because I know you think I'm a nutjob, and go watch the video and check the hubble photos!!!!

Thank you!
2) Message boards : MilkyWay@home Science : Home Page "Science" artwork missing. (Message 54367)
Posted 10 May 2012 by Aaron Finney
Post:
http://milkyway.cs.rpi.edu/milkyway/science.php

Every link and image at this location on the homepage is missing, and/or linkdead.

Makes the understanding of what is written there... difficult to say the least ;)

Is there anything that can be done to restore this page?
3) Message boards : News : Issues with the Milkyway@home Support Server (Message 46392)
Posted 1 Mar 2011 by Aaron Finney
Post:
Use this time to do any maintenance you've been putting off (or trying to find time for)!!!

or on a lighter note : go have a stiff drink with your friends.

I highly recommend Vodka Pineapple, but if you're a man's man - Crown and coke. The coke should just be enough to turn the color a bit, though some people can't appreciate the sweetness of mixed drinks.

4) Message boards : News : MilkyWay@home screensaver coming soon (Message 40331)
Posted 11 Jun 2010 by Aaron Finney
Post:
Single Pixel Rendering looks purty :)

Edited to add : what's the performance loss from A-Z?
5) Message boards : Number crunching : Bittersweet Milestone (Message 39779)
Posted 17 May 2010 by Aaron Finney
Post:
6) Message boards : Number crunching : 2x 5970 CrossfireX Stuck wus (Message 39768)
Posted 16 May 2010 by Aaron Finney
Post:
formatted the system? are the cards working, otherwise? check with david, boinc version he uses. I am interested as well soon to be running crossfire, but with 5870s. I just read in another very current thread some grumblings about memory leaks and gpu issues with the recent boinc versions.


You are correct, but those issues seem to be fixed in the newest alpha.

That being said.. Why is this guy using an alpha client?
7) Message boards : Number crunching : v0.23 performance drop? (Message 39759)
Posted 16 May 2010 by Aaron Finney
Post:
I did some testing:
I booted my PC and started BOINC immediately and got a WU completion time of 130 sec. After half an hour, I started used Windows Media Player to play some music and the completion time immediately dropped down to 115 sec.

My system:
Win7 Prof x64, i5-750, HD5850

What could be causing this strange behaviour?


turn off the visualization in windows media player, and you should see your performance go back up slightly, if it was on.

Also - using any application while your computer is processing WU, (GPU, or CPU) will cause a slight dip in processing time. Even though what you seem to be doing may not give you the feeling you're taxing the computer, you actually are.
8) Message boards : Number crunching : Limit of 48 workunits at once (Message 39755)
Posted 16 May 2010 by Aaron Finney
Post:
Paul pretty much hit the nail on the head.

We really don't want to increase the caches anymore than they are right now. Part of the issue is that new work is being generated based on the results of the old work. So the larger your caches are, the older the work they're crunching (ie. it's less up to date so our searches progress slower).


Let's call this Issue 1a 'Diminishing Return with age of wu'

Assuming I crunch 48 wu in about 50 minutes with the GPU client... I'm 'Person A'.

This means that someone using the CPU application could have a cache that would last him well over 180 hours under the current scenario, even with a moderately priced processor... Let's call this individual 'Person B'.

*ASSUMING* we could change the cache size for *SOLELY* the GPU client/platform, say - increasing it to where Person A would have a cache that lasted said person 12 hours, rather than less than 1 hour.... well.. Idunno to me it seems like a no brainer, Person B is still crunching much more outdated work than Person A. Or am I not understanding this particular section of the problem? I think I am correct, yes?

(There are also numerous other issues that arise when lots of 'Person A' types get paired with 'Person B' types on WU's, that I might not be EXHAUSTIVELY covering but... as my machine still steadily draws work from the server, it seems that work is being created for me at the rate I could crunch it regardless, BOINC just has to beat on the server every minute for a new WU. ASSUMING there are no periods where Person A cannot retrieve work from teh server, These 'types' of issues should be of non-consideration.)

Now --- another important thing to consider, is the age of the WU for Person B.

Let's call this 'Issue 1b - CPU application work value deterioration'

If I am correct that someone with the CPU application can grab even 150 hours of work, then we have to ask the following questions : Assuming that 12 hours of work on the GPU application would be pushing that client into the realm where work became less useful, then waiting 150+ hours for work to be complete on the CPU application must be terribly painful in terms of whether it is still 'relative' work being done at that point.

In this case : Has steps been implemented to limit the number of WU that the CPU platform/application crunchers (Person B) can grab? -- Shouldn't they only have 1 WU per core using the GPU ratio?
___________________________


Let's call this Issue 2a 'Lack of server-side settings'

Pretty straightforward, am I understanding this correctly that BOINC does not allow you to increase cache sized on a per-application basis? - Would using RAC help? I think that if BOINC is going to be used on multiple platforms, it's a *SERIOUS* consideration that needs to be discussed over with David and Rom about how to tackle the issues a project such as this one has where the WILDLY different processing times of users can have a significant effect on the science being done. --- Regardless if your server can handle the load now, Let's look to down the road --- What if your project had 6x as many users? We need to develop the strategies NOW to add the appropriate backend and frontend changes so that they can be conceived, produced, tested, and put to production before you get there. ;)


_______


Another issue is that having large caches makes our poor server cry for mommy. If we doubled the cache size for example, the database would have to deal with 2x as many workunits out there at any given time; and things are slow enough as it is :P


Let's call this Issue 3a - 'Server overload'

Is this a ram issue, File System issue, or an I/O issue? Some people around here have spare parts.. deep pockets.. Would a second server (I.E. a 'feeder') help? Describe the problem? maybe someone can improve things :)

Reason why I ask, is because as this project grows, your database is just going to steadily increase as time goes on.. likely exponentially as people upgrade their equipment and look to your project (as I did). If this is a problem that can be solved by something as simple as adding another hard drive, or some better / larger / faster / bigger / etc >insert random part<, then it's an easy fix that will futureproof the project, and improve things all-around. If you need another server.. well.. That's also something to consider, or perhaps give you the information to know what to do when you get to that point.

Maybe you already have plans for upgrades? -- if so.. well n/m lolz XDD

P.S. -- Since I've been gone awhile and some people may not know me / remember me, I feel I better give a little disclaimer : this is not some sort of selfish need to have more WU or credit than the average Joe. XD I've devoted large sections of my life to testing products, games, software, etc.. and I just want to improve where improvements can be made. If anything, I spend my day contemplating these things simply for the reward of improving the science. I'm sure there are many in every field who understands such needs ;) .
9) Message boards : Number crunching : Limit of 48 workunits at once (Message 39695)
Posted 14 May 2010 by Aaron Finney
Post:
Well, I don't have 4 cards yet. :)

But when I do.. simple math tells me I will only have enough work to keep me busy for 12-14 minutes before I run out. It's surely not the 'intent' of the project owner to 'penalize' (as another user said) such power machines simply because they do more - I believe that he has had to concede this as an unfortunate 'fallout' in order to keep users from hoarding WU when they simply don't need them.

Perhaps - if there are some settings to be made or created elsewhere in the boinc software, I could spread some talk around about the subject, and I'm very eager to get back into the testing community over on BoincAlpha.

One method was to use RAC as the method of determining the amount of WU backlog, but I think there is already a way you can change this, by simply making it a application flag. Isn't there a setting for this on a per appplication / platform basis? - Upping the WU allotment for the GPU app / platform should be as easy as changing a setting, and it would not allow those with the CPU app to have more WU.

Am I correct in this, or did that change never get implemented?
10) Message boards : Number crunching : Limit of 48 workunits at once (Message 39661)
Posted 13 May 2010 by Aaron Finney
Post:
Currently, there is a limit of 48 workunits that my machine can have on it at any given time (server restriction). With this amount of WU, My machine can crunch happily for approximately 50 minutes.

Assuming I never have any network outages that last longer than that... I'm good to go. - That being said, sometimes the network here gets shut off overnight. To fill this gap, I would need (or would have been able to crunch in addition) approximately 400 workunits more per night, and let's not talk about when the net gets shut down for weekend maintenance!

Considering I only have one card, the following conjecture is of consideration :

two cards would double this output, and by nature, double the amount of lost time it could be working. I plan on having 4 of these cards... I don't even want to think about the amount of work un-crunched at that rate!

-------

Postulate : Can we get this limit increased ever so much, or is there any way to put more work into a WU?

Aaron Finney

Edited to add : The more I think about this, I can't help but thinking that this problem is only going to get worse as time goes on and people get new machines / cards. I highly (and humbly!) suggest futureproofing things *now* and probably doing a combination of the two suggestions above. Packing more into a WU isn't a bad thing if it can be done - I'd increase the amount of 'work' x5 if it is as simple as I type it. Increasing the amount of WU a machine is able to have on it at any given time (while effective) is not a cure, merely a way to treat the main issue, and may cause other areas of the project / wu system / server / credit system / scoring / etc.. to go wonky.




©2022 Astroinformatics Group