|
@sidehack
I'm working through an issue with gt_addict. The combination of his (WIN10) environment + four midstate packets appears to be causing mining to stall. I would like to later conclude it's not needed, but for the moment it's an alternative path to a form of AB that can approach 900+TH/s on the r606.
Extra Troubleshooting Path: (normal) -> (gekko-lowboost) -> (gekko-noboost)
|
|
|
|
@evade_57 pool diff automatically changes upward toward the network diff to force you send less traffic depending on your worker hashrate. if you are allowed to take an initial guess (suggested-diff / pool side setting), aim anywhere between 2(min) to 5(max) times your hashrate (GHs).
New build (a62385f) Linux instructions: rename (save), clone, build. (see first post) Windows binary: cgminer-4.11.1-windows-gekko-a62385f.7z sha1sum a4c65616886dff429dd01b4caac582cea32ab43b cgminer.exe Fixed version mask negotiation. + AsicBoost now works for prohashing.com & slushpool.com Added "--gekko-lowboost" + 2 midstate mode vs normal 4 midstate mode. + less efficient version of AB. Add locking around some shared memory structures. + potential place for program fault. |
|
|
|
|
@WilcoWi
The miner has an upper frequency boundary for performance, that message is the code is trying re-target to it. The highest detected/computed of 3 attempts (1/3, 2/3, 3/3) is set as the new frequency.
It's information data at the moment, unless it unusually low.
@mstrozier
on linux append " 2> out.001.log" to the end of the command line run string.
Exiting to summary was reported before but I haven't been able to properly reproduce it. That normally only triggers when a special stop signal from the keyboard or another process activate. If you set this environment up before the 5/11 update, grab and build the latest code.
|
|
|
|
New build (ef74c27) Instructions for linux: rename old (save), clone again, build. Windows binary: cgminer-4.11.1-windows-gekko-ef74c27.7z Fixed statline overflow. + display shows garbage string in windows when driver appended info exceeds 64 bytes. + possible trigger for core dump. + possible cause of "shutdown signal received" via feedback through ncurses. Suspended periodic frequency checks. + use case does not apply anymore. free up some traffic on the bus. Step down BM1384 frequency on shutdown. + part of december code lost in r606. |
|
|
|
@mstrozier Check if it can settle at a higher frequency when connected to a tested pool supporting AB. (bottom of this post) the quick way: add --gekko-r606-freq 700 to a copy of the original test_mining.bat, and run it for a little bit as is. |
|
|
|
|
That would be the autotune version, auto-tuning. For the most part, you can consider it informational.
Also double check that you didn't plug the NewPac into a usb port with a 2A regulator. That might bottleneck it sub 450MHz.
|
|
|
|
Try running it with just a few miners at a time to see if you get the same behavior. screen 1: append "--usb :2" screen 2: append "--usb :4" screen 3: append "--usb :6" ./cgminer -o stratum+tcp://bch.viabtc.com:3333 -u Xylander.gekko1 -p x --suggest-diff 1280 --gekko-newpac-detect --gekko-newpac-freq 500 --usb :2
That message is generally related to the software trying to put in more data than can fit into a predefined spot. I'll see if i can recreate it / track it down locally. |
|
|
|
I’ll fix that warning in the next commit. Looks like you may be missing the zlib headers/library “-lz”. Try: sudo apt-get install zlib1g-dev |
|
|
|
|
Misc Stats : If you're keeping it as a Lottery Machine:
Bitcoin
1st Prize : 12.5BTC, Daily Odds 1:421088 (750GH/s - 5/1)
vs.
PowerBall
3rd Prize : $50K, Odds 1:913130
|
|
|
|
|
@philipma1957
awesome.
@kingofhammers
Rolling in the official support into the NewPac thread. All notes that apply to NewPac can be recyclable for R606 and the reverse should be mostly be true. Feel free to continue to post in this thread as well.
|
|
|
|
do I load zadig and do winusb driver
Zadig -> WinUSB, would be the correct choice. |
|
|
|
Visit this post: Latest R606 Code & Notes. Grab from : April 30 @ 0d524aa Kick off the test_mining.bat file that's included. If it takes you above 500GH/s, you can edit the .bat and replace the options to fit your need. adjust in this order or all at once: --gekko-r606-freq 900 --suggest-diff 700 then adjust -o and -u --gekko-noboost (if seeing all rejected shares from pool)
@minefarmbuy Those instructions are okay for the prototype and will not work for the shipped ones. |
|
|
|
As those number approach near 1 ms, we'll begin hitting the usb bus limit per miner. Those other chip states were part of an earlier attempt to sense per chip health. The extra details is for the early phase releases and sidehack's burn in testing. They'll fade further into the debug logs in future builds as they become un-interesing for normal use. @cjsummers82 new build ( 0d524aa) : works with prohashing.com in --gekko-noboost mode. they report vmask support but then rejects shares. adding to review later pile. |
|
|
|
|
--gekko-r606-freq
Cool, at least the pools on the supported list are behaving for the miner.
If you would like me to take a closer look at prohashing.com, sent me a pm with a user I can send work shares to.
Ideally your full run syntax to mimic what you see.
|
|
|
|
|
That's the most recent stable one.
You'll occasionally see rejects during the first minute of connecting to a pool.
If the pool doesn't stop rejecting, try a different pool to make sure the unit is healthy.
|
|
|
|
|
Use a powered hub.
Could be DoA, but possible low power condition keeping it from responding.
Catch 22 on that.
The software can't set the frequency of the chip to use lower power if the chips don't have the needed power to start up.
You might have some luck if you set the potentiometer to 3 o'clock.
Use a powered hub, it's better for your miner and the PC port.
|
|
|
|
No, I don't think you need to match the pool, just ensure you are counting nonces based on the nonce difficulty in the chip
(and valid nonces)
Applied to the second posted run below (R606-d0s5r004). Also deceased the difficulty to lower variance. Looking better. Yep when you've done, I'll go back and add up everything on the pool side and spit out another number for this run.
Worker : R606-d0s5r00(2/4)
Device : Lab Workbench
Setting : 5 (Default for devices)
Run : 24 Hours @ kano.is, AsicBoost on.
Run R606-d0s5r002: Approaching 943GH/s UI Run Average : 940.5GH/s (diff x 2^32 per nonce) Pool Accepted : 927.8GH/s (client side) A = 18669098 / 86416 * 2 ^ 32 = 927.8; 927.8/940.5 = 98.6%. A + R = 18684098 / 86416 ^ 32 * 2 = 928.6; 927.8/940.5 = 98.7%  Run R606-d0s5r004*: Approaching 960GH/s UI Run Average : 904.4GH/s - (diff x 2^32 per nonce) Pool Accepted : 904.9GH/s (client side) A = 18228076 / 86899 * 2 ^ 32 = 900.9; 900.9/904.4 = 99.6%. A + R = 18309284 / 86899 * 2 ^ 32 = 904.9; 904.9/904.4 = 100%. *Adjusted to only count hashrate on successful submit_nonce (test_nonce)  R606-d0s5r002 : Summary of stats: Summary of runtime statistics:
[2019-04-22 12:06:09.810] Started at [2019-04-21 12:03:28.187]
[2019-04-22 12:06:09.810] Pool: stratum+tcp://stratum.kano.is:3333
[2019-04-22 12:06:09.810] Runtime: 24 hrs : 2 mins : 41 secs
[2019-04-22 12:06:09.810] Average hashrate: 940536.2 Mhash/s
[2019-04-22 12:06:09.810] Solved blocks: 0
[2019-04-22 12:06:09.810] Best share difficulty: 149M
[2019-04-22 12:06:09.810] Share submissions: 7473
[2019-04-22 12:06:09.810] Accepted shares: 7467
[2019-04-22 12:06:09.810] Rejected shares: 6
[2019-04-22 12:06:09.810] Accepted difficulty shares: 18669098
[2019-04-22 12:06:09.810] Rejected difficulty shares: 15000
[2019-04-22 12:06:09.810] Reject ratio: 0.1%
[2019-04-22 12:06:09.810] Hardware errors: 279
[2019-04-22 12:06:09.810] Utility (accepted shares / min): 5.18/min
[2019-04-22 12:06:09.810] Work Utility (diff1 shares solved / min): 13089.83/min
[2019-04-22 12:06:09.810] Stale submissions discarded due to new blocks: 1
[2019-04-22 12:06:09.810] Unable to get work from server occasions: 2
[2019-04-22 12:06:09.810] Work items generated locally: 13723447
[2019-04-22 12:06:09.810] Submitting work remotely delay occasions: 0
[2019-04-22 12:06:09.810] New blocks detected on network: 149
[2019-04-22 12:06:09.810] Summary of per device statistics:
[2019-04-22 12:06:09.810] GSI 0 (5s):929.9G (avg):940.5Gh/s | A:18669098 R:15000 HW:279 WU:1308
R606-d0s5r004 : Summary of stats: Summary of runtime statistics:
[2019-04-24 07:00:13.630] Started at [2019-04-23 06:50:51.565]
[2019-04-24 07:00:13.630] Pool: stratum+tcp://stratum.kano.is:3333
[2019-04-24 07:00:13.630] Runtime: 24 hrs : 9 mins : 22 secs
[2019-04-24 07:00:13.630] Average hashrate: 904048.5 Mhash/s
[2019-04-24 07:00:13.630] Solved blocks: 0
[2019-04-24 07:00:13.630] Best share difficulty: 48.7M
[2019-04-24 07:00:13.630] Share submissions: 32754
[2019-04-24 07:00:13.630] Accepted shares: 32627
[2019-04-24 07:00:13.630] Rejected shares: 127
[2019-04-24 07:00:13.631] Accepted difficulty shares: 18228076
[2019-04-24 07:00:13.631] Rejected difficulty shares: 81208
[2019-04-24 07:00:13.631] Reject ratio: 0.4%
[2019-04-24 07:00:13.631] Hardware errors: 881
[2019-04-24 07:00:13.631] Utility (accepted shares / min): 22.51/min
[2019-04-24 07:00:13.631] Work Utility (diff1 shares solved / min): 12629.48/min
[2019-04-24 07:00:13.631] Stale submissions discarded due to new blocks: 94
[2019-04-24 07:00:13.631] Unable to get work from server occasions: 14
[2019-04-24 07:00:13.631] Work items generated locally: 16629312
[2019-04-24 07:00:13.631] Submitting work remotely delay occasions: 11
[2019-04-24 07:00:13.631] New blocks detected on network: 143
[2019-04-24 07:00:13.631] Summary of per device statistics:
[2019-04-24 07:00:13.631] GSI 0 (5s):0.000 (avg):164.2Gh/s | A:3241500 R:4000 HW:218 WU:2294.4/
[2019-04-24 07:00:13.631] GSI 1 (5s):0.000 (avg):1.613Gh/s | A:22800 R:0 HW:0 WU:22.6/m
[2019-04-24 07:00:13.631] GSI 2 (5s):963.6G (avg):923.4Gh/s | A:14963776 R:60816 HW:663 WU:1290
|
|
|
|
@rockmoney Keep sending me those headers as you cycle through them. Super useful in fine tuning. @kano But this all, hopefully, may help you find where the difference is  Just double checking everything, I notice I'm counting hw_errors, nonces after flush events. Not significant, but will do better to only include the ones that pass test_nonce. So really all this ends up with, is saying that the most accurate comparable hash rate between miners is the internal work Diff per nonce that comes back to cgminer, and then to get the current preferred (fake) hash rate, multiply that by 2^32
Yeah, every time a nonce is found, the driver reports upstream (device diff x 2^32). To perfectly track with pool side value, I would probably need to go straight with the formula provided, using pool diff instead of device diff and not count lower diff values. As it is, I'm thinking I may have requested the pool difficulty to be a tad on the too high side: Given the lower number of total accepted shares, it's still within the margin of error: Confidence Level: Margin of error for sample size = 1/sqrt(n), 1/sqrt(661) = 3.8% Next test set:
Worker : R606-d0s5r002
Device : Lab Workbench
Setting : 5 (Default for devices)
Run : 12 Hours @ kano.is, AsicBoost on. (heading towards 24h)
 Duration: 43410 Total difficulty of accepted shares: 9444098.0 Calculated hash rate: Diff * 2^32 / Time = 9444098 * 2^32 / 43410 = 934GH/s 934 vs 937 = 99.7% Margin of error for sample size = 1/sqrt(n), 1/sqrt(3777) = 1.6% I'll post the final stats for this one if it survives the full 24hr without a hiccup. |
