Bitcoin Forum
December 11, 2016, 08:25:22 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 [151] 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 »
  Print  
Author Topic: [OLD] Eligius: ASIC, no registration, no fee CPPSRB BTC + 105% PPS NMC, 877 #  (Read 418305 times)
kendog77
Hero Member
*****
Offline Offline

Activity: 742


View Profile
December 12, 2013, 09:49:55 PM
 #3001

@wizkid

Thanks for your endeavor and your explanations. I think you misunderstood something, and I think, I speak for the other KnC Nov rig owners also, no one blamed or wanted to blame you or the pool. We just stated that there is a problem, but did not claim that it's a problem of the pool itself.

Eligius is a fine pool. Keep up your good work and, again, thanks for your work.

I agree. I don't think the problem is with the Eligius pool, but unfortunately the pool ends up taking a hit when the fastest mining rigs on the market don't work well with it using default, non hacked, firmware. The reason November Jupiters don't work well with the pool is kind of irrelevant.

I love the pool and will be back when Knc issues a firmware fix.
1481444722
Hero Member
*
Offline Offline

Posts: 1481444722

View Profile Personal Message (Offline)

Ignore
1481444722
Reply with quote  #2

1481444722
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
wizkid057
Legendary
*
Offline Offline

Activity: 1170


View Profile
December 12, 2013, 10:47:28 PM
 #3002

@wizkid

Thanks for your endeavor and your explanations. I think you misunderstood something, and I think, I speak for the other KnC Nov rig owners also, no one blamed or wanted to blame you or the pool. We just stated that there is a problem, but did not claim that it's a problem of the pool itself.

Eligius is a fine pool. Keep up your good work and, again, thanks for your work.

I agree. I don't think the problem is with the Eligius pool, but unfortunately the pool ends up taking a hit when the fastest mining rigs on the market don't work well with it using default, non hacked, firmware. The reason November Jupiters don't work well with the pool is kind of irrelevant.

I love the pool and will be back when Knc issues a firmware fix.

Well, there are in fact people using this issue with KNC devices to pull people away from Eligius for whatever

That's the thing, the KNC devices do work well with it, as there are quite a few mining Eligius, including many November ship jupiters.  There are only a handful of people actually experiencing this issue.

Its definitely not related to the pool and I'm sure you're not actually getting better long-term hash rates elsewhere.  The issue is with the hardware/software.  Any illusion otherwise just means you either didn't test long enough, just got lucky/unlucky, or your pool is lying about or miscalculating your hash rate.  (Eligius bases this directly on shares accepted, as it should.)  If your Nov. jupiter gets high HW errors on Eligius, then based on my tests (of over a dozen jupiters now, thank you very much for the support folks) it does everywhere else also.  There's no difference in the data sent from Eligius than there is from any other pool aside from the obvious (who gets paid for found blocks).

It's been confirmed that the same issue that affected some Avalon users a while back with Eligius regarding a large coinbase transaction does not affect KNC units as they have tons of CPU headroom. (I tried with a coinbase transaction 50x larger than Eligius's allowed max and KNC devices didn't even flinch.)

Spoke with someone from KNC and they say the issue is likely related to the DC to DC converter temperature, which would explain why the issue is intermittent.

-wk

Tips: 1LDQrLr6dPVqNJmpZm82eZVKqDFRk7ERW8
Operator of the Eligius Mining Pool - 0% Fee, CPPSRB, GBT, Stratum, IRC+Phone Support, Awesome stats, Generation payouts, and more.
Don't feed the trolls. Science Confirms: Internet Trolls Really Are Narcissistic, Psychopathic, and Sadistic (1)
wizkid057
Legendary
*
Offline Offline

Activity: 1170


View Profile
December 13, 2013, 02:25:50 AM
 #3003

Greetings miners,

So, on to some minor fixes/changes.

Since I dropped the minimum payout amount down to 40 TBC (~0.04 BTC) the coinbase/generation transaction has been reaching the set maximum outputs almost every block.  This means that the balance ends up in the pool's cold wallet and needs to be paid manually later (which I have been doing).

In an effort to address this without increasing the size of the coinbase transaction (which can cause problems with miners that have low memory or slow hosts) I've modified the way the coinbase transaction is created slightly with regard to the payout queue.

