so tell me something, is the actual amount you get on par with your hash rate?
using which profitability information for your hashrate? |
|
|
|
I was able to compile with gcc 6.1.
any git available please ?
not until now, cpuminer-opt code is on git from nicehash (with modifications i guess) here: https://github.com/nicehash/cpuminer-opt and from myself to more easily distribute to my miners on linux: https://github.com/felixbrucker/cpuminer-opt (though 3.4.6 is still missing because of benchmark bug, will upload it when 3.4.7 is out as i dont want to do any changes to the code myself) cheers |
|
|
|
THE PHANTOM OF THE ZPOOL
as promised. after all it's plain and simple 30% fee,
the only excuse could be compensating hype of mined shares' stats
is the same seen on BTC addresses?? I haven't been able to tell, but perhaps there is a different code path for non btc exchanging?? all my payouts noted before where btc, so yes |
|
|
|
THE PHANTOM OF THE ZPOOL as promised. after all it's plain and simple 30% fee, the only excuse could be compensating hype of mined shares' stats im sorry but i dont understand this screen without any description of those numbers and what they mean and in which context they stand. i hope you can clarify  The problem is that Zpool over estimates the exchange values for coins (most of which are actually quite worthless). To calculate how much Zpool's estimates are off do: actual_last24h - (estimate_last24h*1000) this sadly does not work for algorithms where ttf is high as actual24h is 0 when no block is found (like lbry when pool had 6gh/s) also it is an average estimate which is useless for current switching, it is only useful to determine if mining a single algo on zpool is profitable |
|
|
|
|
ok thanks, this also proves my point and the points made by others
|
|
|
|
THE PHANTOM OF THE ZPOOLas promised. after all it's plain and simple 30% fee, the only excuse could be compensating hype of mined shares' stats im sorry but i dont understand this screen without any description of those numbers and what they mean and in which context they stand. i hope you can clarify |
|
|
|
if you dont want to compare them to "realtime pps" at least compare them on zpool itself, the api and the pool itself (described in multialgo switching on zpool.ca) serve different algos based on profitability, which is not giving appropriate results estimates
so i cant say result to the values/algos returned by the call/server? "the result of an api call" sounds far better than "the estimate of an api call" however i think you get my point but dont want to comment on it |
|
|
|
For me its not only an issue with the estimate of confirmed/unconfirmed alts converted to btc are FAR less, but also the myself calculated profitability of my rig(s) based on the api matching the results i could get (confirmed/unconfirmed) and not the "actual" profit, if the later wasnt true my calculations would work fine and my miners would not select zpool if nicehash (eg) would be more profitable at the current time. But sadly it isnt. Reducing the estimate (api that is) by a fixed amount that is vaguely guessed (*0.65) does not result in a correct estimate and thus i will "switch", in my case disable zpool.
wow, my 0.65 ratio was kinda joke, i just use 0.7 for pure skein or neo, only. but are you trying to compare profitability from yaamp to nicehash based on estimates ? nearly impossible. nicehash pays realtime, multipool pays long after the mining from very different calculations very wild guess to compare them even if it seems possible afaik (correct me if im wrong) the estimates are based on exchange rate, difficulty and likely some more parameters, assuming the exchange rate stays +- the same (assuming the ttf and exchange timeframe is short) this should be possible as shares are rewarded by PPS? Jared said everything about assuming, i just sign to that. realtime and multipool estimates are "incompatible" to compare, imho if you dont want to compare them to "realtime pps" at least compare them on zpool itself, the api and the pool itself (described in multialgo switching on zpool.ca) serve different algos based on profitability, which is not giving appropriate results |
|
|
|
For me its not only an issue with the estimate of confirmed/unconfirmed alts converted to btc are FAR less, but also the myself calculated profitability of my rig(s) based on the api matching the results i could get (confirmed/unconfirmed) and not the "actual" profit, if the later wasnt true my calculations would work fine and my miners would not select zpool if nicehash (eg) would be more profitable at the current time. But sadly it isnt. Reducing the estimate (api that is) by a fixed amount that is vaguely guessed (*0.65) does not result in a correct estimate and thus i will "switch", in my case disable zpool.
wow, my 0.65 ratio was kinda joke, i just use 0.7 for pure skein or neo, only. but are you trying to compare profitability from yaamp to nicehash based on estimates ? nearly impossible. nicehash pays realtime, multipool pays long after the mining from very different calculations very wild guess to compare them even if it seems possible afaik (correct me if im wrong) the estimates are based on exchange rate, difficulty and likely some more parameters, assuming the exchange rate stays +- the same (assuming the ttf and exchange timeframe is short) this should be possible as shares are rewarded by PPS? |
|
|
|
my last 7 day average is
0.00896 per day..
its not too bad.. i would be getting around 0.007238 per day minus fees mining on bitcoin pool.
i can only guess, but i assume you are talking about sha256 mining with asics? if so this is completely irrelevant as it does not multi-pool-multi-algo switch but is a statically configured miner setup to mine on this pool which does not use the api at all |
|
|
|
|
For me its not only an issue with the estimate of confirmed/unconfirmed alts converted to btc are FAR less, but also the myself calculated profitability of my rig(s) based on the api matching the results i could get (confirmed/unconfirmed) and not the "actual" profit.
If the later wasnt true my calculations would work fine and my miners would not select zpool if nicehash (eg) would be more profitable at the current time.
But sadly it isnt. Reducing the estimate (api that is) by a fixed amount that is vaguely guessed (*0.65) does not result in a correct estimate and thus i will "switch", in my case disable zpool.
|
|
|
|
Auto exchange will be available around 19~21 September. I'm working on it.
If coins are left in Credit_AE state, then it will be transferred and exchanged automatically. But "Credit" coins will not be auto exchanged automatically. You'd have to transfer it between wallets.
That's all I wanted to know Thank You very much for the answer! Greetings thanks same here |
|
|
|
|
so basically you are saying: i dont know/care about what happens with the either too high estimate or too low payout, i just run the src as it is [and im not willing to look into the issue because no one else, besides the ones in this thread, pointed this out yet]
yet you go a step further and say the best way of possibly "fixing" this is to just not/only minimalistic display any estimate
with such a broken estimates system multi algo autoswitching based on estimates can just not work right
|
|
|
|
Your prerogative; although there is no problem with the amount paid.
so riddle me this: i have amount X of lbry credits which currently equal 0.055BTC as of latest exchange data, after 6hrs the exchange is completed and i get 0.35BTC, however the exchange prices have not fluctuated in such a amount that it would result in such a dramatic decrease, where are my lost BTC? if you cant well then cheers |
|
|
|
|
have experienced the same for lbry, estimated balance (unconfirmed) was 0.055BTC, estimated balance (confirmed) reduced to 0.045BTC, payout was only 0.035BTC, i checked the exchange price on poloniex, it stayed +- constant for the last 24hours so it definitely is something else than just fluctuating prices
i will disable zpool for now for my rigs, will follow this thread if it gets fixed
cheers
|
|
|
|
On a tangent I'm curious about the mining performance of the A6's IGPU. The CPU alone is weak but CPU+IGPU
might make up for it.
i can now deliver: best it can do (as of now) is 0.00005404 BTC/Day with nicehash and blake256r8vnl i just ran the NHM benchmark, other algos and other pools might change it a bit but you might get an idea from this cheers |
|
|
|
be aware of the warning comment in his trust level ratings though, your coins might vanish quicker than you'd like |
|
|
|
thanks will try  about the includes etc: i noticed only the bin path is declared in profile file, include and lib64 dirs are somewhere else? cheers |
|
|
|
|
also interestingly 3.4.5 compile fails with multiple error about "PACKAGE_NAME" (being undeclared, expected ',' or ';' before, expected ')' before etc) while 3.4.6 compiles just fine
though i noticed no real improvement on my tiny A6-6400K compared to the AVX core-i build i used previously when utilizing only AES and SSE2, however when using AVX the game changed and speedup was a little over 100% (18->45 H/s)
cheers
|
|
|
|
|
it seems i need to add some dirs to PATH, is this correct?
when using the 7z archive and starting winbuild.sh "no suitable compiler" is found, so i added /d/msys/opt/windows_64/bin to the PATH and it got further, just to display it cant find curl/curl.h
where do i add this path definition for includes and later libs? (/d/msys/opt/windows_64/include [...]/lib etc)
cheers
edit: just did it, my first ever successful compile on windows, i inserted the dirs into the winbuild.sh like so (-I/d/msys/opt/windows_64/include -L/d/msys/opt/windows_64/lib64) but there has to be a "better" systemwide setting for this, right?
thanks for your support!
|
|
|
|
|
Show Posts