|
|
|
Thanks Kano. "extra bit" to "standard" ratio is very close to 3:1, which is as expected. That hash rate is only 95% of what was on screen. I'm going to lean towards one hour being too small. Looks like I should have included the full ending output: [2019-04-21 17:32:59.385] Started at [2019-04-21 14:15:31.643]
[2019-04-21 17:32:59.385] Pool: stratum+tcp://stratum.kano.is:3333
[2019-04-21 17:32:59.386] Runtime: 3 hrs : 17 mins : 27 secs
[2019-04-21 17:32:59.386] Average hashrate: 489341.0 Mhash/s
[2019-04-21 17:32:59.386] Solved blocks: 0
[2019-04-21 17:32:59.386] Best share difficulty: 664K
[2019-04-21 17:32:59.386] Share submissions: 661
[2019-04-21 17:32:59.386] Accepted shares: 661
[2019-04-21 17:32:59.386] Rejected shares: 0
[2019-04-21 17:32:59.387] Accepted difficulty shares: 1322000
[2019-04-21 17:32:59.387] Rejected difficulty shares: 0
[2019-04-21 17:32:59.387] Reject ratio: 0.0%
[2019-04-21 17:32:59.387] Hardware errors: 512
[2019-04-21 17:32:59.387] Utility (accepted shares / min): 3.35/min
[2019-04-21 17:32:59.387] Work Utility (diff1 shares solved / min): 6833.70/min
[2019-04-21 17:32:59.387] Stale submissions discarded due to new blocks: 0
[2019-04-21 17:32:59.388] Unable to get work from server occasions: 0
[2019-04-21 17:32:59.388] Work items generated locally: 1352476
[2019-04-21 17:32:59.388] Submitting work remotely delay occasions: 0
[2019-04-21 17:32:59.388] New blocks detected on network: 14
[2019-04-21 17:32:59.388] Summary of per device statistics:
[2019-04-21 17:32:59.388] GSI 0 (5s):520.7G (avg):489.3Gh/s | A:1322000 R:0 HW:512 WU:6833.7/m
Using the same formula, i still only end up with 479GH/s Duration: 11847 Total difficulty of accepted shares: 1322000.0 Calculated hash rate: Diff * 2^32 / Time = 1322000 * 2^32 / 11847 = 479GH/s I guess a better one-to-one question would be are the total accepted share reported by cgminer matching what you can see for the entire time period. If that matches, it takes us up from 95% to 98%, but still a little off. I'll have another one running to a unique worker for 24hr to get a better sampling of data. |
|
|
|
Center link of my signature, I've updated it with a few additional recently reviewed miners. It should provide a better view of where these unit fits in, in the bigger picture of miners. Sharing Moment:
Worker : R606-d1s0r001
Device : Early Prototype*
Setting : 0
Run : 3 Hours @ kano.is, AsicBoost on.
  489GH/s @ 39.12W = 0.80 J/GH I'm emphasizing early prototype. It's not as well behaved as sidehack's on hand production ones, from which he's actively sharing current data. @Kano, can you pull the last hour of stats for that worker to see how that matched up?
|
|
|
|
|
Show Posts
