Printable View
Guys, ever heard of "update manually" ? :p: Mine don't update until I say to update... and that usually means a week delay :lol2:
I was afraid I'd wake up this morning to "EUE limit reached" but I did not! Yay. Look at the damage 5801 did to the team yesterday, ouch! I didn't get even 8k yesterday, most people had a drop. Except RR, somehow he avoided most of the pain!
Don't try & tease me Rise...Quote:
Originally Posted by Rise
No its not case closed by any means.Quote:
Originally Posted by Marvin_The_Martian
NO it isn't a Hack. At all. They aren't 'ghost' clients. They are perfectly working seperate folders.
Lets read what the link said.... TOW said its a 'recommendation'. Nothing about breaking rules. NOTHING. It even fans me further that your using words previously like 'breaking' rules when your link now clearly says that its just a recommendation.
SAY-IT-WITH-ME "PandeGroup's general recommendation"
This is xtremesystems. It would be different if we are all running a bunch of Durons, and P4's at stock.
And no. I'm NOT out of line.
I'm shocked at the obvious jealousy in Yoda-Goose... rather than embracing the challenge to boost his output to match WFO's insanely high six-figure levels, he resorts to whining and calling penalties. I think we should call the salvation army and see if they can donate some additional hardware for Yoda-Goose to boost his measly output...Quote:
Originally Posted by DAK1640
Quote:
Originally Posted by Marvin_The_Martian
Live with the way I do it
The PC will be off at night because I want to sleep
And don't try to change it or I'll audit you off :fart:
And it's Whisky not Whiskey for the love of the higher power
Ok I see I didn't link you to the right place then..Quote:
Originally Posted by [XC] riptide
- 1. Caching wu's :
http://fahwiki.net/index.php/How_Imp...e_Deadlines%3F
What this treis to explain, is that turn around times are the key for the whole project, it's all about turnaround time per wu.- 2. Dual vs Single SMP:
I already said it's abit of a mute point here on this forum as I myself said if I could clock high enough I would run dual smp. You can ask Kup for the link to the discussion we had about it on redline, where we compared turnaround times at various clocks and single vs dual smp instances and where I came to the conclussion that 3.6g is the point where running dual instances indeed only help the project.
- 3. Being out of line:
I said you where out of line because you told me to stuff it, I still think you are out off line saying that. If you want to properly discuss the pro's and con's thay absolutely ok with me, just keep it civil please. You're fully entiteld to your own views, but so am I. We can only try to discuss where our diffrent point of view comes from, and maybe try to get the other side to see things the same way.
Sorry for the list format, didn't want to cut up your post and want to make sure I'm not confusing anyone.
@Kondik Noooo don't audit me, they might seize my assests if they do :rofl: And sorry, it's Whiskey like you say, guess I just don't drink enough :shrug:
Everyone welcome Willmaker to team Whiskey...
I'm naming yesterday October 28, 2008 "THE PERFECT STORM OF 5801"...
http://www.scootplace.net/fah/XS/halloween/ (hit refresh if you need to, I just uploaded new files).
http://www.scootplace.net/fah/XS/hal..._m7a640631.jpg
http://www.scootplace.net/fah/XS/hal...m_m9865caf.jpg
Welcome Willmaker :wave:
Thanks for helping Whiskey out, we're coming up short :(
:welcome: Willmaker!!! :wave:
:wtf: RR! Having all those SMPs helped you weather the storm yesterday. This race looks to be much closer than I thought it would be. :eek: WFO rummages through closet looking for more PC parts. Hmmm... everything need but a cpu. :p:
Edit: Love the graphics Mike.:up:
Well put coo-coo-clocker...nonetheless; penalties still apply. I'm sure WFO understands...
Stuff it wasn't addressed to you to stuff 'something'. Clearly 'stuff it' has less conotations where I live than where you live.Quote:
Originally Posted by Marvin_The_Martian
And also about the caching. For caching to be a real concern we would see the entire project backlogged waiting for WU's to finish. There is no instance that I can remember this happening. For the project to be fundamentally limited to serial processing, this WOULD happen. Thats why everyone still get WU's when the servers are working. Everyone.
And furthermore, we wouldn't be talking about caching if the servers had a 100% uptime record. Or near to it. The onnus is on them to make that happen. Until then... caching is still going to happen.
I took it diffrent then you ment it :)Quote:
Originally Posted by [XC] riptide
I agree there is a requirement on their part as well, and I already said I understand why people would use it. But I'm still under the opinion that it's against policy and that wiki link describes best why. You are introducing lag into the system, and that does deminish the scientific worth.
I'm not sure you understand though, but the project is depending on serial processing, the fact that usually the servers have enough wu's non the less, is because they provide us with allot of diffrent project ranges. Each range of projects is supposed to be processed in a certain order, and when you take let's say 5 wu's at a time, those 4 wu's you're not crunching right away will also not be given out to other participants ( this is the lagg you're introducing ). The same goes with EUE's ect, if those projects where bad, if you crunched them right away they would eue and their collection/assignment servers will get notified of the eue and when a certain threshold is met the PG can take those offline making sure no other cycles are waisted on bad work units.
Offcourse, you can say it's their responcibility to do QA and don't let cases like the smp 5801 wu get out in the wild, I agree but that's not realistic to count on all the time.
I'm not going to tell you not to cache, I know you got two good reasons for it. Your connection, and the down time of the servers. Both aspects are partially solved ( at your side ) when you cache wu's.
But I hope you will allow me to point to why it actually does not help in the general picture. Think of it this way, what if the entire XS team suddenly would start caching gpu wu's. and let's spice it up, cache those wu's we know give the best ppd? Because you know I can make that happen, and I explained you why I won't do it. It will introduce a lag into the system, and it will make it very hard for the PG to determine what their wu's are doing in the wild. Isolated cases like yours do not cause great harm, but on a larger scale, caching wu's will certainly hurt the project more then it helps.
I know all about cherry picking WU's. IN fact I actually came up with it on a thought excercise independantly myself and IIRC double checked my thinking with you. And I know about the history as it applies to this team from far off times. And no I wouldn't advocate it just here.Quote:
Originally Posted by Marvin_The_Martian
Caching WU's is on a diff level altogether. My case in the wild... if applied to everyone and the reason everyone gave was becasue of server down time, I would expect that we'd see no more server downtime again, if it was that critical to them.
I currently have 5 WU's cached. I didn't cache anything recently until now infact. (New system install from last time.. since I made the guide etc) And the only reason I did cache now was because of yesterdays server problem. And I will continue to keep caches until somebody demonstrates to me that server downtime is a thing of the past.
I got burned before... I won't get burned by server down again... (unless its over 12 hours).
Yeah you did, not trying to take credit for the idea of getting cherry wu's I think that idea is older then both of us :)Quote:
Originally Posted by [XC] riptide
I got no problem with you caching wu's. My problem was that you didn't seem to be willing to accept it's not per se a good thing, that's all I wanted to say on the matter. Maybe I should have worded it better on the first try though, since it seems my later posts have had more effect then the first :(
Court adjurned?
If turn around time is really that important, the servers should never be down, there should never be and bad WUs and all clients should work properly. What about all the slower CPUs? Should they be banned also? What about all the people running slow x2 cpus ban them? I can run the SMP on HT P4 and make the deadlines, I have done it before. Of course they want the results as soon possible but hey what are the deadlines for? I can do 2 SMPs with 80% time to spare before the deadline. What about the video cards? Ban all that are not 280 GTX? They are the fastest. I think this is exactly why there are dealines, if you make it in time fine, Stanford wants the work, some is faster some is slower...
You been part of the discussion(s) afaik on the folding forums about this issue so you should know they are thinking about putting a ppd bonus on quick return times instead of deadlines.Quote:
Originally Posted by road-runner
You're right with saying some hw is faster then others, and all contributions are appriciated, but that doesn't invalidate anything I'm linking to or describing. Turnaround time is key for the project, their current award system is flawed in the way it works, as high ppd and the most scientific value are not 100% teid together as it should ideally be.
Bingo! Causality. If they fix it... they will get it. Until they do. They get dual SMP's and the likes of me caching. And maybe others.Quote:
Originally Posted by Marvin_The_Martian
Yea, yea, yea they been talking about that for years, we will award bonus points for quick turn around etc. They came up with a passkey to keep track, etc. I have been turning them around with Linux since SMP came out and have not seen nothing yet. I have been turning them around for almost 6 years and I have not seen any bonuses and always run pretty up to date hardware, when I see it I will believe it and not until. I could crank up at least 10-478 HT P4s that will make the deadline, would they rather me run those? When they buy my hardware and pay my electric bills I will do exactly what they say...Quote:
Originally Posted by Marvin_The_Martian
that link at fah wiki explains it pretty good. imo it doesn't apply to any of us.. we run fast hardware so dual smp has absolutely zero bearing on this subject when you run on a intel quad... any intel quad can crank out smp wu's fast enough on dual smp it just doesn't matter.. a turn around of 30hrs compared to 20 hrs means squat on stanford's time frame... 10hrs is not a big enough differnce to warrant saying single smp is better for science than dual smp because of delayed turn ins..
that link marvin posted from fahwiki really makes this whole argument a non issue, because it doesn't apply to the hardware we're using as an example.
http://fahwiki.net/index.php/How_Imp...e_Deadlines%3F
we turnin wu's so fast it has absolutely no bearing on a turn in gap... the 10 hr difference between running dual smp and single smp is so miniscule it doesn't even pertain to that fahwiki statement. in fact we are turning in many more wu's by running dual smp's, that it only serves to burn through the projects faster in the end. the 10hr difference is not making anyone wait on project completion.. the fact that we turnin more wu's with dual smp cpu cycles does mean we help reach the end of the project faster.Quote:
How Important are Deadlines?
When you're holding a WU but not working on it, the next person is waiting for you to finish. If everybody takes a WU and only works on it half of the time, then the total simulation will take twice as long to complete. If that process takes (say) 6 months, and because people do not return the results quickly, the process isn't completed for a year or more, the researcher may have moved on to another project or graduated or whatever.
Just because your hardware is fast enough to finish a WU in a very small fraction of the deadline, you shouldn't delay returning the result until near the deadline. The deadlines are there just to take care of WUs that get lost, not to give you an indication of when the project needs the results.
You both got me there fair and square.
I hope both of you don't mind if I keep holding on to the believe science is more important then any reward system how flawd it may be? Because, that's what I am here for, not for the points/reward system. So when I talk about what's good and not good, I'm usually talking about the science and not the points.
Edit:
Mike you posted before I quick replied.
I think you're wrong with thinking that with faster hardware the gaps are not as important. Their just as important, for a simple reason. The biggest improvements the smp client makes is it's speed, allowing a a longer time slice to be simulated with quiker return times. VP has stated already that with current hw and clients, the whole first couple of years of research could now be done in months. But does that mean we should be happy about being so much quicker and not care anymore about the gaps? The principle is still the same, gaps lower the performance of the project, we shouldn't point towards it being so much quicker already.
That would be the same as saying we shouldn't press Intel/Amd to make us faster chips since the current one's are already blazing fast.
I feel you're missing the point, what I would love to see in everyone is the believe in the cause we're folding for, and to realize that this cause is better served by quick return times then more ppd untill they fix this long existing issue where ppd and scientific results unbalanced.
WORD!!! ^^^^Quote:
Originally Posted by road-runner
I don't mind at all Marvin. But when you talk about not following rules (for no good reason)... thats going to get a bunch of us riled up.Quote:
Originally Posted by Marvin_The_Martian
3xQ6600@3.33ghz
Which is better for project 2665?
These projects study how influenza virus recognizes and infects cells. We are developing new simulation methods to better understand these processes.
A. dual smp = 144 wu's per month.
B. single smp = 108 wu's per month.
forget the points.. by the monthly numbers above...
how many months will the project take?
1. with single smp? 108wu/month
2. with dual smp? 144wu/month
it all boils down to simple math... the faster they get through the results, the faster the project gets done.
Easy does it fellas ;) :)
I see it the faster you turn them in the better, but we are all turning the units in long before the deadlines approach (assuming the servers stay up :rolleyes:). I don't know for sure, but dual SMPs on an overclocked quad probably takes approximately the same time as a single SMP on a stock quad. And since they revolve around mostly stock hardware (considering that is what many people run, and I think they even mentioned they tend to prefer stock as it is more stable, though they have no problem with overclocked hardware as long as it is stable) I don't see dual SMP on our overclocked hardware as an issue really.
I'm a single SMP user myself. Never felt like dealing with keeping two on one system in line, sometimes can be a lot of work :lol2: Now I couldn't run dual SMP anyway as I have the SMP going with the ATI GPU client, which does take more CPU power than the nvidia client does.
Ok last try then this thread can continue to be about the contest and not this seemingly endless discussion.
Mike you're thinking more wu's = better. Thats wrong. It's not the number of wu's you do, it's doing each one you as quick as you can. In total you will do less, but the one's you do deliver are worth more. Not in points, but for science. I treid to explain this now 3 times I think so I'm not sure which part you don't understand or don't agree with.
A work unit does not stand alone, their part of a range of wu's which need to be done as quick as possible so they can be analyzed and a new range of wu's can be given out. If wu's where stand alone units, the more wu's you the better you're helping but this is not the case. You're helping the most if you turn it in as quick as possible, allowing them to analyze it and make us more wu's.