Bitcoin Forum
June 21, 2018, 11:27:55 AM *
News: Latest stable version of Bitcoin Core: 0.16.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
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 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 ... 107 »
  Print  
Author Topic: PhoenixMiner 3.0c: fastest Ethereum/Ethash miner with lowest devfee (Windows)  (Read 64014 times)
unixm
Newbie
*
Offline Offline

Activity: 1
Merit: 0


View Profile
February 28, 2018, 09:14:14 PM
 #761

Firstly I don't particularly care whether PM are using Claymore kernels.  Correct me if I am wrong, but if 2 miners share the same kernels yet PM is even slightly faster then that says something about Claymore's code?

Claymore obviously feels threatend now there's competition, but competition is a good thing.

If Claymore's miner submits shares at a lower difficulty then that in itself is useful for him.  For example if you have a lower powered rig, perhaps 1 GPU, it's better to switch to his devfee and find any share even at a lower difficulty than it is to switch and find nothing - When the 2nd scenario occurs Claymore esentially misses out in that devfee window to get something from you, but you still lose because of the time it's taking away from mining for you.

I don't trust Claymore's software and I certainly don't like his Dev Fee's.  I suppose the same can be argued for PM, but I'm happier paying a lower dev fee and with a faster miner.

You may argue he's entilted and earned it but let me tell you, if you run a packet sniffer (Wireshark etc) when it switches to Nicehash for him (or any other pool) and look up his address and then check that against Nicehash/pool you will be truly astounded at the money he is pulling in, in BTC alone - And that's just one thing - I cannot even describe the amount of currency he is making from his miners.

I understand developers need to be paid, but when you run his software you are signing up to paying him constantly for the duration of the time you use his miners - And let's face it most people run his miners - And mainly for the reason that it's the most widely used - Most articles & guides reference his miners.  Think about the new people coming into crypto mining who are just reading guides on how to set-up miners, they are all potential new customers to him.  A lot of people will use his miners because they've simply got it to work and don't even think about changing or finding something better.

There ought to be a better way of paying for this software, why can't you develop a system where you purchase a number of licenses as a one time thing per GPU or per rig - Surely that's more fair ? You wouldn't pay a fee every day to run Windows 10 on 200 machines would you ? That'd be insane.
Automated Bitcoin Fork Extraction Tool WE DO TOUGH WALLETS: BCH | BTG | BCD | SBTC | UBTC | B2X | BCX | BTF Electrum 2FA, Trezor, Ledger, SegWit, Bech32
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1529580475
Hero Member
*
Offline Offline

Posts: 1529580475

View Profile Personal Message (Offline)

Ignore
1529580475
Reply with quote  #2

1529580475
Report to moderator
1529580475
Hero Member
*
Offline Offline

Posts: 1529580475

View Profile Personal Message (Offline)

Ignore
1529580475
Reply with quote  #2

1529580475
Report to moderator
ZombieWorm
Newbie
*
Offline Offline

Activity: 2
Merit: 0


View Profile
February 28, 2018, 09:21:21 PM
 #762

Can anyone help, Phoenix connects and mines away but it seems to get both my cards to mine under one miner. I have two cards that independantly mine using a profit switcher. How do I get Pheonix to mine an instance on one card and if the other card auto-switches opens another window should it need to?

I have nvidia and AMD card in case anyone is wondering.
murgorx
Member
**
Offline Offline

Activity: 154
Merit: 11


View Profile
February 28, 2018, 10:32:41 PM
 #763

Guys, I have seen that the miner finds shares 4950MH and goes up to 928.2GH, have seen also results that go to 1TH+.
What is the meaning of this and how to regulate it, if I have to?
Could anyone give me an advice, please?

aurus33
Newbie
*
Offline Offline

Activity: 20
Merit: 0


View Profile
February 28, 2018, 11:49:45 PM
 #764

Guys, I have seen that the miner finds shares 4950MH and goes up to 928.2GH, have seen also results that go to 1TH+.
What is the meaning of this and how to regulate it, if I have to?
Could anyone give me an advice, please?

Higher difficulty shares means more profit reflected on your earnings from the pool, I do not think there's a way to regulate it, I think it's just simply luck, sometimes you solve higher diff shares, some other times you solve lower diff shares and, sometimes you solve nothing Smiley

