Questions and Answers :
Wish list :
BOINC Wish List
Message board moderation
Previous · 1 · 2 · 3 · 4 · 5 · Next
Author | Message |
---|---|
John McLeod VII Send message Joined: 15 Jul 99 Posts: 24806 Credit: 790,712 RAC: 0 |
My 2 cents..... This would only be for the time that the server would not respond to the button anyway. Once that period is passed, the button would re-enable, even if the client had decided to extend the communications deferral. BOINC WIKI |
Ingleside Send message Joined: 4 Feb 03 Posts: 1546 Credit: 15,832,022 RAC: 13 |
This would only be for the time that the server would not respond to the button anyway. Once that period is passed, the button would re-enable, even if the client had decided to extend the communications deferral. Well, with the current 11-second-deferral, any greying-out of the bottom would have very little effect, so basically is a waste of time to add. Now, some projects has longer deferral, but most of these is either giving fairly steady work-supply, or is (nearly) permanently out of work (like LHC). But, one thing that's been overlooked is, the client doesn't know the difference between "N seconds deferred to not reconnect immediately", and "N hours deferred due to reaching daily quota"... If user has fixed whatever reason for a quota=1, and has one or more finished tasks that will increase the quota, being blocked from connecting for upto 24 hours before can get more work would be a bad idea. "I make so many mistakes. But then just think of all the mistakes I don't make, although I might." |
Steven Meyer Send message Joined: 24 Mar 08 Posts: 2333 Credit: 3,428,296 RAC: 0 |
But, one thing that's been overlooked is, the client doesn't know the difference between "N seconds deferred to not reconnect immediately", and "N hours deferred due to reaching daily quota"... Um ... Correct me if I'm wrong, but isn't "the client" written by the same people in Berkeley who send the messages to defer communications? Or, at least, the two groups of people can talk to each other and decide that "Defer 12 seconds" means "defer 12 seconds", regardless of the reason for the deferral? But, in any case, we have discussed this to no end already and have (I think) collectively come to the conclusion that any sort of lock out by the client is going to be a big problem for folks who are having trouble with communications and are trying to debug the problem, and thus the lock out idea is a "No go" and we are left with the honor system. |
1mp0£173 Send message Joined: 3 Apr 99 Posts: 8423 Credit: 356,897 RAC: 0 |
But, one thing that's been overlooked is, the client doesn't know the difference between "N seconds deferred to not reconnect immediately", and "N hours deferred due to reaching daily quota"... In a very real sense, no. BOINC is a project to write a universal volunteer computing platform. SETI@Home is a volunteer computing platform that uses BOINC. They're friendly, they probably help each other alot, and some are at least listed as part of both projects, but they're different things. ... and BOINC is project-neutral. |
kittyman Send message Joined: 9 Jul 00 Posts: 51468 Credit: 1,018,363,574 RAC: 1,004 |
But, one thing that's been overlooked is, the client doesn't know the difference between "N seconds deferred to not reconnect immediately", and "N hours deferred due to reaching daily quota"... And that's part of the problem occasionally when a few of us (myself included) start to ask for changes to the Boinc client when looking at things from a Seti-centric only point of view. I must plead guilty to this from time to time, as I ONLY run Seti, and sometimes I forget that Boinc must not only handle the way Seti functions, but every other project under the Boinc umbrella as well. I also never have any impact or problems involving workshare and debts between different projects, because other than for a very short time here and there, I have never tried to run anything alongside Seti. What might be grand from a Seti point of view may not always work well with some of the other projects. As Ned pointed out....Boinc needs to remain, as much as possible, project-neutral. A more difficult task than some might imagine........ "Freedom is just Chaos, with better lighting." Alan Dean Foster |
Ingleside Send message Joined: 4 Feb 03 Posts: 1546 Credit: 15,832,022 RAC: 13 |
Um ... Correct me if I'm wrong, but isn't "the client" written by the same people in Berkeley who send the messages to defer communications? Well, as long as a project doesn't start re-coding the scheduling-server, atleast in this instance BOINC is writing both the client-side and server-side... And, it is a fact in this instance, that client doesn't know why it's asked to "deferr for N hours", if it's due to project being down (getting 1 hour), or due to user reaching daily quota (upto 24 hours deferral), or due to projects setting of "don't re-connect before in N seconds". The client, if left alone, will treat all the same, and will deferr for N seconds (or N hours...). User on the other hand will see the difference between "don't re-connect before in N seconds, since if you do, server will deny you any work anyway", and "oops, the problem with quota taking a dive has I now manually fixed, I will report the finished results so I can get new work"... The suggested client-change would remove the user the option of re-connecting in the 2nd. instance, something that could lead to many hours downtime, after user has fixed the problem. Well, of course BOINC could change both client-side and server-side, so you'll get messages like "Quota exceeded, don't re-connect before in (example) 6 hours, 4 minutes and 23 seconds... Oh, and disable the 'update'-bottom for project for... 11 seconds". But, frankly, only 11 seconds is so short an interwall that atleast my optinion it's a waste of time to do this change... BTW, AFAIK the 24-hour-deferrals due to "not enough free disk space", "not enough memory", "no application for your OS/platform" and so on has been removed from the scheduling-server. But it's maybe still possible to reach the project that runs with very old server-code, and nothing stops BOINC from re-introducing something like this again. And, if something like this code re-appears, you definitely don't want users to be blocked from re-connecting after fixing a problem like "oops, setting disk-parameters to leave 100 GB free wasn't my intention, I wanted 1 GB free". "I make so many mistakes. But then just think of all the mistakes I don't make, although I might." |
Steven Meyer Send message Joined: 24 Mar 08 Posts: 2333 Credit: 3,428,296 RAC: 0 |
Ok, here is a thought... User XYZZY has connected to, and is actively processing WU for projects ABC, BCD, and DEF. BOINC has issued new client-side software with the "Update All Projects" item on the context menu: +------------------------------------+ | Open BOINC manager | +------------------------------------+ | Snooze | +------------------------------------+ | * Use GPU while computer is in use | | Update all projects | | Do network communications | +------------------------------------+ | About BOINC Manager | +------------------------------------+ | Exit | +------------------------------------+ Now user XYZZY is fond of keeping everything up-to-date, so s/he often clicks on the "Update all projects" button which causes the BOINC client to send Update messages to all of the connected projects. Each of the three projects keeps a record of the last (5?) times when each user has contacted the project to do updates, and each of the three projects has code that decides when the user is over using the update facility. When that threshold is reached, then that project responds to the next update request with "Please Don't Do That Again For x Seconds/Minutes/Hours", which the BOINC client will respect. When a project has responded with such a deferral, then BOINC client will not include that project in any future "Update all projects" requested by the user until the deferral period has elapsed. If the user's use of the "Update all projects" button has been deferred by all of the attached projects, the BOINC client will cause the button to respond to the user with a message such as "Your attached projects have requested that you not do that again until ..." and list the projects and the date and time when each project will allow user XYZZY to contact the project again. If user XYZZY is trying to debug some issue with his or her connection to project ABC by contacting ABC to explain the problem and an adviser at project ABC has responded and told the user to try some fixes and then use the Update button to test the fix, the adviser will set a temporary flag on the user's account to prevent the user from getting any "Please Don't Do That Again ..." messages for a period of time. If the user is able to connect to the other projects with the Update button, and those projects respond with "Please Don't Do That Again ..." messages, then those projects will not be bothered by the user's BOINC client during the testing, but the BOINC client will not disable the Update button because the user has not received any such messages from project ABC. This puts the "Please Don't Do That Again ..." messages under the control of the projects, and puts the disabling of the Update button under the control of the BOINC client, while still allowing use of the Update button for debugging purposes. [edit] Oh, and by the way, if any project has not implemented the "Please Don't Do That Again ..." messages, then that project will always get those Update messages and the project's users will never get the "Your attached projects have requested that you not do that again..." message. [/edit] |
hbomber Send message Joined: 2 May 01 Posts: 437 Credit: 50,852,854 RAC: 0 |
I modified sources and compiled BOINC Manager 6.6.36 for Windows x86(my x64 development rig has dead memory), so "Use GPU" option appears in context menu and it does same like checkbox in Preferences dialog. Works OK, shows checked and unchecked, depending on current preferences. I'm not sure under what circumstances I can distribute modified executable to other ppl and do I have right t do so. If it is okay, I'll put it for public download. Let me know if anyone is interested. |
1mp0£173 Send message Joined: 3 Apr 99 Posts: 8423 Credit: 356,897 RAC: 0 |
When that threshold is reached, then that project responds to the next update request with "Please Don't Do That Again For x Seconds/Minutes/Hours", which the BOINC client will respect. For the case where this is most needed, connecting to the project servers will fail -- it is the extreme overload that's hard. The rest of this (trying to slow up users so they don't push the project into overload to start with) is a little bit like rearranging deck chairs on the Titanic. ... and solving the real problem is very difficult. |
kittyman Send message Joined: 9 Jul 00 Posts: 51468 Credit: 1,018,363,574 RAC: 1,004 |
When that threshold is reached, then that project responds to the next update request with "Please Don't Do That Again For x Seconds/Minutes/Hours", which the BOINC client will respect. Again I will say...... The tiny fraction of a percent of users that have their finger on the buttons at any given time could not crash the server even it they tried...... "Freedom is just Chaos, with better lighting." Alan Dean Foster |
Grant (SSSF) Send message Joined: 19 Aug 99 Posts: 13746 Credit: 208,696,464 RAC: 304 |
Again I will say...... Nope. But it does mean it takes longer for people to be able to return work, longer for them to get new work, longer for them to report work. It just makes the system load heavier for longer than it needs to be. Grant Darwin NT |
[B^S] madmac Send message Joined: 9 Feb 04 Posts: 1175 Credit: 4,754,897 RAC: 0 |
|
OzzFan Send message Joined: 9 Apr 02 Posts: 15691 Credit: 84,761,841 RAC: 28 |
Again I will say...... Agreed. I don't think I've ever suggested the idea that those who abuse the Update button have caused irreparable harm to the servers (in fact, I think those who abuse the button bring this point up so they do not feel guilty about abusing it), but rather like you said: it still causes unnecessary load and makes things that much worse when trying to get through. Like people cutting in line; there's so few who do it that it doesn't increase line wait times considerably, but it still means that others have to wait that much longer because you (collectively) feel that you're more important than everyone else that you must get yours in immediately. I just think it's selfish and inconsiderate. |
Steven Meyer Send message Joined: 24 Mar 08 Posts: 2333 Credit: 3,428,296 RAC: 0 |
More wishes.
These profiles can be useful when setting up BOINC for special situations that come up often enough to be come tedious to do it all from scratch each time.
|
Jord Send message Joined: 9 Jun 99 Posts: 15184 Credit: 4,362,181 RAC: 3 |
* Use at most Y% of the GPU time. There's no reliable (cross-platform) way available yet to throttle a GPU. It can only do all or not much, or in other words, it can do intricate calculations or it can show you what's happening on your desktop. So you may scratch that one. |
Steven Meyer Send message Joined: 24 Mar 08 Posts: 2333 Credit: 3,428,296 RAC: 0 |
* Use at most Y% of the GPU time. It seems to me that if the user wants less than 100% GPU use, then sending a batch of data to be crunched on for a while, then wait for a bit before sending the next batch would do the trick. After all, that is what the games do when they are showing stuff on the screen. Not that they deliberately wait, just that something has to happen like a rocket move a little ways across the screen towards your face . . . or feet. |
Jord Send message Joined: 9 Jun 99 Posts: 15184 Credit: 4,362,181 RAC: 3 |
It seems to me that if the user wants less than 100% GPU use, then sending a batch of data to be crunched on for a while, then wait for a bit before sending the next batch would do the trick. It isn't that easy. A task will be translated by the application running on the CPU into kernels which are sent to the videocard's memory, where they wait until they're done by the GPU. When done, that data is sent back to the application running on the CPU, which will translate it back into something it can write to disk. Any lull in this to-and-fro transfer can break the task or stop BOINC receiving a heartbeat from the application, which will crash the task. After all, that is what the games do when they are showing stuff on the screen. Most games off late use large maps (750MB and more), of which parts are constantly moved into and out of the videocard's memory, waiting until they're being used or being discarded (unceremoniously dumped out of memory). You can't really compare how a game is run and how CUDA is done, as games use a lot more functionality on the videocard, including registers for DirectX, pixel and vertex shaders, (anti-)aliasing, where to place what pixel and in what color, etc. Most of those aren't used when doing CUDA calculations. |
Steven Meyer Send message Joined: 24 Mar 08 Posts: 2333 Credit: 3,428,296 RAC: 0 |
It seems to me that if the user wants less than 100% GPU use, then sending a batch of data to be crunched on for a while, then wait for a bit before sending the next batch would do the trick. And yet, the games move data into memory on the GPU when it needs to be there, and then back out of the GPU's memory when that is needed, all without losing anything, or crashing, or such. S@H would seem to be a far simpler process. I know that all this moving data around would slow down the processing of the S@H task, but then, that is the whole point isn't it? When the GPU is overheating at 100% usage, you will want to reduce that to maybe 50% usage. Maybe the percentage for the GPU usage will have to have some large granularity. Maybe there would have to allow just 5 values: 0%, 25%, 50%, 75%, or 100%. Currently we do not even have the 0% option. Short of suspending every CUDA task, or suspending BOINC completely, there doesn't seem to be any way to temporarily turn off usage of the GPU. Maybe it will be difficult to make a GPU throttle happen, but I think that it is time to make it happen. Have you ever considered the possibility of using the heartbeat as an opportunity to put a pause into the CUDA code? After each heartbeat it could wait for some time period before it continues. Seconds 0 ... 1 ... 2 ... 3 ... 4 ... 5 ... 6 ... 7 ... 8 ... 9 ... 10 .. 11 .. 12 ..Crunching data.. ...Cooling Down... ..Crunching data.. ...Cooling Down... |
wlh2008 Send message Joined: 25 Aug 09 Posts: 8 Credit: 11,432 RAC: 0 |
I am new, but I think it would be nice if the server would provide a way to allow the client to request that particular WUs be resent in case of a local error which wipes out current work units. An example would be where a system crash causes the OS to zap certain inodes in linux/unix on reboot due to the instance being dirty and those inodes are connected to WUs. wlh2008 |
OzzFan Send message Joined: 9 Apr 02 Posts: 15691 Credit: 84,761,841 RAC: 28 |
I am new, but I think it would be nice if the server would provide a way to allow the client to request that particular WUs be resent in case of a local error which wipes out current work units. An example would be where a system crash causes the OS to zap certain inodes in linux/unix on reboot due to the instance being dirty and those inodes are connected to WUs. There is an option on the server side that allows for this and many other projects use this function. SETI@Home once used it as well, but due to the sheer size of the project and the bandwidth/resources required to enable this option, the SETI Admins were forced to turn it off. |
©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.