Bitcoin Forum
December 12, 2017, 09:13:12 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 [10] 11 »  All
  Print  
Author Topic: [ANN] ETHASH Miner - Eminer v0.6.1-RC2 Released (Windows, Linux, MacOS)  (Read 22914 times)
E-Miner
Jr. Member
*
Offline Offline

Activity: 56

DevOps


View Profile
September 23, 2017, 09:01:49 AM
 #181

Ok so I'm seeing about 0.5 to 1% better hashrate reporting pool side.  Would be nice to have a worker automatic restart if a gpu goes down for some reason, and a warning, or automatic intensity drop for that gpu.

I added to checklist, this can be add to cloud service.
Bitcoin addresses contain a checksum, so it is very unlikely that mistyping an address will cause you to lose money.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513069992
Hero Member
*
Offline Offline

Posts: 1513069992

View Profile Personal Message (Offline)

Ignore
1513069992
Reply with quote  #2

1513069992
Report to moderator
Chocolatte
Full Member
***
Offline Offline

Activity: 126

Citius, altius, fortius


View Profile
September 24, 2017, 11:06:14 PM
 #182

great job!

terrxysq
Newbie
*
Offline Offline

Activity: 23


View Profile
September 25, 2017, 01:03:43 AM
 #183

request to add feature to notify when significant hash rate drop for a worker(ideally configurable). ie. a worker usually do 180mh/s, if drops by more than X%(configurable) it sends a notification. do not need to notify immediately(configurable). but if below the threshold for more than Y(configurable) minutes then notify.
E-Miner
Jr. Member
*
Offline Offline

Activity: 56

DevOps


View Profile
September 25, 2017, 08:06:56 AM
 #184

request to add feature to notify when significant hash rate drop for a worker(ideally configurable). ie. a worker usually do 180mh/s, if drops by more than X%(configurable) it sends a notification. do not need to notify immediately(configurable). but if below the threshold for more than Y(configurable) minutes then notify.


added to checklist, will add to cloud service.
dj--alex
Jr. Member
*
Offline Offline

Activity: 58


View Profile
September 25, 2017, 08:54:22 AM
 #185

I check, it works on linux on one overclocked GTX1060 card.

INFO [09-25|11:53:44] GPU device information                   device=0 hashrate="18.108 Mh/s" temperature="63.00 C" fan=49.00%
I have 18.1Mh instead 19.8  

1- how use temperature control? and decrease intensity if t>80 C ?

2-how to manage intensity?

3- Can i control fee if i want to use devfee on 10% on one card, and two card can work without devfee?
(switching DAG,pool and etc take real time!)

4- please add more samples to header of topic
eminer.exe -S eu1.ethermine.org:4444,eu1.ethermine.org:14444 -U YOUR_WALLETID_HERE.rig3 -P x -N rig3 --cloud-key GENERATE_AT_CLOUD.EMINER.NET

for linux
./eminer -S eu2.ethermine.org:4444 -U YOUR_WALLETID_HERE.rig3 -P x -N home
#--cloud-key GENERATE_AT_CLOUD.EMINER.NET

5. On github i cannot found source codes and cannot compile "Dashboard.png"
I thinking no sources , yes?
laik2
Sr. Member
****
Offline Offline

Activity: 392


View Profile
September 26, 2017, 11:26:35 AM
 #186

Power usage is still pretty high. No watchdog, yet...

ZEC: t1KbbHtXqzSS6qHBaPZDKyWnzxhRjr9oCtW
E-Miner
Jr. Member
*
Offline Offline

Activity: 56

DevOps


View Profile
September 26, 2017, 10:30:50 PM
 #187

Power usage is still pretty high. No watchdog, yet...

Did you try intensity parameter?
terrxysq
Newbie
*
Offline Offline

Activity: 23


View Profile
October 04, 2017, 01:27:01 PM
 #188

any update soon?
halker2010
Sr. Member
****
Offline Offline

Activity: 280


BTX=1AHf5uQY7dDjMxYDEsvRFyYGd6J92mf679


View Profile
October 04, 2017, 03:35:33 PM
 #189

I found an issue with cloud service if i don't use a key or didn't have interest in using it some parameters do not work, like for example -M for device selection.

LuxLP
Jr. Member
*
Offline Offline

Activity: 34


View Profile
October 04, 2017, 03:57:51 PM
 #190

A very good idea, dev! Keep it up!

Are there any tests @ 1060 nvidia?
E-Miner
Jr. Member
*
Offline Offline

Activity: 56

DevOps


View Profile
October 04, 2017, 04:50:02 PM
 #191

I found an issue with cloud service if i don't use a key or didn't have interest in using it some parameters do not work, like for example -M for device selection.

Could you please send full command line, I can test it.
E-Miner
Jr. Member
*
Offline Offline

Activity: 56

DevOps


View Profile
October 04, 2017, 04:51:20 PM
 #192

any update soon?

I'm working for new update, I will announce soon.
halker2010
Sr. Member
****
Offline Offline