I might be wrong tho, this is my understanding so far, havent come up with a good read on how the pools handle difficulty.
hamteivos
Newbie
*
Offline Offline

Activity: 16
Merit: 0


View Profile
March 01, 2018, 04:30:40 AM
 #765

Hitting with this error for the past 2 days, mining ETC on ethermine.
Both gtx 1060 and 1070 no hang, i still can see them using after burner.
Anyone hitting with this kind of errors?

17591:07:20:22.496: main Eth speed: 79.625 MH/s, shares: 47/0/0, time: 0:46
17591:07:20:22.496: main GPUs: 1: 18.465 MH/s (9) 2: 31.832 MH/s (21) 3: 29.329 MH/s (17)
17591:07:20:25.706: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0xeb77fae561c0afcd983a8ff0a1c8372dbead6d4264853049fc44725f2dcbfa7f","0x5683748fa7f53897f1e1a80a8a321d3693761838135be37d1d132c0cd3d7d937","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x5382a3"]}
17591:07:20:25.706: eths Eth: New job #eb77fae5 from eu1-etc.ethermine.org:14444; diff: 4000MH
17591:07:20:27.512: main Eth speed: 78.413 MH/s, shares: 47/0/0, time: 0:46
17591:07:20:27.512: main GPUs: 1: 17.995 MH/s (9) 2: 31.103 MH/s (21) 3: 29.316 MH/s (17)
17591:07:20:29.897: GPU2 CUDART error in CudaProgram.cu:422 : unspecified launch failure (4)
17591:07:20:29.897: GPU2 GPU2 search error: unspecified launch failure
17591:07:20:29.948: GPU1 CUDART error in CudaProgram.cu:422 : unspecified launch failure (4)
17591:07:20:29.949: GPU1 GPU1 search error: unspecified launch failure
17591:07:20:32.334: eths Eth: Send: {"id":6,"jsonrpc":"2.0","method":"eth_submitHashrate","params":["0x4bdeed8","0x94d6170da9ae5da346e6ef1432826c5f7c8d2db8c37ea7de36306d9565f93789"]}

17591:07:20:32.526: eths Eth: Received: {"id":6,"jsonrpc":"2.0","result":true}
17591:07:20:32.544: main Eth speed: 79.620 MH/s, shares: 47/0/0, time: 0:46
17591:07:20:32.544: main GPUs: 1: 18.463 MH/s (9) 2: 31.829 MH/s (21) 3: 29.329 MH/s (17)
17591:07:20:37.575: main Eth speed: 29.327 MH/s, shares: 47/0/0, time: 0:46
17591:07:20:37.575: main GPUs: 1: 0.000 MH/s (9) 2: 0.000 MH/s (21) 3: 29.327 MH/s (17)
17591:07:20:38.346: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0x020e766278c1681f610557f3dfcc9dbf2713e80daafe51c570d60cf53b50a20d","0x5683748fa7f53897f1e1a80a8a321d3693761838135be37d1d132c0cd3d7d937","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x5382a4"]}
17591:07:20:38.347: eths Eth: New job #020e7662 from eu1-etc.ethermine.org:14444; diff: 4000MH
17591:07:20:38.350: GPU1 GPU1: Starting up...
17591:07:20:38.397: GPU2 GPU2: Starting up...
17591:07:20:38.431: GPU1 CUDART error in CudaProgram.cu:230 : all CUDA-capable devices are busy or unavailable (46)
17591:07:20:38.431: GPU1 GPU1 initMiner error: all CUDA-capable devices are busy or unavailable
17591:07:20:38.469: GPU2 CUDART error in CudaProgram.cu:230 : all CUDA-capable devices are busy or unavailable (46)
17591:07:20:38.469: GPU2 GPU2 initMiner error: all CUDA-capable devices are busy or unavailable
17591:07:20:42.592: main 
17591:07:20:42.592: main Eth: Mining ETC on eu1-etc.ethermine.org:14444
17591:07:20:42.592: main Eth speed: 29.332 MH/s, shares: 47/0/0, time: 0:46
17591:07:20:42.592: main GPUs: 1: 0.000 MH/s (9) 2: 0.000 MH/s (21) 3: 29.332 MH/s (17)
17591:07:20:42.592: main Eth: Accepted shares 47 (0 stales), rejected shares 0 (0 stales)
17591:07:20:42.592: main Eth: Incorrect shares 0 (0.00%), est. stales percentage 0.00%
infectedmushi
Jr. Member
*
Offline Offline

