I see no advantages to the "one client per resource" approach, and it has many disadvantagaes: - can't enforce memory usage limit - doesn't handle apps that use 2 resources (e.g. GPU/CPU) - requires rewrite of manager - increases number of scheduler RPCs etc.
You imply that scheduling in 6.10.x is not "stable and well behaved". If you can provide specific examples of this, with appropriate message logs, then we can fix the problem. -- David vid vidmar wrote: > Hello. > Recently I got a strong feeling, that BOINC CC development is heading > in a wrong direction. I have been thinking about it a lot and now I am > positive, that cramming support and scheduling for different resources > (cpus, gpus, and others yet to come) all in one CC is wrong thing to > do as it closes the possibility for expansion with each added resource > by adding complexity to the code and the whole process. Instead of > "internalizing" I think "externalizing" would be much better. > Therefore I started an experiment in which I have a CC running for > each resource (thanks to --allow_multiple_clients), and I think it's > working way better than anything a single (multiple resources aware) > CC is doing (and will be able to). FYI experimentation has led me to > believe, that in 6.4.7 or thereabout, the scheduler is most stable and > well behaved (or was it 5.10.?, but that had other issues). > The only problem I have now with this setup, is that I cannot attach > two different resources to a single project. The trouble is that each > CC instance is seen by the server (relying on IP and domain) as the > same computer (now, think what happens, when result lists don't > match). This server-side behaviour is what is ruining what I think > would be something much more powerful and extensible, than what is > currently being developed. > So, to get to the subject line: would the use of <suppress_net_info> > tag in cc_config.xml prevent such "wrongly-correct" identification, > would then each CC be seen as unique computer, allowing me to pass > this last obstacle without me needing to find, fix and recompile the > code? > Best regards, > Vid Vidmar > > P.S. If this is the second such email from me, I apologize. > _______________________________________________ > boinc_dev mailing list > [email protected] > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
