[OLD] Eligius: ASIC, no registration, no fee CPPSRB BTC + 105% PPS NMC, 877 #

[sconklin321]

+1 on the caring issue

For the ANTminer U1 optimization, I can only speak for the Windows version (I'm running Windows 7 32bit so BFGminer 32bit for me).

I run the following:

Code:

bfgminer -S antminer:all -S erupter:all -S all --set-device antminer:clock=x0981 --icarus-options 115200:2:2 --icarus-timing 2.5=90

I have seen another user further back in this forum run the following:

Code:

bfgminer -S antminer:all -S erupter:all -S all --set-device antminer:clock=x0981 --icarus-options 115200:2:2 --icarus-timing 2.5=90 --weighed-stats

Either way, without making the resistor mods to provide more power to the ASIC chip, the above settings will eek out the maximum hash rate from the U1s

Also, if you run the above, and then do the keystroke S -> W -> ENTER to save the config file bfgminer.conf, then the bottom section should look a little like this:

Code:

"api-mcast-port" : "4028",
"api-port" : "4028",
"expiry" : "120",
"expiry-lp" : "3600",
"gpu-dyninterval" : "7",
"log" : "5",
"no-pool-disable" : true,
"no-show-processors" : true,
"no-show-procs" : true,
"no-unicode" : true,
"queue" : "22",
"scan-time" : "60",
"skip-security-checks" : "0",
"submit-stale" : true,
"temp-hysteresis" : "3",
"shares" : "0",
"kernel-path" : "D:/MinGW/msys/1.0/local/share/bfgminer",
"scan" : [
	"antminer:all",
	"erupter:all",
	"all"
],
"set-device" : [
	"antminer:clock=x0981"
],
"icarus-options" : "115200:2:2",
"icarus-timing" : "2.5=90"
}

and then you can just run the BFGminer application by itself without all the command line options because the conf file will load all the settings

Hope this helps.

I have been running my U1's with just the first part of that command line and they are working but I was wondering if there was any way to tweak them so their production would be more stable. I'm curious about the last switches in those command lines and what they do. specifically the Icarus options and Icarus timing switches. I hadn't seen those before.  I see in the config file you are running a queue of 22 but perhaps you are running many more units and or have more power than I am running. I know I don't want to have the miners waiting for work but is there any issue with setting the queue too high? ie stale work etc?

The icarus settings are for block erupters.  When I dropped them when I sold my last erupter, BFGMiner started reported proper hashing rates in all columns, not just in the one calculated from your accepted/rejected shares.

[1714258807]

1714258807

[ScaryHash]

Damn, that guy have slightly more than 1000 times of what my rig is doing...  Must be running a data center somewhere...

With the latest 28nm ASIC's I've seen machines slightly larger than the current cubes capable of 7.5 T H/s I'm hoping / trying to obtain one of these... possibly the little brother of this beast if that is what I can get accomplished. Then I can join the ranks of the serious bitcoin miners..... my measly 6 ghash setup (soon to be 12) is envious of such power to say the least.

TRN1062 1B3rJa8jAHhCK6nuRQEfYWz4bDiCsbR5P3
 

It takes time. When I started, I think it was May of 2013, I had a whopping 600 Mh/s...hahaha.

After much trial and error, and a lot of learning, I'm at 0.0217% of Eligius. Whooo !

[rmolby]

I have seen another user further back in this forum run the following:

Code:

bfgminer -S antminer:all -S erupter:all -S all --set-device antminer:clock=x0981 --icarus-options 115200:2:2 --icarus-timing 2.5=90 --weighed-stats

I have been running my U1's with just the first part of that command line and they are working but I was wondering if there was any way to tweak them so their production would be more stable. I'm curious about the last switches in those command lines and what they do. specifically the Icarus options and Icarus timing switches. I hadn't seen those before.  I see in the config file you are running a queue of 22 but perhaps you are running many more units and or have more power than I am running. I know I don't want to have the miners waiting for work but is there any issue with setting the queue too high? ie stale work etc?

