Tested NH's services again yesterday.  My settings were as follows:  Two rentals, one at 5Th, and another at 100Th.  Both SHA256 mining, to port 3333 with this password: d=2048,sha256

the 100Th completed without incident, and the 5Th is still going.



Again;  nicehash disappoints with a 100Th rental;  If I keep a steady 5-10Th, I actually make more btc every time that i've done this test.  Strange.  4th time this has happened... no longer a coincidence in my mind....  Probably has to do with luck over a short period vs luck over a long period.   

I haven't wanted to waste that much coin just doing tests knowing I would take that kind of a loss after this many fails or else I would do the same time frames for 5Th and 100Th......  Gonna just cut my losses and stay with slow and steady.... along with just using my own hardware.  Im a blessed one that doesn't pay any power bill

do a "test pool connection" before saving it.   I bet difficulty is not set properly for you... using the password field.....

curious who you are renting from and what algo   I like your idea... as long as the cost to rent is kept reasonable. (Curious what you are using as a trusted source, personally I haven't had great results with Nicehash and large hashrate rentals combined (found blocks lower percentage compared to the more hash i rented))

Id actually try this myself.... 

The other machine was me.....

It was a ~45Mh video card.

The math makes sense; as in my hashrate isn't "negligible" given the hashrate on that algo yesterday.  I am also inclined to point out that I mined for HOURS on that algo with the server accepting about every 250th hash, and it would only report 11Mh on my wallet page, if at all.  When I got home I got the miner software switched out and left it on for some time;  then switched to the other newer algo (dmd-gr, which is now not on the list anymore);   and then finally switched algos again.

I found the pool doesn't report hashrate changes instantly.  The numbers on the listing seem to be normalized... thus it takes time for hashrate to ramp up to display actual readings (in the details section, not the Summary section which doesn't seem normalized)

Every time I start mining, I noticed that on the pool tab it slowly ramped up as well.... same with the pool statistics square at the top right...  plus the pool converts share value submittal / frequency to calculate your hashrate baesd on your work submitted, not the number reported by your miner application.

Now;  things I say about the pool are my observation;  crackfoo can be the actual one to confirm or deny my thoughts.   But I figured I would add this info for you to consider since I can see why it would be perceived as a loss to you, and I was the other miner working alongside you.   Hope it helps!

I myself was amazed at the step up when I moved here from xpool.  FWIW an antminer S3 makes me roughly 3.1-3.5 mBTC/day on its own.


Crack;   I tried the different version of ccminer.   Working like a champ.

Even though I am using a fork that gets updates regularly;  and is specifically for Maxwell GPU's (like I have), I guess its just not as good as this fork.


Thanks for the support.   I very much appreciate you taking your time to help.

Gonna try the new algos for a day or two.

I never got an answer before about the "custom proitability" user setting;  does it scale based on hashrate (which would make sense to me).... because im mentally having trouble grasping how that scales to what factors...   being the person that I am I would be inclined to use values something like lyra2=11.2,qubit=25.4,neoscrypt=0.53, etc.... based on the hashrate that each algo gives me.   is this a proper way of thinking?

Im leaving the ranch.....

so...
Ill just leave it pointed at the myr-gr port until I get home just in case it helps you diagnose.

I just checked and there was a slightly new version of ccminer but it has no changes to this algo;  but I went ahead and upgraded it anyways to be sure.

Thanks for putting in the effort.  If theres any way I can help, LMK.  my email is my username @ gmail.
Ive done lots of alpha and beta hardware/software testing over the years.    Everything from pc games to Honda ECU hardware and chipping/tuning software =)

the ccminer app doesnt tell me the share submitted value; so I am unsure what the level of share is being accepted when the random single share gets accepted

and that share is always accepted just before a new block found message, or rather, new block detected message


turned out a setting of 0.4 seems about right for share submit frequency to be the same as all my other algos...

yeah.

I am using the CCMINER spmod for nvidia....

latest version..

using this string: ccminer.exe -r 0 -a myr-gr -i 17.5 -o stratum+tcp://mine.zpool.ca:5433 -u 1PHSDYvVp6HpqtuUPocK41DrdeHbbezaeP -p d=0.4,myr-gr=49.5
 (cuts out confusion)

ok, ill chalk it up to a firefox issue.   no worries there.

The share thing on the new port I mentioned above is still present.

EDIT:  Diff set at 2, got one accepted share so far.... maybe 10 submits/min at difficulty of 2 (probably should be around 1-1.4 with my video card).

I can leave my miner pointed at it if it helps you diagnose the issue.....

So I noticed before when on the pool tab;

To switch between showing different algos you had to click the algo, the page would refresh, but be the same.  then you click the pool tab again, and it reloads with the newly selected algo.


