 Show Posts
|
|
Pages: [1] 2 3 4 5 »
|
|
2
|
Bitcoin / Pools / Re: [100 TH] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested
|
on: December 02, 2013, 04:27:38 PM
|
21012 2013-12-01 06:42:52 2:36:50 822353445 235376 0.00659462 272440 25.04495605
21011 2013-12-01 04:06:02 0:34:20 181000803 48822 0.00715762 272413 25.11093992
21010 2013-12-01 03:31:42 1:59:40 639039598 171289 0.00651526 272410 25.14099989
21009 2013-12-01 01:32:02 0:04:19 22915150 5768 0.00608615 272399 25.03550690
21008 2013-12-01 01:27:43 0:50:06 265077329 70864 0.00605277 272398 25.02827623
21007 2013-12-01 00:37:37 7:48:38 2147483647 none none 272385 25.20690867
Fix this please!
Just to wrap up: this issue has been fixed - I have the impression there was a recalculation with proportional method. Kudos go to the pool operators. Regards, T |
|
|
|
|
3
|
Bitcoin / Pools / Re: [100 TH] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested
|
on: December 01, 2013, 11:10:51 AM
|
|
For some (including me) shares/reward for round 21007 still show 'none'. I have seen recalculations/fixes in the past before the block is confirmed, but currently there are only 11 confirmations left...
21007 2013-12-01 00:37:37 7:48:38 2147483647 none none 272385 25.20690867 11 confirmations left
This is the block where the total number of shared might have overflowed a 32bit integer - this is only speculation, but the total of shares is shown as exactly 231-1.
After my post on this issue last night and sending a PM within this forum, I was patiently waiting for this to get fixed, but now I have also sent a mail to pool operators and hope they will take action.
Regards,
T
|
|
|
|
|
4
|
Bitcoin / Pools / Re: [100 TH] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested
|
on: December 01, 2013, 02:16:34 AM
|
21007 2013-12-01 00:37:37 7:48:38 2147483647 none none 272385 25.20690867 83 confirmations left
What??? i'm trying out block erupter usb sticks and it's fairly consistant until that block... ' none ' when even if i'm sooo slow at just over 1.00 gHash/sec for it to actualy be of value after 7 hours, it should NOT say ' none '
For Perspective...
21009 2013-12-01 01:32:02 0:04:19 22915150 71 0.00007444 272399 25.03550690 97 confirmations left
21008 2013-12-01 01:27:43 0:50:06 265077329 695 0.00006535 272398 25.02827623 96 confirmations left
21007 2013-12-01 00:37:37 7:48:38 2147483647 none none 272385 25.20690867 83 confirmations left
21006 2013-11-30 16:48:59 0:47:42 251032842 670 0.00005810 272318 25.03404462 16 confirmations left
21005 2013-11-30 16:01:17 0:36:01 189004238 476 0.00006833 272313 25.07062858 11 confirmations left
21004 2013-11-30 15:25:16 2:20:08 739833931 1961 0.00007462 272307 25.18938665 5 confirmations left
21003 2013-11-30 13:05:08 0:57:13 308486793 819 0.00006235 272288 25.25633454 confirmed
21002 2013-11-30 12:07:55 1:07:11 355945193 916 0.00005303 272284 25.04851601 confirmed
21001 2013-11-30 11:00:44 1:03:22 328906191 858 0.00006505 272271 25.01071321 confirmed
21000 2013-11-30 09:57:22 1:17:49 406216337 1069 0.00006336 272260 25.12306089 confirmed
20999 2013-11-30 08:39:33 0:28:41 150222160 398 0.00006666 272255 25.24613312 confirmed
20998 2013-11-30 08:10:52 1:38:52 518634435 1401 0.00006232 272251 25.28002503 confirmed
20997 2013-11-30 06:32:00 0:54:52 287744552 740 0.00006716 272242 25.02774408 confirmed
Reading the two posts immediately before yours might give you some idea about this phenomenon. This seems to be affecting many of us. |
|
|
|
|
5
|
Bitcoin / Pools / Re: [100 TH] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested
|
on: December 01, 2013, 01:24:30 AM
|
|
I have the impression something is strange in the way shares are counted (or displayed) for very long rounds at current difficulty. Let us see the data:
block 272385, duration 7:48:38, number of shares: 2147483647
block 272149, duration 7:04:27, number of shares: 2147483647
It is rather improbable, but theoretically possible to get the exact same number of shares for these two rounds.
If you look at the number 2147483647 a bit closer, the situation looks even more suspicious.
2147483647 = 231-1
This should raise an alert to people familiar with programming...
It might be merely an issue of how data is displayed, or it might eventually be rooted in deeper layers which might or might not have other side effects.
Anyone any comment?
Cheers,
T
|
|
|
|
|
6
|
Bitcoin / Pools / Re: [100 TH] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested
|
on: November 27, 2013, 03:39:16 PM
|
Hi,
rewards for blocks 271745, 271726 and 271685 were zeroed out just a minute ago for me, wonder if anybody else experiences the same...
I am a bit concerned since 271685 has only 4 confirmations left to mature. I know there was some database migration recently, so I assume this is only a transient issue.
Anyone else?
Cheers,
T
As I see these blocks have been recalculated by now via proportional rewards (1 score per share), instead of the exponential slush method. |
|
|
|
|
7
|
Bitcoin / Pools / Re: [100 TH] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested
|
on: November 27, 2013, 03:31:46 PM
|
|
Hi,
rewards for blocks 271745, 271726 and 271685 were zeroed out just a minute ago for me, wonder if anybody else experiences the same...
I am a bit concerned since 271685 has only 4 confirmations left to mature. I know there was some database migration recently, so I assume this is only a transient issue.
Anyone else?
Cheers,
T
|
|
|
|
|
8
|
Bitcoin / Pools / Re: [117Th] Eligius: ASIC, no registration, no fee CPPSRB BTC + 105% PPS NMC, 877 #
|
on: October 14, 2013, 03:10:03 PM
|
i am new to this so please forgive if my questions are stupid or have been answered 100x before:
1) i have 6 miners (knc-hosted jupiters) running on eligius. when i check their individual speeds
2013/10/14 13:30: default: 578261.67 box21: 554642.53 box16: 578261.67 box17: 560343.7 box23: 612468.7 box22: 548941.36 675 seconds: 3.43e+6 this sums up to:
3430 Gh/s but they are running a total of less than 3200 . why is there a difference ?
2) in "shares rewarded" i get figures like 89,3 (as of last block) and 91,5 % (estimated total)
why not 100 % ?
thank you !
Take a look at this: http://eligius.st/~gateway/faq-page - it describes how reward is calculated on this pool and answers your second question (shelved shares). Hope this helps, T |
|
|
|
|
11
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: Swedish ASIC miner company kncminer.com
|
on: September 08, 2013, 09:06:32 AM
|
I like this, thanks! Battery back up is pretty cool. I wander how well that works. I bought this PSU: http://www.newegg.com/Product/Product.aspx?Item=N82E16817171078It was ~$50 cheaper when I got it. I think we're driving up the price. Edit: APC makes some really good power protection products. Problem is there are so many and I have no clue how to shop for one. I may give them a call to see which one would be best for a Jupiter or two. Also, no need for a battery back up now that I think of it. If your power goes out, so does your internet. With KNC products having internal mining software, how would this work? Does it keep trying to connect to the internet without intervention? I'm sure these questions can't be answered right away. So I'm going to wait on this purchase. Surge protectors are all we should need for now. that's not right. If your power goes out but both your modem and router are on a UPS as well, why would your internet go out? I am mining with network devices backed by a UPS as well and I do not loose internet during a power outage. At least as long as the UPS can feed the beasts. You will need a beefy server-grade one like a SmartUPS. Hope this helps, T |
|
|
|
|
13
|
Bitcoin / Pools / Re: [12000 GH/s] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested
|
on: August 31, 2013, 07:27:06 PM
|
Looks like blockchain.info is undergoing maintenance currently. Perhaps that is why blocks are showing up invalid? If Slush is using blockchain.info for verification (as it appears he might be), then this could be causing our invalid block issues. actually, the first 2 were invalid at a time when blockchain.info was still up. I wonder what mechanism they are using to pull the data from blockchain.info. If only part of the site was down, say the mechanism that feeds out block information, then it is possible this could have caused an error on the pool. Could also just be Slush's pool having some issues as well. I am very glad this is now fixed though. Actually, I am rather surprised to see those blocks valid on blockchain.info, then after an outage as orphaned, then later as valid again. What I saw there made me draw premature conclusions... I would not take if for granted that the pool uses blockchain.info services to decide if a block is valid (on the main chain, not orphaned) or not... AFAIK any bitcoin client can give you that information. |
|
|
|
|
14
|
Bitcoin / Pools / Re: [12000 GH/s] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested
|
on: August 31, 2013, 03:37:26 PM
|
Make that three invalid blocks in a row.
I would guess this is a sign of work being done in the background. I believe these blocks are not invalid but marked as such on the pool level (so they do not interfere with rewards), so the operator has some headroom to fix things. We can confirm this once blockchain.info gets back up again. Bockchain.info is back. My assumption was wrong, these blocks seem to be orphaned indeed. All 3. |
|
|
|
|
16
|
Bitcoin / Pools / Re: [12000 GH/s] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested
|
on: August 31, 2013, 03:33:56 PM
|
Make that three invalid blocks in a row.
I would guess this is a sign of work being done in the background. I believe these blocks are not invalid but marked as such on the pool level (so they do not interfere with rewards), so the operator has some headroom to fix things. We can confirm this once blockchain.info gets back up again. |
|
|
|
|
17
|
Bitcoin / Pools / Re: [12000 GH/s] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested
|
on: August 31, 2013, 10:29:38 AM
|
Well, it's back on but I got terribly shorted:
19826 2013-08-31 04:52:18 2:47:25 88406573 21795 0.00167814
Similar situation here 19826 2013-08-31 04:52:18 2:47:25 88406573 4316 0.00044992 Let's hope this will eventually be fixed. Payout is not happening as usual either (crossed my payout threshold more than an hour ago, and it's still there. Looks like Slush's attention is not on this pool, hope that he's well +1, seems this is a global issue. 49 confirmations left for the block to mature, so there is still some time to get it fixed. |
|
|
|
|
18
|
Bitcoin / Pools / Re: [12000 GH/s] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested
|
on: August 08, 2013, 05:42:45 AM
|
Sorry.. does butterflly lab support stratum mining/proxy? Thanks.
This is a rather basic question that does not really belong into this thread. You also failed to provide details on which product you mean. Please check here before posting the next question: http://www.catb.org/~esr/faqs/smart-questions.htmlI assume you are not talking about BFL minirig, but other products. They are connected to a computer via USB and you need a mining software on the computer to use them. The mining software communicates with the pool over the network (or with bitcoind when mining solo), and uses the BFL hardware to solve cryptographic tasks. The BFL hardware is not aware of what protocol your software uses, it just crunches numbers as directed by the software. You should check which protocols are supported by the mining software of your choice. You will find that both stratum and getwork are supported by practically all the miners. Make sure you read up on the topic - you could save yourself some frustration/headache. Cheers, T |
|
|
|
|
19
|
Bitcoin / Pools / Re: [12000 GH/s] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested
|
on: August 05, 2013, 12:59:12 PM
|
Frankly, it is not irrelevant when you mined. This pool uses a reward calculation method where the value of each share you submit is calculated as a function of time elapsed since the start of the round. score share = exp(t/C) where t is round duration in seconds, and C is a constant, currently 200. This means the value of each share is exponentially growing as time goes, so old share have significantly lower value compared to recent shares. If you stop mining while others don't, your part of total pool score for that round will decrease exponentially. This is public information, each pool publishes the method it uses to calculate rewards. You can read the original post about this reward calculation method here: https://bitcointalk.org/index.php?topic=1976.msg50002#msg50002. Unfortunately, many do not read before taking decisions and feel unjust afterwards. Hope the pointer helps to get started, T |
|
|
|
|
