Topic: PhoenixMiner 6.2c: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux) - page 487. (Read 784985 times)

its so nice to be amungst many 40+ people who remember the old stuff

So.. to @pheonixminer actually, it did it for EVERY devfee.. but it does seem to have stopped now.. Ive nothing my end which should stop it, in essence my firewall is all out nothing in if it was a 1 time error, Id not have reported it ran for about 8 hours never making a fee connection and then failed to make any connections at all

So the current main question is stale rate and are the numbers reporting the numbers received the other end..

So

Eth: Accepted shares 1600 (73 stales), rejected shares 0 (0 stales)
Eth: Incorrect shares 1 (0.04%), est. stales percentage 4.56%
Eth: Maximum difficulty of found share: 597.6 TH (!!!)
Eth: Average speed (5 min): 75.857 MH/s
Eth: Effective speed: 74.60 MH/s; at pool: 74.60 MH/s

ethermine says

reported: 76.01
average: 74.98

stales: 5%

so its pretty darn close to be fair.

can everyone please check effective hashrate on the pool side?

its relatively easy to have the excavator SAY you're running X MH/s, but if you aren't submitting shares consistent with that value, it doesnt matter and you will be paid based on a slower rate. this is what i experienced. I dont think anything nefarious is happening, and i like the communication from the dev thus far, but everyone should be diligent in tracking their ACTUAL performance vs what's reported.

in my case, over a 24hr period, Phoenix said it was running 2-3% faster, but submitted shares on nanopool were actually 2-3% lower than with claymore. I've switched back to claymore for now, but mainly ONLY because of the lack of tt and clock adjust functions. when those are added and the miner matures a bit, I'll give it a second shot.

@PhoenixMiner - please research a bit the stale problem. With 2.5d i get 3, 4 even 5 times more stale vs. 2.4. Anyway, the miner is amazing, getting 6 mhs more from 192 to 198 mhs with 6 rx 580. Good job.
Also, please add to the miner cclock, mclock, cvddc, mvddc and other commands from Claymore, it would be really awesome.

Started using this miner a few days ago, the reported hashrate increase from 176,8 to 177,1/4 but is now back at 176,4 +- after cleaning the gpu's and restarting the system really weird

I have been running PhoenixMiner 2.5d instead of Claymore for more than 24 hours and have to admit it is amazing.
My rig is 6x 1070 OC and I used to total 187 MH/s with Claymore: hashrate jumped 3.5% with same OC settings on Asus GPU Tweak II, so I was very pleased.
But the nicest part is that I was able to push OC even more with this miner, so GPUs are now running @ -91 core / +1592 mem smoothly, with avg hashrate of 196 MH/s.
Just by instaling this software and tweaking the GPUs, I gained more than 5% in hashrate, while paying less for dev fees.

ABOUT STALE SHARES: I have 28 after 24 hours, amounting to 1.36% on the total. Since I have no reference (first time mining with Phoenix), let me know if it's similar to what you are getting.
I am using ethermine and my config.txt file is the following:


QUESTION: do you know if ethermine allows sending stale shares? I am not specifying the "-stales " parameter, hence it's defaulting to 1 = "send stales"

So, I want to thank PhoenixMiner for the fantastic job and the great software.
Please keep squeezing performance from our almost-exhausted GPUs

Just an update here, I have two rigs running now on 2.4 and 2.5d (One on each) and I can confirm that on the 2.5d im seeing a massive increase in stale shares, 4-5 times the amount.

Over 3 hours, the 2.4 version has hit 11 stale shares, 2.5d is currently on 49 so there's definately something going on there, judging from the output im seeing shares being submitted on the 2.5d version with 8-9000ms in delay, this never happens on the 2.4 rig, that might correlate to more stales due to the longer report time.

As the poster above mentioned, I am too finding that 2.5d is providing for more stale shares than 2.4. But will leave it go for a little longer.

To the dev's, are any of the cclock/mclock/cvddc/mvddc/tt command line options being tabled for inclusion in later releases ?

I'm still using 2.4 and it's working great since the miner has been white listed to avoid disconnection.
Good job to devs.

Just switched over to 2.5d from Claymore. Working good so far... I'm going to let it run today and see how it does.

anyone use it, i need more information to use it, compare with claymore?

Nanopool does not report stats for stale shares, but the stales are still there.

