I haven't gotten around to adjusting the parts needed for the R606 to run on macOS yet. If you want it to try to run it there, you'll need to make an adjustment to use the R606 branch: curl -o cgminer.rb "https://raw.githubusercontent.com/vthoang/homebrew-cgminer/master/cgminer.rb"
edit the cgminer.rb file and change branch from 'master' to 'r606' followed with: brew install --build-from-source ./cgminer.rb
I'll get around to testing that when the branch gets merged back. At which point it should mostly fix itself. |
|
|
|
|
For mining, there's just a small block of json text that is sent back and forth every once in a while.
Per miner, bi-directional, you won't be sending more than 1 KB of data per second.
The entire blockchain is about 225GB.
If you installed bitcoin-qt, you'll potentially eat up a couple of hundred GB over a few days.
|
|
|
|
I'd like to try and run a single instance of cgminer for each stick and see how they do on their own. However, I'm not sure how to enter in the "--usb :1" command on a windows pc. I'm using a gekkoscience usb hub and I'm unclear if I need to account for the usb hub when entering in command just mentioned.
Could someone kindly post an example on how to correctly enter in this command?
You can append it as is into the command line. There should be a single_test_mining.bat included in the unzipped directory, which has that particular option set, for use as a reference. If you want to target a specific device, you can use "cgminer -n" to get the bus:device_no. Check the README file for the --usb syntax. If you want to target a specific gekkoscience miner you'll need to grab a more recent in-progress build: https://bitcointalk.org/index.php?topic=5053833.msg50023699#msg50023699 |
|
|
|
@merlin3650 I had some measurements a little further into the thread. https://bitcointalk.org/index.php?topic=5053833.msg47766551#msg47766551I'll bring some of those numbers back to the first post in a moment or two. @evade_57 For each device, cgminer spins up a dedicated set of supporting threads. So they are suppose to work like their own instances. In general, it's okay to mix until you run out of share resources, (cpu, memory, bandwidth, power). A miner that doesn't behave can potentially draw resources away from healthy ones which: - can affect other miners sharing the same regulator. - can affect other miners sharing the same cgminer instance. Probably good to group them in a meaningful way to control the collateral devices that are effected, should you need to: - troubleshoot / tune a miner. - restart cgminer. - move the hub. - change pools. - restart the computer. |
|
|
|
Edit: I think it is normal for miners to make child connections, bcz i have seen it on normal working miners log but i dont know what is it for ? and here the problem is it can not authenticate.
Not normal, just temporary functioning so that it's not too obvious. You can go ahead and assume ALL miners have been compromised. For sure any device with IP in this pattern: Bad password attempt for 'root' from 192.168.2.15:57652
As soon as you flash the firmware and plug it into your network (to log in and change the password?), all other compromised miner immediately begins the hijack process, likely succeeds, and sit dormant before you even log in. At some point later (soon or not) it changes and unchanges the pool settings at random interval so you won't notice. A misc note regarding that address that the compromised devices will eventually route to: https://bitcointalk.org/index.php?topic=5036968.msg50011282#msg50011282. Multiple networks as suggested above to work with is probably a good way to approach it while you try to solve the issue. If you are able to, flash them all within a network before powering any on. If you flash them all before you power any of them on and still have the same issue eventually, then: 1) the firmware is a very probable source of the evilness or 2) and external pc/laptop or hardware has been compromised. In which case you'll need to take your best guess to swap out the possible culprit and repeat. |
|
|
|
16 Zone - Rachio 3 Smart Sprinkler Controller Includes enclosure in photo & ground shipping USA. Price: $250 (Shipped - USA)   BTC Only. Can accommodate with or without escrow handler, PM me if interested. EditWill be including free 2nd Gen Echo Dot in shipment to control it. https://www.rachio.com/alexa/ |
|
|
|
hmm. that is definitely a new / unreported one. looks like part of libusb complaining. use this to forcefully bypass the manual intervention part: :loop_forever
cgminer.exe -o ...
goto loop_forever
small side effects: - you lose visibility to other errors. - you won't be able to press q to quit. |
|
|
|
Nginx in stream mode should be able to do what you need. https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/Edit: The generic tcp proxy works just fine. Seems like adding and removing backends dynamically only affects new incoming connections. You'll need a creative way to kill existing. A shell script to rotate config, then stopping and starting nginx seems to do the job. Not awesome though. Here's a short load balance example on Ubuntu 18.04 to get you started. apt-get install -y nginx-extras
cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.orig
cat <<EOF >>/etc/nginx/nginx.conf
stream {
server {
listen 3333;
proxy_pass mining_backend;
}
upstream mining_backend {
server stratum.kano.is:3333;
server stratum.slushpool.com:3333;
}
}
EOF
nginx -t
nginx -s reload
Part 2: By installing nginx-extras instead of plain nginx, you have access to lua for the creative reset component. Use the examples in the link above to dynamically add/remove your desired pool backend(s), then force the miners to reconnect with the lua block below. location /drop_connections {
default_type 'text/plain';
content_by_lua_block {
os.execute("(sleep 1; ps aux | grep 'nginx: worker process' | grep -v $$ | awk '{print $2}' | xargs kill -9) &")
ngx.say('dropped')
}
}
Part 3: While putting it all together, I discovered the backend api are part of nginx+ and not the community version. With lua available, we can quickly skip that and make it happen with a little rearranging: First update /etc/nginx/nginx.conf. stream {
server {
listen 3333;
proxy_pass mining_backend;
}
upstream mining_backend {
include /etc/nginx/mining.conf;
}
}
Then grant the nginx child processes the ability to tweak nginx related configuration. touch /etc/nginx/mining.conf
chown www-data:www-data /etc/nginx/mining.conf
echo "server stratum.kano.is:3333;" > /etc/nginx/mining.conf
cp /etc/sudoers /etc/sudoers.orig
echo "www-data ALL = NOPASSWD:/usr/sbin/nginx" >> /etc/sudoers
Finally, in the server directive of /etc/nginx/sites-enabled/default: location /switch_to_kano {
default_type 'text/plain';
content_by_lua_block {
os.execute("(sleep 1; echo 'server stratum.kano.is:3333;' > /etc/nginx/mining.conf) &")
os.execute("(sleep 2; sudo /usr/sbin/nginx -s reload) &")
os.execute("(sleep 3; ps aux | grep 'nginx: worker process' | grep -v $$ | awk '{print $2}' | xargs kill -9) &")
ngx.header["Content-type"] = "text/plain"
ngx.say('switching to kano.is')
}
}
location /switch_to_slush {
default_type 'text/plain';
content_by_lua_block {
os.execute("(sleep 1; echo 'server stratum.slushpool.com:3333;' > /etc/nginx/mining.conf) &")
os.execute("(sleep 2; sudo /usr/sbin/nginx -s reload) &")
os.execute("(sleep 3; ps aux | grep 'nginx: worker process' | grep -v $$ | awk '{print $2}' | xargs kill -9) &")
ngx.header["Content-type"] = "text/plain"
ngx.say('switching to slushpool')
}
}
My local end results of this setup: Miner mined when connected to stratum+tcp://[myip]:3333, and changes to the targeted pool when my browser hits http://[myip]/switch_to_kano & http://[myip]/switch_to_slush. That was interesting in theory and neat to see working.  |
|
|
|
@ProgrammerFox Someday... maybe. The recommended mitigation steps (best / better / other): Switch to linux, review and build from git. Build the win executable yourself. VirtualBox + Ubuntu + Post #2. Check the sha1 hash using certutil of what you are running versus what was posted here on this forum thread. Re: update the master branch. Soon. The current plan is to do so as batch 2 starts shipping. In the meantime switch to the R606 branch to keep updated. |
|
|
|
@ZimbaCardi Hop on over to the NewPac / R606 thread. Grab the latest code and check over FAQ from the first post regarding low speed in WIN10. The new code should perform better for you, but if it doesn't then apply the additional testing options mentioned there. |
|
|
|
|
Thanks for the feedback of (9e51f0b) vs (a62385f).
Current tally:
Better for:
cliftonk : WIN10 Ubuntu18
DieselWeaseI : Ubuntu18 (Odroid N2)
Worse for:
WilcoWi : WIN 10
os2sam : WIN7 & RPi3
lrowland21093 : PiZero
Just a reminder too that it's not done tuning until T: & P: are the same value (or within a few MHz). I may have slowed down the upper end too much to keep it from hitting plateau too hard.
|
|
|
|
Hi GekkoScience,
Why is my R606 always running at around 200MHZ???
Shouldn't it be at 550Mhz like the T and the command?
Also, Is there a special command to turn on ASIC boost?
AB will turn on if the pool and miner supports it. The plus sign indicates that AB is on ... BM1387:12+ ... You can turn it off with --gekko-noboost. If you are using windows, and are stuck sub 200MHz, you should try --gekko-lowboost or the noboost option. It has shown to helped out in most cases. Switching to Linux does even better. Or try out the latest build. (9e51f0b)
The "Miner Earnings Comparison Table:" http://mining.tipsternet.com/miner.html shows the R606 @ S0: 489 GH/s Watts: 39.12 J/GH: 0.080 Question: Assuming the voltage setting 0, what frequency setting was used for the R606? That entry came from here: https://bitcointalk.org/index.php?topic=5131245.msg50710742#msg50710742 |
|
|
|
New build: ( d76cd8a) (9e51f0b) Linux instructions: save (rename folder), clone, build. (see first post) Windows binary: cgminer-4.11.1-windows-gekko-9e51f0b.7z sha1sum: eb928ef8c878e7aef778520a8566279ce46e2847 cgminer.exe Improve noboost performance. + sends work faster Improved peak detection, slightly faster ramp up. + use different 1m hashrate formula. + allow startup ramp to go up to 550MHz then check hash percentage beyond that. + keeps peak and attempted frequency values closer together at higher frequencies, gentler plateau entry. Other tuning / bug fixes + fix buffer overrun in frequency info log statement. + slow down baudrate on WIN environment, to mitigate AB-4 work frame split. @9e51f0b + give out-of-sync chips a chance to converge at current frequency. |
|
|
|
|
@DieselWeaseI
Those asic chips of the R606 expects work every few ms, on the dot. If the CPU gets diverted elsewhere or the USB bus gets congested by other traffic for even a short period, it's not going to perform ideally.
|
|
|
|
My altcoin source code is here...
These are bitcoin miners. If they happen to work with non-bitcoins, that's neat. Other than that, You should start up your own thread in the non-bitcoin sections of the forum. Also, a quick general reminder that any long discussion leading in that direction will be actively removed.
Ok, lowboost seems to work better, just switched to latest version (a62385f).
That makes two now. You can thank gt_addict for taking the time to help pinpoint that one workaround. Since I haven't found a way to recreate the problem to investigate locally, I'll go ahead and add a note about --gekko-lowboost to the first post's Q&A section. edit: more just to cross out the possibility of power from the ports being different: leaving everything else the same, swap physical places on the hub for GS-10030648 & GS-10031032 Your next set of actions will depend on if the lower speed stays with the miner or with the port.  |
|
|
|
is it normal with asic boost and newpac's, the freq goes down @first? With no asic boost i only see it going up. tried ckpool and now kano pool, but see same behaviour with asic boost...
https://bitcointalk.org/index.php?topic=5053833.msg51047754#msg51047754hmm... just posted about it like a few hours ago. There's a new option you might as well throw into your testing mix. If it heads downward immediately from 200 with asicboost on try including --gekko-lowboost. |
|
|
|
Wow, this new version just went straight to 700Mzh with no issues on voltage level 5. The other versions would only go to 575Mhz on level 5.
Edit: It did finally re-target to 631.25Mhz. But that is better than the 575Mhz my R606 got previously.
It will eventually settle near P: (Peak) But it shouldn't have reached 700MHz, looks like I have another round of adjusting to do (note to self). |
|
|
|
|
There's a hint in the first post's Q&A section that might work for you.
|
|
|
|
Highly surprised any previous version didn't flag AV. The safest path is to review the code and use the cross compile instruction in the first/second post. The version I dropped into the 7z (a62385f) has this signature. # sha1sum cgminer.exe
a4c65616886dff429dd01b4caac582cea32ab43b cgminer.exe
C:\AVExcludedPath\cgminer-4.11.1-windows-gekko>certutil -hashfile cgminer.exe
SHA1 hash of cgminer.exe:
a4c65616886dff429dd01b4caac582cea32ab43b
|
|
|
|
|
Show Posts
