 Show Posts
|
|
Pages: [1]
|
And this folks, is why we load balance ..
I've been lazy about this because I like Slush and until recently I didn't really have enough hashing power to divide up. I have to agree. I am not going to totally leave but I think it's time to put some power some other places to hedge against bad luck streaks like this. |
|
|
|
|
Pool luck (1 day, 7 days, 30 days): 196%, 120%, 101%
How are we at 196% luck when there was a near 22 hour block?
|
|
|
|
Are we finally going to reach the mythical 24h block?
20hrs and counting... 1 block a day... btc under $500... we're all doomed...  21 hours - RUN FOR THE HILLS!  that calls for a raffle... Well praise JEEEZUS. Finally 21737 2014-02-25 13:31:15 21:41:45 Processing... 287747 25.05951250 100 confirmations left What a shitty situation to wake up to. |
|
|
|
Hmmm. Might be a bit early to tell but it looks like the toilets plugged.  Another whoot! that it is... |
|
|
|
I actually experienced an eclipse when I was a kid - it got cold pretty quickly.
More like cool... "All that you touch and all that you'll see, All that you taste... all you feel..." "Eclipse" |
|
|
|
I was fortunate enough to be here during the sad spell few days ago, jumped, pool got hot, came back....and I am the cooler----blame me everyone.
got to love these super long, energy consuming, cost more in electrical consumption than actual reward blocks. sweet chin music in my face !
Yeah. I have worked to keep my calm and not jump because of long blocks. I learned that when I moved from Eclipse to here because Slush was right in the middle of a good string of good luck and I thought it was normal! Still glad I moved, though. My personal philosophy is that one of the good reasons to move pools is bad management. I moved from Eclipse because of a protracted string of bad decisions and a protracted period of time that their system would not pay out properly. I didn't know at the time that Eclipse has such a close relationship to BFL, so after learning that I will never go back there at all. You have to have trust in the pool's management as the pool operator has the ultimate control. If they appear to be dishonest in any way (like BFL's constant dishonesty) then THAT is a good reason to move. |
|
|
|
One thing to note is that only the proxy tool supports longpoll on the cubes, for blades it doesn't matter. I don't really know what longpoll is, but the info I got on another thread was each cube works best if it is running on a dedicated launch of the proxy tool, and the way to separate them is with using a different port switch for each.
I have two cubes now and I run them both through one bfgminer proxy on a PI that is running another instance of bfgminer that I have ten blades proxying through. The two cubes both run at nearly 27.5 Gh/s even though longpoll isn't supported. At least in my case it really seems like the longpolling doesn't seem relevant. I've heard some say that the PI can only handle "a couple of blades" but I've never found this to be the case at all. It's not straining the Raspberry PI... it only runs at about .3 load. There isn't a load on the CPU or memory in ASIC mining. My PI should run be able to run quite a few more cubes or whatever "blade v4" happens to be. What is your efficiency percentage? Pretty sure on bfgminer as proxy my cubes were topping out at around 27gh/s and 85% efficiency. Running separate proxy.exe for each I'm getting 31gh/s and 97% efficiency on low clock, fwiw... My rack of blades doesn't behave like this and they run fine on bfgminer as proxy, in fact they seem to run better than running through the proxy.exe. Just for the record...the "Efficiency %" is a meaningless number on Stratum in bfgminer/cgminer. It serves no purpose whatsoever. Ok, but when my efficiency % says 85% and the cube won't hit 30gh/s on BFGminer, but then using the proxy tool I get 97% efficiency and over 30gh/s it kinda does actually matter. What are you basing your well-researched conclusions on? Exactly how does it not serve a purpose? I believe it has to do with the amount of successful shares relative to power consumption, either way the feedback loop seems meaningful to me because when it's low my gear won't hash to it's fullest. Well, I just checked and I get about 97.8% efficiency on both cubes. My mileage on this apparently varies from the norm. I am using bgminer 3.3.0 if that is an interesting tidbit. I also am sure to follow the advice that folks like Silentsonicboom give on this, and I take the cubes apart and make sure the heat syncs are snug. They *do* often have heat syncs that are not tight. EDIT: Another thing that might be of interest is that I have a setup where everything (the blades, the cubes, and the PI) are all on one dedicated 10/100 switch. I wonder if that is a factor in how these things communicate with the PI. There is a whole heck of a lot of traffic that doesn't have to go over to other parts of my LAN that way. |
|
|
|
One thing to note is that only the proxy tool supports longpoll on the cubes, for blades it doesn't matter. I don't really know what longpoll is, but the info I got on another thread was each cube works best if it is running on a dedicated launch of the proxy tool, and the way to separate them is with using a different port switch for each.
I have two cubes now and I run them both through one bfgminer proxy on a PI that is running another instance of bfgminer that I have ten blades proxying through. The two cubes both run at nearly 27.5 Gh/s even though longpoll isn't supported. At least in my case it really seems like the longpolling doesn't seem relevant. I've heard some say that the PI can only handle "a couple of blades" but I've never found this to be the case at all. It's not straining the Raspberry PI... it only runs at about .3 load. There isn't a load on the CPU or memory in ASIC mining. My PI should run be able to run quite a few more cubes or whatever "blade v4" happens to be. |
|
|
|
Hi support! Again fee null !
21439 2014-01-12 14:43:40 4:33:10 2560373292 none none 280103
Support (slush) doesn't read this forum. I have lodged a ticket with support. BTW - has anyone yet been paid out on 21394,5 & 6 I raised a ticket on these a few days back? Philip 21439 just corrected, not the earlier ones though. Philip My payout for these blocks is fine now. I don't know if the support team reads the tickets either... but eventually these get fixed.... Cheers It looks like, though, it might have happened again for block 21442. |
|
|
|
Hi. Can you explain what is happening? Hardware works perfect and shares are collecting with a profit of 0,0025 BTC from one round. There are no errors too. But there is one problem. Once the round is finished, the statistics shows different information. It does not match any real statistics. There is written "shares (none)" and "your BTC reward (none)". What happened with the income? That way went rounds 21408 and 21389. And more, everytime i see that the number of such problems are increasing.
21408 +1 # Block gefunden Dauer Gesamtanzahl Shares Your shares Deine BTC-Vergütung Block # Block value Gültigkeit
21409 2014-01-09 14:13:42 1:41:20 874452642 65664 0.00172782 279496 25.15484964 97 Bestätigungen ausstehend
21408 2014-01-09 12:32:22 4:22:33 2241595323 none none 279487 25.20279536 88 Bestätigungen ausstehend 21408 2014-01-09 12:32:22 4:22:33 2241595323 none none 279487 25.20279536 86 confirmations left UGH Slush... Now even the database connection on the ticketing server is down! Uncaught Exception
Replace Query: in ./__swift/library/Database/class.SWIFT_Database.php:1059
===============================================================
#0 ./__swift/models/Session/class.SWIFT_Session.php(559): SWIFT_Database->Replace('swsessions', Array, Array)
#1 ./__swift/models/Session/class.SWIFT_Session.php(588): SWIFT_Session::Insert(40, 0)
#2 ./__swift/library/Controllers/class.Controller_client.php(58): SWIFT_Session::InsertAndStart(0)
#3 ./__apps/knowledgebase/client/class.Controller_List.php(33): Controller_client->__construct()
#4 ./__swift/library/MVC/class.SWIFT_Controller.php(331): Controller_List->__construct()
#5 ./__swift/library/App/class.SWIFT_App.php(176): SWIFT_Controller::Load(Object(SWIFT_Interface), Object(SWIFT_App), Object(SWIFT_Router), false)
#6 ./__swift/library/class.SWIFT.php(16): SWIFT_App->ExecuteController(Object(SWIFT_Router))
#7 ./__swift/library/class.SWIFT.php(16): SWIFT->Initialize()
#8 ./__swift/swift.php(16): SWIFT::GetInstance()
#9 ./index.php(28): require_once('/var/www/html/s...')
#10 {main} |
|
|
|
I wish people didn't claim "ripoff" every time there was a glitch. It always gets fixed eventually.
I wasn't being serious but it felt bad because only today I moved all 700+Ghs of my mining power back to Slush just to find this. Ah.. I got you. Yeah.. sounds disappointing.  |
|
|
|
|
21384 2014-01-06 03:05:31 2:42:21 1435249005 none none 278862 25.18020923 96 confirmations left
Whoopsy.. me too. I am assuming one of you guys put in a ticket? I don't wish to duplicate.
edit: I see the answer is YES. I wish people didn't claim "ripoff" every time there was a glitch. It always gets fixed eventually.
|
|
|
|
|
30 day luck as I write this is still at 97%.
That's low, but that's still normal. If it gets closer to 90% then maybe it is time to worry, but +-3 or 4% is normal.
Short term luck means more to human psychology, but we aren't outside of statistics just yet.
|
|
|
|
Our luck is horrible lately. Will we hit a point where this horrible luck becomes the new "normal"? I would think whatever it benchmarks against will adjust because we've been seeing longer rounds for a few days now.
Well, the 30 day average is still at 97%, so it isn't off by that much in the longer term. Don't worry... it will come back. It always does. |
|
|
|
and you cleared all your back order on thanksgiving whopp de do
This is only true if you accept their definition of back order. I have an order I made on the second of August that hasn't been sent yet. As I understand it, the units from their Thanksgiving sale that were supposed to "instantly" ship haven't shipped yet. BFL has also stopped their daily updates that say up to what date they have shipped to. IMHO they continue to be bad actors. If they were trying to fix the problems they wouldn't be making posts that say "we're up to date" because they aren't. |
|
|
|
How often does Slush's pool pay after reaching your payout amount? Just curious.
The FAQ currently says it's now every 15 minutes. That hasn't been my experience, though. I am waiting for a payout and it has been past threshold for at least a couple of hours. It used to be at the top of the hour, but at the moment is seems random. Maybe they are being triggered manually at the moment. All I know is that it isn't consistent right now. |
|
|
|
WHO HOO!! 32% LUCK!!  |
|
|
|
|
I got a little less than double on that round as well...
21029 2013-12-03 00:03:45 0:30:25 174346782 28913 0.00408863 272735 25.00901001 92 confirmations left
21028 2013-12-02 23:33:20 0:28:46 166468331 29568 0.00451569 272729 25.29332793 86 confirmations left
21027 2013-12-02 23:04:34 5:49:17 1993521951 352054 0.00842425 272726 25.00902152 83 confirmations left
21026 2013-12-02 17:15:17 0:42:40 241981189 42646 0.00421066 272690 25.19850076 47 confirmations left
21025 2013-12-02 16:32:37 10:39:33 3490407934 645818 0.00465805 272687 25.06788253 44 confirmations left
|
|
|
|
|
