I am sorry to see all you guys go. I am not going anywhere. I only crunch because I think I can do some good. I strongly disagree with the new progress bars, but that is cosmetic and not enough to have me go away. Kind of reminds me of years ago. We had a Pastor who was kind of a scoundrel, not the kind that might get locked up for being a pervert, but someone who did not give what I would consider a good example to his parish. It didn't cause me to leave the parish because I would not do that, but I was one of many unhappy parishioners for a while. And eventually we got a change. So maybe sometime the powers that be at IBM will see the light and give us some parameters with which we can somewhat track progress, even if changes up and down over time. Like the saying goes "It ain't rocket science, it's harder."
Cheers

I already have a lot of collectible marbles at home.

I am crunching for a direct contribution. We just don't get much from the other end. I will have to split out my own projects and hope for the best. That's about all I can do. Technology hasn't reached the estimating arena, even though I worked a lot of computer jobs and had to deal with silly management forecasts.

In my opinion, reasonably accurate statistical data can be a real motivator. However, I'm becoming concerned that BOINC is falling behind the hardware. There are a number of "limiters" in place that have been around for many years and the hardware is beginning to outpace those numbers. Limiters like the 1000 task in progress limit per client, the 64 FAH2 limit, the 70 WU per core. Most of these are WCG limits but other projects have their versions. They probably shouldn't be removed but should be re-examined for applicability today. With 32 core and 64 core processors now available, these limits are too small. With SCC I can only get about 6 hours of work before I reach the 1000 WU limit. The 70 per core limit only comes into play for 8 cores or less. Anything bigger will hit the 1000 limit first. It's hard to understand why there is this push to get more volunteers but then limit them as to how much work they can get. One large contributor can equal many, many small contributors. So, the question becomes, do we keep the limits and try to recruit many, many small contributors or raise the limits so that larger contributors can effectively participate along with all other contributors. If the bottom line is completed work units, it might help to effectively utilize the available computing resources. Just saying.....

"The 70 per core limit only comes into play for 8 cores or less"

1000 / 70 = 14 to the integer, Newegg telling there's 12 core kits around, but if short, just set up multiple clients. The overhead is small.

https://www.newegg.com/p/pl?d=12+core+processor

You're right with the number but figured 12 core systems are relatively rare. One thing to keep in mind is we keep using the word "core" and we should be using the term "thread". Most likely a 12 "core" processor would have 24 threads. Actually an 8 "core" processor would have 16 threads so that one would hit the 1000 limit first. The client would report 16 processors.

Concerning multiple clients, I've had to do that during the larger challenges like the Pentathlon but it becomes a pain in the back-side. Trying to keep track of 12 separate clients on 6 of the larger 32 thread machines is a challenge. You are right to say the overhead, resource wise, is small but the challenge to keep track of all of them across 14 servers isn't. It's too easy to get things mixed up and 1000 WUs get detached.

One other point: Since there is this desire to recruit more volunteers and part of that strategy is to simplify the running of the software (Science United) why do we want to make volunteers "jump through hoops" to get work. Why not just raise the limits and make everything easy? Those that need it can use it and those that don't, don't have to.