Here is how it worked previously:

  • Sort addresses in queue by balance age, oldest to newest
  • Pay addresses until either the full coinbase/reward amount was consumed or 128 outputs were paid
  • If less than the full reward were consumed, and less than 2000 TBC remain, send the balance to the offline "change" address.
  • If more, pay 2000 TBC to the offline change address, balance to the main offline wallet

Now it works like this, changes highlighted in green:

  • Sort addresses in queue by balance age, oldest to newest
  • Pay addresses until either the full coinbase/reward amount was consumed or 100 outputs were paid
  • If less than the full reward were consumed, re-sort the addresses in queue, highest balance to lowest balance
  • Pay addresses until either the full coinbase/reward amount was consumed or 28 outputs were paid
  • If less than the full reward were consumed, and less than 2000 TBC remain, send the balance to the offline "change" address.
  • If more, pay 2000 TBC to the offline change address, balance to the main offline wallet

This has the effect of better filling the coinbase/generated payout transaction with more miners that are due payouts by effectively allowing miners with the largest balances due to jump ahead in the queue, only when needed, to better pay the full block reward directly to miners, instead of to a pool offline wallet for manual payment.

Summary: The payout queue should be paid out automatically the majority of the time and faster than it has been with less manual payouts needed.  More fresh coins for miners. Smiley

Happy mining!

-wk

Tips: 1LDQrLr6dPVqNJmpZm82eZVKqDFRk7ERW8
Operator of the Eligius Mining Pool - 0% Fee, CPPSRB, GBT, Stratum, IRC+Phone Support, Awesome stats, Generation payouts, and more.
Don't feed the trolls. Science Confirms: Internet Trolls Really Are Narcissistic, Psychopathic, and Sadistic (1)
GigaWave
Sr. Member
****
Offline Offline

Activity: 244


View Profile
December 13, 2013, 04:12:28 AM
 #3004

I didn't read the KNC issues in detail. But one issue I seem to be having lately is if the 'pool difficulty' is high for my device, it seems more likely to crash(Temperature runs higher). Which requires a full power down of the device(BFL 60GH).  I'm looking forward to the set-able difficulty, so I can do some testing.
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
December 13, 2013, 04:21:38 AM
 #3005

I didn't read the KNC issues in detail. But one issue I seem to be having lately is if the 'pool difficulty' is high for my device, it seems more likely to crash(Temperature runs higher). Which requires a full power down of the device(BFL 60GH).  I'm looking forward to the set-able difficulty, so I can do some testing.
Difficulty does not affect devices at all.
Even if you could set difficulty, it is unlikely to allow setting it lower than the automatic variable difficulty (which is lower than most pools use on Eligius).

helmax
Sr. Member
****
Offline Offline

Activity: 406



View Profile
December 13, 2013, 12:44:47 PM
 #3006

@wizkid

Thanks for your endeavor and your explanations. I think you misunderstood something, and I think, I speak for the other KnC Nov rig owners also, no one blamed or wanted to blame you or the pool. We just stated that there is a problem, but did not claim that it's a problem of the pool itself.

Eligius is a fine pool. Keep up your good work and, again, thanks for your work.

thats it

people only want kncminers works good here

looking job
jgarzik
Legendary
*
Offline Offline

Activity: 1470


View Profile
December 13, 2013, 04:09:04 PM
 #3007

coinbase payouts do not matter to me...  I would rather have regular-sized payouts that reduce dust in the wallet (more friendly to the network).

i.e. payout at 0.1 BTC threshold.

Any chance of having that option?

Implementing that would have the side effect of not needing to put a set of addresses in the coinbase.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
twmz
Hero Member
*****
Offline Offline

Activity: 737



View Profile
December 13, 2013, 04:18:57 PM
 #3008

coinbase payouts do not matter to me...  I would rather have regular-sized payouts that reduce dust in the wallet (more friendly to the network).

i.e. payout at 0.1 BTC threshold.

Any chance of having that option?

Implementing that would have the side effect of not needing to put a set of addresses in the coinbase.



minimum payout can be configured here (I have mine set to 0.2):

http://eligius.st/~wizkid057/newstats/mystats.php?cmd=options

Was I helpful?  1TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs
WoT, GPG

Bitrated user: ewal.
Ximoxion
Newbie
*
Offline Offline

Activity: 22


View Profile
December 13, 2013, 04:59:39 PM
 #3009

