Optiminer/Zcash v1.7 (GPU, Windows+Linux, AMD)

[optiminer]

Can you explain in detail what the differences are between the pci-modes?

They use different mechanisms to transfer data between CPU and GPU.

1.6.2 used PCI mode 0 as default.
1.7 uses 2 as default (which is very similar to 0).
Mode 1/3 are closer to what 1.5 did.

[Za1n]

Dear Optiminer Support,
I would like to show HD7950 3G mine with Claymore and Optiminer
- Claymore V12.2: I got 228-230 sol per card. so 5 x 7950 ~ 1150 sol. Wat on wall: 670wat.
- Optiminer V1.7 : I got 206-211 sol per card. So 5 x 7950 ~ 1040 sol. Wat on wall: 678wat.


Best rdg.
John.

I am not support, but I will say that the local displayed (console) hashrates do not always tell the whole story.

A better test would be to run each client for 24 hours on a pool and see how they stack up in terms of shares submitted and income. Ideally you would have two identical rigs that have performed similarly in the past, so you could run each client at the same time to try and reduce the external variations (network hashrate, pool luck, etc.) that happen on a daily basis.

But my main point is at the end of the day it's the number of shares submitted and accepted by the pool that pay your bills, not what the local miner console displays.

[Za1n]

I am going to expand on this a bit more since it is a pet peeve of mine to see people blindly complain about a minor display difference between clients and look no further than that for confirmation. I should actually keep quiet as it is less competition for me, but I am home sick today and bored so here goes...

I have many rigs running various algorithms and like most people, once I have a build I like I keep copying it, which means I have several theoretically identical rigs.
 
They are theoretically identical because while I can control the hardware and use the same mobo, CPU, RAM, GPUs, software, etc. for the build, some things are beyond my control such as the ASIC quality of the parts. In the end even these identical rigs with the same software and configuration settings can perform differently in terms of mining performance, sometime by as much as 5%.

I have ran hundreds of different types of tests to try and find out as many of these differences that I can and have spent considerable amounts of time to try and eliminate those I do find so that all my rigs perform at their peak. One of these testing procedures involves comparing pool performance.

One method that has seemed to work well involves using two identical rigs as far as hardware, software, and configuration and point them each to their own dedicated payment address (or account) on the same pool. This means each will have their own little silo of performance statistics so as to not be thrown off by other rigs sharing the same address. I do not mean different worker IDs, but actual separate pool accounts.

Secondly, I will then start each rig and point them to their dedicated pool account as simultaneously as I can. I will then baseline these rigs for one week to detect any differences that I outlined above and make note of it, i.e. rig A is 5% faster that rig B, all week long. Ideally if they are truly similar both would have the same overall stats, one may outperform the other on one day but the next day it flip flops and viceversa. This is why I like to baseline for at least week before any serious testing.

After I have a baseline established, so I can account for any generic differences, I will often try different settings or different mining clients to compare and find any performance differences I can take advantage of. Using the client testing example I mentioned in my previous post, I would run an instance of the latest Optiminer and an instance of the latest Claymore, maximizing the settings so I am getting the highest hashrates with similar power draw from each rig as I can.
 
I would again point each rig to their own dedicated pool account (same pool of course) and run them for at least a week to ferret out any differences. Sometimes the differences are blatantly obvious right away so you can abort the test and not waste a week on it, but the more subtle differences take time to correctly deduce. I would say anything within a 5% margin of one another would warrant a full week to be sure, and even a 10% difference you might want to run for at least 24 hours to eliminate a random run of bad luck before giving up.

While this is a lot of work, it is the only way to know for sure about small differences in settings or clients that may not be immediately obvious. I know many clients displayed hash rates have little to do with their real performance pool-side, not that they are internally manipulated or anything, but they are measuring a different criteria than the pool is measuring.
 
Your client will show you the hash-rate it calculates and it may very well be correct in that it is doing X guesses per second, but maybe its guessing sucks. Whereas the pool will base your hashrate upon how many valid shares per hour it receives and then calculates the results to display an “estimated” hashrate which is also based on the current network and pool conditions. Some pools will also display the reported hashrate, which again is simply the hashrate sent along from your client and may or may not match up with the poolside calculated rate. Usually the pool rate is lower and this is the first source of forum whining that something “must” be amiss.

