 Show Posts
|
|
Pages: [1] 2 3 4 5 »
|
|
New v1.1 release to address a nonce size calculation bug.
As always, product feedback is always appreciated!
|
|
|
|
Is this proxy support AutoSwitching to most profitable coin on an equihash pool, if so how we can configure it?
While I haven't tried it, I imagine it would work if you use https://miningpoolhub.com for instance. |
|
|
|
Could you please help with installation your proxy on CentOs, I added 2 requests in github.
Hi, thanks for the message - replied to the 'easier' of your two issues already; unfortunately the answer was that it appears you're trying to use Python 3.4, when only Python 3.5 and above is supported. I will give the ZEC nicehash pool support issue some thought, but I'm pretty sure that using any equihash proxy with nicehash isn't possible due to the way they both take the same approach to supporting multiple miners. |
|
|
|
Bitcoin Private team hasn't announced who the official team is yet.
Genuine question, is this still relevant at all? I'd heard that the current BTCP team is vastly different than the one that forked ZCL - I'd be surprised if any of them had the 'keys' to ZCL or its community anymore. My guess would be that ZCL is a free-for-all, and that the BTCP team cannot (ie. is unable to) make this announcement - simply because I assume that it does not have the authority to do so. Case in point; the original BTCP reddit (note, this is not the official one anymore) is still in the hands of Rhett (I'm guessing he's got the mod account `13Chucky`), who's no longer on the BTCP team. BTW, the official reddit sub is here - and note that the official sub has a fraction of the subscribers of the original 🙄. |
|
|
|
|
Version 1.0.2 has just been released: keep-alive fix for non-linux platforms, plus a little help in detecting miner/proxy/pool misconfiguration (via an additional debug statement).
Keep sending me product feedback (via PM or via this thread)!
|
|
|
|
|
A small update (version 1.0.1) has been released today, to add in in worker connection TCP socket keep-alives.
Thanks to everyone who has donated, to keep the project moving!
|
|
|
|
|
Some not very scientific testing reveals that recent versions of `ethminer` deliver a higher hashrate than `bminer` (eth-only) for ETH algo coins. However, `bminer` results were similar to those from `claymore` in eth-only mode. So, I think there is more to gain in `bminer`with regards to eth mining. Looking forward to future improvements!
|
|
|
|
Thank you for your reply. It worked after I opened port 3001 on my router to access this page. Can this block explorer be used as a server to allow electrum to update? OR, can the balance be swept with this block explorer? I need to move funds from the paper wallet. Thanks. The original/official ZCL electrum servers have gone offline. There is a community-driven effort to keep things moving for ZCL - the ZClassic Community Edition team (see posts by 'nimbosa' elsewhere) has worked pretty hard to keep the lights on. https://twitter.com/ZclassicDev/status/979538343204564992 shows that you can add server "electrum.zclassic.community" and port "50002" in your ZCL Electrum settings and everything will start working again. I would think you'd see your original ZCL balance at that point. |
|
|
|
You can try to boot it with only 1 RAM stick and CPU installed. Connect your monitor straight to MOBO's video output and hope for the best.
Take out everything and reseat, be careful not to drop CPU or bend its pins. Also be sure to connect CPU fan to MOBO or your rig won't boot!
I have read things like this before and usually, sadly, you have to RMA your board
Yeah, tried all of those things and nada - still doesn't work. Crap. |
|
|
|
|
I had my 'rig' running well since January, all new components. I had the components precariously placed on my patio table indoors (no frame, just lying loose) - ran without problem. With the nice weather here, it was time to bring the patio table outside so I powered the rig down and dismantled everything.
I got a new shelving unit (wood), so started to put things together again. I attached the mainboard ATX power connector (standard 24 pin), but forgot to attach the ATX CPU power connector (8pin), didn't add any GPUs/risers yet. I hit the power switch, the CPU fan turned for less than a second, then the system shut down. I then noticed I forgot the CPU power connector - so I connected it. Now it won't power on at all, no fan movement whatsoever.
Nothing looks 'wrong' on the motherboard. I tried it with a single PSU. Switched to the other PSU. I tried a backup power switch. Attached a monitor and USB keyboard. Tried shorting the CMOS reset jumper. Nothing yet.
Specs:
Biostar BTC+ 8GPU motherboard
2 EVGA 850W P2 PSUs
- not a factor (yet?)
6x asus rog 1070 GPUs
PCIe risers
Any ideas?
|
|
|
|
yes you def need to turn power back up, i can tell those are 1070 ti, and also reading 50 less than it should be, and then about 100 less than on full tilt, power should be never below 84%, pretty much never above 92% unless catching up or something, currently my 1070 ti's are set to kernel mode, extended msi setting, 94% TPD, +176/+604 (lots of wiggle room with the 1070 ti's, once u go under about 88% the 1070z suffer really hard, keep that in mind when finding a lower efficiency setting.) hopefully a dstm update for windows comes out soon, as we have been waiting a while, 0.7 can be released now and 0.7.1 released in few weeks, we dont have much time so the dev needs to understand we need the miner up to date asap before asics hit and we have to switch coins to mine q=] PS: 4 sols per watt is possible, but who is going to want nor need to turn a 1070 ti down to 58% TPD lol
Incorrect, they are 1070s not 1070TIs. I have, however, optimized their power consumption down to keep fan noise/speed and room temperature low. They are mining at respectable 1070 rates. They have also been mining steady for weeks without crashing, until recently. |
|
|
|
My question is what happens if I run two instances of bminer one for ZEN and other is for BTCP ? both on same pool (suprnova). But without configuring GPU usage. Does one intercept other ? can I fully utilize my GPU power ?
They're different pools, but both owned/run by Suprnova. Yes, you can mine both ZEN/BTCP pools, you just need to specify GPU devices for each running instance of the mining software using whatever the device flag is. Otherwise, the miner will try to use all GPUs for both running instances. |
|
|
|
I had a crash this morning on Linux with DSTM Miner v0.6: *** stack smashing detected ***: ./zmminer terminated  Could you pls provide your startup configuration? Again this morning, same error message. I don't use a config file, I call zmminer in a bash script: ./zmminer --server $server --port $port \ --telemetry \ --user $worker --pass x \ --time >> "$log" 2>&1 Thanks Do your log files contain a 'unresponsive gpu' message before the crash? I didn't see any follow-up on this from `symbiosoft`, but have run into this twice over the last week or so myself. Here are the last few lines of output: 2018-05-07 04:41:33 AM| ========== Sol/s: 2768.4 Sol/W: 4.02 Avg: 2767.2 I/s: 1482.3 Sh: 31.30 1.00 113
2018-05-07 04:41:46 AM| GPU0 55C Sol/s: 460.4 Sol/W: 4.07 Avg: 466.8 I/s: 249.2 Sh: 4.49 1.00 114 +
2018-05-07 04:41:47 AM| GPU2 59C Sol/s: 466.7 Sol/W: 3.97 Avg: 455.7 I/s: 244.6 Sh: 5.16 1.00 116 +
2018-05-07 04:41:47 AM| GPU1 55C Sol/s: 467.2 Sol/W: 4.06 Avg: 465.3 I/s: 249.5 Sh: 5.81 1.00 115
*** stack smashing detected ***: zm_0.6/zm terminated
Aborted (core dumped)
I'm running with this on the command line (Ubuntu Linux 16.04): zm_0.6/zm --time --server us-east.equihash-hub.miningpoolhub.com --port 17023 --user login.rig --pass pass Here's my latest one (this is new, the previously quoted crash was all I'd seen before now): 2018-05-09 05:26:50 PM| ========== Sol/s: 2768.1 Sol/W: 4.02 Avg: 2763.7 I/s: 1479.6 Sh: 2.35 0.99 270
2018-05-09 05:26:50 PM| GPU2 60C Sol/s: 456.8 Sol/W: 3.97 Avg: 455.5 I/s: 243.8 Sh: 0.39 1.00 610
2018-05-09 05:26:54 PM| GPU3 61C Sol/s: 454.8 Sol/W: 3.98 Avg: 456.6 I/s: 244.6 Sh: 0.38 0.99 204
2018-05-09 05:26:57 PM| GPU1 56C Sol/s: 470.0 Sol/W: 4.06 Avg: 466.0 I/s: 249.6 Sh: 0.39 0.99 201
2018-05-09 05:26:59 PM|# server set difficulty to: 00011f7d098fe205b0000000...
2018-05-09 05:27:02 PM|> GPU4 64C Sol/s: 454.4 Sol/W: 4.01 Avg: 459.6 I/s: 246.2 Sh: 0.40 0.99 205
2018-05-09 05:27:04 PM|> GPU0 58C Sol/s: 467.9 Sol/W: 4.05 Avg: 464.4 I/s: 248.3 Sh: 0.41 1.00 202
2018-05-09 05:27:08 PM|gpu_id 1 61 3 unspecified launch failure
2018-05-09 05:27:08 PM|gpu 1 unresponsive - check overclocking
2018-05-09 05:27:08 PM|cudaMemcpy 1 failed
Segmentation fault (core dumped) I assume most others would confirm this is overclock related (duh, the error message?!) - maybe due to the warmer spring weather pushing ambient temperatures up? But, my temps are all consistently below 70C, so this would still surprise me as NOTHING else has changed on this machine since it was rock solid before, other than time has passed and temps have risen. <sadface> Only other option is a loose/malfunctioning riser, I suppose. |
|
|
|
BUT there is now 0 balance in my ZCL wallet and the amount I imported into BTCP shows as "sent" in ZCL. In other words, it looks like the ZCL sent to the BTCP wallet rather than duplicated 1:1 between the two. Is that even possible?
Any help would be much appreciated as I'm really worried I've lost the ZCL! x
The original/official ZCL electrum servers have gone offline. There is a community-driven effort to keep things moving for ZCL - the ZClassic Community Edition team (see posts by 'nimbosa' elsewhere) has worked pretty hard to keep the lights on. https://twitter.com/ZclassicDev/status/979538343204564992 shows that you can add server "electrum.zclassic.community" and port "50002" in your ZCL Electrum settings and everything will start working again. I would think you'd see your original ZCL balance at that point. |
|
|
|
I had a crash this morning on Linux with DSTM Miner v0.6: *** stack smashing detected ***: ./zmminer terminated Could you pls provide your startup configuration? Again this morning, same error message. I don't use a config file, I call zmminer in a bash script: ./zmminer --server $server --port $port \ --telemetry \ --user $worker --pass x \ --time >> "$log" 2>&1 Thanks Do your log files contain a 'unresponsive gpu' message before the crash? I didn't see any follow-up on this from `symbiosoft`, but have run into this twice over the last week or so myself. Here are the last few lines of output: 2018-05-07 04:41:33 AM| ========== Sol/s: 2768.4 Sol/W: 4.02 Avg: 2767.2 I/s: 1482.3 Sh: 31.30 1.00 113
2018-05-07 04:41:46 AM| GPU0 55C Sol/s: 460.4 Sol/W: 4.07 Avg: 466.8 I/s: 249.2 Sh: 4.49 1.00 114 +
2018-05-07 04:41:47 AM| GPU2 59C Sol/s: 466.7 Sol/W: 3.97 Avg: 455.7 I/s: 244.6 Sh: 5.16 1.00 116 +
2018-05-07 04:41:47 AM| GPU1 55C Sol/s: 467.2 Sol/W: 4.06 Avg: 465.3 I/s: 249.5 Sh: 5.81 1.00 115
*** stack smashing detected ***: zm_0.6/zm terminated
Aborted (core dumped)
I'm running with this on the command line (Ubuntu Linux 16.04): zm_0.6/zm --time --server us-east.equihash-hub.miningpoolhub.com --port 17023 --user login.rig --pass pass |
|
|
|
I run 8 x 1070 in one rig, 6 x 1080Ti in one rig and 5 x 1080Ti in one rig. they all run together in their own rig build. I mean, I run zm batch to work 8x1070 together and others respectably in their own.
while running, the target difficulty is set by the server (any chance to achieve static difficulty through miner?). the target difficulty is somehow too high for the 1080Tis which in return I get only 7,5 - 10 shares per minute in average; that being said I get zero returns on payment on some blocks randomly.
but with the 1070s, even though they are %60 solutions capable against 1080Tis, I have around 60 shares per minute in average.
you can say that the size of the share 1080Tis get is larger than 1070, I agree, but it is like more than 6 times the share I get with 1080Tis. so considering the solution power of two, 6 times is much bigger than %60 solution power in between these two.
I've tried this while mining BTCG in suprnova and MPH. I think this is because the target difficulty setting.
Honestly, I think you'll need to wait for a payout to see if you can see the earnings differences - looking at hash or share rate alone (particularly at the pool level!) to compare completely different rigs isn't going to be accurate. Earnings per rig is pretty much the only way to determine anything. That said, if you're looking to have the same target difficulty across all your rigs, you might try running a mining proxy. Makes things slightly more efficient networking wise as well. I have recently created one that works with equihash (and other algos/coins) called aiostratum-proxy (see my signature as well). |
|
|
|
Is there anything for Ubuntu, how MSI AFTenberner for Windows?
Yes, there are lots of posts all over the internet about how to adjust OC settings in Linux, but there aren't any (I don't think?) graphical tools like Afterburner. You use the command line (see below), and once you figure things out, it's actually better than Afterburner. Everything based in percentages is really useless for sharing with others. For example, telling someone you set the power to 70% is useless without knowing what the TDP is for a particular card. However, telling someone the specific wattage setting + the card is better. Here's what I use with my 6x Asus ROG Strix 1070s: # These two lines allow me to run the rig 'headless' (without a monitor)
# Without them, the nvidia commands below won't run unless you log into the Ubuntu graphical UI.
export XAUTHORITY=/var/run/lightdm/root/:0
export DISPLAY=:0
# This enables power management
sudo nvidia-smi -pm 1
# This sets the desired power consumption to 115 watts (no percentages here; specificity!)
sudo nvidia-smi -pl 115
# this tweaks core and memory clock settings and sets the fan speed (ok, fan speed is a percentage...)
sudo nvidia-settings -a GPUPowerMizerMode=1 -a GPUGraphicsClockOffset[3]=200 -a GPUMemoryTransferRateOffset[3]=1050 -a GPUFanControlState=1 -a GPUTargetFanSpeed=25 |
|
|
|
One of my rig is constantly crashing - "cuda 1 memory failed". It has 6 msi armor 1060 6gbs.
I have tried almost all clocks in order to stabilise it.
Now I am running with no clocks only 80% power limit and it keeps crashing. I noted that when temp limit is set to 70C rig is more stable.
Can you please someone assist me as I am desperate for help. Please help me what can be the problem here?!
As you've tried different clocks, I'd guess it's a hardware issue. Perhaps riser/cable related - it isn't uncommon from what I've read/seen. |
|
|
|
Great to see a new OSS project and a brave dev making it open source.
Thanks. Not sure I'll be considered the brightest dev for making it open source, but I'll take 'brave' for now. 🤔 In order to get more traction it would be useful to handle worker names transparently, that is presenting to the upstream pool each and every worker name behind the proxy. Sometimes, when you have 20 workers, you'd need to somehow check their hash stats with the pool.
Good news! Let's get ready for traction! Although not currently documented (my bad, sorry), it already is able to do this. It just requires a minor change in the config. This line of code extracts the worker name from the miner's authorization and appends it to the config file's pool account name, but ONLY IF the config's pool account name doesn't already have a worker name set. My examples in the original post have ".rig1" in the account_name settings (see the following): proxies:
- worker_class: aiostratum_proxy.protocols.equihash.EquihashWorkerProtocol
pool_class: aiostratum_proxy.protocols.equihash.EquihashPoolProtocol
listen:
- host: ''
port: 10666
pools:
- host: pool2.btcprivate.org
port: 3032
account_name: b1CACK65UTwzmHGw2VvyozdPsRLMb8utGLg.rig1
account_password: x
If ".rig1" is removed from that line, aiostratum-proxy will pull the worker name from the miner's authorization - so, like this instead: proxies:
- worker_class: aiostratum_proxy.protocols.equihash.EquihashWorkerProtocol
pool_class: aiostratum_proxy.protocols.equihash.EquihashPoolProtocol
listen:
- host: ''
port: 10666
pools:
- host: pool2.btcprivate.org
port: 3032
account_name: b1CACK65UTwzmHGw2VvyozdPsRLMb8utGLg
account_password: x
At least, it should! I will update the original post to describe this Updated! Thank you for pointing it out. |
|
|
|
I just announced new mining proxy software, see the BCT post here: https://bitcointalk.org/index.php?topic=3179895Open source, no devfee, multi coin/algo, just aiming to help miners out. Building it has been a great learning experience in the mining technology ecosystem. I appreciate the feedback - happy mining. Spread the word! How exactly does a 'proxy' work? Simply put, it sits in the middle between your miner(s) and your pool(s), in an effort to consolidate multiple miners/rigs through a single connection to the pool. Your miners connect to to the proxy, and the proxy connects to the pool (just once, even for multiple miners), resulting in a single difficulty for all connected miners. Without a proxy, your miner connects directly to a pool. There's nothing wrong with this, generally speaking - but with miner crashes/restarts due to overclocking or bugs, the miner has to reconnect to the pool. This can mean that your miner is seen by the pool as 'new' after reconnecting, which is generally considered a bad thing (you can lose out on shares/sharerate as you might be treated as a pool hopper). It's important to note that there are multiple factors involved, and over time pools are likely trying to get better at detecting pool hopping more precisely. With a mining proxy sitting in the middle, the proxy maintains the connection to the pool on miner disconnect, the proxy keeps track of current difficulty and mining job, etc. When miners reconnect, they receive those same values - essentially picking up where they left off. The pool doesn't see any disconnects, and so any impact from pool-hopping isn't attributed to your account. In the past, others have stated that a 20% improvement in sharerate/shares/reduction in stale/invalid shares have been achieved through the use of a proxy. I'm interested whether this still holds true, assuming that miners and pools have actually improved over the last couple of years, which may not be that true... 🤔 Thanks... is it secure and not hackable? Can you explain your concerns more deeply? It's secure if your network is secure. The worst a bad actor could do (if your LAN is unsecured or they are already present on your network) is send invalid shares to your proxy. If that's a concern, then adding proxy-local authentication would address that (already on the list if important to others). The described method of installation always installs the latest canonical version, so if people are following instructions, they will have the official version, not a modified version. Without knowing your concerns more deeply, it's hard to answer. But maybe it's better to have this discussion via PM or on the announcement thread to avoid polluting dstm's thread here. https://bitcointalk.org/index.php?topic=3179895 |
|
|
|
|
