Reading into the discussion about relisting and removing the projects and the work units, I was kind of put of about where we were heading with this. I didn't like it. And this discussion going out to other projects.
The first reason is that this gives us bad repo with the project which we had seen was the case with the enigma@home forum.
Second, lets say someone loves the SZTAKI (no other example came to mind) for the science they do. And also loves Gridcoin because it helps him to contribute to it. So us removing the project is just saying to the volunteer to just choose one among us.
I am also against the disproportionate earning of the gridcoin due to the disparity in the workload given by the project which might discourage some of our diligent community members, who might be earning far less for the work they put into project like SETI, while people earning a lot in projects like SZTAKI.
I am not a developer and the suggestion that I will be suggesting may be improbable so I will gladly like the suggestion. I think these things should be hard coded within the neural network and a workaround can be made by structuring the reward system. I see two probable ways we can follow to address 2 issues,
Lets make a minimum threshold for the amount a computation that must be crunched by the members of the Gridcoin team for the specific boinc project for that project to be added in the superblock. So suppose a project is going to be down for a few weeks due some reason so they are not able to deploy work units for all the crunchers. This will ultimately cause the computation to fall and once it becomes less than the threshold it will not be added until it is back functioning like before. This will save the time for voting and no changes will be required to make.
But this might lead to another problem when the people will not be able to receive their magnitude for a few days. The second solution is the divison of the projects into 3 different tiers. The first ones will be the heavy ones like SETI, MILKYWAY, etc which still lack the volunteers by a large magnitude, the middle tiers which have middle tiers workload and a third tier can be devoted to the shared project for the project which have a low workunits, i.e more volunteers than required. We can define the criteria with the help of computation done by the gridcoin team, the same way done in first method, and if necessary delegate different amount of gridcoin (maybe). Also the 3rd tier can be grouped so volunteers comepete cross project for within this tier for earning gridcoin.
I do think that this will help us add all the existing Boinc project and not worry about if the work units are being distributed and worry about voting. And we can easily add new projects like XANSON and SOURCEFINDER without any hassel.
Lets discuss about it !
P.S. Sorry for the boring text only post. And also what would I need to learn before I can contribute to gridcoin source. Could not find where to start. Would love to help as I have a lot of time in hand and how much time will it take. Thanks.
First of all, I don't think setting a minimum threshold would be at all fair due to the disparity on how many credits each project tends to give out: GPU projects will always have an easier time clearing a fixed threshold than CPU-only projects, for one.
Even if a mechanism to adjust the threshold could be devised using the data on available platforms within a project, the inherent differences between the tasks could still result in a radically different credit output given the same hardware on different projects. For example, Bulldozer CPU's are known to be have only half as many floating point units as integer units. Meanwhile, Ryzen CPU's appear to have reversed this trend with rather strong floating point performance and unusually good encryption capabilities.
Whether or not projects clear a threshold given a similar userbase to other widely-supported projects could easily come down to the type of computations they do.
After all that, the project admin could still manipulate their credit reward computation to clear the threshold by scaling everything by some multiplier. This is one of the reasons that all projects get an equal share of the total magnitude in the first place, to make such manipulation pointless.
It can be a problem but at least it can help in maintaining earning if some project stop sending work units, or they need to take a break.
That is why six or so months ago I came up with the Greylist idea. You do understand that its a projects responsibility to keep work units flowing and their relationship with Gridcoin in the positive not the other way around. Gridcoin doesn't contact a project and " hay buddy you are in jeopardy of losing our teams crunching power get work units generated please. "Enigma@home ran out of work units for more than 3 months and was work-less on the whitelist and a matter of fact they announced they ended the project earlier than planned due to no point of working threw the last few dictionary pages when they had already been gone threw 3 times before and would be a waste of their users resources and electricity. We do not just remove projects from the whitelist because we don't like them so someone throws up a vote out of spite. Just like the current votes on new projects , notice 1 is not fairing to well although it would help by adding another GPU capable project to the current whitelist. I agree the list is small , I hate that projects get removed before 6 months vote or no vote. So a few months ago we started discussing a whitelist idea and I doubt its gotten put in front of Rob as its not been talked about officially nor in the current road map. What this would do is similar to what IRC networks do #1 a project would apply for a vote to be on the WL , if accepted this would put them #2 on a trial whitelist ( greylist ) and they have to #3 meet the requirements to stay on the WL as its a projects responsibility to keep work units flowing to crunchers not Gridcoin. This would be something like but not limited to a steady flow of min WU number count over a period of time , minimal allotment for downtime of any sort such as maintenance or bandwidth/power provider and hardware issues or upgrades ( seti@home for example is down every Tuesday planned ) . After 6 weeks of meeting the requirements then the project would be on the actual whitelist , initially the project would have to meet it 100% for the 6 weeks or so to get off the Greylist and get put on the Whitelist. Once on the whitelist if the project has no WU or was down for any reason for the 6 weeks or 3 months what ever is preset it would auto trigger the automated listing system and put the project back on the Greylist and if not fixed in the time frame alloted such as the preset 90 days and the project would automatically be removed no vote needed BUT if fixed in that 90 days it would be put back on the Whitelist automatically. Maybe this system would also help with the project/superblock issue and projects being left off or falling off the whitelist as far as the neural network is concerned as it could also check that the NN has the correct list of honored projects , this could be really important when the team requirement is removed.
This makes it so its not investor whales who don't crunch denying project votes choosing what projects we crunchers have to choose and support , especially since votes for new projects are still being based upon a past foundation vote that states projects are not required to have SSL in order to be on the whitelist ie: xansons4cod.com vote will fail and I would love to have David Anderson comment on the boinc-server and boinc-client and how/if the back-end actually encrypts data or if its just using port 443 to communicate between the client and the server raw data and the only part of the boinc-server that uses SSL is the webserver itself and the website. The greylist gives a standard for projects to meet in order to keep a working relationship with Gridcoin , if those standards are not meet they should not be on the whitelist. The idea is to keep the WL small and not have frivolous projects on it with no work just because they were there at 1 time because the way the coins are given out for the day. A 0 work project can also leave open room for an idle webserver to be compromised while admins are not watching their server look what happened with openSSL the past few years and there are still systems that have not patched , same with ntpd and ddos amplification.
Additionally Gridcoin is a community project , it does not matter who likes you or wants you around etc anybody can join and help in any area. That also means despite the idiotic irc hierarchy that is abused and ignored and incorrectly used that is untrue and ignored other than whom has been around longer and past channel @op's passing it to whom ever was voiced or around still you and me and everybody even Customminer no matter what anyone may think are equal. GRC8 get along clique included.
Yes GPU work units typically are 5 times the data than a CPU WU btw that is a workflow issue not gridcoin aka end users crunching..
@buggy143
Nice Job!
Keep the good work up!
Thanks for sharing
Thanks @qagiri
Congratulations @buggy143! You have completed some achievement on Steemit and have been rewarded with new badge(s) :
Click on any badge to view your own Board of Honor on SteemitBoard.
For more information about SteemitBoard, click here
If you no longer want to receive notifications, reply to this comment with the word
STOPCongratulations @buggy143! You have completed some achievement on Steemit and have been rewarded with new badge(s) :
Click on any badge to view your own Board of Honor on SteemitBoard.
For more information about SteemitBoard, click here
If you no longer want to receive notifications, reply to this comment with the word
STOP