are you going to opensource this project?
since you are "charging" for premium features i suppose not
Exactly, it a lot of work from me to create that ... it's not in the roadmap to opensource the project too bad on another note, since i have also created monitoring and management software for mining, im curious how you solve the problem of information masses: i developed my software primarily for myself, but its foss so anyone can use it. Currently the most condensed setup is using two whole 1920x1080 websites, on one are web stats (pool, wallet, hardware stats (ohm)), on the other are miner stats from the mining software like claymore-* or nheqminer, or or or etc it gets quite messy with my currently 17 devices each running at least one miner (some with mixed rigs running multiple for maximum profitability) for me it looks something like this: http://img.ctrlv.in/img/17/01/08/5872a448265ff.pnghttp://img.ctrlv.in/img/17/01/08/5872a49e48462.pngwith your current displaying solution and using 17 rigs it would become a endless scrolling  im curious, are you planning to extend this for larger deployments? im aware your stats are not as complete as mine, and i lack some functionality and stats you have but its still al lot to somehow display in a readable format cheers |
|
|
|
|
are you going to opensource this project?
since you are "charging" for premium features i suppose not
|
|
|
|
There is a profitability calculator problem at miningpoolhub.com, I mined xmr for 11 hours straight at 7.5 kh\s average as they graph showed and i just got 0.16 xrm whereas it was supposed to be 0.4 with fees deducted, difficult decreased since i started so minimum would have been 0.45 xmr, has anybody had the same problem? Something is not right. i'd like if any miningpoolhub admin can see what was wrong, this is like 200% less than i was suppose to get, PPLNS based should be giving me 30% more or less, but 200% less begs the question of what is wrong with the pool. here are the images as proof.   For me it wasnt that drastic (but im also only mining with 1kh), but i noticed i was getting almost the same, if not less, earnings as on nicehash so i switched. |
|
|
|
is it possible to use sgminer-gm with nicehash for daggerhashimoto?
tried it but didnt get any accepted shares, 0.000 H/s and "rejected untracked stratum share" once in a while
cheers
anybody? |
|
|
|
Yes, this is used in NHM right now.
Regarding crashes. We will not deny that it cannot happen. We used some unsafe shared memory to gain extra speed. The crash possibility is very low. That is why there are auto-restart scripts included. If crash happens, it will not break your driver, so restart fixes it and you keep on mining.
Yeah that's why when i saw the script i was telling myself "hummm maybe this one isn't as stable since they put this script" ahah  Latest EQM seems to have stability issues, what about you all others fellow miners ? Im not able to keep it from crashing with same level even 5% lower OC than previous EQM version. Keep randomly crashing every 3-4h, happily i got my nice monitoring scripts to pick-up so mining downtime isn't that much but still annoying  by the way nicehash guys, how do you use the monitoring/api port you can start with -a xxxx is that feature working ? i don't see any datas or port even being opened. for me it works as in nheqminer: you query "status\n" on a raw socket on the port and get a json result back (though the last version i tested it with was a while back, but if nothing broke it it should still work) Ah ok got it, the port is only listening on localhost, so you can't remotely query it, how silly of me it was actually in plain sight in the help (-a [port] Local API port) . It indeed work on localhost, thx for sharing. edit : echo "status" |nc localhost 4444 |jq "." { "method": "status", "result": { "connected": true, "interval_seconds": 300, "speed_ips": 1274.77, "speed_sps": 2380.54, work, very nice status was enough no need for the newline \n or carriage return \r Nicehash guys would be nice to be able to bind the admin port to a network card for remote query  "echo" automatically appends newline for you |
|
|
|
Latest EQM seems to have stability issues, what about you all others fellow miners ? Im not able to keep it from crashing with same level even 5% lower OC than previous EQM version. Keep randomly crashing every 3-4h, happily i got my nice monitoring scripts to pick-up so mining downtime isn't that much but still annoying by the way nicehash guys, how do you use the monitoring/api port you can start with -a xxxx is that feature working ? i don't see any datas or port even being opened. for me it works as in nheqminer: you query "status\n" on a raw socket on the port and get a json result back (though the last version i tested it with was a while back, but if nothing broke it it should still work) |
|
|
|
|
the private stratum is down/flappy for me, anybody else? observed since about 4 hours ago
edit: seems to be working again now
|
|
|
|
|
is it possible to use sgminer-gm with nicehash for daggerhashimoto?
tried it but didnt get any accepted shares, 0.000 H/s and "rejected untracked stratum share" once in a while
cheers
|
|
|
|
i plan to somehow enable pools to be configured with priorities in my own software (currently miner-manager, but somewhere soon an aio management software should replace all the different programs i have written)
ideally i configure a device (that is a rig/computer) to have miners and mining groups which have a set of pools configured to use. These pools have priorities (eg. 1, 10, 30) and also autoswitching for nicehash pools is just another pool in this list.
for example i plan to configure nicehash autoswitching pools to be prio 10, some other backup pool (maybe mph) with 20. I might also add another temporary pool on which i want to mine just shortly with prio 5 and disable it later on. in any case one of the stratums goes down, the miner should switch to the next pool in prio order.
im not very familiar with stratum and the details of how to communicate with it but from what ive read its just json rpc over sockets, so i *could* query the pool status myself *somehow* (dont know which methods are enough to verify stratum is working) and just create a stratum checker module my software uses
It would be possible for you to add a stratum checker to a miner manager but the miner will still create its own conection. Every miner does this, changing it requires changing every miner you want to support. yes indeed, i hoped for some of the miners to be able to handle this on their own, many already support this/some sort of, best miner in this regard seems to be sgminer |
|
|
|
Hi joblo,
i just noticed there is no note of failover support, is this possible already? (just use multiple stratum addresses etc like claymore miners do)
i checked ccminer (which cli parameters are very similar) which has one note of failover support back from 2015, but it seems this is only possible via config file.
would be a great addition to the miner to have failover support/define multiple pools via cli and they are getting used in the order they are appended.
cheers
Failover can be easilly implemented using a shell script and "cpuminer -r 0". It can do exactly as you suggest. i fail to see how this would allow automatic switching to the main pool after recovery (one may be able to just restart the whole miner (script) every n minutes to achieve this, but thats just ugly) to achieve this one has to monitor the "main" pool and all other backup pools for availability and switch back to the higher prio one if recovered of course i might be able to run a single miner on the main pool and detect the failed connection via stdout/err passing and start another (second) miner using the second pool while still running the (not connecting) main miner and killing all other miners if the main miner reconnects, but thats also very ugly am i missing something here? What you are asking is more than I am willing to do just for fun. With a shell script you can put a timelimit on the backup pool. You won't detect exactly ewhen the primary pool recovers but you're still mining something until the backup times out. If the primary pool is still down it will immediately switch back to the backup. It's not perfect but I don't see the feasibility in going the next step. I don't see pool failures as a big problem and I don't see much gain from smoothing out the failure/recovery. The overhead of restarting the miner is trivial. What exactly do you expect to gain? i plan to somehow enable pools to be configured with priorities in my own software (currently miner-manager, but somewhere soon an aio management software should replace all the different programs i have written) ideally i configure a device (that is a rig/computer) to have miners and mining groups which have a set of pools configured to use. These pools have priorities (eg. 1, 10, 30) and also autoswitching for nicehash pools is just another pool in this list. for example i plan to configure nicehash autoswitching pools to be prio 10, some other backup pool (maybe mph) with 20. I might also add another temporary pool on which i want to mine just shortly with prio 5 and disable it later on. in any case one of the stratums goes down, the miner should switch to the next pool in prio order. im not very familiar with stratum and the details of how to communicate with it but from what ive read its just json rpc over sockets, so i *could* query the pool status myself *somehow* (dont know which methods are enough to verify stratum is working) and just create a stratum checker module my software uses |
|
|
|
|
OR just create your personal git repo with the claymore files and let each rig get the latest version via "git pull" executed by a script every n minutes.
|
|
|
|
could you guys let me no where you bought your baikal miners from I was looking but heard of a few sites that are a scam Thanks
i bought mine straight from baikalminer.com, contact has been done via skype |
|
|
|
Hm.... so what is the final difficulty level you got after several minutes?
I want to know the difficulty level when it is stabilized.
Actually monero is quite difficult to deal about difficulty value because there's no "set difficulty" command in monero's stratum protocol. I don't know who wrote this stratum protocol, just I couldn't find the appropriate command for it.
New difficulty is sent by every work job, and this job need to be sent rarely to not disturb already running job.
I would have to limit difficulty increase/decrease level.
I'll test more and find optimal solution.
Thanks.
stabilized diff is 5k, i believe it would go lower if the server would allow it (5k gives approx 2.4 shares per minute with 240H/s and 0.9 shares per minute with 80H/s) Thank you for detailed info. I fixed some issues that didn't start with last difficulty value and manual starting difficulty hint (d=XXX) option. It worked well before, but broken after I changed some other stuffs. Also I lowered minimum difficulty value from 5000 to 2000. I hope you like it. Thanks. thanks working fine have not tested d=xxx option as the last diff (2k) got picked up correctly after a 30 minute pause, thanks |
|
|
|
Hi joblo,
i just noticed there is no note of failover support, is this possible already? (just use multiple stratum addresses etc like claymore miners do)
i checked ccminer (which cli parameters are very similar) which has one note of failover support back from 2015, but it seems this is only possible via config file.
would be a great addition to the miner to have failover support/define multiple pools via cli and they are getting used in the order they are appended.
cheers
Failover can be easilly implemented using a shell script and "cpuminer -r 0". It can do exactly as you suggest. i fail to see how this would allow automatic switching to the main pool after recovery (one may be able to just restart the whole miner (script) every n minutes to achieve this, but thats just ugly) to achieve this one has to monitor the "main" pool and all other backup pools for availability and switch back to the higher prio one if recovered of course i might be able to run a single miner on the main pool and detect the failed connection via stdout/err passing and start another (second) miner using the second pool while still running the (not connecting) main miner and killing all other miners if the main miner reconnects, but thats also very ugly am i missing something here? |
|
|
|
|
Hi joblo,
i just noticed there is no note of failover support, is this possible already? (just use multiple stratum addresses etc like claymore miners do)
i checked ccminer (which cli parameters are very similar) which has one note of failover support back from 2015, but it seems this is only possible via config file.
would be a great addition to the miner to have failover support/define multiple pools via cli and they are getting used in the order they are appended.
cheers
|
|
|
|
@miningpoolhub
Has the site been having problems on the Baikal ports? My Baikal has been shutting down randomly and has to be reset, OR it goes to a fail-over pool. It never did this before the recent server move.
I've been running a number of baikals here, no problems that I've noticed. I'll keep a closer eye on it for a bit and let you know if I see anything. This is what mine is doing. In fact it was down when I just checked it and got it going again. https://s29.postimg.org/lbgmaqznb/Baikal.jpgNo problems here... But I am only mining dash atm.. Could you set one of your Baikal's to mine the ASIC Baikal to see if you have problems? I've been watching mine(since I'm bored) and the problem seems to happen SOMETIMES on a coin change. It doesn't do it every time, but when mine goes down it is during a coin change. I only use auto-switch. Let me go look at it, I've not checked since I posted. It looks like it correctly auto-switched about 45 minutes ago. I might power your unit down, unplug the adapter so the caps drain (like, for a minute or two) then fire it back up. If you're comfortable SSHing into the device (the login is the same as the web interface) you could do a "sudo shutdown" before you pull the plug to let it shutdown gracefully. Let me know if that helps. i had the same problem some time back for me my baikal miners were running the first multi-algo image (v2.1 orange pi image) and an upgrade to the v2.2 image fixed it (v2.2 is the image with nicehash, mph and zpool multi-algo switching officially supported) might be worth a try if you are running v2.1 |
|
|
|
Hm.... so what is the final difficulty level you got after several minutes?
I want to know the difficulty level when it is stabilized.
Actually monero is quite difficult to deal about difficulty value because there's no "set difficulty" command in monero's stratum protocol. I don't know who wrote this stratum protocol, just I couldn't find the appropriate command for it.
New difficulty is sent by every work job, and this job need to be sent rarely to not disturb already running job.
I would have to limit difficulty increase/decrease level.
I'll test more and find optimal solution.
Thanks.
stabilized diff is 5k, i believe it would go lower if the server would allow it (5k gives approx 2.4 shares per minute with 240H/s and 0.9 shares per minute with 80H/s) |
|
|
|
i noticed the starting diff for monero is very high, is it possible to lower it?
also it seemed to first increase it and then lower it after some minutes (20k -> 30k -> 5k) even though it did not find any shares (0 shares for at least 3-5 minutes)
Starting diff is roughly tuned for 6 way rig. 20k, target time 30 seconds. It goes up and down to match to your hashrate at first connection, and this difficulty value will be reused when you reconnect. So your miner will not waste time again. Please tell me your hasrate and average difficulty value after stabilized. I'll consider it to set lower. my hashrate is 40 to 200 H/s depending on the cpu used, diff seemed to stabilize at around 5000, though it seemed to be the minimum possible by the server. setting the starting diff with d=5000 (or even d=10000) didnt work here is a screen that shows what im talking about with the increasing diff before finally lowering:  diff started with default 20k, increased to 140k (!!), after that it lowered slowly. it finally got an accepted share after 7 minutes with 16k:  |
|
|
|
i noticed the starting diff for monero is very high, is it possible to lower it?
also it seemed to first increase it and then lower it after some minutes (20k -> 30k -> 5k) even though it did not find any shares (0 shares for at least 3-5 minutes)
Starting diff is roughly tuned for 6 way rig. 20k, target time 30 seconds. It goes up and down to match to your hashrate at first connection, and this difficulty value will be reused when you reconnect. So your miner will not waste time again. Please tell me your hasrate and average difficulty value after stabilized. I'll consider it to set lower. my hashrate is 40 to 200 H/s depending on the cpu used, diff seemed to stabilize at around 5000, though it seemed to be the minimum possible by the server. setting the starting diff with d=5000 (or even d=10000) didnt work |
|
|
|
|
i noticed the starting diff for monero is very high, is it possible to lower it?
also it seemed to first increase it and then lower it after some minutes (20k -> 30k -> 5k) even though it did not find any shares (0 shares for at least 3-5 minutes)
|
|
|
|
|
Show Posts
