<<  >> (p.17)
    Author Topic: ethminer-0.9.41-genoil-1.1  (Read 397410 times)

    • maxvall
    Sr. Member
    ****
    Offline Offline

    Activity: 268
    Merit: 250


    View Profile
    April 07, 2016, 12:34:05 PM
    Last edit: April 07, 2016, 12:52:10 PM by maxvall
     #321
    Quote from: Genoil on April 07, 2016, 09:24:24 AM
    Quote from: Ayers on April 07, 2016, 06:23:52 AM
    Quote from: Genoil on April 06, 2016, 02:16:08 PM
    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, 11: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.

  • Genoil (OP)
    Sr. Member
    ****
    Offline Offline

    Activity: 438
    Merit: 250


    View Profile
    April 07, 2016, 01:05:40 PM
     #322
    Quote from: maxvall on April 07, 2016, 12:34:05 PM
    Quote from: Genoil on April 07, 2016, 09:24:24 AM
    Quote from: Ayers on April 07, 2016, 06:23:52 AM
    Quote from: Genoil on April 06, 2016, 02:16:08 PM
    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.
    ETH: 0xeb9310b185455f863f526dab3d245809f6854b4d
    BTC: 1Nu2fMCEBjmnLzqb8qUJpKgq5RoEWFhNcW

  • davembg
    Sr. Member
    ****
    Offline Offline

    Activity: 340
    Merit: 251


    Smell the glove.


    View Profile
    April 07, 2016, 06:27:17 PM
     #323
    Quote from: w0lf0. on April 07, 2016, 11:56:55 AM
    Quote from: drr0ss on April 06, 2016, 09:20:40 PM
    Quote from: w0lf0. on April 04, 2016, 03:15:21 PM
    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 (OP)
    Sr. Member
    ****
    Offline Offline

    Activity: 438
    Merit: 250


    View Profile
    April 07, 2016, 08:26:01 PM
     #324
    Quote from: davembg on April 07, 2016, 06: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
    ETH: 0xeb9310b185455f863f526dab3d245809f6854b4d
    BTC: 1Nu2fMCEBjmnLzqb8qUJpKgq5RoEWFhNcW

  • sorry2xs
    Legendary
    *
    Offline Offline

    Activity: 924
    Merit: 1000


    Dark Passenger Bitcoin miner 2013,Bitcoin node


    View Profile
    April 07, 2016, 08:30:09 PM
     #325
    Genoil here is a toke for you: 6b97afb3ce515d3926403cb09e4e61b50555670466655f9bd7c0704f250bbb3f-000 Smiley
    Please tip the Node 1MPWKB23NsZsXHANnFwVAWT86mL24fqAjF; KO4UX
    THAT NO GOOD DO GOODER BAT!!!

  • davembg
    Sr. Member
    ****
    Offline Offline

    Activity: 340
    Merit: 251


    Smell the glove.


    View Profile
    April 08, 2016, 02:48:15 AM
     #326
    Quote from: Genoil on April 07, 2016, 08:26:01 PM
    Quote from: davembg on April 07, 2016, 06: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.

  • Genoil (OP)
    Sr. Member
    ****
    Offline Offline

    Activity: 438
    Merit: 250


    View Profile
    April 08, 2016, 07:23:42 AM
     #327
    Quote from: davembg on April 08, 2016, 02:48:15 AM
    Quote from: Genoil on April 07, 2016, 08:26:01 PM
    Quote from: davembg on April 07, 2016, 06: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.
    ETH: 0xeb9310b185455f863f526dab3d245809f6854b4d
    BTC: 1Nu2fMCEBjmnLzqb8qUJpKgq5RoEWFhNcW

  • ol92
    Sr. Member
    ****
    Offline Offline

    Activity: 445
    Merit: 255


    View Profile
    April 08, 2016, 07:57:06 AM
     #328
    Quote from: Genoil on April 08, 2016, 07:23:42 AM
    Quote from: davembg on April 08, 2016, 02:48:15 AM
    Quote from: Genoil on April 07, 2016, 08:26:01 PM
    Quote from: davembg on April 07, 2016, 06: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 (OP)
    Sr. Member
    ****
    Offline Offline

    Activity: 438
    Merit: 250


    View Profile
    April 08, 2016, 10:42:40 AM
     #329
    Quote from: sorry2xs on April 07, 2016, 08:30:09 PM
    Genoil here is a toke for you: 6b97afb3ce515d3926403cb09e4e61b50555670466655f9bd7c0704f250bbb3f-000 Smiley

    Thanks! Much appreciated!
    ETH: 0xeb9310b185455f863f526dab3d245809f6854b4d
    BTC: 1Nu2fMCEBjmnLzqb8qUJpKgq5RoEWFhNcW

  • davembg
    Sr. Member
    ****
    Offline Offline

    Activity: 340
    Merit: 251


    Smell the glove.


    View Profile
    April 08, 2016, 09:58:59 PM
     #330
    Quote from: ol92 on April 08, 2016, 07:57:06 AM
    Quote from: Genoil on April 08, 2016, 07:23:42 AM
    Quote from: davembg on April 08, 2016, 02:48:15 AM
    Quote from: Genoil on April 07, 2016, 08:26:01 PM
    Quote from: davembg on April 07, 2016, 06: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 Smiley

  • malekbaba
    Legendary
    *
    Offline Offline

    Activity: 1526
    Merit: 1026


    View Profile
    April 09, 2016, 04:38:24 AM
     #331
    is it still worth mining Eth ? price is down and difficulty is sky high.

  • aimsml
    Member
    **
    Offline Offline

    Activity: 66
    Merit: 10


    View Profile
    April 09, 2016, 01:41:19 PM
     #332
    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
    Full Member
    ***
    Offline Offline

    Activity: 290
    Merit: 100


    View Profile
    April 09, 2016, 01:44:40 PM
     #333
    Quote from: aimsml on April 09, 2016, 01:41:19 PM
    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
    **
    Offline Offline

    Activity: 66
    Merit: 10


    View Profile
    April 09, 2016, 01:49:52 PM
     #334
    Quote from: Ekanenf on April 09, 2016, 01:44:40 PM
    Quote from: aimsml on April 09, 2016, 01:41:19 PM
    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
    Sr. Member
    ****
    Offline Offline

    Activity: 266
    Merit: 250


    View Profile
    April 09, 2016, 04:45:52 PM
     #335
    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?
    CZd9oh4FWe4f1TB69YyedxnuGyHt21zEPu

  • scryptr
    Legendary
    *
    Offline Offline

    Activity: 1798
    Merit: 1028



    View Profile WWW
    April 10, 2016, 12:14:19 AM
     #336
    Quote from: shadypepe on April 09, 2016, 04:45:52 PM
    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
    SCRYPTR'S NOTEBOOK: https://bt.irlbtc.com/view/5035515.msg46035530#msg46035530
    GITHUB: "github.com/scryptr"  MERIT is appreciated, also.  Thanks!

  • parmatiya
    Full Member
    ***
    Offline Offline

    Activity: 239
    Merit: 250


    View Profile
    April 10, 2016, 08:06:55 AM
     #337
    Quote from: aimsml on April 09, 2016, 01:49:52 PM
    Quote from: Ekanenf on April 09, 2016, 01:44:40 PM
    Quote from: aimsml on April 09, 2016, 01:41:19 PM
    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
    Legendary
    *
    Offline Offline

    Activity: 3276
    Merit: 1072



    View Profile
    April 10, 2016, 09:18:09 AM
     #338
    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
    Member
    **
    Offline Offline

    Activity: 118
    Merit: 10

    PC repair master, engeneer, radioamateur


    View Profile WWW
    April 10, 2016, 03:00:34 PM
     #339
    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.
    Minergate altcoins GUI miner since 2014 ->
    Best BTC faucet ever since 2014 ->Win Free Bitcoins every hour! - www.freebitco.in

  • shadypepe
    Sr. Member
    ****
    Offline Offline

    Activity: 266
    Merit: 250


    View Profile
    April 10, 2016, 07:09:32 PM
     #340
    Quote from: scryptr on April 10, 2016, 12:14:19 AM
    Quote from: shadypepe on April 09, 2016, 04:45:52 PM
    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!
    CZd9oh4FWe4f1TB69YyedxnuGyHt21zEPu
    Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 [17] 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 ... 90 »
      Print  
Page 16
Viewing Page: 17

IRLBTC™ © 2025 IRLBTC.com