P69, news flash.... no one wants to do business with Americans [...] quit whining [...]
Moreover, this discussion is off-topic for this thread, and for this subforum. Take it over to Service Discussion please. |
|
|
|
|
Why does b.i now default to displaying values in USD for me?
I'm examining Bitcoin blocks and transactions. I don't give one hoot about USD.
Worse, I can't even select BTC units. Only mBTC, which confuses things.
Worse still, the selection doesn't "stick", and reverts back to USD all by itself.
|
|
|
|
Beware of BitPlastic
Also beware of BTC-e
BTC is at 1014 (MtGox)
This is the KnC thread. |
|
|
|
Hi, all 4 of my ant miners would show XXXXXXXXX across the board instead of OOOOOOOs after a few days of running, it still says running at 180GH, slush pool shows it running at 150GH instead of 180GH.
Does anyone know why this happens or if it is actually working?
I hear there's a firmware bug that can cause that. Try updating the firmware to the latest. https://github.com/AntMiner/AntGen1/tree/master/firmware |
|
|
|
"Minion driver is now available
We have completed the first version of the driver for the Minion and submitted it into cgminer.
This driver has been tested and certified on FPGA.
After several months of tests we have concluded that in order to achieve the best efficiency with our code, the Minion will have to run at 1.01Ghz. For this reason we have increased the number of cores from 64 to 99."
99 cores? WTF kind of number is that? Make it 96 or 128. Anyhow, what I originally came here to ask BA is: When do you currently expect tapeout to happen? |
|
|
|
|
To add to the speculation, are there any legal pros here who can say what sort of a legal mechanism could possibly have been applied to cause the BTC to become unavailable, and also to bar Ukyo and Graet from discussing the matter?
I can think of some to cause the former, but I'm not managing to come up with any that would cause the latter.
|
|
|
|
Today one of my Ants had a cooked power lead: http://imgur.com/a/lve4tThe pins that got fried on the Ant end were the ones that did not fry on the PSU end. I figure one end went first, some pins stopped conducting, and the remaining ones then overloaded on the other end. Fortunately I had a spare PSU and cables and such. I made up a new PCIe plug to go onto the Ant end, and it's all fixed now.  |
|
|
|
I just wanted to chime in and say that I'm still waiting to hear something about my 10 Chili boards. The website says "Shipment up to 4 weeks after reciept of your chips". Tracking shows they received my chips on 04-December. I sent a forum PM and a message in my order history page on the website asking what's going on, and have not received a response.   |
|
|
|
if anyone else would like me to make his boards let me know...
Go ahead and make mine please. Thanks. |
|
|
|
|
The most potentially profitable game going on in the BTC world currently seems to be making and selling mining hardware.
There is a certain mining hardware company in California whose name rhymes with Cash Last that has working silicon, but is in dire need of a financial bailout at this very moment.
If they were to receive a sudden infusion of cash right now, they could be in a position to cover their current liabilities that now threaten to destroy them, and go on to become a successful and highly profitable mining hardware company.
Unfortunately for all involved, I doubt that you and your investment partners can move quickly enough to pull this off.
|
|
|
|
Drugs or alcohol?
I fail to see a distinction. |
|
|
|
I can confirm that this exact unit is en-route (via Fedex International Priority) to the IceDrill research/engineering facility where it will undergo rigorous evaluation. ETA: Friday 3 Jan. Have you received it yet? |
|
|
|
I really feel for HF customers but I too don't understand why so many people actually think a BTC refund is even possible. Their claim that they would give full BTC refunds actually was one of the reasons I decided not to order from HF because it sounded scammy since there's simply no way they could guarantee it with BTC's volatility.
Sure they could guarantee it, and in fact they did just that. All they had to do to make it possible was hold enough BTC to cover all of their BTC-denominated liabilities. Having guaranteed those refunds in BTC, not doing so would be irresponsible at best, and criminal at worst. |
|
|
|
Sounds like Luke-Jr has his Baby-Jet and is trying to get it going at full speed (30gh/s at last check with cgminer and bfgminer). Check out the Eligius IRC channel for more info. 30gh/s? I don't even know if should i cry or should i laugh. This is just with unfinished code, and possibly some problems with the unit. Also, it's 30 Gh/s average. More like 600 Gh/s (haven't measured exactly), but not working 95% of the time. That being the code that was shipped with the unit? |
|
|
|
|
I always thought "Network Protection" was a funny way to put it. I would think "Customer Protection" would be more apt.
|
|
|
|
Bankrupt UNLESS, they decided to bump up the MPP so that their customers would at least have a chance of breaking even. Now that their R&D is complete, the easiest and cheapest them for them to do is ship more chips.
That's essentially what CoinTerra decided to do. Batch 1 customers will be receiving more hashpower. So far as I can tell, those customers are largely satisfied with that outcome. |
|
|
|
As much as i wish this was true, It wouldn't end up killing BFL. They occupy a hell of a lot of space in terms of marketing, appealing on the broadest of terms. I'd hazard a guess that they're target audience these days is their target audience has always been noobs who don't know any better.
FTFY. |
|
|
|
Does anyone notice that their miners generally runs better until the first flushwork?
I get around 1% HW errors, and after a flushwork occurs, it shoots up to 3-4%. The HW ticker goes from 1-7 a jump to upwards of 50 a jump.
YES, I noticed that all along... I think the flush-work....still needs work! **** It seems to "Flush" with every single block detected, and not for just the pool you are on, which causes the errror rate to be higher than it has to be...drastically. IMHO...that's the biggest tweak needed atm You are way off on this one... Flushwork has to run with every block detected on the network. Blocks are built on top of each other network wide, not just on your pool. Hmm, I still respectfully disagree. Here's why... I never had that problem mining with GPU's... and it never flushed anything other than our own "Stale" shares. In pool mining...We don't solve blocks for other pools, we work on our own blocks, and by running flush-work every time a block is detected, you literally loose every workshare you are currently solving, even though your pool hasn't found it's block yet. My pants are literally loose. But no, all miners (and pools) are working to add a new block to the end of THE block chain. Pools don't each work on their own separate chain. Each time a new block is added to the chain, all miners (and pools) stop their current work, and begin new work, trying to extend the now longer chain. The block trying to be added is unique to the pool, but the chain it is being added to is not. (There are rare exceptions involving hostile miners, but let's not complicate the discussion with those cases.) hmm, ok... Try this.... look/watch the error rate jump @ flushwork times. Given the jumps, why would the dumped/flushed shares contribute to errors if the pool didn't want them? You will also notice the lack of a jump in errors during the flushwork when your pool is finding the block. I hear what you are saying, but the errors I monitored over the course of mining say otherwise. I can point my Raedon card at the same pool, on a separate account, and physically see the difference. IMO there is is still a bug (or more than one bug) in the KnC driver code that handles work changes. Changing work should never cause a HW error. A HW error indicates that the an ASIC chip returned a nonce claiming that it results in a valid share of difficulty 1 or greater, but the controller then does not reach the same conclusion when it tries to validate that claim, and rules that the ASIC was wrong (a hardware error). A HW error always indicates a local problem, specifically a disagreement between the hashing engine(s) and the host/controller. A pool should never be able to cause a HW error to be reported. (BTW, the correct spelling is "lose", not "loose". I'd go mad if I tried to explain this to everyone I see making this error, but you seem like a pragmatic enough fellow that it's probably safe to explain it to you.  ) |
|
|
|
Does anyone notice that their miners generally runs better until the first flushwork?
I get around 1% HW errors, and after a flushwork occurs, it shoots up to 3-4%. The HW ticker goes from 1-7 a jump to upwards of 50 a jump.
YES, I noticed that all along... I think the flush-work....still needs work! **** It seems to "Flush" with every single block detected, and not for just the pool you are on, which causes the errror rate to be higher than it has to be...drastically. IMHO...that's the biggest tweak needed atm You are way off on this one... Flushwork has to run with every block detected on the network. Blocks are built on top of each other network wide, not just on your pool. Hmm, I still respectfully disagree. Here's why... I never had that problem mining with GPU's... and it never flushed anything other than our own "Stale" shares. In pool mining...We don't solve blocks for other pools, we work on our own blocks, and by running flush-work every time a block is detected, you literally loose every workshare you are currently solving, even though your pool hasn't found it's block yet. My pants are literally loose. But no, all miners (and pools) are working to add a new block to the end of THE block chain. Pools don't each work on their own separate chain. Each time a new block is added to the chain, all miners (and pools) stop their current work, and begin new work, trying to extend the now longer chain. The block trying to be added is unique to the pool, but the chain it is being added to is not. (There are rare exceptions involving hostile miners, but let's not complicate the discussion with those cases.) |
|
|
|
Most of the US households are not 240V and 200 Amps though.
Really? I thought that was pretty standard. |
|
|
|
|
Show Posts
