Posts by Brian Silvers

21) Message boards : Number crunching : Deadline problem (Message 34552) Posted 15 Dec 2009 by Brian Silvers Post: Another of my boxes is today on MW. Task list downloaded have a report deadline of today's date! Great stuff - not a hope in hell to complete any task. My wing will soon become very upset flying with me. Deadlines are 3 days. Today is the 15th. Deadline on your remaining unaborted task is the 18th. Looks quite normal.
22) Message boards : Number crunching : Report deadline: not enough time for low-end processors? (Message 34397) Posted 8 Dec 2009 by Brian Silvers Post: As to the OP's query, due to the fact that new tasks are dependent upon tasks currently being processed, increasing the deadline causes drift in the results, possibly causing the search to go down the wrong path. Deadlines are actually 3 times longer than the project actually wanted (1 day), so an increase in deadline is unlikely and it is better that they do not, for the sake of scientific accuracy. That said, I knew that when the tasks were lengthened for all users, this kind of issue would crop up. I'm thankful that GPU users are now at least a bit less...vocal...however a good thing to probably do is route these larger tasks exclusively to GPU users, if at all possible. CPU users could then run any 1 or 2-stream tasks, and, most likely, caches could be increased for everyone. This was the general concept that I was proposing for all these past months...
23) Message boards : Number crunching : Cruncher's MW Concerns (Message 34072) Posted 1 Dec 2009 by Brian Silvers Post: I got one of the larger units, and when I divided total credits by hours spent crunching the result was a bit lower (fell down to 37/hour on the same opti-app). 37/hr is approximately what my P4 2.4GHz would get, so I think things are pretty much constant (only minor variations, if any). What is interesting to note though is given the difference in FP performance of K8 vs. Northwood, your 3500+ should've significantly outperformed my P4, and my 3700+ should significantly outperform my P4, but they do not. In your case, it is slightly slower, and in my case, my 3700+ is only slightly faster. In both cases, there are clock speed differences, your 3500+ slower, while my 3700+ is faster than my P4. It's either the app is more integer based, or it mostly resides in cache...
24) Message boards : Number crunching : Cruncher's MW Concerns (Message 33975) Posted 30 Nov 2009 by Brian Silvers Post: In fact, what is even more dumb than that, is comparing credits of any project against any other project. Cross project parity is a socialists point of view. As long as there is a BOINC-wide credit-based "Leaderboard" as is being done by the various statistical sites, then those primarily interested in being at the top / around the top of that leaderboard will gravitate towards projects that lend themselves towards that goal. To illustrate: If I were to make up a project tomorrow that had as its' goal to calculate the maximum number of times the words "I like credits" would fit on one side of a standard letter-size piece of paper, if I made each result award triple the amount per second as the next highest awarding per second, there will be a percentage of people who will process tasks for my project nearly exclusively, even though as a project it is pretty dumb and has no actual reward to society other than the inane "Trivial Pursuit" type of knowledge. The general principle behind Cross-Project Parity is to prevent something like that, where leaderboard goals cause manipulation of the volunteers by the projects and of the projects by the volunteers. The correct way to go about it however is NOT by having the projects be involved, nor by having BOINC (UCB) be involved, but by having statistical normalization done by the statistical sites (BOINCStats, BOINC Combined Credit, DCStats, etc, etc, etc...)
25) Message boards : Number crunching : Problem with tiny cache in MW (Message 33921) Posted 29 Nov 2009 by Brian Silvers Post: I'm suggesting that MW review it's 6 wu/cpu policy in light of the fact that they get a large majority of their work completed these days by GPUs. To help, maybe Travis could spend an hour or so reviewing the lengths of outages in the last 6 to 12 months for frequency and length of the outages and let us know the results. In my case any outrage longer than 10 minutes would mean my quad core with 2 GPUs was out of work and an outage longer than 20 minutes would mean my old P4 with the 3850 was out of work. So extending this out to GPU crunchers in general and making some assumptions, it implies that any outrage longer than 20 minutes would mean that all GPU crunchers would have run out of cached work. I wonder how often an outrage of 20 minutes or longer has occurred in the last 6 to 12 months? Would increasing the amount of cached wu's mean that the overall crunching availability would have increased from the mid 90%'s to the high 90%'s and would it be worth the effort? :facepalm: Travis has already told you that giving you more WUs in your cache ends up bringing the project to a halt due to the server not being able to handle it. In other words, giving you all more of these small tasks will end up with you having MORE outages, so it would mean you had less work in total. The "crunching availability" would decrease, not increase... Can you please read my posts on this subject before replying.... Can you please read Travis' posts on this subject before replying? Could you PLEASE try to figure out that he is trying to make sure that you have a steady amount of work, even if it is less than what you would like to see? Could you PLEASE try to figure out that I'm actually not just advocating something advantageous to myself, but advantageous to YOU as well because having work continuously is, well, better than having a lot, then none for a while, then some, then none, then a little, then none, then a lot, then none...? Again, he has told you all that there are two separate reasons why he doesn't increase the cache. You are choosing to look at only one of them, the need for faster turnaround times, and are saying that it doesn't make sense because GPUs are faster. If GPU users were given 20x the current amount, that would work out to a 3-hour cache, which I guarantee will still not be "satisfactory" to some people. To make people happier, it would likely need to be 40x the current amount, or 6-hour caches. Even then people would likely still be grumpy, but it would be "a start"... The problem is that you are completely ignoring the second reason why he isn't increasing caches, which is that what happens is the result table gets to the point where it doesn't function properly and causes the entire project to become slow, run out of work, etc, etc, etc... The project needs to concern itself with a good, steady, manageable level of work being done. Increasing the cache to placate certain people works against that goal.
26) Message boards : Number crunching : Problem with tiny cache in MW (Message 33903) Posted 28 Nov 2009 by Brian Silvers Post: I'm suggesting that MW review it's 6 wu/cpu policy in light of the fact that they get a large majority of their work completed these days by GPUs. To help, maybe Travis could spend an hour or so reviewing the lengths of outages in the last 6 to 12 months for frequency and length of the outages and let us know the results. In my case any outrage longer than 10 minutes would mean my quad core with 2 GPUs was out of work and an outage longer than 20 minutes would mean my old P4 with the 3850 was out of work. So extending this out to GPU crunchers in general and making some assumptions, it implies that any outrage longer than 20 minutes would mean that all GPU crunchers would have run out of cached work. I wonder how often an outrage of 20 minutes or longer has occurred in the last 6 to 12 months? Would increasing the amount of cached wu's mean that the overall crunching availability would have increased from the mid 90%'s to the high 90%'s and would it be worth the effort? :facepalm: Travis has already told you that giving you more WUs in your cache ends up bringing the project to a halt due to the server not being able to handle it. In other words, giving you all more of these small tasks will end up with you having MORE outages, so it would mean you had less work in total. The "crunching availability" would decrease, not increase...
27) Message boards : Number crunching : Problem with tiny cache in MW (Message 33876) Posted 28 Nov 2009 by Brian Silvers Post: Anyway, this is all moot unless a new server gets installed or more complex scientific work is made available for GPU users. I wish that in the meantime people would settle down and realize that we've hit a hard limit on the capacity, and that adding strain to a server that is having problems will not help matters any I don't think that will happen anytime soon as more & more Participants are jumping on the GPU Bandwagon because that's where the Credit is at and in some sense the Future of BOINC at many Projects as they get on Board with GPU Work. So if anything it's just going to get worse unless the Project does something to lessen the Strain on the Server. Putting a new Controller in isn't going to solve the problem either, it might make things a little smoother but there's still going to be the constant complaints about Low Caches & Caches being run out before new work is issued. So until the Cache Problem is solved the Project still going to have a problem too with people leaving & complaints about the Caches ... IMO Perhaps, but there will still be enough people that will stay. The credits are higher here, so they come back, even if it is only as a "filler" for the other project. Not only that, but having fewer GPUs for a little while would help give him a break with regards to having to continually stay on top of the server. That's really what they need, is some time to do things other than constantly deal with support. The team I was with at a prior job had that same problem - too much support to do. We got so far behind on other things because of having to devote so much time to support tasks. At one point in time we had 250-300 new problem tickets every hour, with only 1 person working the inbound tickets. Even diverting one other person meant that just to keep pace, you'd have to address 125-150 tickets an hour, so less than 30 seconds for each issue. It just wasn't doable...especially when the weak computer they gave several of us to use took 90 seconds just to open one of the tickets...and another 90 to close it. 3 minutes were taken up just in opening and closing, not even counting the work that needed to be done, which sometimes would take 2-3 hours (if there was a file corruption that needed to be dealt with).
28) Message boards : Number crunching : Problem with tiny cache in MW (Message 33872) Posted 27 Nov 2009 by Brian Silvers Post: As far as I know, the project hadn't been focused on implementing more complex tasks for GPUs lately, although I don't know if they are thinking about it again now that server problems that are related to constant heavy I/O loads have come up again... It's probably to simple of a solution for them to implement ... ;) More likely it was a difficult solution to implement. They appear to have struggled with doing the CUDA code themselves. After that, they didn't have a way to implement the ATI application natively, so app_info override would still be required for ATI cards. I wish they would not have broadcast that they were looking at the new credit plan that DA has cooked up along with the announcement that they were looking at making the server-side changes to natively support ATI cards. That was a mistake. Not saying to not disclose it at all, it's just that due to the sensitivity of people it was not the best thing to have linked the two together. Anyway, this is all moot unless a new server gets installed or more complex scientific work is made available for GPU users. I wish that in the meantime people would settle down and realize that we've hit a hard limit on the capacity, and that adding strain to a server that is having problems will not help matters any...
29) Message boards : Number crunching : Problem with tiny cache in MW (Message 33868) Posted 27 Nov 2009 by Brian Silvers Post: I have no problems with longer Wu's for my GPU's here, in fact the Short Wu's & Low Cache is the Main reason I switched to Collatz & haven't looked back once. I just got tired of the Constant Idleness of my GPU's here at Milkyway & all the Hassle of continually having to change App's to keep up. Then you, as someone who has GPUs, need to talk to your fellow GPU users and convince them that it's not an evil plan and would actually work better in the long run than just having more of the shorter tasks, because I can't do it. People tend to shoot me first, rather than the message, then proceed to shoot the message. No it's the Participants that are actually running the project that need to do it if that's what they want, I'm not running it ATM so I don't really care what they do with the Wu's. We complained a little at the Collatz Project so finally Slicker proposed to make the WU's Longer. After a bit when nobody objected he did it and nobody complained after he did it either. The Project has to want to do it & the Participating Participants have to want to do it then whats the problem with doing it. Obviously one or the other has an Objection to it or it would have been done already. MW_GPU was designed to have significantly more complex tasks so that it gave GPUs something more complex to work on because they can handle it. The project gave up on it after they discovered a setting change on the server side of things that relieved the pressure for the moment. The participants didn't (and likely still don't) want to wait the amount of time it would take for it to be implemented. They tend to want things NOW, so that they can have their credit keep going up, which is what Travis is noticing and posted about in this thread - that many participants are primarily concerned with getting credits, not what would make the most sense scientifically for the project. The real irony is that a better long-term plan would make it to where their credit can keep going up more smoothly as there would be less interruptions in total. Problem is, people are impatient... Already even with the mere mention of a newer server, people are asking for it to be ramped to full capacity right from the start. Doing that will just have the same problems for the new server eventually without a long-term plan. What needs to be done with a new server is things need to be left alone so that Travis wouldn't have to tend to it as much so that work can be done on getting other people up to speed on how to run the project and getting something changed to make MW_GPU or something similar happen. As far as I know, the project hadn't been focused on implementing more complex tasks for GPUs lately, although I don't know if they are thinking about it again now that server problems that are related to constant heavy I/O loads have come up again...
30) Message boards : Number crunching : Cruncher's MW Concerns (Message 33829) Posted 27 Nov 2009 by Brian Silvers Post: The projects I mentioned pay better for ME. Your reply to Sailor's post, validates my point. With GPU/CPUs performances all over the map, everybody's facts will be different. Looking at your host via BOINCStats, you appear to be using your GPU at Collatz, but CPU here. Perhaps you are unaware that this project is CUDA-capable now, or that perhaps your specific GPU is not capable of running here. In either case, you're comparing a faster GPU against CPU performance. Of course the GPU is going to be faster and get you more credits. What's being said is that if you compare "apples to apples", credit is higher here than with other projects. This is true. It may not appear true to you based on the difference of using CUDA somewhere else and not here, but when evaluated objectively the credit per unit time is better here in most (if not all) cases as far as CUDA, and definitely better in all cases in regards to ATI on credit per unit time. People also get caught up into just relying on RAC to be the be-all-end-all determination of which project gets higher credit, but disregard that if you aren't at a 50/50 resource split and you have work fetch problems at one project (MW), but not the exact same work fetch problems at the other project (Collatz), one project could appear to get higher credit based on the relative viewpoint...
31) Message boards : Number crunching : Problem with tiny cache in MW (Message 33827) Posted 27 Nov 2009 by Brian Silvers Post: I have no problems with longer Wu's for my GPU's here, in fact the Short Wu's & Low Cache is the Main reason I switched to Collatz & haven't looked back once. I just got tired of the Constant Idleness of my GPU's here at Milkyway & all the Hassle of continually having to change App's to keep up. Then you, as someone who has GPUs, need to talk to your fellow GPU users and convince them that it's not an evil plan and would actually work better in the long run than just having more of the shorter tasks, because I can't do it. People tend to shoot me first, rather than the message, then proceed to shoot the message.
32) Message boards : Number crunching : Problem with tiny cache in MW (Message 33825) Posted 27 Nov 2009 by Brian Silvers Post: Edit: It's also unlikely that a 3-hour cache would satisfy people, or if it did, only very temporarily, so there'd be yet another round of wanting a larger cache sometime shortly after the 20x increase to get to 3-hour caches. How about trying to advocate something that has real long-term benefits for everyone instead of this scenario? Increasing the size of the GPU Wu's by 5-10 times they are now or even more & adjusting the Credits accordingly would be one solution to the Low Caches but then there would be a lot of complaining about wasting Processing Power. Funny though that's what Slicker did to help ease the burden on his Server, he doubled the WU Length or something close to that & I haven't seen 1 Post complaining about it, but then that's Collatz and not Milkyway. That's exactly what I've been advocating for a long time now. It was the whole purpose behind the MW_GPU project. We've already seen what short-sighted thinking does, as when the tweak that was found about the feeder/shared memory segment was made, the project backed away from the separate project. I'd rather not see another short-sighted move if it can be avoided. I do not understand how it would be "wasting processing power" though. If more actual science is being done, then I do not see how that is possible. What I think would be a very good thing to do is to restart work into getting MW_GPU going and provide those of you with GPUs some very intense work there. To help turnaround time here, they could also move all of the 3-stream (3s) tasks over to MW_GPU, leaving the 1-stream and 2-stream tasks here, which are well within the capabilities of CPUs. This type of plan would have a much longer-lasting effect and would benefit far more people, not the least of which is the project itself as it could be getting a lot more work done in less time and with less continual hassles, either from the equipment or from the volunteers.
33) Message boards : Number crunching : Problem with tiny cache in MW (Message 33820) Posted 27 Nov 2009 by Brian Silvers Post: I just wish Travis would acknowledge that once the new server is installed that he will look into increasing the number of wu's allowed to be cached. Not by CPU but by GPU! So, you want no relief for him in regards to server upkeep duties? You want him to have to have no room for growth and for him to have to keep being on edge, having to constantly make sure things are done just exactly right on here, thus diverting his time away from training other people to help him and taking time away from getting a more permanent solution in place? Collatz can run their database with over 300k wu's in progress and yet MW can only handle 90k...give me a break. With an updated server there'd be plenty of capability for both more cached wu's and room to grow. Three issues: 1) Collatz is not dependent upon current work being completed in a timely fashion for generation of new work. 2) The Project Administrator here has said that they don't have the capability of increasing to meet your credit gathering demands. If it were to help scientifically, I'm sure he'd be all about giving you all you and the server could handle. Oh, wait, he has said he is giving you all you and the server can handle (within reason) right now. 3) As I told ETA, increasing work for just those of you with GPUs would end up starving out everyone else. To cater to you, to have just a 3-hour cache you'd have to have 20x the current workload, from what I remember. Maybe more. By the time we add up all of you with GPUs, you would outnumber the rest of us if that 20:1 ratio got applied. Out goes everyone with a CPU and this becomes a GPU-only project. In your short-sighted moment of cheering, you'd neglect to consider that eventually the low-end GPUs would end up being considered to be "CPU-like" in nature, meaning that they'd turn in tasks slower than the newer GPUs, thus creating a never-ending cycle of having to have people on the lower end forced out to placate people on the high end and their drive for the highest number of credits. Edit: It's also unlikely that a 3-hour cache would satisfy people, or if it did, only very temporarily, so there'd be yet another round of wanting a larger cache sometime shortly after the 20x increase to get to 3-hour caches. How about trying to advocate something that has real long-term benefits for everyone instead of this scenario?
34) Message boards : Number crunching : Problem with tiny cache in MW (Message 33815) Posted 27 Nov 2009 by Brian Silvers Post: I just wish Travis would acknowledge that once the new server is installed that he will look into increasing the number of wu's allowed to be cached. Not by CPU but by GPU! So, you want no relief for him in regards to server upkeep duties? You want him to have to have no room for growth and for him to have to keep being on edge, having to constantly make sure things are done just exactly right on here, thus diverting his time away from training other people to help him and taking time away from getting a more permanent solution in place?
35) Message boards : Number crunching : Problem with tiny cache in MW (Message 33800) Posted 27 Nov 2009 by Brian Silvers Post: The 'variable cache size depending on turnaround time for that PC' idea, presented elsewhere, seems to have merit. Of course that would require more code at the server end... Getting you GPU folks your own project or work that is significantly more complex than the current work has the most merit and is the most likely to produce long-term relief. If there were any relief by giving you more tasks, you'd merely demand more and more due to the drive to accumulate credits until the point where we'd grind to a halt again.
36) Message boards : Number crunching : Problem with tiny cache in MW (Message 33799) Posted 27 Nov 2009 by Brian Silvers Post: The project is addicted to the fast turn around times that GPU crunching gives them. I don't think they care if GPU crunchers can't cache many wu's. For our project to do the science we're doing, we need fast turnaround times on workunits. I hope there's still the sticky describing why we really need that. On top of this, we've found that when we increase the workunit cache, the amount of WUs out in the system increases to a point where the database can't handle it's queries fast enough (because a lot of it is dependent on the result table). So right now, this project needs a low cache, partly because of the server and partly because of the scientific needs of the project. If you guys appreciate the science we're doing here, then we hope you'll put up with having a small WU cache. Part of what's nice about BOINC is that you can also be part of other projects that will fill out your cache when you don't have work from us. But you seem to forget that cpu crunching gets you the same cache and yet takes 50 times longer to complete a wu. So your argument tends to fall in a heap at that.... This is where a lot of you just tune out some of what he said. I have bolded and underlined the important part that you're tuning out for you. I have told many of you this over and over and over and over, and now someone from the project is supporting what I have said. The project cannot keep up with you all by giving you more tasks. If they give you all more tasks, the entire project comes to a halt eventually because the server cannot handle the load. Please, read...without selectively tuning out things...
37) Message boards : Number crunching : getting no new workunits (Message 33476) Posted 21 Nov 2009 by Brian Silvers Post: BTW, reality checks are on sale at only $99.95 (pre Black Friday savings). Who`s reality will be used as the stipulated terms? ;-) Abby Someone... Abby Someone? Abby who? Abby Normal...
38) Message boards : Number crunching : Not getting any WUs (Message 33430) Posted 21 Nov 2009 by Brian Silvers Post: ...of course I'm aware that there aren't any right now... This thread is dedicated to Kevin... :-)
39) Message boards : Number crunching : Server Crash November 10 (Message 33365) Posted 19 Nov 2009 by Brian Silvers Post: You mean to boldly go forth where no cosmo has gone before? OMG: Cosmo's up again. Maybe I need to start making bold statements more often... lol No, that I thought it would take them longer to get some software running than it would for this project to replace some hardware. They're claiming DB corruption. I suppose that's possible, as one person was reporting that they had processed tasks and were not seeing their credit totals go up since Oct 30/31... They still have the myriad of other problems though, and massive memory requirements...
40) Message boards : Number crunching : Server Crash November 10 (Message 33354) Posted 19 Nov 2009 by Brian Silvers Post: OMG: Cosmo's up again. Maybe I need to start making bold statements more often... lol

Previous 20 · Next 20