my cpu is at 200% with the gui client and setgenerate true 2 but gethashespersec = 0. wtf?
I think now only the enterprise CPUs are able to mine the Zcoin. With every single block the hashrate drops... Not yet. You can easily mine with i3/i5/i7 or even with older Core2Quad or Core2Duo CPUs for now. Hashrate will not be big, but decent enough, so you can get few coins per day with few machines. Depending on what they will cost, it could be reasonable. I wonder where these guys are getting their CPU power from? This is on Suprnova: Rank Donor User Name KH/s XZC/Day
1 paulscreen 112 9,458.737
2 huber 84 7,057.705
3 iflyplane 55 4,659.601
4 anonymous 34 2,874.489
5 anonymous 32 2,659.563
6 anonymous 26 2,192.228 112 Khash/s? Botnets or GPU miner? The Supernova numbers are way off. I think the calculations are based on a different coin. ZCoin's entire network hashrate is 88.5 kH/s at the moment. It's not KH/s but H/s OC, with all the respect those numbers cannot be hash/s. Just one of my machines shows 17.95 hash/s locally, but all the machines combined show just about 1.2 something/s at Suprnova (in average). That could be KH/s or something else, but it cannot be hash/sec. Now we have miner with 204 something/sec!!! That should be about 1000 CPU cores working, when estimated compared with my hashrate and shown number!  Yes, you're right, it's indeed kh/s, i'm a bit confused sorry. Units are HH (hectohash, 100H) according to my stats, but the pool reported speed still doesn't match the speed reported by the miner. Very confusing. |
|
|
|
Here are some benchmarks from the Height problem.
One of my CPUs on Block 2300 now hashes at 8.3H/s, while at Block 23000 it will hash at 1.35H/s. This doesn't take into account the difficulty changes by then. Every CPU will linearly follow this pattern.
I have a question... I understand it will be increasingly more complex to produce a single hash. Some people see a problem in that, and expect the chain to stop at some point. However, if hashes are be produced less often, the blocks will be found less often, the difficulty will decrease, and block will be found again, just with less hashes contributed. Is this correct? So in short, difficulty decrease will compensate for the increased complexity of producing a hash. Doesn't this mean there is no problem at all? Matrix size is block height * 24576 bytes per thread. Currently that's 60 MB per thread or 560 MB for an i7 with 8 threads. At block 1 million its 24.576 GB, at 10 million 240GB. With big Xeons it would be close to 1 TB at 1 million blocks. I actually like the concept of increasing mining resource requirenents as block height increases because it protects against tech advancements, faster CPU clocks, more threads, more mem, faster mem, etc. The problem with the current algo is the curve is too steep. Memory requirements of the algo would probably increase faster than memory tech. So what we have is an algo that is impeded from graduating to GPU* and ASIC while it's ability to mine on low end systems diminishes over time. It's squeezed at both ends. * I'm not familiar with GPU mining specifics but typically they have many more threads than CPUs so I assume greater memory usage. Someone who knows please correct me. |
|
|
|
Here are some benchmarks from the Height problem.
One of my CPUs on Block 2300 now hashes at 8.3H/s, while at Block 23000 it will hash at 1.35H/s. This doesn't take into account the difficulty changes by then. Every CPU will linearly follow this pattern.
degredation will accelerate when memory is exhausted and starts swapping to disk. |
|
|
|
Im trying to feed the noonce loop into an opencl kernel so we can finally GPU mine this coin however upon looking at the code its messed up.
LYRA2 is a matrix, usually of 2 or 4. However for this coin the matrix = height; so with every new block the matrix gets bigger and bigger and it will get harder and harder to solve. Pretty much like the difficulty bomb with ETHEREUM.
Yikes. Thanks for sharing. It's even worse, the matrix is height*256. Lyra2 is 1*8 and lyra2v2 is 1*4. It not only gets harder to solve but it also requires more memory to solve each new block. Lyra2 is already a challenge on a GPU, lyra2v2 is a little better (less lyra2) but zcoin is all lyra2 and with overkill. So, yes, mining will self destruct unless the algo is changed, and GPU mining is probably DOA. |
|
|
|
There is no AVX2 targetted code in cryptonight so the diffreence
between Ivybridge and Haswell should be minimal. Try -core-avx-i on the Haswell to confirm. It should perform similar to -core-avx2, if not
there may be an issue.
joblo, Hi. Thx for your updates and etc in git am read about compiling with minGW for Windows... can i compile with VS 2015 ? No, VS isn't supported. You could try the precompiled binaries. |
|
|
|
I looked at the CPU miner for riecoin a few months ago but didn't see any obvious optimization opportunities. I may take another look but I'm not really interested if I don't think I can improve it. |
|
|
|
joblo, can I make a request for a new coin? z.cash is on testnet right now. Looks interesting. (plus there's a bounty for good open source miners, so you get a chance at $30k USD).
I'm aware of the bounty but writing an algo from scratch is out of my league. |
|
|
|
My results are consistent with Nicehash. I get best performance with 4 threads with i7 and 3 threads with i5 for cryptonight.
Your performance seems low for an i7 no matter the number of threads you used. My i5-2400 is faster than your i7-3770.
huh really? This PC is running a 480 which is mining also, but looking at the stats it doesn't seem to be using the CPU at all. Additionally I've checked and the CPU is not thermally throttling or anything like that.  I'm not doing anything particulary strange with my cpuminer config. I'm running the most recent 3.4.7 build using cpuminer-core-avx-i.exe with the command: cpuminer-core-avx-i.exe -a cryptonight -o stratum+tcp://xmr-eu.dwarfpool.com:8005 -u [wallet address] -q Any ideas why I might be getting such a low hash rate on this machine? On another machine with an i7-4770 I get around 200 H/s using the cpuminer-core-avx2 binary. Co-mining with Nvidia causes no problems but I've never co-mined with AMD. There is no AVX2 targetted code in cryptonight so the diffreence between Ivybridge and Haswell should be minimal. Try -core-avx-i on the Haswell to confirm. It should perform similar to -core-avx2, if not there may be an issue. |
|
|
|
joblo: we have detected that cryptonight would run faster in most cases when not using all available threads. This has most likely to do with CPU cache; the bigger it is, the more threads it can run fast. Are you aware of this?
Speed increase can be around 10-15% when using less than all available threads and that is not something to simply ignore.
Really? I did some benchmarking on my i7-3770 (8 MB L3 cache) in 4,6,7 and 8 thread usage (4C HT). My results were as follows. 4 threads average : 123.21 standard deviation 1.36 6 threads average : 139.18 standard deviation 13.57 7 threads average : 144.74 standard deviation 9.21 8 threads average : 157.94 standard deviation 21.55  This is data collected from three different runs over several minutes, approx 50 data points per number of threads. As you can see the hashing speed for cryptonight does increase when more threads are used, however the consistency of the data lowers. When I was running 4 threads almost all the results were consistent (e.g. 122.3, 124, 122.5, 123.6, 124 .. etc), however as the number of threads increased to cover hyperthreaded cores that value started to fluctuated wildly. For example, for 8 threads I saw values ranging from a min of 125.0 to a max of 208.4! However, when averaged out you can still see that more threads = faster hashing rate. I didn't try more threads than the number of physical and logical cores on my machine. My results are consistent with Nicehash. I get best performance with 4 threads with i7 and 3 threads with i5 for cryptonight. Your performance seems low for an i7 no matter the number of threads you used. My i5-2400 is faster than your i7-3770. |
|
|
|
YAAMP_ALLOW_EXCHANGE will be set in another config file before the defaults are run, so the !defined check will not pass.
More made up BS. There is no way you would know that. |
|
|
|
I found an interesting function. It ckearly shows that no conversion is done if the ernings coin ($coin->id) is the same as the user's payout coin ($user->coinid) it does no conversion. It simply returns the amount unchanged. It further shows that BTC payouts are the only ones that can use a market exchange. The returned value is then added to the balance. What's my point? This is called by BackendClearEarnings which is where the block's status is changed to "Cleared". This is a key place to collect data to verify the credit from a block and there is a debug log already. This also answers the question about doing needless exchanges. Can we progress forward now and get some real data to stop the speculation? function yaamp_convert_amount_user($coin, $amount, $user)
{
$refcoin = getdbo('db_coins', $user->coinid);
$value = 0.;
if (YAAMP_ALLOW_EXCHANGE) {
if(!$refcoin) $refcoin = getdbosql('db_coins', "symbol='BTC'");
if(!$refcoin || $refcoin->price2 <= 0) return 0;
$value = $amount * $coin->price2 / $refcoin->price2;
} else if ($coin->price2 && $refcoin && $refcoin->price2 > 0.) {
$value = $amount * $coin->price2 / $refcoin->price2;
} else if ($coin->id == $user->coinid) {
$value = $amount;
}
return $value;
}
yeah but allow exchange is turned on, that means the symbol is forced btc. if allow exchange is disabled, then you would only get paid in the coin that you mine.. this is what its saying. YAAMP_ALLOW_EXCHANGE is set to false here... web/yaamp/defaultconfig.php:if (!defined('YAAMP_ALLOW_EXCHANGE')) define('YAAMP_ALLOW_EXCHANGE', false);
... and never set true. So the first branch of the if is always skipped. However there is a bug, or just bad coding. The "same coin" test (3rd branch) should be done before the "other altcoin" test (2nd branch). The way it is written the altcoin test is done before the same coin test and will catch the same coin case unless the price is strategically set to 0. This means the same coin case will do a price conversion but it should be 1/1 because the price is being divided by itself. Something else to confirm. the pool admin, crackfoo, would have set allow_echange to true in the config.. its obviously enabled cause if it wasnt we wouldnt be paid in bitcoin at all.. BS, you just made that up. If false, which it is, it converts to the refcoin value, which can be BTC. That's what the code says. The only effect of it being true in this piece of code is to set the refcoin to BTC if is currently not defined. |
|
|
|
I found an interesting function. It ckearly shows that no conversion is done if the ernings coin ($coin->id) is the same as the user's payout coin ($user->coinid) it does no conversion. It simply returns the amount unchanged. It further shows that BTC payouts are the only ones that can use a market exchange. The returned value is then added to the balance. What's my point? This is called by BackendClearEarnings which is where the block's status is changed to "Cleared". This is a key place to collect data to verify the credit from a block and there is a debug log already. This also answers the question about doing needless exchanges. Can we progress forward now and get some real data to stop the speculation? function yaamp_convert_amount_user($coin, $amount, $user)
{
$refcoin = getdbo('db_coins', $user->coinid);
$value = 0.;
if (YAAMP_ALLOW_EXCHANGE) {
if(!$refcoin) $refcoin = getdbosql('db_coins', "symbol='BTC'");
if(!$refcoin || $refcoin->price2 <= 0) return 0;
$value = $amount * $coin->price2 / $refcoin->price2;
} else if ($coin->price2 && $refcoin && $refcoin->price2 > 0.) {
$value = $amount * $coin->price2 / $refcoin->price2;
} else if ($coin->id == $user->coinid) {
$value = $amount;
}
return $value;
}
yeah but allow exchange is turned on, that means the symbol is forced btc. if allow exchange is disabled, then you would only get paid in the coin that you mine.. this is what its saying. YAAMP_ALLOW_EXCHANGE is set to false here... web/yaamp/defaultconfig.php:if (!defined('YAAMP_ALLOW_EXCHANGE')) define('YAAMP_ALLOW_EXCHANGE', false);
... and never set true. So the first branch of the if is always skipped. However there is a bug, or just bad coding. The "same coin" test (3rd branch) should be done before the "other altcoin" test (2nd branch). The way it is written the altcoin test is done before the same coin test and will catch the same coin case unless the price is strategically set to 0. This means the same coin case will do a price conversion but it should be 1/1 because the price is being divided by itself. Something else to confirm. |
|
|
|
I found an interesting function. It ckearly shows that no conversion is done if the ernings coin ($coin->id) is the same as the user's payout coin ($user->coinid) it does no conversion. It simply returns the amount unchanged. It further shows that BTC payouts are the only ones that can use a market exchange. The returned value is then added to the balance. What's my point? This is called by BackendClearEarnings which is where the block's status is changed to "Cleared". This is a key place to collect data to verify the credit from a block and there is a debug log already. This also answers the question about doing needless exchanges. Can we progress forward now and get some real data to stop the speculation? function yaamp_convert_amount_user($coin, $amount, $user)
{
$refcoin = getdbo('db_coins', $user->coinid);
$value = 0.;
if (YAAMP_ALLOW_EXCHANGE) {
if(!$refcoin) $refcoin = getdbosql('db_coins', "symbol='BTC'");
if(!$refcoin || $refcoin->price2 <= 0) return 0;
$value = $amount * $coin->price2 / $refcoin->price2;
} else if ($coin->price2 && $refcoin && $refcoin->price2 > 0.) {
$value = $amount * $coin->price2 / $refcoin->price2;
} else if ($coin->id == $user->coinid) {
$value = $amount;
}
return $value;
}
|
|
|
|
I can't say I know or understand how the internal exchanging works when you're mining in exchange mode and with an address that is !=BTC but perhaps the share of BERN you earned is converted to BTC and virtually bought back?
Anyway, if you want to discuss this further I'd appreciate if you'd start your own thread.
I'm happy to help anyone with technical issues, mining problems, payouts not sent etc...
looking at the code i see this happening.. even if it says you "earned" 10 BERN or whatever, its really .000002342 BTC and its just showing the BERN amount based on exchange rate at that time. this is why when you actually get a payout its less. it actually looks like it comes up with this value by ask+bid/2 * 0.9 - tx fee.. it also looks like its set to dump the coins on the exchange at up to a 20% loss if it cant meet this price.. during actual exchange.. the only way i see fixing this, is to get the author to tighten up the guesstimation, and lower the loss to say 5% or so.. but the problem this would cause is the people mining BERN or whatever and want to get paid in BTC would see a lot longer pending times.. to the guys that want to mine a certain coins to get paid out in those coins, they should really find a different pool. this one is setup to pay out in bitcoin. I appreciate the explanation but I have some concerns about it. Could you point me to the code you are looking at? I think your math is off. ask+bid/2 * 0.9 is actually 90% of the mean, so it's minus 10%, not 20%. Regardless of the math it looks like you're saying it will not dump the coins if the price drops more than a specified percentage. This looks like good downside protection that should limit the losses, not exacerbate them. |
|
|
|
I can't say I know or understand how the internal exchanging works when you're mining in exchange mode and with an address that is !=BTC but perhaps the share of BERN you earned is converted to BTC and virtually bought back?
So where did the 20% go? (third time I ask this question, never answered) bid 0.00000038 ask 0.00000078 Whats the math there? Anyways, this discussion is for another thread. Move it please. Say you do an internal trade in the worst case, you pay the ask and receive the bid. It's an internal trade and you end up with less than you started with. Where are those coins you lost? Are they in the pool's BTC wallet? If so that's wrong. However, your example does not line up with the available data. I have not seen anyone post losing more than 30-35% nor less than 15% and diffferent coins have different spreads so there should be some higher volume, and better known, coins with smaller spreads and correspondingly smaller losses. But they are all centered around 20%. It's a pattern that is not dependent on the coind being mined, the coin being paid out or whether an exchange, internal or external, is required. The simplest case is when the payout coin is the same as the mined coin. No exchange nor estimating is required. Internal exchnage is the next more complex case because an internal exchange is required. However, the internal exchange does not incur trading fees and should not be subject to price spread or market flooding. External exchange, only required for BTC payout, is the most complex case as there are exchange fees and all other market risks. If the software is executing unnecessary internal trades for same coin payout it complicates debugging. But it seems a simple to bypass it if it is happening. If the problem goes away for same coin payout you've found where the problem is. But it's still premature to think about fixes because the problem is still not fully understood. It still needs to be determined where the loss occurs. It's after the block is cleared but before it appears in the user's balance. That includes retrieving the data from the DB, possible exchange to payout coin, deducting the estimated block value from the pending and adding the actual value to the balance. At one of those points an error is being made causing a loss of ~20%. You say you noted the problem, what is your next step? |
|
|
|
I can't say I know or understand how the internal exchanging works when you're mining in exchange mode and with an address that is !=BTC but perhaps the share of BERN you earned is converted to BTC and virtually bought back?
So where did the 20% go? (third time I ask this question, never answered) |
|
|
|
Yes.
Something is happening.
Don't say what it is unless you can prove what it is. I agree that a proper block share % on a same-as-mined coin should be 98% of that block assuming you have 100% of the total shares. Don't fall short on this recognition. But without a full dataset of proof on the block rewards, then yes... I am skeptical and look into every possible cause. I don't irrationally focus and make claims that I have no full evidence of. I speculate.
It's like trying to prove a black hole exists without the math behind it.... only pointing towards a dark speck at the sky saying... look... see for yourself.
It's rather annoying that you just sit and repeat what you seem to hold as a fact without proof. You have yet to verify the pool works the way you believe it is coded.
I'm asking for data, I only repeat myself when the same lame unsupported speculations are posted over and over. And I always explain the basis for my speculation with the available data. You don't do that. It's always it could be this or it could be that but never why it could be. Time for speculating is over, WE NEED DATA, another repetition. I spent 20 years doing exactly this kind of problem solving. The only difference was I had all the tools I needed then. When I had a theory I could prove it myself. I could collect the data myself, analyse it, chnage the code, and retest. A Major part of that is designing the tests and avoiding extraneous variables. I can't help it it you can't appreciate professional problem solving techniques. The only black hole is what happens between the time a block is cleared and credited to the users. But unlike a cosmological black hole someone can actually observe this one. |
|
|
|
One user demonstrated the problem when getting paid in the same coin as mined. Here it is... https://bitcointalk.org/index.php?topic=1260863.msg16332061#msg16332061All reports have been in the 15 to 30% range, always negative. The has been no contradictory evidence or claims presented, only empty speculation about price volatility, exchnage fees etc that have no bearing on the problem. That's proof enough for me. very little proof... a very small dataset.... Just a graph showing an estimated value becoming an actual value.... Let me expand: What were the rest of the statistics for those specific payouts to the wallets? How were the estimates derived mathematically? What variables are in that calculation and in what order to provide this result? SEE WHAT I AM SAYING YET? See how I keep pointing out there's more variables than people choose to focus on. NO I don't see what you are saying. It's BERN to BERN, it's not an estimate, it's actual. One BERN will always be worth exactly one BERN. That's grade 1 math. Edit: you're just throwing shit out there to see if it will stick. |
|
|
|
Overwhelming a thin market with a large sell order is always a concern as it would drive the price down and would always have\ a negative bias on profit. That is why I'm focussed on the same payout coin example. There is not actual exchange at an external market, there is no need for internal conversion or estimates of any kind. It's all apples, no oranges. Do you plan on backing out these changes to test? |
|
|
|
you misread as I state that's an issue that needs looked at in my reply above.
so you are telling me that you are certain you were earning 100% block reward (by share submission) and no other miners has delta hashrate left over from a previous connection at that same time as your test?
I did read that sentence but did not respond. My main concern was bringing back old lame excuses that had already been rejected by data and sound logic. To my knowledge there has never been a case with 100% (98% after mining fee) of a block by one user. That may be another issue to be explored but I digress. My personal observations, without verbose rationalization. On the graph, regardless of the algo, everytime the balance goes up the total goes down. Bigger coins produce more visible results. The size of the drop is alway proprotional to the size of the balance increase and can be visibly estimated at about 1/4. I specifically oobserved an LBRY block that was maturing. The BTC value fluctuated as it matured as expected due to exchange price variations. I noted the value just before maturing to compare with the balance credit for that block. It was about 20% less. Other users have reported similar losses with various algos and various payout coins. Some have posted their data and analysis in great detail. I have reviewed their claims and they are consistent with my observations. One user demonstrated the problem when getting paid in the same coin as mined. Here it is... https://bitcointalk.org/index.php?topic=1260863.msg16332061#msg16332061All reports have been in the 15 to 30% range, always negative. The has been no contradictory evidence or claims presented, only empty speculation about price volatility, exchnage fees etc that have no bearing on the problem. That's proof enough for me. |
|
|
|
|
Show Posts