Activity: 280


BTX=1AHf5uQY7dDjMxYDEsvRFyYGd6J92mf679


View Profile
October 04, 2017, 04:54:22 PM
 #193

I found an issue with cloud service if i don't use a key or didn't have interest in using it some parameters do not work, like for example -M for device selection.

Could you please send full command line, I can test it.
Here

Code:
setx GPU_FORCE_64BIT_PTR 0

setx GPU_MAX_HEAP_SIZE 100

setx GPU_USE_SYNC_OBJECTS 1

setx GPU_MAX_ALLOC_PERCENT 100

setx GPU_SINGLE_ALLOC_PERCENT 100

eminer.exe -S stratum+tcp://europe.ethash-hub.miningpoolhub.com:20535  -U halker.amd -P x -M 0,2,3

peteycamey
Legendary
*
Online Online

Activity: 1013



View Profile
October 08, 2017, 12:18:02 AM
 #194

slightly better pool side reported hash rate and slightly higher power consumption.

very stable, and nice UI for cloud service.

intensity does not seem to make any difference.

overall 9/10.

Koyunlara fısıldayan adam.
laik2
Sr. Member
****
Offline Offline

Activity: 392


View Profile
October 09, 2017, 07:27:23 PM
 #195

slightly better pool side reported hash rate and slightly higher power consumption.

very stable, and nice UI for cloud service.

intensity does not seem to make any difference.

overall 9/10.

Sorry for the late answer.
Yes intensity doesn't make any difference as of power usage, but it does reduce hashrate.

ZEC: t1KbbHtXqzSS6qHBaPZDKyWnzxhRjr9oCtW
Wolf0
Legendary
*
Offline Offline

Activity: 1764


Miner Developer


View Profile
October 10, 2017, 08:31:49 AM
 #196

any update soon?

I'm working for new update, I will announce soon.

You're doing better with keeping your IP hard(er) to get at - nice work. Might want to use C instead of Go so you can put in some anti-debugging traps, too.

Also... in your "Optimized 4 threads" OpenCL... I know this won't make a huge difference, but it still makes me sad:

Code:
bool update_share = thread_id == ((a >> 3) % THREADS);

Were that interpreted how you wrote it (verbatim), you would be eating... 4 clocks for the shift, and an untold number of clocks for the modulo, as AMD GCN doesn't even have modulo implemented - it's emulated. In reality, it's going to optimize that to an AND, making it look more like this:

Code:
bool update_share = thread_id == ((a >> 3) & (THREADS - 1))

Okay, that's 8 clocks - two full-rate instructions. Unless you use a local worksize that's not a power of two, and in that case, god help you. But we can do better.

First, for AMD - you're using LDS. Any worksize above wavefront size (64 work-items) is going to make those barriers take a LOT longer. Reason being, an AMD GCN CU (Compute Unit) only executes wavefronts. Larger work groupings are cut into wavefront-sized pieces and executed that way. If you use an LDS barrier with a worksize of 64 (wavefront size) - big deal, the whole wavefront is handled by that CU, and as such, the barriers can actually be omitted! And they are, by the AMD OCL compiler, in that case. When you make your group larger - suddenly you need to sync with other execution units: this is going to make you very sad. So - at least for AMD - I would keep it to 64 work-items/local group.

Now - we know the value of THREADS - the kernel says it's a 4-way - so... get you one of these...

Code:
#pragma OPENCL EXTENSION cl_amd_media_ops2 : enable

... and suddenly you have access to the amd_bfe builtin, which is purpose-built for what you wanna do! It gives you direct access to the v_alignbit_b32 instruction. And this gives us:

Code:
bool update_share = thread_id == amd_bfe(a, 3U, 2U);

Shaving at LEAST four ticks off the best the compiler would likely come up with (and I am being generous.) As it's looped, this magnifies the effect of the optimization, although it's still not much. Now you have the operation done in a single full-rate instruction, though - which IS an improvement.

Code:
Donations: BTC: 1WoLFdwcfNEg64fTYsX1P25KUzzSjtEZC -- XMR: 45SLUTzk7UXYHmzJ7bFN6FPfzTusdUVAZjPRgmEDw7G3SeimWM2kCdnDQXwDBYGUWaBtZNgjYtEYA22aMQT4t8KfU3vHLHG
E-Miner
Jr. Member
*
Offline Offline

Activity: 56

DevOps


View Profile
October 10, 2017, 11:32:28 AM
 #197

any update soon?

I'm working for new update, I will announce soon.

You're doing better with keeping your IP hard(er) to get at - nice work. Might want to use C instead of Go so you can put in some anti-debugging traps, too.

Also... in your "Optimized 4 threads" OpenCL... I know this won't make a huge difference, but it still makes me sad:

Code:
bool update_share = thread_id == ((a >> 3) % THREADS);

Were that interpreted how you wrote it (verbatim), you would be eating... 4 clocks for the shift, and an untold number of clocks for the modulo, as AMD GCN doesn't even have modulo implemented - it's emulated. In reality, it's going to optimize that to an AND, making it look more like this:

