Max target for PoW is actually 15 min. |
|
|
|
"networkghps" : 0.00205548, How much is this in MH/s ?
Last I checked, there were a thousand megas in a giga. So approximately 2Mhash/s. You'll want to get multiple readings over, say, an hour or so, given the constant difficulty adjustment, the estimate bounces around as well. Only 2Mhash/s ?? The pool alone is doing 1Mhash/s so should be getting 50% of all PoW blocks ? Instead its hitting one block every couple of hours ?? How is this possible ? slimcoin 2014-6-24 15:02:22 UTC 19485 000000044b6cd55ad887d022d0e3d2efdd9039d14d63408a8dcb5e14ec045bc3 9.36 immature slimcoin 2014-6-24 13:29:25 UTC 19431 00000000f7c59c2bc135a41bc7b5d7c48840acdfd354a3e52e2b8b90a716f8db 8.64 immature last two blocks pool found - 1hour 30min difference This time you are right primer  Sandor take a close look at your logfiles... That is definitely worse than "bad luck". Take some action, fast please! My first guess would be you're on a version of the node.js stratum that has the "block invalid" bug.. meaning a found block is is rejected in the stratum, but accepted in the client. Stratum and DB however do not notice that and the block is not counted at all There is nothing wrong with the pool... there are actually no blocks being rejected, all 100% submitted. Btw there were only 4 PoW blocks generated between 19431 and 19485 : 19467, 19477, 19479, 19480 It's basic statistics, primer-. If the network hashrate was 2 Mh/s, that means we would get 50% over the long run. BUT, since the sample size is only 4 blocks that means that the spread is large, so nothing alarming that the pool mined two less blocks than it was supposed to. Compare it to flipping a coin 4 times and getting 4x tail in a row. There were only 4 PoW blocks (which should spawn every 90 secs) in 1.5 hours ?? And dont patronize me with basic statistics, instead of wasting characters about statistics you should have wrote something about a broken algo - PoW block should be created every 90 secs not one every 30 minutes! Where does it say that PoW blocks are created every 90 seconds? |
|
|
|
"networkghps" : 0.00205548, How much is this in MH/s ?
Last I checked, there were a thousand megas in a giga. So approximately 2Mhash/s. You'll want to get multiple readings over, say, an hour or so, given the constant difficulty adjustment, the estimate bounces around as well. Only 2Mhash/s ?? The pool alone is doing 1Mhash/s so should be getting 50% of all PoW blocks ? Instead its hitting one block every couple of hours ?? How is this possible ? slimcoin 2014-6-24 15:02:22 UTC 19485 000000044b6cd55ad887d022d0e3d2efdd9039d14d63408a8dcb5e14ec045bc3 9.36 immature slimcoin 2014-6-24 13:29:25 UTC 19431 00000000f7c59c2bc135a41bc7b5d7c48840acdfd354a3e52e2b8b90a716f8db 8.64 immature last two blocks pool found - 1hour 30min difference This time you are right primer Sandor take a close look at your logfiles... That is definitely worse than "bad luck". Take some action, fast please! My first guess would be you're on a version of the node.js stratum that has the "block invalid" bug.. meaning a found block is is rejected in the stratum, but accepted in the client. Stratum and DB however do not notice that and the block is not counted at all There is nothing wrong with the pool... there are actually no blocks being rejected, all 100% submitted. Btw there were only 4 PoW blocks generated between 19431 and 19485 : 19467, 19477, 19479, 19480 It's basic statistics, primer-. If the network hashrate was 2 Mh/s, that means we would get 50% over the long run. BUT, since the sample size is only 4 blocks that means that the spread is large, so nothing alarming that the pool mined two less blocks than it was supposed to. Compare it to flipping a coin 4 times and getting 4x tail in a row. |
|
|
|
Shinyminer source: https://github.com/siklon/shinyminergit clone https://github.com/siklon/shinyminer
cd shinyminer
./autogen.sh
./configure CFLAGS="-Ofast -funroll-loops"
make
./minerd -o stratum+tcp://106.3.225.46:6666 -O SWVcv2ByWmriwD4X97bEUhnooHww6qR2at:x -t 1
|
|
|
|
Anybody knows why slimminer on widnows 8.1 just exits after the line "1 miner threads started, using 'dcrypt' algorithm."? Config is 100% correct. On linux (compiled from source) no problems whatsoever. -D -P switches reveal no problems. Windows 7 machine the same problems. Using precompiled binaries from zippyshare on windows.
Compile with "-g" and run in gdb, should tell you any errors before exiting. |
|
|
|
Although the concept of the coin and the measures the dev has taken in order to keep things as fair as possible deserve a big kudos, there are a few issues that need to be addressed asap:
3. It is not possible to manage the wallet from the command line under GNU/Linux, unless you have enough free RAM to run the internal miner thread.
4. On Windows and Linux the wallet does not seem to sync if 'ramhogthreads=0'.
5. The provided config file should have more sane default values, at least ramhogthreads should be zero.
I have covered these questions already, but let's reiterate; the answer to these is simple: how does a wallet know which blocks are valid and can be accepted? The only way is to hash the block header with ramhog and check if the hash is below target, which requires 15 GB memory at minimum. There is no way this can be changed without a hard fork that changes the hashing algo. |
|
|
|
Has this pool processed any payments so far? @7000years... yes... the default settings for the wallet is sic. mine means kill  Expecting from people to run the wallet in order to send/receive coins on a 32GB box is simply insane. I mean, it's like expecting someone to have 3 gfx cards on the box that checks his emails!  All the blocks mined so far by the pool (3) are orphaned, I'm looking into it as I speak.. I would suggest mining solo for now. pool seems down now.
Re-downloading these is required.Linux standalone miner: https://www.dropbox.com/s/dbfxvmoryekyq5i/shinyminerWindows 64-bit standalone miner: https://www.dropbox.com/s/0l4hjypmrg48x6t/shinyminer.zip |
|
|
|
Has this pool processed any payments so far? @7000years... yes... the default settings for the wallet is sic. mine means kill Expecting from people to run the wallet in order to send/receive coins on a 32GB box is simply insane. I mean, it's like expecting someone to have 3 gfx cards on the box that checks his emails! All the blocks mined so far by the pool (3) are orphaned, I'm looking into it as I speak.. I would suggest mining solo for now. |
|
|
|
Pool is fixed : http://106.3.225.46/, no more connection time out. If we find a block I can publish the miner source code. ...are you working on the pool - or do I kill you slightly with my pc's? after switching more than 2 or 3 machines on (43hash per machine) connection timeouts occure again. I'm occasionally restarting the pool after making some changes, so that will cause time out errors. my shares start from zero - are you stable to leave some machines on over night, or do I hash into the dustbin? A example for solo mining for the other guys would be kind, you know. you will get you hash as first pool. The shares you see stats page doesn't reflect your total shares, they are not reset anyway. |
|
|
|
There are the following options: --coinbase-addr=ADDR payout address for solo mining
--coinbase-sig=TEXT data to insert in the coinbase when possible
Could you provide an example about how to solo mine while paying the mined coins to ADDR? Thanks for your work. Source code is better. I agree. Only open-source is secure enough. I don't get it why the source is not released. If the dev wants donations, he could put an address for donations. I am forced to release the source by the GPL licence, I will do it as soon as the pool mines its first block. |
|
|
|
Pool is fixed : http://106.3.225.46/, no more connection time out. If we find a block I can publish the miner source code. ...are you working on the pool - or do I kill you slightly with my pc's? after switching more than 2 or 3 machines on (43hash per machine) connection timeouts occure again. I'm occasionally restarting the pool after making some changes, so that will cause time out errors. |
|
|
|
Proof regarding my CPU utilization claim few posts up :
Server i7 4770 (4 cores / 8 threads), 32GB ram
ramhogthreads=1
[root@CentOS-65-64-minimal .shinycoin]# ./shinycoind getmininginfo
{
"blocks" : 149,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 0.00000122,
"errors" : "",
"generate" : true,
"genproclimit" : 1,
"hashespermin" : 25,
"pooledtx" : 0,
"testnet" : false
}
ramhogthreads=2
[root@CentOS-65-64-minimal .shinycoin]# ./shinycoind getmininginfo
{
"blocks" : 149,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 0.00000122,
"errors" : "",
"generate" : true,
"genproclimit" : 2,
"hashespermin" : 37,
"pooledtx" : 0,
"testnet" : false
}
What proof is that?  Read my post if you want to be informed, ramhogthreads != cpu threads. |
|
|
|
People, don't forget that the "blocks" figure you are seeing in getinfo/getmininginfo includes PoB/PoS blocks. Actually there are a lot of PoB/PoS blocks mined ATM, so it's not accurate to look at the figure and compare it to the PoW blocks the pool has mined. Everything is fine. Your other IP is down : 92.222.27.45 / 3333 Thank you for letting me know. |
|
|
|
At least 15G of memory! Meaning: Most people can not participate
Where shiny future
Where is your plan
the worst part is that you need 32gb to mine at full potential, basically we need a server lol 16 GB is up to 16 cpu threads, 32 GB is up to 32 cpu threads, etc... If the # of cpu threads is >16 and isn't a multiple of 16, then you aren't mining at full potential. 32gb for mining , so practically it is not possible to mine this on home pc at full potential ? It's possible to mine if you have 15 GB of free memory. As requested; static binary for linux : https://www.dropbox.com/s/dbfxvmoryekyq5i/shinyminer |
|
|
|
Pool is fixed : http://106.3.225.46/, no more connection time out. If we find a block I can publish the miner source code. that's sad I can't your binary on my OS. I'm working on making a static binary... |
|
|
|
At least 15G of memory! Meaning: Most people can not participate
Where shiny future
Where is your plan
the worst part is that you need 32gb to mine at full potential, basically we need a server lol Exactly. My message about cpu utilization/ram usage got woooed earlier by the dev minions. He needs to fix the code so 15gb utilizes a single 8 core processor 100% instead of current 60% Well no, it's not that simple, cpu usage isn't relevant with this algo. The reason why it isn't utilizing 100% cpu is because the scratchpad initialization is done in parallel threads before the actual hashing is started. It has to wait for threads to finish which is why cpu usage drops. Btw the scratchpad initialization takes up most of the hashing time. |
|
|
|
At least 15G of memory! Meaning: Most people can not participate
Where shiny future
Where is your plan
the worst part is that you need 32gb to mine at full potential, basically we need a server lol 16 GB is up to 16 cpu threads, 32 GB is up to 32 cpu threads, etc... If the # of cpu threads is >16 and isn't a multiple of 16, then you aren't mining at full potential. |
|
|
|
Pool is fixed : http://106.3.225.46/, no more connection time out. If we find a block I can publish the miner source code. |
|
|
|
People, don't forget that the "blocks" figure you are seeing in getinfo/getmininginfo includes PoB/PoS blocks. Actually there are a lot of PoB/PoS blocks mined ATM, so it's not accurate to look at the figure and compare it to the PoW blocks the pool has mined. Everything is fine. |
|
|
|
|
The difficulty is at it's highest now
{
"blocks" : 18167,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 0.21516656,
"errors" : "",
"generate" : false,
"genproclimit" : -1,
"hashespersec" : 0,
"networkghps" : 0.00247094,
"pooledtx" : 0,
"testnet" : false
}
Takes ~17.5 min for the pool to find a block on average.
|
|
|
|
|
Show Posts