Activity: 39
Merit: 0


View Profile
March 01, 2018, 05:41:38 AM
 #766

17591:07:20:29.897: GPU2 CUDART error in CudaProgram.cu:422 : unspecified launch failure (4)
17591:07:20:29.897: GPU2 GPU2 search error: unspecified launch failure
17591:07:20:29.948: GPU1 CUDART error in CudaProgram.cu:422 : unspecified launch failure (4)
17591:07:20:29.949: GPU1 GPU1 search error: unspecified launch failure
17591:07:20:32.334: eths Eth: Send: {"id":6,"jsonrpc":"2.0","method":"eth_submitHashrate","params":["0x4bdeed8","0x94d6170da9ae5da346e6ef1432826c5f7c8d2db8c37ea7de36306d9565f93789"]}
.
.
.

17591:07:20:38.350: GPU1 GPU1: Starting up...
17591:07:20:38.397: GPU2 GPU2: Starting up...
17591:07:20:38.431: GPU1 CUDART error in CudaProgram.cu:230 : all CUDA-capable devices are busy or unavailable (46)
17591:07:20:38.431: GPU1 GPU1 initMiner error: all CUDA-capable devices are busy or unavailable
17591:07:20:38.469: GPU2 CUDART error in CudaProgram.cu:230 : all CUDA-capable devices are busy or unavailable (46)
17591:07:20:38.469: GPU2 GPU2 initMiner error: all CUDA-capable devices are busy or unavailable

i was having this also, for me it was related to some OC settings.

@Claymore competition is always healthy for every party.. despite if PM dev is using Claymore's code, he should give him credits for it at least..
PhoenixMiner
Jr. Member
*
Offline Offline

Activity: 131
Merit: 5


View Profile
March 01, 2018, 06:58:37 AM
 #767

@PhoenixMiner:

you use my GPU kernels in your "fastest" miner, 100% match of binaries. I can prove it if you are not going to confirm it.
So do you confirm it?
   No, we certainly DO NOT confirm it. We believe that you've tried (and apparently you think you succeeded) in extracting our kernels using reverse engineering techniques. That wasn't very nice of you to say the least but we have expected something like this, just not that fast. In some sense it is flattering but also a little annoying.

   The first version of our kernels was obtained from someone on this very forum for quite a bit of coins. They were a little bit slower than the best miner on the market at this time - yours - but we decided to use them to jump start our project anyway. After a lot of tinkering with Polaris GPUs we found out how to increase the speed a bit and improved the kernels a lot, achieving higher speed and/or lower consumption than your miner (in most cases). The original versions were left as a honeypot for particularly persistent reverses which apparently did its job quite well Smiley

   Now, are these old kernels the same as old versions of yours? We don't know for sure but we doubt it, and we can't just take your word for it (especially after throwing accusations like this after basically admitting that YOU are trying to reverse OUR miner), and because they were slower than your miner, and they do not support dual mining at all (and dual mining is still the killer feature). But even if they were, frankly this isn't our problem - we've paid handsomly for them, and we haven't used them in any of the publicly released versions, so we won't lose any sleep over this. If you beleive so, search for a digruntlet employee, or perhaps your unnamed source(s) at AMD?

   Last but not least, we take offense in your description of our miner as a "wrapper" around the kernels. While the kernels are very important, the miner is wrapper no more than a car is a "wrapper" around the engine's crankshaft Wink The source code of the whole miner is two orders of magnitude larger and more complex than the kernels, so we beg to differ here in our opinions. We may have less than percent of your market share but we are proud of our miner and (after we finally crack dual mining, and release Linux version   Embarrassed ) we believe that it is going to be the best in the market.
PhoenixMiner
Jr. Member
*
Offline Offline

Activity: 131
Merit: 5


View Profile
March 01, 2018, 07:44:46 AM
 #768

Hi did anybody ever figure out the Fatal Error: debugger detected problem?

Over the last week I have installed 3 rigs, 2 went fine, third one was a problem. The only thing I can point out as different is that on the 3rd one I had to grab a new win10 ISO from MS as I lost my USB, otherwise it is the same https://www.scan.co.uk/products/asrock-z270-killer-sli-intel-z270-s-1151-ddr4-sata3-m2-(pcie-sata)-2-way-sli-crossfire-gbe-usb-30-ap?v=c same ram, same psu, and same cpu. Cards are a bit different but shouldn't be relevant.