Nothing is wrong, it is just a different way to arrive at your hashrate and will be more accurate as it is based off you shares submitted, which is what you are paid off of anyway. This last point bears repeating, it is the number of valid shares submitted that you are paid against not hashrate.

So going back to the testing, your end goal is to see which configuration, or client, yields the most pool-side valid shares. Anything else is just a distraction. While the local displayed hashrate may be useful for tweaking your settings as changes are more obvious and provide instantaneous feedback, the testing is not truly completed until you have verified your changes against the pools submitted share counts.

Of course this involves more work which is why people do not do it and why we see an endless flood of forum posts that complains that client A shows 150 MH/s while client B only shows 146 MH/s.

Another example is extreme overclocking where the hashrate looks good locally but the amount of shares submitted actually goes down when pushed too far.
Astute miners will already be using utilities such as HWMonitor to look for excessive memory errors, but less savvy types simply crank up the clocks until they crash, reduce the settings a bit to keep from crashing all the time, and then post “wow I am getting mega HPS with these settings” and never bother to investigate any further, meanwhile they are burning through electricity and probably shortening the lifespan of the cards all at the same time as they are submitting less overall shares to the pool.

Anyway, the rant is over and I feel better. Take some of this or leave it, I don’t care. Sorry to Optiminer for putting this in his thread, but it seemed appropriate due to some of the responses. And finally, I am not endorsing or commenting on which miner performs better or worse (that's your job, see above). My main beef is the lack of any investigation what-so-ever other than a quick glance at a console display or pool readout and instantly "knowing" without doubt that something is better or worse, or some pool is cheating, etc. Also I am not picking on anyone in particular either, just been noticing a common symptom of laziness I see displayed all over this forurm.

[fr4nkthetank]

Well, now that is a good post.  I also compare payouts, simply set one rig, or one gpu, to a pool, and another to a different one, etc.  of course with pplns pools there is variance...luck is a big factor.  anyways, why dont you post your results.  for the hardware errors when you top up memory clock, well keep in mind, if you bring hashrate up 10%, and get 0.1% memory errors...then its still worth while.  Plus power consumption doesnt really go up much.  You can easily see these with claymore.  the memory error thingy in HWinfo doesnt really mean much to be honest.  see stilt threads on other forum about that.

[Za1n]

Well, now that is a good post.  I also compare payouts, simply set one rig, or one gpu, to a pool, and another to a different one, etc.  of course with pplns pools there is variance...luck is a big factor.  anyways, why dont you post your results.  for the hardware errors when you top up memory clock, well keep in mind, if you bring hashrate up 10%, and get 0.1% memory errors...then its still worth while.  Plus power consumption doesnt really go up much.  You can easily see these with claymore.  the memory error thingy in HWinfo doesnt really mean much to be honest.  see stilt threads on other forum about that.

Yeah, it was a long enough post already so I wasn't going into every little minute detail, but as you said .1% memory errors I would not be concerned about either. But when it begins spamming tons of errors it can still look like it is mining properly without crashing even though there comes a point where share submission starts to suffer. Same with power, there comes a point of diminishing returns, but you seem to fall into the astute category and knew that anyway...

[BigWolf]

Well, now that is a good post.  I also compare payouts, simply set one rig, or one gpu, to a pool, and another to a different one, etc.  of course with pplns pools there is variance...luck is a big factor.  anyways, why dont you post your results.  for the hardware errors when you top up memory clock, well keep in mind, if you bring hashrate up 10%, and get 0.1% memory errors...then its still worth while.  Plus power consumption doesnt really go up much.  You can easily see these with claymore.  the memory error thingy in HWinfo doesnt really mean much to be honest.  see stilt threads on other forum about that.

Yeah, it was a long enough post already so I wasn't going into every little minute detail, but as you said .1% memory errors I would not be concerned about either. But when it begins spamming tons of errors it can still look like it is mining properly without crashing even though there comes a point where share submission starts to suffer. Same with power, there comes a point of diminishing returns, but you seem to fall into the astute category and knew that anyway...

You failed to mention Windows vs Linux.  That's my what always irritates me about all these comparisons.  First of all, Optiminer has always said his performs better on Linux and Claymore has said he prefers the Windows side.   So then you get these people that complain that their card isn't doing as well as the other person's card but neither have stated which platform they are on.  If you don't give all the important details of what your results are, don't bother posting them!

But to what you said, you are totally right.  When I make a change I look at my hash rates on the local screen to make sure the cards are doing approx what they should be for 5-10 minutes and then I walk away and I'll spot check the pool results for the next few hours if I'm near the computer and then I don't look at it until the next day to see if my average is going up/down.  I also look at the network difficulty to see if that is going up/down also as that will also show in your average as well.

[willrain]

1.6.2 vs 1.7:

Code:

rain@miner1:/mnt/rw/rain$ amd_vers 
14.20.7
rain@miner1:/mnt/rw/rain$ sysinfo.sh 
* 2 x model name        : AMD Athlon(tm) II X2 250 Processor
* RAM: 3.96 GB
* Disk /dev/sda: 15.8 GB
* GPU
 * AMD Pitcairn (16 CU) 2 GB GDDR5
 * AMD Tahiti (28 CU) 3 GB GDDR5
 * AMD Pitcairn (20 CU) 2 GB GDDR5
 * AMD Tahiti (32 CU) 3 GB GDDR5

894 -> 883

18/19 - identical hardware:

Code:

rain@miner18:/mnt/rw/rain$ amd_vers 
15.10.4
rain@miner18:/mnt/rw/rain$ sysinfo.sh 
* 2 x model name        : Intel(R) Celeron(R) CPU G1840 @ 2.80GHz
* RAM: 3.93 GB
* Disk /dev/sda: 15.8 GB
* GPU
 * AMD Tonga (28 CU) 2 GB GDDR5
 * AMD Tonga (28 CU) 2 GB GDDR5
 * AMD Tonga (28 CU) 2 GB GDDR5
 * AMD Tonga (28 CU) 2 GB GDDR5

miner18 832 -> 822  
miner19 877 -> 856

Rolling back to 1.6.2

[reelen]

Thank you so much for the --pci-mode update.  This has made a 7-8 problem cards work again and I am able to support using your miner as I had pre 1.6.

Keep up the great work!

[optiminer]

Thank you so much for the --pci-mode update.  This has made a 7-8 problem cards work again and I am able to support using your miner as I had pre 1.6.

Which modes does work on the problematic cards?

[reelen]

Thank you so much for the --pci-mode update.  This has made a 7-8 problem cards work again and I am able to support using your miner as I had pre 1.6.

Which modes does work on the problematic cards?

1 and 3.  3 seems the most stable for me personally, although overnight I am still getting a few cards that went back to showing cclock normal and then Mclock showing 300 (in Simpleminer OS).  I rebooted the machines and they have been stable for another 30min so far.

[Biodom]

I had a RX 470 rig that was unstable on 1.6.2 (stable on 1.5).
This rig is now stable on 1.7 (overnight) in default pci-mode (2). I did not check other modes.
Overall speed is improved in 1.7 vs 1.5, so I am happy.
The rig uses about 50-70W more, though, on Ubuntu Linux 16.04 (about 6-7%) with speed increase of 6-7% as well (vs 1.5), so make sure you have power reserves if you switch.
Thanks for an update, Optiminer.

[johnkill]

I had a RX 470 rig that was unstable on 1.6.2 (stable on 1.5).
This rig is now stable on 1.7 (overnight) in default pci-mode (2). I did not check other modes.
Overall speed is improved in 1.7 vs 1.5, so I am happy.
The rig uses about 50-70W more, though, on Ubuntu Linux 16.04 (about 6-7%) with speed increase of 6-7% as well (vs 1.5), so make sure you have power reserves if you switch.
Thanks for an update, Optiminer.

Confirm!
For me 1.6.* versions was awful but 1.7 work gr8 and very stable. Profit is little better than Claymore too.

[blockops]

Woo-hoo! I'm loving 1.7!! It's brought some cards back from the dead that 1.6.2 could not make work. And it's faster! Love it!

[charles2k]

On my R9 270X and 280X under ethos no change, or even aprox. 1s/s less than in version 1.6.0

[pilalove]

I wonder why Optiminer get "profit" much more than Claymore.
Windown 7x64 for all

[restless]

Can anyone with 470 share speed under Linux?

[tiennou]

Can anyone with 470 share speed under Linux?

Based on 16 GPUs : between 260 and 270.

[citronick]

optiminer - does miner support SSL port mining at NICEHASH?

If yes, what command line to use?

[philipma1957]

okay I ran my 8 gpu panda miner using 1.7 at nicehash zcash  stable no real issues.

I am now running my 8 gpu pandaminer using 1.7 at flypool stable no real issues

in both cases I use simplemining OS a linux based system


this will run in smOS to flypool

-s zstratum+tls://us1-zcash.flypool.org:3443 -u t1d81R73LY4tX9y1VskH6gJELH3PfCvGwz5.pandaP -p x


this will run in smOS to nicehash

-s equihash.usa.nicehash.com:3357 -u 1JdC6Xg3ajT3rge3FgPNSYYFpmf53Vbtje.panda1 -p x

both work and have no options or commands in use.

I use claymore a lot and he posts a long command list on how to tweak a rig

I see there are commands available from reading the thread here but no list of commands.

Is there a list on the thread?  and I am just missing it? 

[felixbrucker]

taken from "Optiminer -h":

Code:

USAGE: 

   Optiminer.exe  [--pci-mode <0-3>] [--benchmark <seconds>]
                  [--list-devices] [--force-generic-kernel]
                  [--experimental-kernel] [--nodevfee] [-i <number>] ... 
                  [-m <port>] [--watchdog-cmd <command>]
                  [--watchdog-timeout <seconds>] [--max-log-files <count>]
                  [--max-log-file-size <bytes>] [-l <filename>] [-v] [-p
                  <string>] [-u <string>] [-s <host:port>] [-d <integer>]
                  ...  [-c <integer>] [--] [--version] [-h]


Where: 

   --pci-mode <0-3>
     Communicate mode between host and GPU. Valid values are 0-3.

   --benchmark <seconds>
     If specified runs a benchmark for the given number of seconds on all
     specified devices and then exists the miner.

   --list-devices
     List all recognized devices with their platform and device id and
     quit.

   --force-generic-kernel
     Force use of generic kernel even when a device-specific kernel is
     available

   --experimental-kernel
     Unlock faster experimental kernel for certain graphic cards.

   --nodevfee
     If set, the dev fee will be disabled. Miner will run a bit slower.
     Enable this if you do not want any more improvements of the miner and
     want to earn less.

   -i <number>,  --intensity <number>  (accepted multiple times)
     Worker intensity. 0 means auto-detect based on available memory.
     Higher values use more GPU memory. Can be specified once applying the
     same intensity to all devices or once per device (same order as -d).

   -m <port>,  --monitoring-port <port>
     The monitoring port to listen on for HTTP requests. Disabled by
     default. If enabled, accepts requests from everywhere.

   --watchdog-cmd <command>
     The watchdog command to execute. See --watchdog-timeout.

   --watchdog-timeout <seconds>
     Timeout after which the watchdog triggers if a GPU does not produce
     any solutions. It will execute the command specified by
     --watchdog-cmd. You can use this command to do an appropriate action
     (e.g. reset driver or reboot). 0 disables watchdog.

   --max-log-files <count>
     Maximum number of rotated log files to keep.

   --max-log-file-size <bytes>
     Maximum size of log file before it gets rotated.

   -l <filename>,  --log-file <filename>
     Write logs to given file

   -v,  --verbose
     Verbose logging.

   -p <string>,  --password <string>
     Stratum password.

   -u <string>,  --user <string>
     Stratum user.

   -s <host:port>,  --stratum <host:port>
     Host and port of the stratum server to use.

   -d <integer>,  --device <integer>  (accepted multiple times)
     A OpenCL device id to use. If no devices are specified, all are used.

   -c <integer>,  --platform <integer>
     The OpenCL platform id to use.

   --,  --ignore_rest
     Ignores the rest of the labeled arguments following this flag.

   --version
     Displays version information and exits.

   -h,  --help
     Displays usage information and exits.


   (C) by Optiminer 2017