Bitcoin Forum
April 27, 2018, 01:22:49 AM *
News: Latest stable version of Bitcoin Core: 0.16.0  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Poll
Question: What type of pool payouts do you prefer?
Bitcoins - 3229 (80.4%)
Bank transfer / USD - 415 (10.3%)
Gold/silver coins and bars - 371 (9.2%)
Total Voters: 4013

Pages: « 1 ... 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 [1036] 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 ... 1140 »
  Print  
Author Topic: [2.5+ EH] Slush Pool (slushpool.com); World's First Mining Pool  (Read 4326006 times)
kkurtmann
Sr. Member
****
Offline Offline

Activity: 475
Merit: 250



View Profile WWW
March 03, 2015, 05:14:29 AM
 #20701

I just started mining but been adding S3+'s, S5's and Sp20's to my rig. Still a baby setup compare dot you guys though. LOL

I do have to chime in though, I don't see the possibility of a 0.03-0.05 watt / GH possibility. Even if it's in a 100Th setup. No way, no how, with today's technology.
Only way is to do a hybrid of alternate Energy + grid power.


I'm pretty sure he was talking about the supposed next gen 16 nm or smaller technology as per the efficiency quote.

Still. I somehow doubt they have more efficient engineers than Intel or ATI/AMD, IBM, and even they have not reached such low power figures.

I just don't see it.. This next gen releases will probably be in the 0.30W/GH power figure, maybe high 20's if they really get some good dies made.

Besides if that becomes true. It will highly impact the BC Mining world and I don't think in a good way for smaller miners.  Grin

Well, KnC miner claims achieving 0.07 w/GHs for their new 16nm on their website here https://www.kncminer.com/news/news-118 . I'm sure other manufacturers will make the same or better claims. This is old news that companies have been working on this, but I'm pretty sure there won't be any physical devices until the end of this year at the earliest. 

https://www.buytrezor.com?a=55c37b866c11   well sir, I like it!
1524792169
Hero Member
*
Offline Offline

Posts: 1524792169

View Profile Personal Message (Offline)

Ignore
1524792169
Reply with quote  #2

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

Posts: 1524792169

View Profile Personal Message (Offline)

Ignore
1524792169
Reply with quote  #2

1524792169
Report to moderator
1524792169
Hero Member
*
Offline Offline

Posts: 1524792169

View Profile Personal Message (Offline)

Ignore
1524792169
Reply with quote  #2

1524792169
Report to moderator
1524792169
Hero Member
*
Offline Offline

Posts: 1524792169

View Profile Personal Message (Offline)

Ignore
1524792169
Reply with quote  #2

1524792169
Report to moderator
bspurloc
Hero Member
*****
Offline Offline

Activity: 569
Merit: 500


View Profile
March 03, 2015, 03:20:24 PM
 #20702

The last 2 firmware updates do not work with my S3's.  Even after doing the updates in order.  F/W 5 & 6 create a 500 error on the miner status page and although the lights flash and they belch hot air there is no mining.  Reverted to F/W 4 and mining happily again.

what is the actual mindset that updates have to be installed in order when all an update is is a replacement of the OS, so a previous patch should have absolutely no mind of what was on the machine before, as the previous gets completely wiped out.

I haven't been following but the only way a previous could hinder a new one is if there is an actual mod being done to the chips which I am pretty sure there are no programmable chips on these. It all sounds to me like the newer versions are flakey and people are trying to find something to blame.
  I have all mine left alone and mining till they die. haven't touched them in 3 months. just letting everything wind down, got tired of chasing new hardware! never mind bitmain adding huge shipping and handling fees soured the taste of their equipment.
have spondoolies become more quiet yet?
 
pekatete
Hero Member
*****
Offline Offline

Activity: 518
Merit: 500



View Profile WWW
March 03, 2015, 03:33:15 PM
 #20703

what is the actual mindset that updates have to be installed in order when all an update is is a replacement of the OS, so a previous patch should have absolutely no mind of what was on the machine before, as the previous gets completely wiped out.

My thoughts exactly ... to an extent.