Was wondering if there was any update on the Hashbuster Micros.  I placed an order and have not received confirmation or any other information.  Thanks
jgarzik
Legendary
*
Offline Offline

Activity: 1470


View Profile
December 13, 2013, 06:40:31 PM
 #3010

coinbase payouts do not matter to me...  I would rather have regular-sized payouts that reduce dust in the wallet (more friendly to the network).

i.e. payout at 0.1 BTC threshold.

Any chance of having that option?

Implementing that would have the side effect of not needing to put a set of addresses in the coinbase.



minimum payout can be configured here (I have mine set to 0.2):

http://eligius.st/~wizkid057/newstats/mystats.php?cmd=options

A simple minimum payout does not avoid the problem of receiving dust.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
twmz
Hero Member
*****
Offline Offline

Activity: 737



View Profile
December 13, 2013, 06:46:25 PM
 #3011

A simple minimum payout does not avoid the problem of receiving dust.

Ok, then I don't understand what you're asking for. 

The my payments are always 0.2xxxxxxx.  The only case where I would receive a dust payment is if I stop mining altogether at eligius right after I had received a payment, then eventually I would get my balance (no matter how small and dusty) as a payment.

Are you asking for payments to only ever be in clean multiples of some payment threshold?  So 0.20000000 but never 0.21738261?  I guess I can see the point if when you spend bitcoins, you only ever spend them in nice round numbers.  That hasn't been typical for my purchases (via BitPay), because of exchange rates, the merchants are often asking me to send them a payment of 0.162534 or whatever, and so even if my wallet was initially full of nice clean inputs, they wouldn't stay clean for long.

Was I helpful?  1TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs
WoT, GPG

Bitrated user: ewal.
GigaWave
Sr. Member
****
Offline Offline

Activity: 244


View Profile
December 13, 2013, 09:02:49 PM
 #3012

I didn't read the KNC issues in detail. But one issue I seem to be having lately is if the 'pool difficulty' is high for my device, it seems more likely to crash(Temperature runs higher). Which requires a full power down of the device(BFL 60GH).  I'm looking forward to the set-able difficulty, so I can do some testing.
Difficulty does not affect devices at all.
Even if you could set difficulty, it is unlikely to allow setting it lower than the automatic variable difficulty (which is lower than most pools use on Eligius).

So for example, when it's finished, if I set the '--request-diff' flag to '64' for example, it will still give a automatic value? What is this flag really accomplishing?

Just a FYI, '64' diff. seems to be the safe limit for my device, when it starts using '128' the temp runs higher and then it is more likely to completely crash, requiring a cold boot.
xyzzy099
Legendary
*
Offline Offline

Activity: 941



View Profile
December 13, 2013, 09:11:39 PM
 #3013

I didn't read the KNC issues in detail. But one issue I seem to be having lately is if the 'pool difficulty' is high for my device, it seems more likely to crash(Temperature runs higher). Which requires a full power down of the device(BFL 60GH).  I'm looking forward to the set-able difficulty, so I can do some testing.
Difficulty does not affect devices at all.
Even if you could set difficulty, it is unlikely to allow setting it lower than the automatic variable difficulty (which is lower than most pools use on Eligius).

So for example, when it's finished, if I set the '--request-diff' flag to '64' for example, it will still give a automatic value? What is this flag really accomplishing?

Just a FYI, '64' diff. seems to be the safe limit for my device, when it starts using '128' the temp runs higher and then it is more likely to completely crash, requiring a cold boot.

Changing the diff does not change the operation of your device at all.  It still generates shares exactly the same way it was already doing.  The difficulty simply determines which shares actually get submitted to the pool.  If the difficulty is 64, then only shares with a difficulty over 64 are submitted.  If the diff is 128, then only generated shares that just happen to have a difficulty of 128 or higher are submitted.

Changing difficulty does not make your hardware work harder, or less hard, or change anything at all about the hardware operation - it just defines which generated shares actually get submitted to the pool by the miner software.

PS - The last time I mined on Eligius, the '--request-diff' flag was not honored by the pool.  I don't know if that is still true or not.

Libertarians:  Diligently plotting to take over the world and leave you alone.
GigaWave
Sr. Member
****
Offline Offline

Activity: 244


View Profile
December 14, 2013, 01:03:52 AM
 #3014

