Message boards : Graphics cards (GPUs) : ... still babysiting ...
Author | Message |
---|---|
The scheduler in the 6.5.0 must still have problems with long time projects. I've CPDN (2 tasks, one with over 200 hours, one with 1600 hours), PrimeGrid, MilkyWay and ABC running as CPU tasks. In this case the BM don't ask for work automatically. If I stop one or 2 projects, I get this call and answer: | |
ID: 4847 | Rating: 0 | rate: / Reply Quote | |
You can also try to extend the cache size. I know we should if we are on HS connections run with a lean cache, but, I had to up mine to 0.4 days to get work reliably. | |
ID: 4848 | Rating: 0 | rate: / Reply Quote | |
You can also try to extend the cache size. I know we should if we are on HS connections run with a lean cache, but, I had to up mine to 0.4 days to get work reliably. My work cache is set to 2.00 days. The problem exist on the boxes with the fast cards (GTX280 and GTX260²). BTW: The GTX280 runs more than 30% faster with 3+1, the GTX260² runs fine with 4+1, all with Vista 64 bit. ____________ | |
ID: 4850 | Rating: 0 | rate: / Reply Quote | |
I would like just to confirm this strange behavior (not requesting more work if other projects are not suspended). | |
ID: 4851 | Rating: 0 | rate: / Reply Quote | |
I would like just to confirm this strange behavior (not requesting more work if other projects are not suspended). Me too, on 6.4.2. MrS ____________ Scanning for our furry friends since Jan 2002 | |
ID: 4860 | Rating: 0 | rate: / Reply Quote | |
I would like just to confirm this strange behavior (not requesting more work if other projects are not suspended). Yep, me too now, even on 6.3.21. :-\ And I first thought, it only was a client problem of 6.5.0, that's why I switched back because I didn't had this problem before with the 6.3.21... ____________ Member of BOINC@Heidelberg and ATA! | |
ID: 4863 | Rating: 0 | rate: / Reply Quote | |
Just to dip my oar, my experience is different. I am running 6.5.0 and it has been returning and fetching work normally for me. Though I just got one task with a 168 hour run time... forcing the prior task into high priority (it just completed). Now that it is running the time is coming down quite nicely thank you. | |
ID: 4865 | Rating: 0 | rate: / Reply Quote | |
I have a mix of long time and short time projects running. On MilkyWay and PrimGrid I get also work if the BM calls for one second free time. One CPDN task has work for 850 hours. So the calls for work on GPUGrid are too short to get work. If I stop CPDN, MW and PG calls immediately a lot of WUs and after restart CPDN some projects going in high prio mode. I have to set all projects (without GPUGrid) to NNW and then to stop. That's the only way for me to get new work on this Vista 64 machine with the GTX280. | |
ID: 4867 | Rating: 0 | rate: / Reply Quote | |
I have a mix of long time and short time projects running. On MilkyWay and PrimGrid I get also work if the BM calls for one second free time. One CPDN task has work for 850 hours. So the calls for work on GPUGrid are too short to get work. If I stop CPDN, MW and PG calls immediately a lot of WUs and after restart CPDN some projects going in high prio mode. I have to set all projects (without GPUGrid) to NNW and then to stop. That's the only way for me to get new work on this Vista 64 machine with the GTX280. This is the subject of a post in the SaH NC forum where I discuss how GPU processing breaks the resource share model ... which is the basis for making these calculations. Splitting the model to have two separate calculations only works when the project is pure CPU or Pure GPU processing. That model also breaks when you have a situation like SaH where you have capabilities to run on both processing elements. More interesting to me is the fact that the long neglected issues with credit calculations *COULD* have been the solution to this conundrum. Even sadder is that we predicted issues such as this back in beta testing of BOINC when discussing the future. Unfortunately the developers kept telling us we did not understand and that a correctly operating credit calculation system was not important. However, if we did have correct characterization of the CPU and GPU as to their capabilities in processing as defined by the original model of Cobblestones, then we would know what the processing capabilities of each processor system was, from there you know the total capacity, can look at the current loading, and allocate the resources. From THERE, you can ask for the correct type of work to properly "balance" the resource allocation ... and so on ... I hate to be right all the time ... :) | |
ID: 4873 | Rating: 0 | rate: / Reply Quote | |
... and again ... it's no fun, can't grab new work ... | |
ID: 4878 | Rating: 0 | rate: / Reply Quote | |
Which hostid? | |
ID: 4879 | Rating: 0 | rate: / Reply Quote | |
I'm having this problem also. In my case I got the impression that the problem was caused by everything wanting to run in 'high priority' mode. | |
ID: 4881 | Rating: 0 | rate: / Reply Quote | |
Which hostid? Host ID 7785 ____________ | |
ID: 4885 | Rating: 0 | rate: / Reply Quote | |
I would like just to confirm this strange behavior (not requesting more work if other projects are not suspended). To add more detail: - I have 2 CPU projects, one with many many WUs (due to some previuos error, nevermind) and a normal one - all WUs (CPU+GPU) are in high priority mode due to this massive amount of cached WUs - cache size is set to 1.25 days - GPU-Grid has 37.5% ressource share And even if the current GPU-WU is down to a few hours of runtime BOINC won't request new work, until I suspend the project with many WUs. MrS ____________ Scanning for our furry friends since Jan 2002 | |
ID: 4900 | Rating: 0 | rate: / Reply Quote | |
Just a note, Dr. Anderson has aknowledged that there are issues with with the work fetch policy which is contributing to our misery. He plans to start working on this soon ... | |
ID: 4912 | Rating: 0 | rate: / Reply Quote | |
Message boards : Graphics cards (GPUs) : ... still babysiting ...