Bitcoin Forum
August 18, 2017, 12:52:56 PM *
News: Latest stable version of Bitcoin Core: 0.14.2  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 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 »
  Print  
Author Topic: [OLD] Eligius: ASIC, no registration, no fee CPPSRB BTC + 105% PPS NMC, 877 #  (Read 444065 times)
NecroBones
Jr. Member
*
Offline Offline

Activity: 59

Mining hobbyist


View Profile
January 25, 2014, 04:52:25 AM
 #3881

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

I stopped using the icarus settings shown here. It throws off bfgminer's tracking of the average hash rates, plus I found that it reduced my actual work done by about 5%.

-NecroBones
1503060776
Hero Member
*
Offline Offline

Posts: 1503060776

View Profile Personal Message (Offline)

Ignore
1503060776
Reply with quote  #2

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

Posts: 1503060776

View Profile Personal Message (Offline)

Ignore
1503060776
Reply with quote  #2

1503060776
Report to moderator
1503060776
Hero Member
*
Offline Offline

Posts: 1503060776

View Profile Personal Message (Offline)

Ignore
1503060776
Reply with quote  #2

1503060776
Report to moderator
TRN1062
Jr. Member
*
Offline Offline

Activity: 49


View Profile
January 25, 2014, 06:39:09 AM
 #3882

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

I stopped using the icarus settings shown here. It throws off bfgminer's tracking of the average hash rates, plus I found that it reduced my actual work done by about 5%.

Thanks for the update.

Im currently trying to figure out how to buy my new rig... I need about 7 or 7.5 BTC as they only accept bitcoin for payment but I don't have any bitcoin currently and only have a credit card I wanted to make the purchase with.... Wish me luck

TRN1062 1B3rJa8jAHhCK6nuRQEfYWz4bDiCsbR5P3

1B3rJa8jAHhCK6nuRQEfYWz4bDiCsbR5P3
sconklin321
Member
**
Offline Offline

Activity: 109


View Profile
January 25, 2014, 03:38:08 PM
 #3883


+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.
ScaryHash
Hero Member
*****
Offline Offline

Activity: 528


View Profile
January 25, 2014, 08:20:04 PM
 #3884

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
Member
**
Offline Offline

Activity: 75


View Profile
January 25, 2014, 10:58:42 PM
 #3885

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
Sr. Member
****
Offline Offline

Activity: 428



View Profile
January 26, 2014, 08:59:38 AM
 #3886

any news about patch kncminer ?

looking job
ronin4bits
Jr. Member
*
Offline Offline

Activity: 59


View Profile
January 26, 2014, 01:09:02 PM
 #3887

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
Jr. Member
*
Offline Offline

Activity: 59

Mining hobbyist


View Profile
January 27, 2014, 04:43:12 AM
 #3888


"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?

-NecroBones
gorgatron
Member
**
Offline Offline

Activity: 110


View Profile
January 27, 2014, 06:45:16 AM
 #3889

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
Member
**
Offline Offline

Activity: 110


View Profile
January 27, 2014, 06:56:55 AM
 #3890


"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
Member
**
Offline Offline

Activity: 71



View Profile
January 27, 2014, 01:09:30 PM
 #3891

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

Save dolphins! Donate to 1BTC4brox2pd14QubXGsXwarp9zV9tc8CZ
Mine Bitcoins in the cloud at cex.io
MrTeal
Legendary
*
Offline Offline

Activity: 1274


View Profile
January 27, 2014, 02:33:37 PM
 #3892

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
Member
**
Offline Offline

Activity: 67


View Profile
January 27, 2014, 04:16:20 PM
 #3893


"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.

For tips only - 12QT6zPJM5kQ5piZfn7tyFfcJrbgvSnMLn
lightfoot
Legendary
*
Online Online

Activity: 1246

I fix broken miners. And make holes in teeth :-)


View Profile
January 27, 2014, 04:20:43 PM
 #3894

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
Sr. Member
****
Offline Offline

Activity: 383


View Profile
January 27, 2014, 04:47:54 PM
 #3895

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.

BTC/XCP 11596GYYq5WzVHoHTmYZg4RufxxzAGEGBX
DRK XvFhRFQwvBAmFkaii6Kafmu6oXrH4dSkVF
Eligius Payouts/CPPSRB Explained  I am not associated with Eligius in any way.  I just think that it is a good pool with a cool payment system Smiley
proclivity
Member
**
Offline Offline

Activity: 67


View Profile
January 27, 2014, 05:37:27 PM
 #3896

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

For tips only - 12QT6zPJM5kQ5piZfn7tyFfcJrbgvSnMLn
cobra.btc
Newbie
*
Offline Offline

Activity: 1


View Profile
January 27, 2014, 06:34:43 PM
 #3897

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
Full Member
***
Offline Offline

Activity: 157


View Profile
January 27, 2014, 07:50:24 PM
 #3898

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
Full Member
***
Offline Offline

Activity: 157


View Profile
January 27, 2014, 08:14:41 PM
 #3899

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
Legendary
*
Offline Offline

Activity: 1274


View Profile
January 27, 2014, 08:29:47 PM
 #3900

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?
Pages: « 1 ... 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 »
  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!