I didn't read the KNC issues in detail. But one issue I seem to be having lately is if the 'pool difficulty' is high for my device, it seems more likely to crash(Temperature runs higher). Which requires a full power down of the device(BFL 60GH).  I'm looking forward to the set-able difficulty, so I can do some testing.
Difficulty does not affect devices at all.
Even if you could set difficulty, it is unlikely to allow setting it lower than the automatic variable difficulty (which is lower than most pools use on Eligius).

So for example, when it's finished, if I set the '--request-diff' flag to '64' for example, it will still give a automatic value? What is this flag really accomplishing?

Just a FYI, '64' diff. seems to be the safe limit for my device, when it starts using '128' the temp runs higher and then it is more likely to completely crash, requiring a cold boot.

Changing the diff does not change the operation of your device at all.  It still generates shares exactly the same way it was already doing.  The difficulty simply determines which shares actually get submitted to the pool.  If the difficulty is 64, then only shares with a difficulty over 64 are submitted.  If the diff is 128, then only generated shares that just happen to have a difficulty of 128 or higher are submitted.

Changing difficulty does not make your hardware work harder, or less hard, or change anything at all about the hardware operation - it just defines which generated shares actually get submitted to the pool by the miner software.

PS - The last time I mined on Eligius, the '--request-diff' flag was not honored by the pool.  I don't know if that is still true or not.


At this point I can't definitively say what I have noticed is true, but it really does look like that is the case. Also, this seems to be a more recent thing. This device has been mining for a few months now, and in the past I would typically only have a hard crash once every two weeks at most. In the past 4 days, it has happened 5 times.

I keep a pretty close eye on the ambient temps and they really haven't changed. I have a Arduino with a temp sensor next to the device and can log the temps. Is their a easy way to log BFGMiner output to a file?

From my understanding they are days away from getting the flag working.