At work so I can't check the bios but all 6 cards are present and correct, dagpatch done etc. Claymores is currently running fine so it's not as far as I can tell a hardware issue. Can remote in and try settings if anyone has suggestions.

Otherwise superb miner, can't wait for linux version (focus on Ubuntu as that seems most common!).
   It's definitely not a hardware problem - this is the anti-debug code activating without good reason apparently. We are trying to make these checks smarter and lighter but obviously we aren't there yet. Still, we are hesitant to relax the checks too much for obvious reasons - apparently there is no lack of highly esteemed developers trying to reverse our miner Wink
   
Is there a certain date for dual mining? thx
   Not yet, unfortunately, it is proving to be harder that we expected, so we better not throw around optimistic schedules without delivering.

I've been mining since 2.4, now on 2.7b, on a single Vega 56, W10, latest drivers, and it's been mostly fine. I've only experienced one recurring problem where mining stops (driver crash AFAIK) then restart and hangs at detecting cards for 60-80 minutes before resuming mining. Before 2.7b, my wattman overclock settings were reset to default, now with 2.7b I get to keep my settings which is much better already.
    Thank you for the logs. Unfortunately we can't determine much from there just that the GPU thread is freezing after the crash. You've got quite a bit of memory overclock though maybe try dialing it back a little. We also had problems with Vega because of the card high power consumption - even 600W quality PSU led to sporadic crashes when powering a single Vega56 even with big underclock. It seems like Vega has high peak currents that lead to crashes if the PSU is not ridiculously overpowered. We have some work to do with hardware controls support for Vega though, as it appears to use some new (and undocumented) ADL functions and structures.

Any reason to NOT use -mi 12, but lower number?
   Stale shares. The high mining intensity increases the time window within which a stale share can occur. Therefore the default is 10 even though 12 gives a slightly higher hashrate. Still, the stale shares are sometimes dominated by the pool latency so you may see a better results with -mi 12 but keep an eye on stale shares to avoid losing more via stale shares than you have gained from the higher hashrate.

Do this program support OC, undervolt and set a work temp for gpu?
   Yes, but only the latest beta version which can be found here: https://bitcointalk.org/index.php?topic=2647654.msg31091660#msg31091660 The last official release (2.6) doesn't support these options yet.

Too bad if this is a ripoff of Claymore.
  It isn't  Cool

Can anyone help, Phoenix connects and mines away but it seems to get both my cards to mine under one miner. I have two cards that independantly mine using a profit switcher. How do I get Pheonix to mine an instance on one card and if the other card auto-switches opens another window should it need to?

I have nvidia and AMD card in case anyone is wondering.
   Yes, you can. Start a two copies of PhoenixMIner and add the -amd command-line option on the first, and -nvidia on the second. The first will mine only with the AMD card and the second - with the Nvidia card.

Guys, I have seen that the miner finds shares 4950MH and goes up to 928.2GH, have seen also results that go to 1TH+.
What is the meaning of this and how to regulate it, if I have to?
Could anyone give me an advice, please?
   Well, actually you don't profit at all from the higher difficulty shares - it only matters that the share is above the difficulty specified by the pool. There is nothing sinister there though - this is the reason the pool exists: to equalize the luck of the individual miners according to their actual hashrates so it doesn't matter who actually finds the block.


Claymore
Donator
Legendary
*
Offline Offline

Activity: 1302
Merit: 1207

Miners developer


View Profile
March 01, 2018, 08:20:14 AM
 #769

@PhoenixMiner:

you use my GPU kernels in your "fastest" miner, 100% match of binaries. I can prove it if you are not going to confirm it.
So do you confirm it?
   No, we certainly DO NOT confirm it. We believe that you've tried (and apparently you think you succeeded) in extracting our kernels using reverse engineering techniques. That wasn't very nice of you to say the least but we have expected something like this, just not that fast. In some sense it is flattering but also a little annoying.

   The first version of our kernels was obtained from someone on this very forum for quite a bit of coins. They were a little bit slower than the best miner on the market at this time - yours - but we decided to use them to jump start our project anyway. After a lot of tinkering with Polaris GPUs we found out how to increase the speed a bit and improved the kernels a lot, achieving higher speed and/or lower consumption than your miner (in most cases). The original versions were left as a honeypot for particularly persistent reverses which apparently did its job quite well Smiley

   Now, are these old kernels the same as old versions of yours? We don't know for sure but we doubt it, and we can't just take your word for it (especially after throwing accusations like this after basically admitting that YOU are trying to reverse OUR miner), and because they were slower than your miner, and they do not support dual mining at all (and dual mining is still the killer feature). But even if they were, frankly this isn't our problem - we've paid handsomly for them, and we haven't used them in any of the publicly released versions, so we won't lose any sleep over this. If you beleive so, search for a digruntlet employee, or perhaps your unnamed source(s) at AMD?

