I get it. Do you happen to have the info on how many Windows users there are, compared to the Linux users?
This is just a guess, since I dont have those figures, although that brings up a good point, that we should make an attempt to grab those figures for development purposes.
Based on my experience with other coins, believe it or not, its usually an 80% windows download rate, 20% linux (1% mac).
However, I believe with BiblePay, we have a handful of grass-root linux supporters who seem to run a high quantity of nodes (IE they seem to
have excess money laying around for hobbies, and/or have some relationship to cloudmining). We might be attracting people who deal with excess PC resources, being the only coin that hasnt been exploited by GPUs.
Anyway, Im going to guess that out of 750 users, 70% are still PC users, but I believe personally that if you went with node count, we would be along the lines of 1000 nodes with 50% being linux nodes... So the linux count is probably skewed due to ROI and huge quantity per hobbyist.
(There are stories on the internet of some coins that tried to launch as linux-only, and they always died.)
Very interesting analysis, thank you. I had the exact same thoughts about Linux hobbyists with money or a relationship to cloud mining or access to a lot of unused PCs, perhaps even in some organization.
Do you think there's a way to make the wallet detect OS version so that you could then run a report command just like with version numbers?
Correct, exactly, you nailed it. Well, ideologically I guess it's not bad to favor the mid to small miners for high decentralization purposes, but I am still wondering from the technical side of things, is that a bug in the algo or something.
Alrighty a guess and some homework for you is all I can offer on this today:
So the old algorithm had an outer loop of 1000 X11 hashes and an inner loop of one biblepay hash, meaning that if you ran 80 threads on x11-bbp pre F7000, that distributed thread could conduct its hashing without the resources of the full node. (Whenever the miner needs to access the resources of the full node, for example, asking it for AES/md5/chaining the KJV together) grabbing the pindex bestblockindex map, it is in a way locking the thread for a few milliseconds and grabbing its data and then continuing. In the NEW world, in F7000, its hashing only one X11 hash (for the blockindex), yet 1000 BibleHashes of work being expended per loop. So its no longer able to decentralize a thread with just a math problem (IE x11 solution), and come back and join the rest of the threads, instead, its doing a lot of biblehash->askfullnode->biblehash->askfullnode, etc.
So my guess is this: In f7000, there is a strong reliance on the full nodes availablility, and the thread itself can only do so much work before its waiting around for availablility of the data it needs (like a blockindex for example, from the map). The reason the kernel cant allow two threads to read the same value simultaneously is that would cause a segfault error.
So what I recommend is this: Find a way to run multiple copies of biblepay on one server, and do a side by side comparison of those specs with the sum of the hash of biblepay instances. If the hash throughput is higher on the multiple copies, then we know that I said above is true and the only way to consolidate hardware to high power servers is then to run multiple instances per node.
On a side note if we find that to be the case then that is good- as you said earlier -part of the benefit of requiring the full node is to reward the decentralized full node environment (IE not the people with the biggest nodes) as part of the original vision is to not be greed based but to be service oriented.
A bit more technical lingo than I am able to handle right now, but I got the gist of it.
I have some errands to do now, but in the evening or tomorrow I will try to run two nodes on one machine and will report back with the results, to see if your theory is correct (I have a feeling it is).
Awesome work, very fast.