Suprnova's Dcr Pool

Discussion in 'Proof-of-work Mining' started by ocminer, Feb 2, 2016.

  1. 2017/12/15 - Decred v1.1.2 released! → Release Notes  → Downloads
  1. thijsjuhhh

    thijsjuhhh New Member

    Jan 28, 2016
    50
    14
    Male
    That is your problem. The hd5xxx and hd6xxx are listed as default as --vectors 2. That is wrong. Create a configfile an you will see. When you have created the configfile change --vectors 2 in --vectors 1. Then Cgminer whil show your actual hashrate (which is about 500/550). I had the same problem with my hd6950
     
  2. Metallicelmo

    Metallicelmo New Member

    Jan 30, 2016
    76
    10
    Male
    So this might be a problem with many people mining.. I did a testrun, and I still get higher numbers with vectors 2 in stead of 1 (showing on the pool stats) so I'll stick to running with vectors 2 for now.
     
  3. HeapsIoN

    HeapsIoN New Member
    Advocate (Facebook)

    Dec 28, 2015
    45
    4
    Male
    Got onto the pool fine, managed to run 3 pcs almost all weekend. However now just about everything i do is rejected.

    Any ideas?

    Changing ports helped as suggested, but just curious over all. Anything else i could do or try?
     
  4. LastNinja

    LastNinja Full Member

    Dec 31, 2015
    451
    199
    Male
    Try --no-submit-stale --scan-time 2

    Do not set the queue to 0 since this will give you "pool does not provide work fast enough" errors. Queue is by default on 1 and sometimes it even helps to increase it when the link to the pool is slow.
     
  5. Jamie Keefer

    Jamie Keefer New Member
    Advocate (Twitter)

    Jan 16, 2016
    69
    12
    Male
    #405 Jamie Keefer, Feb 22, 2016
    Last edited: Feb 22, 2016
  6. Jamie Keefer

    Jamie Keefer New Member
    Advocate (Twitter)

    Jan 16, 2016
    69
    12
    Male
    Appears it was stuck. Suprnova staff took care of it. :)
     
  7. Metallicelmo

    Metallicelmo New Member

    Jan 30, 2016
    76
    10
    Male
    I see Decred has moved up to nr. 32 on coinmarketcap, pretty cool
     
  8. CodyF86

    CodyF86 New Member

    Feb 14, 2016
    32
    1
    Male
    Didn't want to start a new thread, but just some fun watching the chain / node control in action. Is this just an orphan or an actual fork (duh not trying to sound dumb) and it figuring out which block was a good block? I 'dcrctl -u -P verifychain' ...'ed, afterwards for good measure. I guess an orphan and a fork go hand in hand. lol :)

    21:32:17 2016-02-22 [INF] BMGR: Processed 1 block in the last 7m33.47s (2 transactions, height 4382, 2016-02-22 21:32:14 -0500 EST)
    21:32:17 2016-02-22 [INF] CHAN: FORK: Block 0000000000003f579318ac1f4d392de2f74093c23788f152bb55d81968276757 (height 4382) forks the chain at height 4381/block 0000000000002ee52a834f707e0101afb0e947a746ed71646d1e462f653f4a0f, but does not cause a reorganize
    21:35:30 2016-02-22 [INF] CHAN: REORGANIZE: Block 0000000000001680c9e9edc42523592b2a507068beae1c950c8d4c72a64f3214 is causing a reorganize.
    21:35:30 2016-02-22 [INF] CHAN: REORGANIZE: Chain forks at 0000000000002ee52a834f707e0101afb0e947a746ed71646d1e462f653f4a0f, height 4381
    21:35:30 2016-02-22 [INF] CHAN: REORGANIZE: Old best chain head was 000000000000205db7238b11fd26babe0ee9e8fc007c52022fa3b0697176909b, height 4382
    21:35:30 2016-02-22 [INF] CHAN: REORGANIZE: New best chain head is 0000000000001680c9e9edc42523592b2a507068beae1c950c8d4c72a64f3214, height 4383
    21:35:30 2016-02-22 [INF] BMGR: Processed 2 blocks in the last 3m13.12s (8 transactions, height 4383, 2016-02-22 21:35:43 -0500 EST)
    21:38:07 2016-02-22 [INF] BMGR: Processed 1 block in the last 2m36.69s (1 transaction, height 4384, 2016-02-22 21:39:20 -0500 EST)
    21:42:35 2016-02-22 [INF] BMGR: Processed 1 block in the last 4m28.58s (1 transaction, height 4385, 2016-02-22 21:38:08 -0500 EST)
    21:43:18 2016-02-22 [INF] BMGR: Processed 1 block in the last 42.53s (2 transactions, height 4386, 2016-02-22 21:46:08 -0500 EST)
    21:45:06 2016-02-22 [INF] RPCS: Verifying chain for 288 blocks at level 3
    21:45:06 2016-02-22 [INF] RPCS: Chain verify completed successfully

    Also some more randomness from me. A week ago I switched to the diff 4 port which got rid off all my rejects with 1.1GHs, but have been getting 10% or so lately. Switching to the diff 8 port with 1.1GHs seems to have fixed it for now with ccminer.
     
  9. ceejep

    ceejep Sr. Member
    Developer

    Dec 14, 2015
    192
    220
    If there are two or more blocks at the chain tip, the mining algorithm in the daemon automatically chooses the block that has the most votes cast on it. If there are not enough votes on any block on the blockchain tip, it will begin mining off the parent to select a new round of lottery winners. This is why you may occasionally see more reorganizations now that PoS is active.
     
    LastNinja likes this.
  10. CodyF86

    CodyF86 New Member

    Feb 14, 2016
    32
    1
    Male
    Ah yeah...lol I've been fiddling with PoS all day now and it completely went over my head that was from a PoS block. Thanks for the explanation! :)
     
  11. ocminer

    ocminer Jr. Member
    Pool Operator (PoW)

    Jan 17, 2016
    135
    45
    Male
    I've added some extra code to include POS voters etc. to increase block rewards ,how can I check if every block has included voters etc ? Block explorer ?
     
  12. sambiohazard

    sambiohazard Sr. Member

    Jan 21, 2016
    844
    372
    yeah block explorer shows voters in each block, it has an API so maybe there is a way to pull this data from there.
     
  13. LastNinja

    LastNinja Full Member

    Dec 31, 2015
    451
    199
    Male
    Suprnova now too has many blocks with destroyed subsidy. Mining rewards therefore down significantly since PoS voting started and votes fail to be included frequently.
     
  14. ocminer

    ocminer Jr. Member
    Pool Operator (PoW)

    Jan 17, 2016
    135
    45
    Male
    i'm always polling latest data from the daemon - and comparing latest getwork call with most recent - not much more I can do
     
  15. LastNinja

    LastNinja Full Member

    Dec 31, 2015
    451
    199
    Male
    I initially suspected that it is mostly the fault of PoS voters who fail to keep their wallets online 24/7. Maybe to many it wasn't even clear that they should when they decided to purchase tickets. Whatever, it's bad for both PoW and PoS miners. A substantial percentage of subsidy is destroyed each day.

    https://dcr.suprnova.cc/index.php?page=statistics&action=blocks

    It's all those blocks with less than 18.x in the "amount" column.
     
  16. michael sørensen

    Translator (Dansk)

    Jan 1, 2016
    130
    62
    Male
    Lol. I actually found a blok, with a 600 MH/s.
    - Had I solo mined, I would have gotten more out that one blok, than the 10 days I've spent on the pool. >.<

    Ooh well.
     
  17. Kandiru

    Kandiru Member

    Feb 21, 2016
    206
    87
    I think a lot of people got carried away on release day and started doing PoS mining after their airdrop matured without realising they would need to have a wallet online 24/7 for 6 months afterwards. Once PoS pools start, this should stop being a problem.
     
  18. Neurosploit

    Neurosploit New Member

    Jan 19, 2016
    36
    13
    Male
    .NET Software Engineer
    Amsterdam
    Well I'm not sure about that. What happens when the pool goes down due to unforseen reasons or even things like a ddos? The wiki states:
    I take it that it also applies to the staking from the pool.
     
  19. sambiohazard

    sambiohazard Sr. Member

    Jan 21, 2016
    844
    372
    Official staking pool will have redundant servers to prevent that as much as possible.
     
  20. LastNinja

    LastNinja Full Member

    Dec 31, 2015
    451
    199
    Male
    Maybe the real solution is to not have all stake tickets globally in one pool ;)
    Not much of "decentralized" otherwise.

    I hope not everyone goes in that one PoS pool once it becomes available.
     
    sambiohazard likes this.

Share This Page