ethminer-0.9.41-genoil-1.1 - page 77.

Ekanenf

full member

Activity: 290

Merit: 100

Quote from: aimsml on April 09, 2016, 08:41:19 AM

Hello.
Prompt, to run in solo, depending on the complexity of the network parameter --cl-global-work it is necessary to increase or decrease? Thank you.

It make no difference if you want to run solo or pool mining. -cl-global-work is just the allocated work in the GPU.

aimsml

member

Activity: 66

Merit: 10

Hello.
Prompt, to run in solo, depending on the complexity of the network parameter --cl-global-work it is necessary to increase or decrease? Thank you.

malekbaba

legendary

Activity: 1526

Merit: 1026

is it still worth mining Eth ? price is down and difficulty is sky high.

davembg

sr. member

Activity: 340

Merit: 251

Smell the glove.

Quote from: ol92 on April 08, 2016, 02:57:06 AM

Quote from: Genoil on April 08, 2016, 02:23:42 AM

Quote from: davembg on April 07, 2016, 09:48:15 PM

Quote from: Genoil on April 07, 2016, 03:26:01 PM

Quote from: davembg on April 07, 2016, 01:27:17 PM

Like Genoil says, the rate reporting isn't very sophisticated - so it skips around like mad.
One thing that's puzzling to me it the need for the DAG to reside in GPU memory.
I suppose accessing it via the PCI bus (in system RAM) would be slower, but, would all for 1GB cards to mine.
What do you think?

The whole point of ethash is RAM latency. Lower latency = faster mining. If you keep the DAG in system RAM, you might as well access it with the CPU. ethminer -C Cool

Or sure, DDR5 GPU RAM is optimal - but, have you tried it?
I'm planning on it, when I have a spare day or two.
Any GPU is much better suited for mining than a CPU, of which I'm sure you are aware.

With ethash, it doesn't look like there will be any kernel optimizations or "revelations".
What I'm saying is that 1GB GPUs could likely mine much faster than a CPU.
Of course, proof is in the pudding.

A good rule of thumb for determining a card's hashrate is 80% * bandwidth / 8KB. 8KB is the amount of data that is retrieved from the DAG for each hash. 80% is the average effciency I've found to be common. i.e. 280X = 0.8*224GB/8KB = 22.4MH/s
GTX970 = 0.8*196GB/8KB = 19.6MH/s

Now you take the max PCIE 3.0 bandwidth (x16), which is about 16GB/s. This should give you a theoretical hashrate of about 1.6MH/s.

In practise it's much worse though. I only had to change 2 lines of code in my CUDA miner to keep the DAG in device mapped system RAM. The hashrate of my GTX970 dropped to about 300KH/s. My i5-4570 CPU does about 400KH/s.

This formula does not work with GTX 980 Ti with a hashrate a little above GTX 970 and bandwith of 313Gb/s

Yeah, that is brutal. Nice work on testing, saved me the "told you so" from Genoil

Genoil

sr. member

Activity: 438

Merit: 250

Quote from: sorry2xs on April 07, 2016, 03:30:09 PM

Genoil here is a toke for you: 6b97afb3ce515d3926403cb09e4e61b50555670466655f9bd7c0704f250bbb3f-000

Thanks! Much appreciated!

ol92

sr. member

Activity: 445

Merit: 255

Quote from: Genoil on April 08, 2016, 02:23:42 AM

Quote from: davembg on April 07, 2016, 09:48:15 PM

Quote from: Genoil on April 07, 2016, 03:26:01 PM

Quote from: davembg on April 07, 2016, 01:27:17 PM

Like Genoil says, the rate reporting isn't very sophisticated - so it skips around like mad.
One thing that's puzzling to me it the need for the DAG to reside in GPU memory.
I suppose accessing it via the PCI bus (in system RAM) would be slower, but, would all for 1GB cards to mine.
What do you think?

The whole point of ethash is RAM latency. Lower latency = faster mining. If you keep the DAG in system RAM, you might as well access it with the CPU. ethminer -C Cool

Or sure, DDR5 GPU RAM is optimal - but, have you tried it?
I'm planning on it, when I have a spare day or two.
Any GPU is much better suited for mining than a CPU, of which I'm sure you are aware.

With ethash, it doesn't look like there will be any kernel optimizations or "revelations".
What I'm saying is that 1GB GPUs could likely mine much faster than a CPU.
Of course, proof is in the pudding.

A good rule of thumb for determining a card's hashrate is 80% * bandwidth / 8KB. 8KB is the amount of data that is retrieved from the DAG for each hash. 80% is the average effciency I've found to be common. i.e. 280X = 0.8*224GB/8KB = 22.4MH/s
GTX970 = 0.8*196GB/8KB = 19.6MH/s

Now you take the max PCIE 3.0 bandwidth (x16), which is about 16GB/s. This should give you a theoretical hashrate of about 1.6MH/s.