.... but the only way a previous could hinder a new one is if there is an actual mod being done to the chips which I am pretty sure there are no programmable chips on these. ....

You'd be wrong because the controller board has a programable chip, and the PIC firmware is uploaded on each cold boot (not sure about a restart). I am actually convinced that this is where bitmain fudge things up, as the PIC firmware is obfuscated and no source code available. I have tried dis-assembling the firmware with no positive results as there are only so many hours in a day!

However, I believe the subsequent changes to the PIC firmware are to blame for the sporadic results with the latter firmware, so the logic would be the reverse of sequentially installing updates as the last firmware update wipes the lot off (as you correctly state)!

bigbitmine
Full Member
***
Offline Offline

Activity: 210
Merit: 100


Big Bit Mine


View Profile
March 03, 2015, 08:45:34 PM
 #20704

what is the actual mindset that updates have to be installed in order when all an update is is a replacement of the OS, so a previous patch should have absolutely no mind of what was on the machine before, as the previous gets completely wiped out.

My thoughts exactly ... to an extent.

.... but the only way a previous could hinder a new one is if there is an actual mod being done to the chips which I am pretty sure there are no programmable chips on these. ....

You'd be wrong because the controller board has a programable chip, and the PIC firmware is uploaded on each cold boot (not sure about a restart). I am actually convinced that this is where bitmain fudge things up, as the PIC firmware is obfuscated and no source code available. I have tried dis-assembling the firmware with no positive results as there are only so many hours in a day!

However, I believe the subsequent changes to the PIC firmware are to blame for the sporadic results with the latter firmware, so the logic would be the reverse of sequentially installing updates as the last firmware update wipes the lot off (as you correctly state)!

Although the S3's are reverted to original F/W and operating perfectly well again one does like to beep every now and then indicating it has briefly lost connection.  Not really bothered by it so I won't be messing with it again.

SargeR33
Member
**
Offline Offline

Activity: 112
Merit: 10

★Bitin.io★ - Instant Exchange


View Profile
March 04, 2015, 06:31:32 AM
 #20705

I used to get random beeping and very slow cpanel access with particular firmwares on the S3. I can't recall which I'm using now but I found it is the best of the lot.

alh
Legendary
*
Offline Offline

Activity: 1512
Merit: 1002


View Profile
March 04, 2015, 06:11:55 PM
 #20706

Looks like the "0% luck for a day" has finally come to a close at 27+ hours. That was BRUTAL!!!!
MrTeal
Legendary
*
Offline Offline

Activity: 1274
Merit: 1000


View Profile
March 04, 2015, 07:09:05 PM
 #20707

Looks like the "0% luck for a day" has finally come to a close at 27+ hours. That was BRUTAL!!!!
I don't think it's luck. There's a pretty consistent pattern there where we have bad luck for that block if the pool hashrate is (10 + n*0.23-n)PH/s, where n is any positive integer. The block at 10.23PH/s was 20.5 hours, and the one at 10.45PH/s was over a full day. Lord knows what would happen if we actually hit 10.67PH/s, it could be a couple day long block.

I hope slush looks into this and can find the error in his code. These long blocks need to stop.
musicmaker613
Member
**
Offline Offline

Activity: 93
Merit: 10


View Profile
March 05, 2015, 03:36:31 AM
 #20708

Looks like the "0% luck for a day" has finally come to a close at 27+ hours. That was BRUTAL!!!!
I don't think it's luck. There's a pretty consistent pattern there where we have bad luck for that block if the pool hashrate is (10 + n*0.23-n)PH/s, where n is any positive integer. The block at 10.23PH/s was 20.5 hours, and the one at 10.45PH/s was over a full day. Lord knows what would happen if we actually hit 10.67PH/s, it could be a couple day long block.

I hope slush looks into this and can find the error in his code. These long blocks need to stop.