I decided to check your miner as soon as I noticed that you have same tuning option ("+" and "-" keys in runtime) that works exactly as my -dcri option, also your miner has no "optimized" kernels for same set of chips as my miner. After checking I found 100% match in GPU kernel on GPU.
Now you are talking about some "old unknown" kernels and you don't use them anymore and have super-protection that can fool me and so on... okay.
I will create step-by-step guide how to confirm that you send my kernels to GPU and you will say that your miner uses "old unknown" kernels because it detects dumping but still mines at the same speed. That's funny answer, but you don't have better one, I understand.
So my word against yours. The result is obvious for me, however, since I call you a liar, anyone who wants to confirm by yourself that this miner uses my kernels can PM me and I will send step-by-step guide how to do it, then you can say the results; no newbies please, be at least sr.member on this forum, just to be sure that you don't want to become another "phoenixminer" and spend my time again...

Please read Readme and FAQ in the first post of this thread before asking any questions, probably the answer is already there.
List of my miners: https://bitcointalk.org/index.php?topic=3019607
Rewqpro
Jr. Member
*
Offline Offline

Activity: 51
Merit: 0


View Profile
March 01, 2018, 08:21:11 AM
 #770

What a drama coming!

For those who wants Claymore to lower dev fee - suck it up dudes, he makes constant developments of miner things and he's the only one who always deliver.

If you are so greedy and for you 0.35% makes a huge difference (sick joke, seriously), it would be better to throw yourselves out of the window.

I am 100% sure those who have industrial mines have their own miner software and not have any problem with comission.

So, most of baby cryers outta here have 1 rig with 300$ monthly income -- 3$ per month for actually MAKING this income possible -- it is too much for you guys?




Coming back to reverse engineering thing, I do not appreciate such kind of actions. Hope it has nothing with stealing Claymore's code.

Have a nice day everyone!
Bigdrago
Jr. Member
*
Offline Offline

Activity: 182
Merit: 0


View Profile
March 01, 2018, 08:46:00 AM
 #771

I disabled fee in Claymore. Lost 1Mh/s on each gpu.

So it' s worth to pay the fee.
Wolf0
Legendary
*
Offline Offline

Activity: 1834
Merit: 1002


Miner Developer


View Profile
March 01, 2018, 08:54:27 AM
 #772

When was that comparison done - with the percentages? 1.3% isn't bad - I managed ~4.71% last November over his then-current version. Still working.

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

Activity: 51
Merit: 0


View Profile
March 01, 2018, 09:00:45 AM
 #773

I disabled fee in Claymore. Lost 1Mh/s on each gpu.

So it' s worth to pay the fee.
how come 1% is more than 1Mh/s ? what is wrong with you?
headshot155
Newbie
*
Offline Offline

Activity: 4
Merit: 0


View Profile
March 01, 2018, 09:20:01 AM
 #774

What a drama coming!

For those who wants Claymore to lower dev fee - suck it up dudes, he makes constant developments of miner things and he's the only one who always deliver.

If you are so greedy and for you 0.35% makes a huge difference (sick joke, seriously), it would be better to throw yourselves out of the window.

I am 100% sure those who have industrial mines have their own miner software and not have any problem with comission.

So, most of baby cryers outta here have 1 rig with 300$ monthly income -- 3$ per month for actually MAKING this income possible -- it is too much for you guys?




Coming back to reverse engineering thing, I do not appreciate such kind of actions. Hope it has nothing with stealing Claymore's code.

Have a nice day everyone!

I have significant hashpower and believe me, 0.35% makes a substantial difference at current prices
Wolf0
Legendary
*
Offline Offline

Activity: 1834
Merit: 1002


Miner Developer


