Topic: [ANN]Bminer: a fast Equihash/Ethash/Cuckaroo29z miner for AMD/NVIDIA GPUs 16.4.9 - page 114. (Read 148347 times)

So Phil  how will you do this test?

You have 2 identical machines.
They run on the same router  with the same gigabyte switch correct?

Okay
 for testing bminer against dstm to test the software you need 2 identical rigs pointed to the same pool running simultaneously

you need 2 identical rigs..  test 3 days  in a row at the same time on the same pool from the same gigabyte switch

rig a on bminer rig b on dstm  after 3 day test reverse

rig b on bminer rig a on dstm after 3 day test reverse

rig a on bminer rig b on dstm after 3 day test reverse

rig b on bminer rig a on dstm after 3 day test stop and tally


in theory bminer should do a  better avg.

now I have two identical rigs  both are omen hp rigs with a pair of 1080ti's in them.

I did some testing with a lot of rigs pointed to   nicehash  but I will set up the omens  and leave them

running.

So I just  set up 2 rigs on simple mining

both are omen hp.co with
i5 8400 cpu
8 gb ram
750 watt psu
2x 1080ti's
clocks are
 130 core
 600 ram
  69c  temp
   73 fan
155 watts

clocks are the same


they  are pointed to new btc account at nicehash.  all that matters it the btc number all other stats are bullshit.  I pointed them within 1 minute of each other.

I will come back and show results in a day.

I will then show results in 2 days

and then show results in 3 days

the one one the left is dstm

May I ask how many days test would be more accurate How to make the test more accurate? How about 3 days?

Never mind, I just found it on the website.
https://www.bminer.me/references/#rest-apis

Where can I find detailed API information?

https://www.bminer.me/faq/#why-does-windows-defender-report-bminer-as-virus-malicious-software

This is quite normal, their FAQ page has similar questions been answered, also Bminer runs on Win x64.

i think pool problem i'm moving to poolhub and works fine

what's your problem? I have some experience mining BTCP at suprnova with this miner, maybe I can help

Maybe, but why with DSTM (during several days 7-8 or more) my pool (viabtc.com) report that my average hashrate after 24h (even estimated as you said) is a solid 900-910sol, and with bminer, during more than a month, I always had 850-870sol every day and no more?

Bminer V 5.5.0 reports the following in windows....

i have problem mining at suprnova with this miner ... somebody know to solve this?

Thanks

Before that i am using DSTM 0.6 version so now i switch to bminer to test it out and have been running for 3 days..

In term of harshrate it seem slightly higher .. around 7300 sols to 7340 sols on average hashrate (24 hours) and the payout time is about average about every 3hrs. Rejected shares about 0.4% for my 1st rig and 0.7% for my 2nd rig.

Before that i use on nicehash before and the rejected shares is about 2% to 3% but now i mine at flypool the rejected share rate is alot lower...

Any way to mine ZERO coin on suprnova?

ZERO - equihash 192-7

and a 1 day test is not accurate as 900 sols could simply have a bad day  and vary a lot  as much as 10%  since the pool decides your rate by the shares you submit

Scorpio, pools do not know your hashrate, they only estimate it.

[quote author=realbminer
# Why the reported hashrate of Bminer is higher than the reported hashrate from mining pools?

Bminer reports hashrate generated by your *hardware*, while a mining pool
estimates the hashrate based on the number of submitted shares. The Bminer
hashrate is different from the pool hashrate because:

1. The Bminer reported hashrate includes the devfee.

2. A small portion of the generated shares may get rejected or become stale due
   to network delay and transmission problems. Bminer reported hashrate will
   include such shares, but such shares will not contribute to the pool
   estimated hashrate.

3. Your pool hashrate is an estimate based on received shares, therefore it
   will vary a lot unless you control a significant amount of hashpower and you
   run it over a long period of time.

4. Some pools may calculate the estimated hashrate incorrectly.

Specially, if you turn on nofee option. You will see the same number of
hashrate but the underlying computation is slowed down due to disabled
optimizations.
[/quote]
But the problem is that with DSTM in console my hasrate is 925sol and in the pool I have solid 900-910sol after 24 or 48 hours, as it should be with 2% devfee. And with bminer in the same conditions in console my hashrate is 955sol but in the pool after 24h only 860-870( And that is a big disappoint of bminer. I hope you will fix these issues in the future update)

https://www.bminer.me/faq/

just found some answers here

I am using bminer 5.4 from simplemining.net

https://www.nicehash.com/miner/3QPFEdX8rtXHoVZHct5eUbp7AK1t1vRMfL

will run it for a bit.  then run same gear on  dstm

I will also check to see if simplemining.net  will update to your latest version  6.0


to all  2%  is a huge amount of money  op has no incentive to steal as  people would just stop using his miner and go to dstm

lets see what my testing shows.

And there will be support for Algo Equihash 96/5 (Mars) for coin MinexCoin?

I am actively working on 6.0 and I hope I can release it out before next week. I am also working actively on a big release (after 6.0) which would bring additional hash algorithm supports in bminer.

I am not ignoring any of your concerns. During the last two weeks, I just focused more on the development and did not get time to monitor bitcointalk thread.

Here are my answers to questions about console hashrate, rejected shares, and private connections. I will also update FAQ because these questions have been raised many times.

# Why the reported hashrate of Bminer is higher than the reported hashrate from mining pools?

Bminer reports hashrate generated by your *hardware*, while a mining pool
estimates the hashrate based on the number of submitted shares. The Bminer
hashrate is different from the pool hashrate because:

1. The Bminer reported hashrate includes the devfee.

2. A small portion of the generated shares may get rejected or become stale due
   to network delay and transmission problems. Bminer reported hashrate will
   include such shares, but such shares will not contribute to the pool
   estimated hashrate.

3. Your pool hashrate is an estimate based on received shares, therefore it
   will vary a lot unless you control a significant amount of hashpower and you
   run it over a long period of time.

4. Some pools may calculate the estimated hashrate incorrectly.

Specially, if you turn on nofee option. You will see the same number of
hashrate but the underlying computation is slowed down due to disabled
optimizations.

# Why I see rejected shares when using Bminer?

There are many reasons for rejected shares. Two primary reasons for rejected
shares are:

1. Network latency: If your latency to the connected pool is too long, then a
   valid share may become stale and invalid during the transmission. This will
   cause the share being rejected. The solution to this problem is to choose a
   pool server that has low latency connection to your rig.

2. Overclocking: Aggressive overclocking setting may cause GPU to produce
   incorrect results and therefore generates invalid shares being rejected.

Software bugs in Bminer may also cause a small portion of rejected shares. We
will keep improving bminer and reduce the number of rejected shares.

# Why Bminer starts private connections to bminer.me

The first communication checks the update and receives license information,
including for example where to mine devfee. Note that in this communication
bminer *does not send out any information*, it only receives information from
bminer.me.

The follow-up communications only send runtime information of bminer, like the
mining speed of each card and performance status. This may enable bminer to
choose better optimization strategies. Starting from version 6.0.0, these
follow-up communications will become transparent.