I know others had postulated that the pool was has having trouble "handling" over 10 PH, but you're suggesting there could be an error related to or caused by the formula you provided?  Seems unlikely to me, as there is nothing obviously significant about the formula or the resulting numbers AND the fact that the pool hashrate is just an estimate of the total scoring hashrate (representing a rather wide range of numbers in terms of even GH (10^9 hashes per second) and rounded to the nearest 10^10).  I guess my point would be the pool's scoring hashrate is too arbitrary of a number to likely be responsible for a glitch in the pool, if that makes sense.

My guess is just coincidence and occasional long blocks due to bad luck.  Recent days have done a lot to disprove the original hypothesis of the pool being unable to handle hashrates above 10 PH, as the last couple of days have seen several blocks found over 10 PH AND 100% luck.  Here's hoping the same will continue to happen.

My question is, where did 1 entire petahash suddenly appear from...?  ~10.45 to 11.45!

SYS: SjFeMefQpgCRWuwRdiN3Hf8V6CkocV3Xdq
DOGE: DG4EwxvNCM5YFBQ8xo7pkEua2Nf1jRMmQg
bigbitmine
Full Member
***
Offline Offline

Activity: 210
Merit: 100


Big Bit Mine


View Profile
March 05, 2015, 03:51:34 AM
 #20709

Looks like the "0% luck for a day" has finally come to a close at 27+ hours. That was BRUTAL!!!!
I don't think it's luck. There's a pretty consistent pattern there where we have bad luck for that block if the pool hashrate is (10 + n*0.23-n)PH/s, where n is any positive integer. The block at 10.23PH/s was 20.5 hours, and the one at 10.45PH/s was over a full day. Lord knows what would happen if we actually hit 10.67PH/s, it could be a couple day long block.

I hope slush looks into this and can find the error in his code. These long blocks need to stop.

I know others had postulated that the pool was has having trouble "handling" over 10 PH, but you're suggesting there could be an error related to or caused by the formula you provided?  Seems unlikely to me, as there is nothing obviously significant about the formula or the resulting numbers AND the fact that the pool hashrate is just an estimate of the total scoring hashrate (representing a rather wide range of numbers in terms of even GH (10^9 hashes per second) and rounded to the nearest 10^10).  I guess my point would be the pool's scoring hashrate is too arbitrary of a number to likely be responsible for a glitch in the pool, if that makes sense.

My guess is just coincidence and occasional long blocks due to bad luck.  Recent days have done a lot to disprove the original hypothesis of the pool being unable to handle hashrates above 10 PH, as the last couple of days have seen several blocks found over 10 PH AND 100% luck.  Here's hoping the same will continue to happen.

My question is, where did 1 entire petahash suddenly appear from...?  ~10.45 to 11.45!

Please!!!  Not the 10PH argument again.

kano
Legendary
*
Offline Offline

Activity: 2436
Merit: 1039


Linux since 1997 RedHat 4


View Profile
March 05, 2015, 05:11:47 AM
 #20710

Looks like the "0% luck for a day" has finally come to a close at 27+ hours. That was BRUTAL!!!!
I don't think it's luck. There's a pretty consistent pattern there where we have bad luck for that block if the pool hashrate is (10 + n*0.23-n)PH/s, where n is any positive integer. The block at 10.23PH/s was 20.5 hours, and the one at 10.45PH/s was over a full day. Lord knows what would happen if we actually hit 10.67PH/s, it could be a couple day long block.

I hope slush looks into this and can find the error in his code. These long blocks need to stop.
I get the feeling people took your comment seriously Cheesy

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 2058
Merit: 1000


Poor impulse control.


View Profile WWW
March 05, 2015, 05:32:44 AM
 #20711

Looks like the "0% luck for a day" has finally come to a close at 27+ hours. That was BRUTAL!!!!
I don't think it's luck. There's a pretty consistent pattern there where we have bad luck for that block if the pool hashrate is (10 + n*0.23-n)PH/s, where n is any positive integer. The block at 10.23PH/s was 20.5 hours, and the one at 10.45PH/s was over a full day. Lord knows what would happen if we actually hit 10.67PH/s, it could be a couple day long block.

I hope slush looks into this and can find the error in his code. These long blocks need to stop.
I get the feeling people took your comment seriously Cheesy

The devil made him do it.

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
musicmaker613
Member
**
Offline Offline