In practise it's much worse though. I only had to change 2 lines of code in my CUDA miner to keep the DAG in device mapped system RAM. The hashrate of my GTX970 dropped to about 300KH/s. My i5-4570 CPU does about 400KH/s.

This formula does not work with GTX 980 Ti with a hashrate a little above GTX 970 and bandwith of 313Gb/s

Genoil

sr. member

Activity: 438

Merit: 250

Quote from: davembg on April 07, 2016, 09:48:15 PM

Quote from: Genoil on April 07, 2016, 03:26:01 PM

Quote from: davembg on April 07, 2016, 01:27:17 PM

Like Genoil says, the rate reporting isn't very sophisticated - so it skips around like mad.
One thing that's puzzling to me it the need for the DAG to reside in GPU memory.
I suppose accessing it via the PCI bus (in system RAM) would be slower, but, would all for 1GB cards to mine.
What do you think?

The whole point of ethash is RAM latency. Lower latency = faster mining. If you keep the DAG in system RAM, you might as well access it with the CPU. ethminer -C Cool

Or sure, DDR5 GPU RAM is optimal - but, have you tried it?
I'm planning on it, when I have a spare day or two.
Any GPU is much better suited for mining than a CPU, of which I'm sure you are aware.

With ethash, it doesn't look like there will be any kernel optimizations or "revelations".
What I'm saying is that 1GB GPUs could likely mine much faster than a CPU.
Of course, proof is in the pudding.

A good rule of thumb for determining a card's hashrate is 80% * bandwidth / 8KB. 8KB is the amount of data that is retrieved from the DAG for each hash. 80% is the average effciency I've found to be common. i.e. 280X = 0.8*224GB/8KB = 22.4MH/s
GTX970 = 0.8*196GB/8KB = 19.6MH/s

Now you take the max PCIE 3.0 bandwidth (x16), which is about 16GB/s. This should give you a theoretical hashrate of about 1.6MH/s.

In practise it's much worse though. I only had to change 2 lines of code in my CUDA miner to keep the DAG in device mapped system RAM. The hashrate of my GTX970 dropped to about 300KH/s. My i5-4570 CPU does about 400KH/s.

davembg

sr. member

Activity: 340

Merit: 251

Smell the glove.

Quote from: Genoil on April 07, 2016, 03:26:01 PM

Quote from: davembg on April 07, 2016, 01:27:17 PM

Like Genoil says, the rate reporting isn't very sophisticated - so it skips around like mad.
One thing that's puzzling to me it the need for the DAG to reside in GPU memory.
I suppose accessing it via the PCI bus (in system RAM) would be slower, but, would all for 1GB cards to mine.
What do you think?

The whole point of ethash is RAM latency. Lower latency = faster mining. If you keep the DAG in system RAM, you might as well access it with the CPU. ethminer -C Cool

Or sure, DDR5 GPU RAM is optimal - but, have you tried it?
I'm planning on it, when I have a spare day or two.
Any GPU is much better suited for mining than a CPU, of which I'm sure you are aware.

With ethash, it doesn't look like there will be any kernel optimizations or "revelations".
What I'm saying is that 1GB GPUs could likely mine much faster than a CPU.
Of course, proof is in the pudding.

sorry2xs

legendary

Activity: 924

Merit: 1000

Dark Passenger Bitcoin miner 2013,Bitcoin node

Genoil here is a toke for you: 6b97afb3ce515d3926403cb09e4e61b50555670466655f9bd7c0704f250bbb3f-000

Genoil

sr. member

Activity: 438

Merit: 250

Quote from: davembg on April 07, 2016, 01:27:17 PM

Like Genoil says, the rate reporting isn't very sophisticated - so it skips around like mad.
One thing that's puzzling to me it the need for the DAG to reside in GPU memory.
I suppose accessing it via the PCI bus (in system RAM) would be slower, but, would all for 1GB cards to mine.
What do you think?

The whole point of ethash is RAM latency. Lower latency = faster mining. If you keep the DAG in system RAM, you might as well access it with the CPU. ethminer -C Cool

davembg

sr. member

Activity: 340

Merit: 251

Smell the glove.

Quote from: w0lf0. on April 07, 2016, 06:56:55 AM

Quote from: drr0ss on April 06, 2016, 04:20:40 PM

Quote from: w0lf0. on April 04, 2016, 10:15:21 AM

guys is normal this result? i'am trying to mine with 7950

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
ethminer -G -F http://127.0.0.1:8080/rig1 --cl-local-work 128 --cl-global-work 8192

I' am new on ETH, the real hashrate are first or second figure?

Thanks

Hi Wolf, your hash rate is a normal for 7950, do not use recheck 200 for mining without proxy, 400 is a optimal.
Miner hash rate is digits before 'H/s ='