Now if you click the algo it loads right away as you think it should;  but in this instance I was viewing X11, clicked Lyra2 and it now looks like the photo below.   I assume something is slightly goofed.

*edit: now when I need to switch between viewing algos;  its back to the old behavior.  strange.

Also, the myr-gr port returns low difficulty share rejects only.  currently I have diff set at 20 which is rather high to see if that changes anything.

The pool luck must be pretty high today!  Digibyte SHA seems to be paying pretty well.

What was the reason for the large spike in the payout graph ~5 hours ago?  seems out of place as it didn't have a correlating rise in the total unpaid balance in the previous hours....

1PHSDYvVp6HpqtuUPocK41DrdeHbbezaeP

Is it safe to say in the simplest terms:
Can I just set the numbers to the same ratio that my output hashrate is, per algo; to achieve a "balanced" profitability??

i noticed over yesterday that the lyra2 calc seems waaaay off.


As a test I dropped my miner for 12 hours on X11 and payouts all came back up to close to normal for me...  Typically with my gear I see a minimum of 3.5Mbtc-8.5Mbtc/day.   The 8.5Mbtc days are when Lyra is actually profitable around the .2000~ range.

The issue:
For the last day lyra has been .1500 and dropped to .0516 by 1PM today;   And meanwhile X11 is .1710  and my miner hasn't switched over to X11 or any other algo....

On My GTX980 I get roughly:
11000Khs Lyra2
10000Khs X11
6000Khs X13
16000Khs Qubit

I am wondering if its a server side calc problem?  Is My video card profitability between algos just majorly different than most others out there?

If I were to set a custom profitability scale;  do I add or subtract from each algo to give it more presidence over the other?  I dont want to make a correction the wrong way.  At that rate it would take me days to figure out where I need to adjust it to on my end.

i think it seems to store shares per-coin....   after switching algos it can end up paying me for a different algo up to 15 min later.. after ive already generated new blocks with the new algo....

Ive noticed on several occasions that when the network difficulty goes down on lets say a set of scrypt coins... to less than 100;  blocks get crapped out faster than the assigned miner difficulty level will let the shares be found... And I see it in my share percentage.   Is there a way to have the server adjust the difficulty level between switching coins to account for this?

I adjusted my difficulty manually and it seems to have leveled out to be consistent, same as I did with Lyra;  but during the higher difficulty coin mining, share frequency will be excessive; so id like to avoid that scenario for the pools sake =)

Still very happy with the pool.  Way better results than all the rest.

The one listed for my transaction shows confirmed on blockchain...
Im a little confused myself;  haven't noticed anything major from my end.

now im starting to think that the pool mistakengly made that TX due to some error; and they are crediting back... so to speak...

Am I the only one so far that has noticed an inconsistency with the clock on zpool's website at the upper right corner?


For instance;  It says next payout 15:52 EST; But I am presently at 5:09 PM Pacific time (17:09PST) which is -3 hours from EST.   And a payout was just processed:
1m ago   0.00155413          3e1707c0ea8272eb1b12502130286d55e54f...

Curious as to what determines rental price;

and;  I did notice the rental with a BTC payout.. but it would be nice to see the total in rental accumulated just as it is with any coins mined =)

in the profitability section;

'scrypt'   => 1,
'scryptn'   => 0.5,
'c11'      => 2.0,
'x11'      => 5.5,
'x13'      => 3.9,
'x14'      => 3.7,
'x15'      => 3.5,
'nist5'      => 6.0,
'zr5'      => 10.0,
'drop'      => 5.0;
'neoscrypt'   => 0.3,
'lyra2'      => 1.3,
'quark'   => 6,

I want to understand how to relate it;

Is scrypt the base, and these numbers are what determine the "normalization" between them like was done with hashrate reporting in xpool? 

Do I increase or decrease the value to give that algo more precedence?  By guessing I would think that the number is the multiplier; but even if it is, it's a crapshoot if it's an inverse effect code-wise.

MY first algo is X13;  but it never gets an initial response then rolls to lyra2 every time.  That has been one issue I have noticed so far...
It blipped into X11 once yesterday automatically;  but right back to lyra with defaults.  With my video card it's a 11Mh on lyra2, and 11.7Mh on X11;  so lyra is almost always more profitable for me by observation.

This evening it switched to X11 and stayed there;  I had a correlated change in earnings during that time.... so that lead me to ask about the tables because the description on the site is basic with just how to;  but little direction on effects either way =)

Still very impressed with the new site/service.

i cant quote on the watchdog, but its well documented;  I followed an online tutorial.

Thats the correct setting for minera;  just set a sane timer for reboot (2-15 min?)...

I always saw a solid hashrate bar in the readouts; and can normally see blips in the hashrate graph if it reset....

With MinerA I believe I used bfgminer;  gridseeds the regular cgminer.