search

cazala / coin-hive-stratum

use CoinHive's JavaScript miner on any stratum pool
http://npmjs.com/package/coin-hive-stratum
416 stars 465 forks source link

Hash Rate #138

Open pb376 opened 6 years ago

pb376 commented 6 years ago

I've noticed that my hash rate is about 25% lower when using this proxy with a pool (supportxmr) versus CoinHive itself. I've tried tweaking the difficulty settings to see if that could improve the rate, but to no avail. Is this something that should be expected? If not, could anyone suggest some places I could look to try to improve the rate?

letlet commented 6 years ago

supportxmr has a fixed diff (may be 1000) and Coinhive's diff is much lower(may be 200)

pb376 commented 6 years ago

I installed xmr-node-proxy to reduce the diff for the miners to 100 but the results were not much different. I'm not too familiar with the internals of miners and pools, but I was wondering if a low diff would result in the mining clients having more downtime as they quickly finish the calculations and potentially sit and wait for the next job from the pool, which would hurt the overall hash rate. If the clients queue multiple jobs so they always have a new job immediately available after they complete one, however, this would not be an issue.

One thing I did notice is that after running for a while the coin-hive-stratum proxy begins outputting a fair amount of proxy/authentication errors. This could explain an eventual drop in hash rate, but not the discrepancy I'm seeing.

I'm still using the Coinhive lib directly, not the self-hosted assets, so that could possibly be causing some of the gap as well (I can't use the self-hosted assets in my situation, so I can't test this.) Initially I thought that CoinHive may intentionally hurt performance if it detects you using a proxy that doesn't belong to them in order to dissuade people from leaving their pool, but it seems unlikely.

I also saw that CoinHive has many shards the miners can use, whereas I'm using one, so I guess there's also a chance they're doing some location-based load balancing to minimize for network latency. However I don't see that making such a large impact.

adamdupuis commented 6 years ago

Lower diff means the miners submit jobs more frequently and do not get beat out as much so it would be better for web miners. Check out http://moneroocean.stream/ - they seem to support web mining and have a lowest difficulty of 100. I'm thinking about switching from SupportXMR to them as well.

pb376 commented 6 years ago

I tested out moneroocean earlier today and the results were better, but not by too much.

I decided to split-test vanilla CoinHive versus this proxy and a pool earlier as well. Originally, before the split test, I was seeing ~5k hashes per second to the pool. After the split test I saw about ~5k hashes per second across both CoinHive and the pool simultaneously - double the hashing power on the same traffic. Approximately 10k hashes per second is what I was expecting from the traffic, so I’ve been wondering if there was some kind of inherent 5k hps limit by using this proxy. I haven’t tested 100% of the traffic inn CoinHive yet, but I probably will do so tomorrow.

adamdupuis commented 6 years ago

What throttle do you set it to and roughly how many miners did you have connected to get 5k hps?

pb376 commented 6 years ago

On the proxy I saw approximately 450 miners with a throttle set to 0.7.

pb376 commented 6 years ago

I tweaked some OS settings (primarily max open file descriptors and some kernel tcp memory limits) and it seems like the problem is solved.

However I now notice that the number of miners and overall hash rate decreases over time. If I restart the proxy then the number of connected miners and hash rate are both about 10% higher than they were when the proxies were previously running. Has anyone else experienced this?

I'm thinking it could be related to the invalid job id errors as I currently see a fair amount of them. Right now I have two coin-hive-stratum proxies feeding into one node-xmr-proxy that then splits traffic to two different pools. Is it possible that at some point the job is being submitted to the wrong proxy or pool?

This could potentially happen after a reconnect - the miner may still be mining the last job, reconnects, gets assigned to a new pool, and then tries to send the old job to it? I believe I've read that people have experienced this error while using just one proxy and pool, so that would mean this was likely not the cause; further, since the pool balancing is performed by xmr-node-proxy, that would mostly be an issue on their end. However, as donations are sent to a different pool than the user-configured one, it may be possible that donations can trigger this scenario without the usage of xmr-node-proxy. Even if this is true, I don't really see why it occurs so persistently only after running for an extended period of time.

Any input or ideas would be greatly appreciated. I have very limited time to work on this project but if someone can identify the root cause I can create the fix, as I'm not a huge fan of my current restart-every-hour solution...