ethminer-0.9.41-genoil-1.1

[maxvall]

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 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.

[Genoil]

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.

[davembg]

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]

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 

[sorry2xs]

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

[davembg]

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  

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.

[Genoil]

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  

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.

[ol92]

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  

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]

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

Thanks! Much appreciated!

[davembg]

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  

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

[malekbaba]

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

[aimsml]

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.

[Ekanenf]

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]

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.

Thanks for the answer.
When working in a solo there is no need to put any parameters. This is true?

[shadypepe]

I'm mining like 1.7 MHash/s on my Intel 530 internal GPU (6700k), do you think that's quite efficient if I just let that run when the PC is on anyway?

[scryptr]

I'm mining like 1.7 MHash/s on my Intel 530 internal GPU (6700k), do you think that's quite efficient if I just let that run when the PC is on anyway?

STRATUM OR GETWORK? --

If you are running on a stratum connection, you will get lunch money every week.  NanoPool suggests a minimum of 5MH/s for a single miner.  With GetWork, you'd be fading in and out, but will still pull in a few dollars a week.  If your computer is well ventilated, you should be OK.  I don't know how much heat is a problem mining that way.  My AMD cards stay under 70 deg C if the room temp is cool.  My nVidia cards actually run hotter, they are in closely spaced rigs.  nVidia cards still use less energy, though.       --scryptr

[parmatiya]

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.

Thanks for the answer.
When working in a solo there is no need to put any parameters. This is true?

No. You still need to put in parameters, like:

setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_USE_SYNC_OBJECTS 1
setx GPU_MAX_HEAP_SIZE 100

ethminer -G --cl-global-work 16384 --cl-local-work 64

[Amph]

there is still that stupid crash affecting the last build? after a while of mining my gpu dead and i need to restart, it appear to be true only when i run the full hash possible, in the sense that i do not decrease the intensity

[bbopa637]

Could you tell me, is there a way to see ETH pool current difficulty (VARDIFF) in ethminer?? Like cgminer and sgminer it shows. Mining on this stupid dwarfpool, and I have acctepted 1 per 10-13 minutes, just 10 minutes loosing time, not fining any hashes, because of very big vardiff vich this pool automatically set for miners. So I want to see that difficulty. My mining speed is 15MH/s.

[shadypepe]

I'm mining like 1.7 MHash/s on my Intel 530 internal GPU (6700k), do you think that's quite efficient if I just let that run when the PC is on anyway?

STRATUM OR GETWORK? --

If you are running on a stratum connection, you will get lunch money every week.  NanoPool suggests a minimum of 5MH/s for a single miner.  With GetWork, you'd be fading in and out, but will still pull in a few dollars a week.  If your computer is well ventilated, you should be OK.  I don't know how much heat is a problem mining that way.  My AMD cards stay under 70 deg C if the room temp is cool.  My nVidia cards actually run hotter, they are in closely spaced rigs.  nVidia cards still use less energy, though.       --scryptr

Getwork, haha I like gambling a bit. My pc is well ventilated, 25mm fan + 2 120mm and the i7 is liquid cooled (Corsair H110). Thanks though, I'll let it run then I guess!