Message boards :
Number crunching :
Rescheduling Hosts - Bad Practice
Message board moderation
Previous · 1 . . . 3 · 4 · 5 · 6 · 7 · 8 · 9 . . . 11 · Next
Author | Message |
---|---|
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
BTW, very simple and quite elegant IMO way to deal with limits is to allow users to set limit by themselves with low default. What it will give: those who needs (or think that they needs, no matter) more tasks will get more tasks. "unattendent hosts" will be limited still just because they don't care! Active fraction small enough so this solution will greatly reduce tension on forums while will not bloat database too much. Right? ;) SETI apps news We're not gonna fight them. We're gonna transcend them. |
kittyman Send message Joined: 9 Jul 00 Posts: 51469 Credit: 1,018,363,574 RAC: 1,004 |
I want a 100/GPU limit. Do I have to ask again? @raistmenr...........Don't try to evade your previous comments. Apologize or retract, please. You are trying to evade the question, and I think, to save face, you should. @claggy.............. Dunno what you mean, I have been up to the total 1800 limit on my 9 rigs, regardless of the mix. "Freedom is just Chaos, with better lighting." Alan Dean Foster |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
Rasitmer............ Mark, perhaps you wanted to address your post to me though you still can't write my nick right after all these years. Well, ok with that, no matters. But you are definitely not the William, and I definitely did not comment any of your posts before so I don't quite understand why you answer me regarding your posts. Also, personal insults not welcomed either. If you have one of those your "funny states" again, then time stop perhaps. SETI apps news We're not gonna fight them. We're gonna transcend them. |
kittyman Send message Joined: 9 Jul 00 Posts: 51469 Credit: 1,018,363,574 RAC: 1,004 |
Rasitmer............ I am not in one of those 'funny states', and did not make any 'personal insults'. If I did, you would certainly hear them. Just get back to the coding board, my friend, and do what I cannot. I do not know your background, and certainly cannot do what you do. That does not stop me from commenting on what I perceive to be right or wrong. Carry on, buddy. You certainly have done more right than wrong. And I shall continue to comment when I feel appropriate. OK? Hmm..........do you have cats, Raistmer? As my sig goes, that might settle the matter once and for all........LOl. "Freedom is just Chaos, with better lighting." Alan Dean Foster |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
... That and a 'total channels to do' <200 will help most people here. Right now the total channels to do is 416. To last out 416 to 0, I'd need around 450 APs. If the total channels to do was never more than 200 after loading, there might be a chance to not run out of AP work. |
Batter Up Send message Joined: 5 May 99 Posts: 1946 Credit: 24,860,347 RAC: 0 |
My biggest problem is 100 CPU WU can take 10 days to clear wile 100 small GPU WU only 10 hours. I can crunch CPU WU wile crunching MB GPU WU so I like to have them but if I want to clear my cache and not abort 100 CPU WU it is a problem. |
kittyman Send message Joined: 9 Jul 00 Posts: 51469 Credit: 1,018,363,574 RAC: 1,004 |
My biggest problem is 100 CPU WU can take 10 days to clear wile 100 small GPU WU only 10 hours. I can crunch CPU WU wile crunching MB GPU WU so I like to have them but if I want to clear my cache and not abort 100 CPU WU it is a problem. My biggest problem is 700.00 power bills,. You got an answer for that? I am sorry for you. I got 9 rigs, 24/7, that do what you even ATTEMPT to achieve, SIR.\0 I do in one day what some crunchers hope to achieve in their lifetime. Pretty amazing, eh?\\ "Freedom is just Chaos, with better lighting." Alan Dean Foster |
HAL9000 Send message Joined: 11 Sep 99 Posts: 6534 Credit: 196,805,888 RAC: 57 |
My biggest problem is 100 CPU WU can take 10 days to clear wile 100 small GPU WU only 10 hours. I can crunch CPU WU wile crunching MB GPU WU so I like to have them but if I want to clear my cache and not abort 100 CPU WU it is a problem. It's called dedication, or insanity. Maybe both. :P SETI@home classic workunits: 93,865 CPU time: 863,447 hours Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[ |
juan BFP Send message Joined: 16 Mar 07 Posts: 9786 Credit: 572,710,851 RAC: 3,799 |
@william That´s we could call "agressive negotiations"... :) Back to topic: I just want 3 things: - a cache who holds for at least 1/2 a day (100WU GPU limit is not enought). - cruch MB or AP and receive on the same host the same credit for the same crunching time. - don´t need to rescheduling my work to achieve that! I don´t thing is too much to ask... BTW... i could add... i wish my power bill where low as 700 US$/month... Before anyone say nothing, yes i´m insane... but any BFB cruncher sure is... Anyway I still love´s the kitties... :) |
Geek@Play Send message Joined: 31 Jul 01 Posts: 2467 Credit: 86,146,931 RAC: 0 |
But a 200 task limit is what I see right now. 100 for CPU and 100 for GPU. 200 total on one box. Boinc....Boinc....Boinc....Boinc.... |
Wiggo Send message Joined: 24 Jan 00 Posts: 34896 Credit: 261,360,520 RAC: 489 |
For those who want to complain about how big the database is, one way would be to do something about rigs like these 1's that have annoyed me over the last 3 days. 6918964 6134523 7126088 5851927 6775327 5173830 5744165 5816451 7143915 5355835 6204067 5636309 6309357 7011923 6687080 7174864 5255577 5256566 5337199 5940343 5967897 6107404 6253478 6818618 6889146 5813849 6062303 6772486 5814038 5422967 7062362 5940769 6962510 5567264 6765911 4750332 6709864 6143011 6995169 7182427 6901240 5857368 This is not all of them, but they are the worst of the lot. I'm sure that my "State: All" numbers will then drop a lot. On the other side, those who by rescheduling or by "magic" just so that they can get AP work above the current set limits set will never have my respect just the same as those who abort MB work to get more AP's whenever they are being split. Cheers. |
Batter Up Send message Joined: 5 May 99 Posts: 1946 Credit: 24,860,347 RAC: 0 |
Yes, Kuwait one cent for a K/h. |
juan BFP Send message Joined: 16 Mar 07 Posts: 9786 Credit: 572,710,851 RAC: 3,799 |
No way, too hot to crunch... and no B-girls, bad for me at least. I´m out. |
ExchangeMan Send message Joined: 9 Jan 00 Posts: 115 Credit: 157,719,104 RAC: 0 |
Maybe a quick to implement change, the powers that be at Seti could implement the 200 WU limit as a floating quota as one poster mentioned. If you don't crunch any CPU, then 200 is available for GPUs. It wouldn't totally fix the problem, but it would be a band-aid for a little while. A more permanent fix would be a quota based on number of GPUs. I've got 8 in my big cruncher and 100 work units (especially MBs) won't take to me too far. Or maybe a more all-encompassing solution that would vary the number of work-in-progress work-units per host. It could look at such things as host reliability (not trashing work-units), host uptime, average work-unit turnaround time, crunch power of the cpus/gpus and number of cancelled tasks. I know this would be a lot to implement, but could be a more long-term solution. The way things stand now, anyone including myself with lots of gpus stuffed into a single host is screwed - yes, my fault for building such a beast. I'm thinking of building another one, but the logistics of cost to build, cost of electricity and cooling are preventing me from executing the plan. |
Josef W. Segur Send message Joined: 30 Oct 99 Posts: 4504 Credit: 1,414,761 RAC: 0 |
Within the design limits of CreditNew, balance has been achieved. That is, a host doing stock MB CPU tasks and stock AP CPU tasks gets about the same credit per hour for each. The comparison is a little difficult to judge since AR has so much influence for MB tasks and the stock AP CPU stderr doesn't reveal how much blanking was involved. But if you go back several thousand in the Top computers list and choose hosts with no GPU, you can find systems with enough MB and AP CPU stock tasks listed to judge for yourself. Hosts with GPUs would also be suitable, you just have to ignore the GPU results. I realize that this thread is mostly concerned about GPU credit rates. At a minmum, some evolution of CreditNew will be needed before GPU credit rates become sensible. Just for the record, I agree that any action taken by a user to circumvent the limits is unethical. Joe |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
...That is, a host doing stock MB CPU tasks and stock AP CPU tasks gets about the same credit per hour for each... Actually, since the global (down)scale chooses a CPU app in both cases unilaterally (by design flawed omission of SIMD), and the preceeding individual host scales are determined by an underclaim (based on Boinc Whetstone), it works out that AP pays approximately 2x, due to there being no AVX in the stock AP CPU app yet. [And incidentally, but related, that by reasonable or not task estimates, AP should be made considerably more efficient to be on par with MB. i.e. you get a special bonus with AP for the stock CPU app being dated, to offset some of the underclaim.]. Both cases end up a fraction of the cobblestone scale, and diminishing. I've yet to find deflation documented as a design goal of CreditNew, but it's very apparent. Moore's law and (stock cpu app) optimisation driven with the current four identified design flaws in play. "Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions. |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
Well, just another name ("design limits") for wrong asumption that lies on the ground of this credit system. Well, lets call them design limits, but those limits are preventing CreditNew to be useful. Quite valuable limits no one should break, not? :P And for the record, I consider energy waste produced by stock AP-based hosts and any means that aimed to keep stock CPU AP tasks supply (100 tasks per ATi GPU limit including) as unethical. If category of moral applied to such topics at all of course, but quite many posters in this thread insist that it's applicable, so... SETI apps news We're not gonna fight them. We're gonna transcend them. |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
i.e. you get a special bonus with AP for the stock CPU app being dated, Exactly. And if/when stock app will be updated to more efficient build at last? What then? Will AP credit drop like it was for MB7? If yes, then we will get another wave of desperation from credit-oriented (actually not only from them, some number to measure host performance needed anyway so when RAC changes for some external reasons not related to host performance it's bad for everyone) users. And then we again recive direct contradiction between credit system and project goals. Project goal is to increase its performance so updating stock app to faster one is good... but this will perhaps annoy quite a lot peoples because of CreditNew "design limits". So one could think twice before doing such update... So, very existence of such CreditNew credit system may hinder project's development. SETI apps news We're not gonna fight them. We're gonna transcend them. |
kittyman Send message Joined: 9 Jul 00 Posts: 51469 Credit: 1,018,363,574 RAC: 1,004 |
Yes, Kuwait one cent for a K/h. You are quite cute. I shall move my crunchers to Kuwait directly. I suggest you move there too. Meow.l "Freedom is just Chaos, with better lighting." Alan Dean Foster |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
i.e. you get a special bonus with AP for the stock CPU app being dated, If we brought stock CPU AP up to MB optimisation standards (AVX, polymorphic function dispatch etc), then AP credit will drop like a stone to at or below MB on a per hour basis. The mechasism is penalising optimisation of the stock applications, just the same (I'm told) as it's penalising multithreading on MilkyWay out, effectively dividing credit by the number of cores, when it should be multiplying. [Blocking technology progress!] That's just a function of the design having assumed faster uses the same resources, so leaving out instruction level parallelism, vectorisation and coarser parallelisation completely out of the design. What *could* have happened, at least in our case here at seti@home, is we know task estimates for FPU operation are 'not too bad' (relatively speaking), therefore any apparently more efficient processing that is valid is using some form of parallelism (what kind we don't care), and so can be used to gauge the average parallelism, scaling (upward) appropriately to compensate for shorter time, as opposed to dividing credit downward even further causing spiral deflation. The end result of proper scaling would converge on the cobblestone scale. "Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions. |
©2024 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.