Activity: 93
Merit: 10


View Profile
March 05, 2015, 05:37:24 AM
 #20712

Looks like the "0% luck for a day" has finally come to a close at 27+ hours. That was BRUTAL!!!!
I don't think it's luck. There's a pretty consistent pattern there where we have bad luck for that block if the pool hashrate is (10 + n*0.23-n)PH/s, where n is any positive integer. The block at 10.23PH/s was 20.5 hours, and the one at 10.45PH/s was over a full day. Lord knows what would happen if we actually hit 10.67PH/s, it could be a couple day long block.

I hope slush looks into this and can find the error in his code. These long blocks need to stop.
I get the feeling people took your comment seriously Cheesy

I know MrTeal's been around on the block for a while.  I trusted it was "tongue-in-cheek".  Doesn't change the fact that I'm a sucker for talking about formulas and numbers  Smiley

But I honestly am quite curious about the recent jump in pool hashrate.  10% in roughly a day?  That's a pretty good jump for Slush, which has been bouncing between 9.5 and 10.5 PH for weeks now.  Yet according to blockchain's distribution chart, Slush has dropped to only 2% of the network hashrate.  Just looking at those two numbers, you would think total net hashrate (and difficulty) were shooting up again, but we appear to be due for another semi-marginal difficulty increase.  Just my observations.

SYS: SjFeMefQpgCRWuwRdiN3Hf8V6CkocV3Xdq
DOGE: DG4EwxvNCM5YFBQ8xo7pkEua2Nf1jRMmQg
rupy
Hero Member
*****
Offline Offline

Activity: 691
Merit: 500



View Profile
March 05, 2015, 09:19:45 AM
 #20713

CEX is down, and antpool dropped 15 PH at the same time... My miners are not going to their backup pool (slush), something is fishy. I will go out to the remote location and switch back slush to primary, I'd rather have 24 hour blocks than 8 hours full blast lost mining.

BANKBOOK GWT Wallet & no-FIAT Billing API
SargeR33
Member
**
Offline Offline

Activity: 112
Merit: 10

★Bitin.io★ - Instant Exchange


View Profile
March 05, 2015, 10:31:52 AM
 #20714

CEX is down, and antpool dropped 15 PH at the same time... My miners are not going to their backup pool (slush), something is fishy. I will go out to the remote location and switch back slush to primary, I'd rather have 24 hour blocks than 8 hours full blast lost mining.

If your miner is not mining, does it still consume power? Surely there is some code there to stop power consumption on idle...

bigbitmine
Full Member
***
Offline Offline

Activity: 210
Merit: 100


Big Bit Mine


View Profile
March 05, 2015, 11:48:24 AM
 #20715

CEX is down, and antpool dropped 15 PH at the same time... My miners are not going to their backup pool (slush), something is fishy. I will go out to the remote location and switch back slush to primary, I'd rather have 24 hour blocks than 8 hours full blast lost mining.

If your miner is not mining, does it still consume power? Surely there is some code there to stop power consumption on idle...

Yes, they should go idle.  All mine do.  Some of them beep as well to tell me they're not mining.

kano
Legendary
*
Offline Offline

Activity: 2436
Merit: 1039


Linux since 1997 RedHat 4


View Profile
March 05, 2015, 11:50:52 AM
 #20716

CEX is down, and antpool dropped 15 PH at the same time... My miners are not going to their backup pool (slush), something is fishy. I will go out to the remote location and switch back slush to primary, I'd rather have 24 hour blocks than 8 hours full blast lost mining.

If your miner is not mining, does it still consume power? Surely there is some code there to stop power consumption on idle...

Yes, they should go idle.  All mine do.  Some of them beep as well to tell me they're not mining.
No they still use too much power when idle Tongue

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
MrTeal
Legendary
*
Offline Offline

Activity: 1274
Merit: 1000


View Profile
March 05, 2015, 04:48:03 PM
 #20717