You can absolutely run without the Icarus settings, I am using them because it makes the BEs run absolutely rock stable in my configuration. I have tried without and the stats are correct, but the BEs run at fluctuating speeds and quit working after just a few hours. When I run with the Icarus settings, I can run for up to 6 days straight before I have to restart BFGminer.

Once I start relegating the BEs to mining some of the other SHA-256 coin, I will be dropping the Icarus settings as well.

As for the Queue of 22, I didn't set the setting and left it running for 3-4 hours, and then checked to see what the queue had grown to, and it was at 22, so I set it specifically to 22, and I sometimes see it go to 24 or 26.

[helmax]

any news about patch kncminer ?

[ronin4bits]

any news about patch kncminer ?

He's coded a special ver of cgminer AND provides a special port for you precious little device...

{Ignore you now}

[NecroBones]

"250.19174185 BTC are ahead in queue, putting this user's payout after a 10 block delay."

This has been happening a lot this week. Have the payout delays gone up since the trouble last weekend?

[gorgatron]

any news about patch kncminer ?

I won't go so far as to ignore you after this (lol - though the fact ronin4bits is doing so is amusing), but I would point you to the following site that will answer such questions without you having to post them here. Just go to Eligius.st, and you'll see a little box there with info for KnC users. One f my units is an October batch Mercury (Yes, I'm no high roller), and I was able to connect to Eligius using the same port as I do with my BFL miners. no issues at all. If you have an October batch and are running firmware 0.99 or higher, bfgminer is included, and you shouldn't need a special version of cgminer. I was running firmware 0.98 w/ BertMod and bfgminer enabled, and got in just fine, and noticed no worse performance than at other pools. If you have a November machine, it too should have bfgminer built in, but I do not know if there may have been other issues. At any rate, right on the homepage there is info for KnC users. Go read it. It is helpful, and reading is generally good for keeping the mind sharp. Good luck out there!

[gorgatron]

"250.19174185 BTC are ahead in queue, putting this user's payout after a 10 block delay."

This has been happening a lot this week. Have the payout delays gone up since the trouble last weekend?

I've noticed something similar, though not too much more extreme than what I had experienced before things went to hell a little. My first payout after things went back to 'normal' was only a few blocks behind, and the payout came not too long after it should have. Today, it's a little different. I started out way down on the list, and then move up a few hundred sports over the course of 3-4 hours. Before replying to your post, I checked once more, and I've dropped another 30 spots or so. As I mention in a response posted just before this one, I don't receive large payouts, so it's not a big deal to me if I receive the standard payout right on time, or a larger one several hours later. That said, I do notice what you're talking about, and can see where it might be an issue for some. Since the amounts seem right (I have not doubts there), I'd rather be able to see what's going on and know a late payout is coming, as opposed to flying blind and not knowing, despite the fact that I've not had any problems with payouts during the 'troubles.' ~256 BTC does seem to put you on quite a long list, though. Fortunately the order isn't static, and there's a good chance you'll receive your payout before making your way up the list one payout at a time. Still, I'd also be curious to know if this is simply an aftereffect of all the work that had to be undertaken by WK to get the pool and feature back to a state to keep assholes from yelling 'scam!' like so many fucktards on these boards so often do.

[brox]

I am mining at eligius with BFL 60GH/s miner. Usually (several months, actually) it averages to 60.7 GH/s, but starting last week it shows 59.9 GH/s
Anyone noticed something similar? If it was hardware issue like one core dead, I believe hashrate would decrease significantly more

[MrTeal]

I didn't notice it in the FAQ, but does the Maximum Reward line in the graph represent the 100% PPS earnings? Should the pool go on a run of faster blocks and clear its payout queue, will the unpaid + everpaid line reach the max reward line?

[proclivity]

"250.19174185 BTC are ahead in queue, putting this user's payout after a 10 block delay."

This has been happening a lot this week. Have the payout delays gone up since the trouble last weekend?

I've noticed something similar, though not too much more extreme than what I had experienced before things went to hell a little. My first payout after things went back to 'normal' was only a few blocks behind, and the payout came not too long after it should have. Today, it's a little different. I started out way down on the list, and then move up a few hundred sports over the course of 3-4 hours. Before replying to your post, I checked once more, and I've dropped another 30 spots or so. As I mention in a response posted just before this one, I don't receive large payouts, so it's not a big deal to me if I receive the standard payout right on time, or a larger one several hours later. That said, I do notice what you're talking about, and can see where it might be an issue for some. Since the amounts seem right (I have not doubts there), I'd rather be able to see what's going on and know a late payout is coming, as opposed to flying blind and not knowing, despite the fact that I've not had any problems with payouts during the 'troubles.' ~256 BTC does seem to put you on quite a long list, though. Fortunately the order isn't static, and there's a good chance you'll receive your payout before making your way up the list one payout at a time. Still, I'd also be curious to know if this is simply an aftereffect of all the work that had to be undertaken by WK to get the pool and feature back to a state to keep assholes from yelling 'scam!' like so many fucktards on these boards so often do.

I also noticed the same, but I believe it's due to luck and timing.. as in a good string of luck will accelerate payment, a bad string of luck will shelve shares and delay the next payment.

[lightfoot]

I also noticed the same, but I believe it's due to luck and timing.. as in a good string of luck will accelerate payment, a bad string of luck will shelve shares and delay the next payment.

Is that it? I've noticed over the last month or so that although variance on the pool is low, payout variance seems to be all over the place. Granted I'm only a 220gh setup here, but I have seen the payouts being delayed.

Perhaps it's the impact of very large miners?

C

[baddw]

I also noticed the same, but I believe it's due to luck and timing.. as in a good string of luck will accelerate payment, a bad string of luck will shelve shares and delay the next payment.

Is that it? I've noticed over the last month or so that although variance on the pool is low, payout variance seems to be all over the place. Granted I'm only a 220gh setup here, but I have seen the payouts being delayed.

Perhaps it's the impact of very large miners?

C

It looks like there were/are several large miners waiting for payout.  Last night when I checked, there was at least one miner waiting for over 30BTC of payout (including one whole block to himself), and several others in the 10+ BTC range. 

Payouts are more random/variable than earnings because every user can set their own payout threshold, which mostly scales up depending on hashrate.  If I were running 100TH then I wouldn't want to be paid out every 0.04 BTC.  But if I were running 60GH then of course 0.04 BTC is a reasonable payout threshold. 

I think most people probably set theirs for every 12-24 hours.  In any case, some of the high rollers have relatively high payout thresholds (which makes perfect sense), and when those are hit then it takes a while to clear them out.

[proclivity]

I am mining at eligius with BFL 60GH/s miner. Usually (several months, actually) it averages to 60.7 GH/s, but starting last week it shows 59.9 GH/s
Anyone noticed something similar? If it was hardware issue like one core dead, I believe hashrate would decrease significantly more

Check out this thread for more details - sounds like 3 less cores are enabled if you dropped that much.

https://bitcointalk.org/index.php?topic=258643.0

[cobra.btc]

Dears,

I've got some questions during my mining for a long while, it would be great if I can get the answer form here.

I have several blades which get connection with Eligius pool via independence miner proxy, and I use the same wallet without separating them into individual worker.
And I made my own SW to calculate my total hashrate from each proxy, however, there is always 10% ~ 20% gap between my calculation and my status in pool.
The bigger hash power I have, comes with the bigger gap.

Is there anyone has same issue as me or is there anything I can do for  improvement?
Thank you.

[un_ordinateur]

I didn't notice it in the FAQ, but does the Maximum Reward line in the graph represent the 100% PPS earnings? Should the pool go on a run of faster blocks and clear its payout queue, will the unpaid + everpaid line reach the max reward line?

Yes... And no.

Each time you submit a share, the pool records it in the share log, at it's straight PPS value. When a block is found, 25 BTC worth of shares (starting from the most recent) are paid.

If the pool is unlucky, and it took more shares than average to find the block, some of the shares submitted for that block cannot be paid (since the pool does not have the money to cover them). The pool "remembers" those shares; they are shelved.

If the pool gets lucky, and it took less shares than average to find a block, pool will have some BTC left after paying every share submitted for that block. It will therefore pay whats left to the most recent shelved shares.


However, paying everybody like that in every block would be a problem: First, small miners would only get micropayments in every block; and it would be dust that accumulates in their wallet (and increases their fees when they use the coins). Second, some clients have a bug in which that cannot support a too big amount of outputs per transaction. (Doing payments like that in Eligius would cause more than 5000 output per transaction)

Therefore, Eligius implements a sort of tradeoff. Instead of directly paying the shares when they are found; it internally computes which shares are to be paid, and which shares are not (yet), without actually sending the money to the miner. Instead, it holds onto them until a given amount is accumulated (chosen by the miner), at which time the pool will send the coins.

Therefore, it means that even if the pool were to empty it's payout queue, it does not mean that everybody's shares ever submitted have been paid. It does mean, however, that nobody has accumulated enough rewarded-but-unpaid shares to be paid. (In those cases, the pool sends the block reward to an offline wallet, from which the miners will be paid when the payout queue gets long enough.)


Thus, about the graphs and stats:
The everpaid line is amount of BTC the pool has ever sent to you.
The unpaid+everpaid line is that amount, plus the value of all the shares the pool has rewarded to you, but has not set the actual money yet, because you have not met your treshold. (the unpaid amount is the amount marked in the "unpaid balance" in the table above the graph)
The maximum reward line is the total value of all the shares you ever submitted to the pool, including those it does not have the funds to pay yet.

If the pool gets lucky, "unpaid+everpaid" will get closer to "maximum reward", and may even touch it. However, they would not "meet" at the same time for all users, depending when that user joined. Most recent shelved shares being paid first, the pool would have to be lucky a lot longer to pay all the way back to 2012, when the pool began, than to pay all the shares of somebody who started one month ago.


However, nobody's payment will ever go above "maximum reward": once all your shares have been paid, all the extra coins go to paying other who have to yet been fully paid. Finally even if the pool were to clear it's whole backlog, then it would hold onto the extra coins until less lucky times. (in any case, such event would be extremely unlikely: In the beginning, Eligius suffered from pretty severe bad luck, and thus has accumulated an hefty amount of unpaid shares. According to my calculations, the pool has acumulated over 2800 BTC worth of unpaid shares, which means it would need to find something like 112 blocks RIGHT NOW to pay them all)

[un_ordinateur]

the pool has acumulated over 2800 BTC worth of unpaid shares

However, note that over the same period, the pool has rewarded over 113 650 BTC, meaning that unpaid shares represent less that 2.5% of the pool earnings.

The unpaid shares accrued since the beginning of 2013 represent less that 2% of the pool earnings since then. And the pool was lucky since november, since, on average, all of the shares accrued since then have been paid.

[MrTeal]

I didn't notice it in the FAQ, but does the Maximum Reward line in the graph represent the 100% PPS earnings? Should the pool go on a run of faster blocks and clear its payout queue, will the unpaid + everpaid line reach the max reward line?

Yes... And no.

Each time you submit a share, the pool records it in the share log, at it's straight PPS value. When a block is found, 25 BTC worth of shares (starting from the most recent) are paid.

If the pool is unlucky, and it took more shares than average to find the block, some of the shares submitted for that block cannot be paid (since the pool does not have the money to cover them). The pool "remembers" those shares; they are shelved.

If the pool gets lucky, and it took less shares than average to find a block, pool will have some BTC left after paying every share submitted for that block. It will therefore pay whats left to the most recent shelved shares.


However, paying everybody like that in every block would be a problem: First, small miners would only get micropayments in every block; and it would be dust that accumulates in their wallet (and increases their fees when they use the coins). Second, some clients have a bug in which that cannot support a too big amount of outputs per transaction. (Doing payments like that in Eligius would cause more than 5000 output per transaction)

Therefore, Eligius implements a sort of tradeoff. Instead of directly paying the shares when they are found; it internally computes which shares are to be paid, and which shares are not (yet), without actually sending the money to the miner. Instead, it holds onto them until a given amount is accumulated (chosen by the miner), at which time the pool will send the coins.

Therefore, it means that even if the pool were to empty it's payout queue, it does not mean that everybody's shares ever submitted have been paid. It does mean, however, that nobody has accumulated enough rewarded-but-unpaid shares to be paid. (In those cases, the pool sends the block reward to an offline wallet, from which the miners will be paid when the payout queue gets long enough.)


Thus, about the graphs and stats:
The everpaid line is amount of BTC the pool has ever sent to you.
The unpaid+everpaid line is that amount, plus the value of all the shares the pool has rewarded to you, but has not set the actual money yet, because you have not met your treshold. (the unpaid amount is the amount marked in the "unpaid balance" in the table above the graph)
The maximum reward line is the total value of all the shares you ever submitted to the pool, including those it does not have the funds to pay yet.

If the pool gets lucky, "unpaid+everpaid" will get closer to "maximum reward", and may even touch it. However, they would not "meet" at the same time for all users, depending when that user joined. Most recent shelved shares being paid first, the pool would have to be lucky a lot longer to pay all the way back to 2012, when the pool began, than to pay all the shares of somebody who started one month ago.


However, nobody's payment will ever go above "maximum reward": once all your shares have been paid, all the extra coins go to paying other who have to yet been fully paid. Finally even if the pool were to clear it's whole backlog, then it would hold onto the extra coins until less lucky times. (in any case, such event would be extremely unlikely: In the beginning, Eligius suffered from pretty severe bad luck, and thus has accumulated an hefty amount of unpaid shares. According to my calculations, the pool has acumulated over 2800 BTC worth of unpaid shares, which means it would need to find something like 112 blocks RIGHT NOW to pay them all)

Thanks, that's exactly what I was looking for. I suppose I could have asked if maximum reward is unpaid+everpaid+shelved, which is what seems to be the case.

I understand the general concept, with shares being stored and every time a block is found the most recent 25BTC worth of shares are paid.

Am I correct in my understanding that there are two separate queues, one for the shares and one for payouts? As shares are received, they are added to the share queue and each time a block is found 25BTC worth of shares are removed from the share queue and are are marked as unpaid balance. When your unpaid balance exceeds the minimum threshold, you enter the payout queue which is paid oldest accounts first. If this is the case, why is the payout queue so long (currently 525BTC) if the funds are all available to pay out those shares? Is it just that a portion is held in the offline wallet and to flush the payment queue would take a manual transaction?

Also, is there a place to view the current number and value of shelved shares?

[fireman50]

I'm hoping someone can help me with merged mining.  I cannot get the signature to pass when I add my nmc address.  I've used multiple programs to sign and verify including mtgox, bitcoin-qt, electrum, and just about every other app out there.  The sig passes on the application but fails on the website and I've even manually typed in every character rather than copy/paste and it still fails.  What am I doing wrong ?

[MrTeal]

I'm hoping someone can help me with merged mining.  I cannot get the signature to pass when I add my nmc address.  I've used multiple programs to sign and verify including mtgox, bitcoin-qt, electrum, and just about every other app out there.  The sig passes on the application but fails on the website and I've even manually typed in every character rather than copy/paste and it still fails.  What am I doing wrong ?

Are you sure you selected the correct address to sign with?