Thanks drr0ss,farm recheck only shows hash rate more or less frequently or changing it also changes the result of hash?

Hey Wolf0 - you can go to cl-local-work 256 --cl-global-work 16384 with the 7950.
The one in next room is doing 24MH very consistently.

Like Genoil says, the rate reporting isn't very sophisticated - so it skips around like mad.
One thing that's puzzling to me it the need for the DAG to reside in GPU memory.
I suppose accessing it via the PCI bus (in system RAM) would be slower, but, would all for 1GB cards to mine.
What do you think?

Genoil

sr. member

Activity: 438

Merit: 250

Quote from: maxvall on April 07, 2016, 07:34:05 AM

Quote from: Genoil on April 07, 2016, 04:24:24 AM

Quote from: Ayers on April 07, 2016, 01:23:52 AM

Quote from: Genoil on April 06, 2016, 09:16:08 AM

Removing the m_pending check will lead to these incomplete responses. That's why it's there. But it is not thread safe, will have to fix that.

is this response for my question about the crash?, i don't remember the crash in the 4b3 release

not to a crash. i get reports that the miner just randomly fails to receive new work any longer. trying to reproduce that behavior, but haven't succeeded yet.

For reproduce this bug I manually broke connection (disable network adapter).

I applied your fix with mutex, and as first look it works good. I will perform more tests soon.

Also I sometimes get "Allocating/mapping single buffer failed with: clEnqueueWriteBuffer(-4)" error on reconnect.
I have 5 GPUs with 2GB on machine with 4GB RAM and 8GB pagefile (Win7 64bit).
This occurs only on reconnect, miner starts to work successfully always. So, may be stop farming on reconnect not a good idea.

Thanks for testing. I have just pushed a commit that disables the farm stop on reconnect. When I get to stratum failover implementation (don't have much time), I could reintroduce it as a timeout, i.e. stop miners after not having a connection for 60 seconds.

maxvall

sr. member

Activity: 268

Merit: 250

Quote from: Genoil on April 07, 2016, 04:24:24 AM

Quote from: Ayers on April 07, 2016, 01:23:52 AM

Quote from: Genoil on April 06, 2016, 09:16:08 AM

Removing the m_pending check will lead to these incomplete responses. That's why it's there. But it is not thread safe, will have to fix that.

is this response for my question about the crash?, i don't remember the crash in the 4b3 release

not to a crash. i get reports that the miner just randomly fails to receive new work any longer. trying to reproduce that behavior, but haven't succeeded yet.

For reproduce this bug I manually broke connection (disable network adapter).

I applied your fix with mutex, and as first look it works good. I will perform more tests soon.

Also I sometimes get "Allocating/mapping single buffer failed with: clEnqueueWriteBuffer(-4)" error on reconnect.
I have 5 GPUs with 2GB on machine with 4GB RAM and 8GB pagefile (Win7 64bit).
This occurs only on reconnect, miner starts to work successfully always. So, may be stop farming on reconnect not a good idea.

Quote from: w0lf0. on April 07, 2016, 06:56:55 AM

Thanks drr0ss,farm recheck only shows hash rate more or less frequently or changing it also changes the result of hash?

In stratum mode yes, in getwork mode "farm recheck" this is a also period of new work rechecking.

w0lf0.

hero member

Activity: 1050

Merit: 513

Quote from: drr0ss on April 06, 2016, 04:20:40 PM

Quote from: w0lf0. on April 04, 2016, 10:15:21 AM

guys is normal this result? i'am trying to mine with 7950

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
ethminer -G -F http://127.0.0.1:8080/rig1 --cl-local-work 128 --cl-global-work 8192

I' am new on ETH, the real hashrate are first or second figure?

Thanks

Hi Wolf, your hash rate is a normal for 7950, do not use recheck 200 for mining without proxy, 400 is a optimal.
Miner hash rate is digits before 'H/s ='

Thanks drr0ss,farm recheck only shows hash rate more or less frequently or changing it also changes the result of hash?

tolazy

full member

Activity: 196

Merit: 100

stupid question.
what does --cl-local-work 128 --cl-global-work 8192 do.
mean will it make me do more shares. when i tried i didnt see any diff i used
--cl-local-work 256 --cl-global-work 16384
and
--cl-local-work 256--cl-global-work 8192
for my 390x

Genoil

sr. member

Activity: 438

Merit: 250

Quote from: Ayers on April 07, 2016, 01:23:52 AM

Quote from: Genoil on April 06, 2016, 09:16:08 AM

Removing the m_pending check will lead to these incomplete responses. That's why it's there. But it is not thread safe, will have to fix that.

is this response for my question about the crash?, i don't remember the crash in the 4b3 release

not to a crash. i get reports that the miner just randomly fails to receive new work any longer. trying to reproduce that behavior, but haven't succeeded yet.

Ayers

legendary

Activity: 2590

Merit: 1022