Looks like the "0% luck for a day" has finally come to a close at 27+ hours. That was BRUTAL!!!!
I don't think it's luck. There's a pretty consistent pattern there where we have bad luck for that block if the pool hashrate is (10 + n*0.23-n)PH/s, where n is any positive integer. The block at 10.23PH/s was 20.5 hours, and the one at 10.45PH/s was over a full day. Lord knows what would happen if we actually hit 10.67PH/s, it could be a couple day long block.

I hope slush looks into this and can find the error in his code. These long blocks need to stop.
I get the feeling people took your comment seriously Cheesy

The devil made him do it.
That guy's always whispering in my ear.
dmwardjr
Hero Member
*****
Offline Offline

Activity: 966
Merit: 1008


The Few, The Proud, The BTC


View Profile
March 08, 2015, 12:12:23 AM
 #20718

My Kill A Watt meter was defective when determining power consumption of my rigs.  In fact, it has burned out completely now and will not work.  I got information from another buddy who has a working watt meter and came up with the following results:

I HAVE DRAWN THE CONCLUSION IT IS NOT WORTH UNDER-CLOCKING THE S3 or S3+ [At least at present price of bitcoin].  I don't know that it would ever be worth under clocking it?  I can see under-clocking to make more power available to add more rigs with a higher hash rate and better power efficiency to your present set up.  That's about the only advantage.  As well as having a faster interface with the new firmware upgrade.

I have tuned my S3's back to .725 volts and default frequency instead of slightly over clocked frequency of 237.5 MHz.


S3 @ 270 watts [under-clocked at 175 MHz @ 0.68 volts (0680) and 340 to 360 GH/s (I chose 350 GH/s for the math)]

$0.106 (10.6 cents) per kWH power costs for 270 watts:

Cost Per Hour:   $0.028620
Cost Per Day:   $0.686880
Cost Per Week:   $4.808
Cost Per Month:   $19.23
Cost Per Year:   $250.02

Power costs at $0.106 (10.6 cents) per kWH for 380 watts:

Cost Per Hour:   $0.040280
Cost Per Day:   $0.966720
Cost Per Week:   $6.767
Cost Per Month:   $27.07
Cost Per Year:   $351.89

With BTC @ $273.471 & Difficulty at 46,684,376,316 and S3 tuned to 175 MHz @ 0.68 volts for 350 GH/s @ 270 watts:

Mined Per Hour:    0.0001571  BTC   $0.04296  USD - $0.028620 pwr. costs = $0.01434 per hour
Mined Per Day:     0.00377  BTC       $1.031  USD - $0.686880 pwr. costs = $0.34412 per day
Mined Per Week:   0.02639  BTC       $7.217  USD - $4.808 pwr. costs = $2.409 per week
Mined Per Month:  0.1131  BTC         $30.93  USD - $19.23 pwr. costs = $11.70 per month

With BTC @ $273.471 & Difficulty at 46,684,376,316 and S3 tuned to 237.5MHz @ 0.725 volts for 480 GH/s @ 380 watts:

Mined Per Hour:    0.0002155  BTC   $0.05893   USD - $0.040280 pwr. costs = $0.01865 per hour
Mined Per Day:     0.005171  BTC     $1.414       USD - $0.966720 pwr. costs = $0.44728 per day
Mined Per Week:   0.03619  BTC      $9.897       USD - $6.767 pwr. costs = $3.13 per week
Mined Per Month:  0.1551  BTC       $42.42       USD - $27.07 pwr. costs = $15.35 per month

The following screen shot shows what is mined in BTC with 350 GH/s:



The following screen shot shows what is mined in BTC with 480 GH/s:


BTC ADDRESS:
bigbitmine
Full Member
***
Offline Offline

Activity: 210
Merit: 100


Big Bit Mine


View Profile
March 08, 2015, 12:30:08 AM
 #20719

When I get a miner I just plug it in and leave it alone.  Works out well that way.

alliebtcpup
Newbie
*
Offline Offline

Activity: 1
Merit: 0


View Profile
March 08, 2015, 03:10:40 PM
 #20720

When you set back to default settings on the S3 is that by putting 0725 in the voltage?
Pages: « 1 ... 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 [1036] 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 ... 1140 »
  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!