|
Payout for round 18218 -- ongoing miscalc problem, low transaction fees, or just variance?
18219 --2013-05-25 23:31:47 -- 0:33:15 -- 4923475 -- 2350 -- 0.01151355 -- 237930 -- 25.21042000 -- 84 confirmations left
18218 --2013-05-25 22:58:32 -- 0:25:35 -- 3754815 -- 1814 -- 0.00691102 -- 237928 -- 25.00650000 -- 82 confirmations left
..
18216 --2013-05-25 21:32:11 -- 0:26:24 -- 3940018 -- 1850 -- 0.01299966 -- 237915 -- 25.07852000 -- 69 confirmations left
...
18213 --2013-05-25 20:25:33 -- 0:28:52 -- 4289177 -- 2142 -- 0.01138243 -- 237903 -- 25.51505422 -- 57 confirmations left
|
|
|
|
|
Having a problem using bfgminer-3.0.0-win64 with usb hubs.
4 BFL FPGAs tried on Satechi 10-port USB 3.0 hub, Satechi 12-port USB 2.0 hub, and Stratitec 4-port USB 2.0 hub. All hubs are powered.
bfgminer will find and start all four miners, but almost immediately will start throwing HW error "Error: Get temp returned empty string" for all but the first miner found. bfgminer runs normally if I plug the miners into 4 of the PC's 2.0 and 3.0 USB ports.
Suggestions?
[Edit] Just to be more clear -- decided to free up the USB ports on my PC so moved the FPGAs to the 4-port hub and saw the errors when I restarted bfgminer. Tried moving the hub input to different ports on the PC, same result. Tried switching the FPGAs around on the 4-port and it was always the first detected that ran ok with other three miners throwing the error. Thought maybe the hub was bad, so tried the 12-port 2.0 hub (it has 2 independently switched banks of 6 powered ports each) -- same result irrespective of ports connected on the hub or the PC. Next, tried the 10-port 3.0 hub (3 independently switched banks of 3 ports each plus one iphone/ipad charger port) -- same result. Moved the miners back to ports on the PC, no errors.
|
|
|
|
Hm, today's luck has been around 144% , does this mean difficulty is going to rise pretty high next adjustment?
We had a lucky day today, earlier this week we had a couple of unlucky days as well. It all balances out. You can't use a single day or even a single week as a basis for expectations of how the future will pan out, you need to look at a much larger sample size. Compare all of today on all of the large pools for example, then average the data from all of those pools for a month. Our good luck benefited us today, but it's just a small ripple in the ocean when you start looking at the big picture Yeah, luck was good. Would've been even better if Block 237574 had made it into the pool database. [Edit] Wonder where it went. |
|
|
|
What is a normal rate for invalid blocks, we seam to have a lot of those lately on top of bad luck. I remember 2 yesterday and now two today.
Invalid is just bad luck, too -- more machines hashing with increasing hash power = greater chance of "collision" |
|
|
|
Anyone working on client that will connect the upcoming BFL ASICs to Slush's pool? I have some BFL FPGA's running BitMinter but that doesn't connect to Slush. Can't get cgminer to run 'em -- error says "need to install USB driver" which has been done -- and I imagine the ASICs will have the same problem.
Are you using the latest cgminer version 3.1.1? It has a dedicated readme for ASICs as well as an executable for non-GPU use. https://bitcointalk.org/index.php?topic=28402.0. There's also bfgminer, which I have read has better ASIC compatibility, but I have no experience using that at all. There is no need for a new miner. Ah, I see that even though cgminer says that I must load a Windows USB driver, it doesn't work with the Windows USB driver, and really wants me to use libusb instead. How clever of the coders  Hafta reboot to load libusb, but will wait until the current round finishes so I'm not penalized for a disconnect after 2.5+ hours of mining on the gpus. |
|
|
|
|
Anyone working on client that will connect the upcoming BFL ASICs to Slush's pool? I have some BFL FPGA's running BitMinter but that doesn't connect to Slush. Can't get cgminer to run 'em -- error says "need to install USB driver" which has been done -- and I imagine the ASICs will have the same problem.
|
|
|
|
Figures this would happen on the same day I got my new GPU and tripled my hash rate.
Well, there's always eBay for converting BTC into $  |
|
|
|
0 That's it! Party's over! Everyone, out of the pool!  This is just a quick and dirty to put a hold on transfers until the IRS can figure out how to tax them. |
|
|
|
The lulz in all of this being, of course, Apr 04 00:16:02 * dub suggests to #mtgox that they list on MPEX to raise capital for engine
Apr 04 00:16:10 <mircea_popescu> banned in 3 2 1
Apr 04 00:16:12 <jurov> muhaha
Apr 04 00:16:28 <dub> <MagicalTux> dub: except that'd be illegla MtGox thinks MPEx is illegal. MtGox thinks MtGox is legal. MP points and laughs. MtGox has its French accounts frozen, complains, is kicked out of Europe. MP points and laughs. MtGox has its US accounts frozen. MP points and laughs. Coin* thinks it "brings Wall Street to Bitcoin", half year to a year after MPEx already has. Coin* implodes in lolsuit. MP points and laughs. Bitcoin. Backed by drama and lols. MPEx. Failing last. Since 2011. MPEx may fail last, but that upfront 30 BTC registration fee is wall I'm not sure I wanna climb. |
|
|
|
So there would be no negative effects using one worker but running my up to 100 mashienes in a subnet with one external IP?
btw: I am using a stratum proxy of cause.
One worker per IP fed by subnet or one worker per machine reporting from a single IP makes no difference for your payout. I favor one worker per machine so I can quickly spot any that go down -- if I had 100 machines to worry about, I'd write an Excel app to poll the worker Web page every 5 minutes or so and send an alert with worker name for any worker dropped to 0 KH/s. |
|
|
|
Is there a way to set a failover pool\server in the stratum_proxy command line flags?
Failover is set up in your miner config, not the proxy. |
|
|
|
Hello guys, we are sorry, but we don't speak Deutsch, although we reside nearly the Deutschland boarder in Liberec. We aren't happy, that you think, that our company is a scam, so we would like to explain you a few things. - The miners are compiled by czech company with our 250 Mh/s chips and boxed to Tyan-Server cases. We are sorry, but we don't want to tell other informations about our hardware. - We are not against personal pick-up in our office, so if you come, you can check and discuss everything about our hardware. - We do accept escrow payments via www.moneybookers.com, escrow means, that you pay and moneybookers will give us money only if you tell them, that you have received your postage. - Due to Czech law, we MUST, give you back your money even after 14 days, if you are not satisfied with the product. If you have any questions, feel free to ask at info@anamurminers.comThanks, Anamur Miners. I'm not saying your company is a scam, but I do wonder about the pricing of your 50GH/s miner for $1400 more than your 63GH/s miner and the very spotty connection to your Web site. Further, there are several Skrill (Moneybookers) scams floating around, not to mention some weirdness in trying to set up a Skrill account. If you're legit, why not accept Amex -- with your 5-digit pricing, you could certainly afford their fees. |
|
|
|
New servers are up and site is majorly upgraded!! Enjoy!
Did port numbers change? I can't connect to either server (eu on p80 or us on p3333). US servers are responding, "yay!!!" |
|
|
|
New servers are up and site is majorly upgraded!! Enjoy!
Did port numbers change? I can't connect to either server (eu on p80 or us on p3333). |
|
|
|
|
What about adding a command that is the mirror image of sendmany, so you could consolidate however many receipts of of nano-coins (or any amount) into a single transaction you can only send to yourself and pay a fee based on the total amount? Controls could be put in place for a minimum total for a consolidation (say 0.01 BTC) and protection against "double-send" by an appropriate confirmation number.
|
|
|
|
Check back again after a few minutes. Things seem to go from PROCESSING to none/none and then finally to a score.... In my case, with two miners, things first go from none/none to the score for the lowest miner, then finally ends up at the combined score - sometimes it takes 1/2 hour for the correct stuff to show up.
Ah -- now I remember Slush saying something about increasing the time between payout calculations, probably to reduce load on the servers. Thanks! |
|
|
|
|
Hmmm,
# Block found at Duration Total shares Your shares Your BTC reward Block # Block value Validity
17864 2013-05-06 01:16:16 0:09:57 1310375 none none 234729 25.01460000 99 confirmations left
17863 2013-05-06 01:06:19 0:02:56 380632 38 0.00241811 234727 25.12480000 97 confirmations left
Stats show I submitted 38 shares in the 2:56 round, but wonder why "none" submitted in the 9:57 round that followed? I was hashing at 640+ MH/s throughout both rounds (GPU traces showing 99% usage). And then there's the question of why score resets to zero during a round every now and then.
Scoring -- it's a mystery.
|
|
|
|
I found a good param for cgminer for keeping your gpu cool :
-auto-fan --temp-target 70
I also added --auto-gpu just in case if I see air temp over 30... And I'm not sure why but if you setup GPU and RAM speeds from cgminer it runs cooler... EDIT: 7870 cmd line setings... --temp-target 68 --auto-fan --gpu-fan 50-100 --auto-gpu --gpu-engine 1100-1250 --gpu-memclock 625 Usually see 7870 mem clocks between 4500-4900 for gaming rig, but LTC mining doesn't need very high memory speeds, so setting them low helps the card run cooler, even if the gpu is oc'd. |
|
|
|
|
stratum seems to be sick today -- frequent disconnects & lost shares. same thing happening in my Bitcoin pools.
|
|
|
|
I'm not sure, I'm actually using the latest guiminer, with the dropdown just set to slush's pool. It doesn't actually say what url it uses for that setting. But I am still submitting shares, albeit inconsistently...
out-of-the-box guiminer defaults slush's pool to getwork. To change to stratum, click on the worker's tab and stop the miner. Draw down the Server list, picking "other" at the bottom. With that a box labeled Host will show under Server. Type in stratum.bitcoin.cz and change the Port box to 3333, save the settings, and start the miner. Wrong. If that was the case I would have warnings all over my account page, and each miner would have a red no next to it instead of a green yes. Which means that the current guiminer, out of the box, supports stratum. That procedure was required on older versions of guiminer, but not any more. As I've said before, I'm a lifer, and was a beta tester of stratum. I'm on top of things. I will defer to your time in service. Perhaps my guiminer version is older than yours. The original poclbm.ini created by my version of guiminer when I first installed it had "api2.bitcoin.cz" as the hostname and port 8332 as the port for the miners I created using the "slush's pool" server selection. I thought those settings pointed to the getwork server (nslookup shows an IP of 176.31.157.134). After configuring my miners as described above, poclbm.ini shows "stratum.bitcoin.cz" for hostname and 3333 for port. nslookup for stratum.bitcoin.cz shows slush's Amazon EC2s (54.xxx) The version number is displayed right at the top of the guiminer window. the most recent one is v2012-12-03... Same version I have. Did you look at your poclbm.ini file? But you said your account was showing a stratum connection, so my guess is that Slush has a proxy on api2.bitcoin.cz:8332. That would make us both right |
|
|
|
|
Show Posts