View Profile
March 01, 2018, 09:21:45 AM
 #775

I disabled fee in Claymore. Lost 1Mh/s on each gpu.

So it' s worth to pay the fee.
how come 1% is more than 1Mh/s ? what is wrong with you?

Can't you count? The 1MH/s loss scales too. That is, let's say he has 1k GPUs, at 31MH/s per:

With the fee on, his "effective" hashrate is 31 * 1000 * 0.99 = 30,690MH/s.
With the nofee switch and the inability to modify the code to disable the slowdown: 30 * 1000 = 30,000MH/s.

Pretty clear to me.

Code:
Donations: BTC: 1WoLFdwcfNEg64fTYsX1P25KUzzSjtEZC -- XMR: 45SLUTzk7UXYHmzJ7bFN6FPfzTusdUVAZjPRgmEDw7G3SeimWM2kCdnDQXwDBYGUWaBtZNgjYtEYA22aMQT4t8KfU3vHLHG
Wolf0
Legendary
*
Offline Offline

Activity: 1834
Merit: 1002


Miner Developer


View Profile
March 01, 2018, 09:27:34 AM
 #776

@PhoenixMiner:

you use my GPU kernels in your "fastest" miner, 100% match of binaries. I can prove it if you are not going to confirm it.
So do you confirm it?
   No, we certainly DO NOT confirm it. We believe that you've tried (and apparently you think you succeeded) in extracting our kernels using reverse engineering techniques. That wasn't very nice of you to say the least but we have expected something like this, just not that fast. In some sense it is flattering but also a little annoying.

   The first version of our kernels was obtained from someone on this very forum for quite a bit of coins. They were a little bit slower than the best miner on the market at this time - yours - but we decided to use them to jump start our project anyway. After a lot of tinkering with Polaris GPUs we found out how to increase the speed a bit and improved the kernels a lot, achieving higher speed and/or lower consumption than your miner (in most cases). The original versions were left as a honeypot for particularly persistent reverses which apparently did its job quite well Smiley

   Now, are these old kernels the same as old versions of yours? We don't know for sure but we doubt it, and we can't just take your word for it (especially after throwing accusations like this after basically admitting that YOU are trying to reverse OUR miner), and because they were slower than your miner, and they do not support dual mining at all (and dual mining is still the killer feature). But even if they were, frankly this isn't our problem - we've paid handsomly for them, and we haven't used them in any of the publicly released versions, so we won't lose any sleep over this. If you beleive so, search for a digruntlet employee, or perhaps your unnamed source(s) at AMD?

I decided to check your miner as soon as I noticed that you have same tuning option ("+" and "-" keys in runtime) that works exactly as my -dcri option, also your miner has no "optimized" kernels for same set of chips as my miner. After checking I found 100% match in GPU kernel on GPU.
Now you are talking about some "old unknown" kernels and you don't use them anymore and have super-protection that can fool me and so on... okay.
I will create step-by-step guide how to confirm that you send my kernels to GPU and you will say that your miner uses "old unknown" kernels because it detects dumping but still mines at the same speed. That's funny answer, but you don't have better one, I understand.
So my word against yours. The result is obvious for me, however, since I call you a liar, anyone who wants to confirm by yourself that this miner uses my kernels can PM me and I will send step-by-step guide how to do it, then you can say the results; no newbies please, be at least sr.member on this forum, just to be sure that you don't want to become another "phoenixminer" and spend my time again...

I may look into it, just to check. While they have only a Win version, where I'm less practiced, I don't need nor want to go through the logic itself - location and extraction of the binary GPU kernel will tell me. Even if they based it on yours and made modifications - certain things in it stand out, so it shouldn't be ambiguous at all.

While I *know* it's quite possible to do better than Claymore's kernels - recently, he's made improvements resulting in them being quite a bit better, which cuts some of my own advantage. The optimizations in regards to core computations I've done result in me requiring far lower core clocks for the same hashrates, so I'll take the power savings. Despite this, I don't see Claymore blatantly lying about something so easily proved.

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

Activity: 39
Merit: 0


View Profile
March 01, 2018, 09:38:16 AM
 #777

disabling the fee ("-nofee" command) will lose "optimizations" according to claymore.. and it does, i've tried.

if you use the -nofee option, miner becomes slower for about 1MH/s ... i can confirm also.
PhoenixMiner
Jr. Member
*
Offline Offline