Code:
bool update_share = thread_id == ((a >> 3) & (THREADS - 1))

Okay, that's 8 clocks - two full-rate instructions. Unless you use a local worksize that's not a power of two, and in that case, god help you. But we can do better.

First, for AMD - you're using LDS. Any worksize above wavefront size (64 work-items) is going to make those barriers take a LOT longer. Reason being, an AMD GCN CU (Compute Unit) only executes wavefronts. Larger work groupings are cut into wavefront-sized pieces and executed that way. If you use an LDS barrier with a worksize of 64 (wavefront size) - big deal, the whole wavefront is handled by that CU, and as such, the barriers can actually be omitted! And they are, by the AMD OCL compiler, in that case. When you make your group larger - suddenly you need to sync with other execution units: this is going to make you very sad. So - at least for AMD - I would keep it to 64 work-items/local group.

Now - we know the value of THREADS - the kernel says it's a 4-way - so... get you one of these...

Code:
#pragma OPENCL EXTENSION cl_amd_media_ops2 : enable

... and suddenly you have access to the amd_bfe builtin, which is purpose-built for what you wanna do! It gives you direct access to the v_alignbit_b32 instruction. And this gives us:

Code:
bool update_share = thread_id == amd_bfe(a, 3U, 2U);

Shaving at LEAST four ticks off the best the compiler would likely come up with (and I am being generous.) As it's looped, this magnifies the effect of the optimization, although it's still not much. Now you have the operation done in a single full-rate instruction, though - which IS an improvement.

WOW! tons of job like for me. @Wolf thanks your mention. I'll keep up these and will be share results here.
fr4nkthetank
Legendary
*
Offline Offline

Activity: 1218


cryptominingtalk.com


View Profile WWW
October 11, 2017, 01:39:25 PM
 #198

w0lf is a legend.  Always ready to help others, although he won't spoon feed you but when people want to learn i've seen him time and time again help out and spread the knowledge.  If only we had more wolfs in crypto and less sp's Smiley  I'll test out your new update when you get it out

                                 
           ░▓█████████████████▓░
          ▒▓██▓▓▓▓▓▓▓▓▓▓▒▓▒▒▒██▓▒░
      ░▒▓███▓                 ▒██▓▓▒░░    ░
▓▒███████▓▒        ░▒▒▒▒▒▒▒░    ░▓▓▓██▓▓▓▒▓
▒░██▒░░         ▒▓▓▓▓▒▒▒▒▓▓██▓▒     ░ ▒▓▓░▓
░▒▓█▒         ▒█▓▓▒▒▒▒▒▒▒▓▓▓████▓▓▒   ▒█▓▒▒
 ▒░██        ██▒▒▒▒▒▒▒▒▒▒▒▒▒░▒▒░██▒   ██▒▒
 ▓░▓█▒      ██▒▒▒▒▒▒░▒░░▒▒▒░░▒▓██▓   ▒██░▒
 ░▓░█▓     ▓█▓▒░▒▒▒▒▒▒▒░░░▒▒▓▓▓▓▓▒   ██░▓░
  ▓▒▒█▓  ▓▒█▓▒▒▓▓▒░▒░░░▒▒▒▒▒▒▒▒ █▒  ██▓░▓
   █░▒█▓ ▓███▓▒▒░░▒▒▒▒▒▒▒▒▒▒▒░ ▓█  ██▓ ▓
    █░▓█▓ ░██▓███▓▓▒▒▒▒▒▒▒░▒▒▓██  ██▓░▓
    ░█░▒██  ░ ░▓███████▓██████▒  ██▒░▓
      █▒░██▓      ░▒▒▓▓▓▓▒▒░   ▓██░▒▓
       ▓▓░▒██▒               ▒██▓░▓▓
        ░█▓░▓██▒           ▒██▓░▓█░
          ▒█▓░▓██▓       ▓██▓▒▓█▒
            ▒█▓▒▒███░ ▒███▒▒▓█▒
              ▒██▓▒▓███▓▒▒██▒
                ░▓██▒▒▒███░
                   ▒███▒














terrxysq
Newbie
*
Offline Offline

Activity: 23


View Profile
October 20, 2017, 01:25:44 PM
 #199

it does seem that sometimes the miner would just stop working solutions but would not crash. the error handling and watchdog feature need to be improved. wonder when will there be a new version coming out?
smparo
Newbie
*
Offline Offline

Activity: 20


View Profile
October 27, 2017, 12:30:57 PM
 #200

Last days I notice that the software some times not report to the mining pool the stale share that I can view on the console Shocked
The problem that I had was low shares and for testing I started claymore miner and I notice that I found a lot of stale shares: it's okay ... the pool have some problems!   Embarrassed Cry Undecided
Now the problem is away but can you correct this problem?
Pages: « 1 2 3 4 5 6 7 8 9 [10] 11 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!