EDIT:(20 minutes after last reboot)
Just had it crash again, I wonder if this thing is just thinking about giving up the ghost or what?  Here is a screenshot of what it does when it crashes.(from a month ago, but it's the same thing)
bmoconno
Sr. Member
****
Offline Offline

Activity: 266


New In Town...


View Profile WWW
December 14, 2013, 01:04:20 AM
 #3015

This issue may have been gone over already, but as this is currently at like a billion pages, I'm hoping someone might be able to help me out.

I just recently added 2 Antminer S1 units (~400 Gh/s), but my 128 and 256 second hash rates don't seem to be showing my new hash speed correctly.  As I've had my new machines up and running for nearly 3 hours, the 3 hour average actually appears to be correct.  Is this a problem other people have had?  Or should I be doing something to resolve this?

Thanks,
bmoconno

Chained To Your Miners?  Try Miner Minder for a web based stratum proxy that you control!
If I've helped you out, or you just think I'm awesome… 13SZex4uANVrfTeeuFEXGu6W8EVYtWVB53
wizkid057
Legendary
*
Offline Offline

Activity: 1170


View Profile
December 14, 2013, 01:12:01 AM
 #3016

So with the help of many volunteers I believe I have found the cause of the issues with KNC miners running cgminer.

cgminer seems to be "forgetting" about work if new work is not given often.  Eligius uses what I believe was an originally defined standard of 55 seconds between stratum work updates.  Work is valid for 120 seconds.  However, when cgminer doesnt get a work update every 30 seconds or so, it occasionally seems to forget the work it gave to some hashing cores and this manifests as false hardware errors.

So far three affected KNC users have confirmed that changing the work update interval to 30 seconds fixes the false HW error issue and gives a boost in hash rate.  As for tracking down the actual cgminer bug I will try to work with conman and kano on it, and hopefully keep it civil.

I will be updating the pool to do stratum work updates every 30 seconds instead of 55 seconds like it does now.  Anyone else having KNC HW error issues willing to test this before its on the live server (dev server, still get full credit for work) shoot me a PM on IRC.

I'm unsure if this issue affects non-KNC devices running cgminer as my efforts in tracking this down have been focused on KNC.

---

Side note, Bitminter beat us by about a second on a block earlier and it ended up throwing a failsafe.  Stats and payout queue are catching up. 

Basically, I'm going to *try* to dedicate most of this weekend to Eligius improvements.  So, more to come.

-wk

Tips: 1LDQrLr6dPVqNJmpZm82eZVKqDFRk7ERW8
Operator of the Eligius Mining Pool - 0% Fee, CPPSRB, GBT, Stratum, IRC+Phone Support, Awesome stats, Generation payouts, and more.
Don't feed the trolls. Science Confirms: Internet Trolls Really Are Narcissistic, Psychopathic, and Sadistic (1)
wizkid057
Legendary
*
Offline Offline

Activity: 1170


View Profile
December 14, 2013, 01:13:14 AM
 #3017

This issue may have been gone over already, but as this is currently at like a billion pages, I'm hoping someone might be able to help me out.

I just recently added 2 Antminer S1 units (~400 Gh/s), but my 128 and 256 second hash rates don't seem to be showing my new hash speed correctly.  As I've had my new machines up and running for nearly 3 hours, the 3 hour average actually appears to be correct.  Is this a problem other people have had?  Or should I be doing something to resolve this?

Thanks,
bmoconno

The 128/256 second hashrates rely on the reward system, and as noted in my last post, it went into failsafe mode earlier.  They should be correct in about an hour.  The 22.5 minute and longer time period hashrates should always be correct.

Tips: 1LDQrLr6dPVqNJmpZm82eZVKqDFRk7ERW8
Operator of the Eligius Mining Pool - 0% Fee, CPPSRB, GBT, Stratum, IRC+Phone Support, Awesome stats, Generation payouts, and more.
Don't feed the trolls. Science Confirms: Internet Trolls Really Are Narcissistic, Psychopathic, and Sadistic (1)
bmoconno
Sr. Member
****
Offline Offline

Activity: 266


New In Town...


View Profile WWW
December 14, 2013, 01:14:01 AM
 #3018

This issue may have been gone over already, but as this is currently at like a billion pages, I'm hoping someone might be able to help me out.

I just recently added 2 Antminer S1 units (~400 Gh/s), but my 128 and 256 second hash rates don't seem to be showing my new hash speed correctly.  As I've had my new machines up and running for nearly 3 hours, the 3 hour average actually appears to be correct.  Is this a problem other people have had?  Or should I be doing something to resolve this?

Thanks,
bmoconno

The 128/256 second hashrates rely on the reward system, and as noted in my last post, it went into failsafe mode earlier.  They should be correct in about an hour.  The 22.5 minute and longer time period hashrates should always be correct.

Excellent!  Thanks for the rapid response, I love your pool!

Chained To Your Miners?  Try Miner Minder for a web based stratum proxy that you control!
If I've helped you out, or you just think I'm awesome… 13SZex4uANVrfTeeuFEXGu6W8EVYtWVB53
Biffa
Legendary
*
Offline Offline

Activity: 1022



View Profile
December 14, 2013, 02:45:03 AM
 #3019

Anyone else having KNC HW error issues willing to test this before its on the live server (dev server, still get full credit for work) shoot me a PM on IRC.

Will pop on IRC can test on dev

lenny_
Legendary
*
Offline Offline

Activity: 953



View Profile
December 14, 2013, 05:34:48 AM
 #3020

I have issues with HW ratio on Eligius on KNC Jupiter November units. I have 3 units, all of them behave exactly the same.

Testing scenario one of the units:
1. Restart cgminer, choose Eligius pool via ssh, reset cgminer statistics, let it run for couple of hours, write down stats
2. Restart cgminer, choose BitMinter pool via ssh, reset cgminer statistics, let it run for couple of hours, write down stats
3. Repeat nr 1
4. Repeat nr 2

Stats:
1. Eligius 9.4% HW, WU 8437 https://drive.google.com/file/d/0B2z0CgjT8HdwYnhkTFk1TGd1VUE/edit?usp=sharing
2. BitMinter 1.5% HW, WU 9199 https://drive.google.com/file/d/0B2z0CgjT8HdwZFB6Nkx1czBNdEE/edit?usp=sharing
3. Eligius 8.9% HW, WU 8478 https://drive.google.com/file/d/0B2z0CgjT8HdwazZsRnlPbDdYQkk/edit?usp=sharing
4. BitMinter 1.6% HW, WU 9188 https://drive.google.com/file/d/0B2z0CgjT8HdwMTJMaW1kdkNaQlE/edit?usp=sharing

I have default settings of:
Code:
[Q]ueue: 1
[S]cantime: 60
[E]xpiry: 120

wizkid057, what should I set there? I will be happy to help with dev pool, sent you PM.

Regards,
Lenny
Pages: « 1 ... 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 [151] 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!