Activity: 131
Merit: 5


View Profile
March 01, 2018, 09:40:39 AM
 #778

@PhoenixMiner:

you use my GPU kernels in your "fastest" miner, 100% match of binaries. I can prove it if you are not going to confirm it.
So do you confirm it?
   No, we certainly DO NOT confirm it. We believe that you've tried (and apparently you think you succeeded) in extracting our kernels using reverse engineering techniques. That wasn't very nice of you to say the least but we have expected something like this, just not that fast. In some sense it is flattering but also a little annoying.

   The first version of our kernels was obtained from someone on this very forum for quite a bit of coins. They were a little bit slower than the best miner on the market at this time - yours - but we decided to use them to jump start our project anyway. After a lot of tinkering with Polaris GPUs we found out how to increase the speed a bit and improved the kernels a lot, achieving higher speed and/or lower consumption than your miner (in most cases). The original versions were left as a honeypot for particularly persistent reverses which apparently did its job quite well Smiley

   Now, are these old kernels the same as old versions of yours? We don't know for sure but we doubt it, and we can't just take your word for it (especially after throwing accusations like this after basically admitting that YOU are trying to reverse OUR miner), and because they were slower than your miner, and they do not support dual mining at all (and dual mining is still the killer feature). But even if they were, frankly this isn't our problem - we've paid handsomly for them, and we haven't used them in any of the publicly released versions, so we won't lose any sleep over this. If you beleive so, search for a digruntlet employee, or perhaps your unnamed source(s) at AMD?

I decided to check your miner as soon as I noticed that you have same tuning option ("+" and "-" keys in runtime) that works exactly as my -dcri option, also your miner has no "optimized" kernels for same set of chips as my miner. After checking I found 100% match in GPU kernel on GPU.
Now you are talking about some "old unknown" kernels and you don't use them anymore and have super-protection that can fool me and so on... okay.
I will create step-by-step guide how to confirm that you send my kernels to GPU and you will say that your miner uses "old unknown" kernels because it detects dumping but still mines at the same speed. That's funny answer, but you don't have better one, I understand.
So my word against yours. The result is obvious for me, however, since I call you a liar, anyone who wants to confirm by yourself that this miner uses my kernels can PM me and I will send step-by-step guide how to do it, then you can say the results; no newbies please, be at least sr.member on this forum, just to be sure that you don't want to become another "phoenixminer" and spend my time again...

Do what you've got to do of course - obviously you feel strongly about this and believe that this is well worth your time Smiley It's just not exactly clear what you are trying to prove though - we already conceded that our old/honeypot kernels might be the same as your old kernels but this is not very likely. But since you are willing to provide the blobs of your kernels in these PM sessions, our kernel guy would certainly like to take a look, so thank you.

Frankly we've got a lot of respect for you, and if you have chosen to contact us via PM with your concerns, we would have respected that and checked if there is any merit in your claims but you've come swinging and accusing us in our thread and if you expect us to just sit there and take it, you are quite wrong.

It is also quite wrong of you to assume these things:
  • That you can't be fooled by our anti-reversing measures (really do you think that we can't detect dll-injection attacks?).
  • And that, if you do succeed in extracting our real/current kernels and leak them in the open, we can't do the same with yours. "We know" a guy that was part of the driver development team of AMD and he is itching to test its kernel-level emulator by trying to extract your current kernels. Heck, if he's successful, we can even put your kernels in our miner and let the users select them explicitly and see for themselves how they compare with ours.  Grin

Anyway, we prefer to concentrate our efforts on improving our miner bit by bit (we are still lacking in many areas) but if you want to play this game, we can play it too. Just keep in mind that we were nobody in comparison with you just a few weeks ago, and you seem resolute to put us on the map so to speak, for which we thank you - it well known that controversial or bad publicity is always better than no publicity at all.  Grin
nitrobg
Member
**
Offline Offline

Activity: 353
Merit: 16


View Profile
March 01, 2018, 09:47:32 AM
 #779

Iamtutut
Jr. Member
*
Offline Offline

Activity: 140
Merit: 0


View Profile
March 01, 2018, 09:55:00 AM
 #780

Phoenix, is your 2.7B optimized for the latest AMD drivers ? It seems slower than the 2.6 with my 2 RX570 and blockchain drivers.
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 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 ... 107 »
  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!