I tried switching one of my machines (10 in total) back to v2.4 and at leat over the past hour the stale shares has dropped back to 5 for that rig, down from 31 the hour before that - 2.4 have even found 27% more shares in that timeframe, but too soon to tell if there's anything up with that.

Hi,
  
   I have been running  2.5d for 24 hrs. I have changed to nanopool.org. It dont have any problem.  

You most likely did not flash the bios correctly, the numbers suggest it is running stock bios.

In regards to 2.5d - After going through the logs I can see that I have actually had 7 hardware errors, somethings up with this build, my cards run perfectly stable with anything but 2.5d - Claymore, ethminer and v 2.4 can run for days without any errors, not even mem errors in hwinfo is logged.

I cannot get more than (in the past) 20 MH/s from my rx 480 and any miner I have tried.

I ended up with the slowest version ever released.  4GB, hynix RAM.

Flashing BIOS.  Blockchain drivers are even worse and cannot use my computer.

Equiqhash it can do at 580 s/s 24/7 with 2 of them.

I know, it doesn't make sense.

Only on my end that I have noticed a massive increase in stale shares with the 2.5d version?

I typically average around 2-4 stales per hour, which was true for version 2.4 and also for claymore, but with 2.5d im consistently at 25-30 stales per hour which is naturally a major problem.

It is worth noting that this is pool side, in the client the stale shares are ~2%

Nope my friend. i have no keyboard with my rigs. Even if choose N(no) mining crashes... weird issue. I hope developer will reply.

I'm 52

I had most fun with 6502 actually, it was like first RISC, 1MHz 6502 was on par with 4MHz Z80
But most elegant was 68000, Intel processors code was mess in comparison to Motorola

Didn't know its a group effort, I thought Phoenixminer was lone wolf miner


I have idea what coin you could actually dual mine to get some advantage over Claymore, as
most current algos will fade away soon. Maybe we could discuss that in PMs

   The only thing than can be possibly linked to this is the new OpenCL initialization code (if you are using AMD cards?). We will make it optional in the next version if there are more reports of such behavior as the solved problem by the new code (occasional crashes on startup) is quite rare.

   Thank you for the log. As you have the same problem with both 2.4 and 2.5d, this isn't caused by the new OpenCL initialization code. OpenCL error -6 is CL_OUT_OF_HOST_MEMORY, which probably means that you have to increase the size of your page file to at least 16 GB. Let us know if the increasing of the page file size (you have to restart Windows after that in order to apply the changes) doesn't solve the problem.

   We tested with the same devfee pool by disabling all others (eth-eu2.nanopool.org:9999) and it worked fine. Probably a temporary connection issue. Furthermore, 2.5d has at least one backup devfee pool (and in most cases two), so this shouldn't be a problem.

    At first we though that ethermine was having difficulties with the spike in Ethereum hash power lately. As soon as we realized that the block is targeting our miner, we published a warning message here. You are probably right and we should have tried to contact them beforehand but it's a bit of chicken and the egg problem - if (almost) nobody uses our miner why should they believe us and white-list us just based on our word? Additionally, outright blocking IP-s is probably not the best way to deal with a potential botnet. Perhaps it would be better to just "shadow-ban" the suspicus  devfee-like connections and accept shares as normal but don't credit any coins to these addresses. In this way if the connections are from malicious software, the bad guys would give up because there is no upside to continue. And if it is a legitimate miner as ours, it would only affect our devfee, not the users of our miner, which was way, way worse.

   Anyway, it seems that the issue is fully resolved now - ethermine and ethpool work normally with PhoenixMiner (even the older versions). Kudos to ethermine for reacting so quickly, they really are top notch. Unfortunately the few bad apples in this business make the life harder for everybody else.

   Our average age is closer to 40 than to 30  It is fun but the last two days (and nights) were anything but. There was a lot of swearing, hair pulling, and face-palming in our office. To continue the side note, one of our programmers is really into retro computing. His house is like a computer museum. His remark: "6502 wasn't fun to write for, 8080/Z80 was much better, and when the IBM PC came out, the 8088 assembly was like writing in high-level language, compared to 6502".

I'm mining expanse at

https://exppool.maxhash.org/#/

no problems at all

I moved mine to nanopool and the miner works grate for now ,no connection errors , reported hashrate is 665.3 Mh/s as it is and avarage hash for 6 hours 643.6 , which is super. Keep the good work.