When will he do it? I really don't know. He usually does manual payments once a week. It nothing urgent; the pool does work presently, and waiting for 3 days for some money will not kill anybody. But I fully trust he will eventually get to it: two months ago, the pool had a major failure in which the website was down for a whole week. During that time tens of thousands of BTC were sent to the offline wallet, and nobody was getting payed. He could have run with a shitload of money and nobody could have done anything about it. Yet, the website came back online, and everybody got payed in full. So a delay of a few days does not worry me at all.
+1. Despite the "I want my coinz now!" stuff (ME included! ), this is the best pool I've used. Yes it has problems occasionally, but I always get my BTC in the end. Keep up the good work wizkid.
|
|
|
Since MtGox price is SO far out of whack from the others, I'd like to exclude it from my average. Acknowledging that this could be true for some other exchange in the future, I propose that every exchange has a checkbox next to its name so the user can choose which exchanges to include or exclude from the average. For example, I'd like to exclude localbitcoins also.
|
|
|
Thanks for making me feel bad.
as long as they hash dude Yeah - we all get the same shiny bitcoins in the end no matter how pretty or ugly (like mine!) the mining rigs are.
|
|
|
The queue was required for the very first sample chips with limited availability. Following waves will be available in volumes and should not need to register.
As for the clock: the eval board in China uses 12MHz clock, Bitmine's 16MHz - both work. PLL settings allow arbitrary setting of divider, configuration tables for the PLL settings for 12 and 16MHz input clock and different system clock rates will be added to the documentation ASAP. If you design a multi-chip board, to feed all chips with one oscillator you need - guess what - clock buffers (no kidding here).
Cheers, zefir
Crap, that means another 6 months until we get chips. I think he means you need clock buffers on the board, not on the chips. No need to worry yet. Edit: Removed excess text.
|
|
|
For those of you waiting; I ordered on Nov 26 and got a "shipping" notice on Dec 4 but my order did not actually leave their facility until Dec 11. USPS tried to deliver to my work on Saturday but no one was there so I got the order today.
I agree that this is slow shipping but I'm happy with my order. My recommendation to Amagi Metals is to be more open an honest about what is happening with orders. For example, do not say "in stock" if it really isn't. Say "available in 5 to 10 business days" or whatever is appropriate.
Other than the slow shipping, I'm happy with my order.
|
|
|
can someone tell me which parts of the VRM are most important to cool w/ little heatsinks?
It's best to just add heatsinks to the back of the board. However, the parts you are cooling are the black plastic transistors between the large aluminum cylinders (the filter capacitors) and the large black cubes of metal (the inductors). The reason the back is better to cool than the parts directly is that the parts are mounted with a metal pad in the middle that is designed to conduct the heat into the board. On the other hand, the top of the part is plastic and does not conduct heat as well. Thus, cooling the back of the board is best. Also, when you add heatsinks on the top of the parts, you risk shorting out some of the other small capacitors near the devices you are cooling. To repeat: It is best to heatsink and cool the back of the board under the VRM, and NOT heatsink any of the individual parts.
|
|
|
There seems to be something strange going on with the "Global Average" number. Even though the USD and CNY (converted to USD) prices are very close and >90% of the volume, the Global Average number is much lower than either of these prices. That would imply the rest of the world is WAY below this price - which seems to NOT be the case.
(I have a web page image to insert here but don't know how to do it.)
|
|
|
BFL did have problems with engine 0 making the miner unstable,
Can you disable engine 0 within the software? and then test without engine 0 running on each chip?
This was only true for the first revision of chips. All of those were shipped in BFL products except a few early sample chips. All of the other chips sent out to us were the second revision where engine 0 is working.
|
|
|
With only a single LED flashing, it looks like maybe the MCU has rebooted. The LEDs are numbered 1 (closest to USB connector) to 8 (closest to the PCI-E power connector). Is it LED 7 that is blinking?
|
|
|
I just got 2 emails that something on my account has changed even though I did not do it. After logging in, everything looks OK as far as I can tell.
Is this due to a recent EMC change and I can safely ignore?
|
|
|
anyone try chaining these things yet? I have 10 of em and am just wondering if the z-link chain is working and how I would go about connecting all ten via the pins.
Z-link is NOT working yet. It is low on the priority list at this time. It *might* get done in a month or so but there are other changes that are much more important.
|
|
|
Please somebody upload the original firmware. After updating firmware, my chilis run slow.
How much slower? How long did you let them run before deciding they are slow? When first powering on, they intentionally run slow then speed up based on temperature.
|
|
|
I updated the firmware. I confirmed 4 outer and 4 inner leds are blinking in turn. After power cycling, when I check the firmware version, it is still 1.0.0. What's the problem?
Okay. I found this. I believe it should show up as 1.2.14e Version 14d and earlier reported as 1.0.0 Yes that is correct. Perhaps you have an older version? 2 have been released so far with 14e (1.2.14e) being the newest.
|
|
|
MrTeal and I have developed mining hardware called Chili using BFL chips and it uses the BLF driver. The driver interface / protocol defines a command (ZTX) that allows cgminer to request three voltages from the hardware. The 3 values are typically 3.3V, 1.0V, and 12V. cgminer displays the 3.3V value on the screen but in my opinion this is the least interesting voltage value. I would prefer it to show the (nominal) 1.0V value as this directly impacts hashing speed and power. On other BFL hardware, this value is fixed at the factory, but on a Chili, it is configurable by software allowing automatic overclocking. Thus the interest in displaying this value. Please consider this reply a formal request to change the displayed value from the 3.3V value to the 1.0V value. If you have enough screen real estate, it should show 3 digits to the right of the decimal point. Ex: 1.057V Thank you. BTW - We have added a new field to the ZCX command to distinguish our hardware apart from BFL hardware: "MANUFACTURER: MrTeal and ChipGeek\n"
|
|
|
I have 1 miner that will not finish the boot sequence. it just keeps flashing the 7th and 8th leds. i have turned it off for several hours and tried it again still no luck.
Is that batch 1 or 2? There was a bug in early batch 1 boards that was fixed half way through batch 1. it is batch 1 I would recommend upgrading the firmware. Details here: https://bitcointalk.org/index.php?topic=304250.msg3531327#msg3531327
|
|
|
I have 1 miner that will not finish the boot sequence. it just keeps flashing the 7th and 8th leds. i have turned it off for several hours and tried it again still no luck.
Is that batch 1 or 2? There was a bug in early batch 1 boards that was fixed half way through batch 1. Edit: Before someone asks, the bug was due to new behavior in the revision 2 ASIC chips and was fixed (a workaround) with new firmware.
|
|
|
just received my chilli i connected it to my raspberrypi and i am gettting failed to send queue message and retry in 1 second
it is detected and temp is 30 degrees
any ideas?
Thanks
If you are using cgminer, you need version 3.6.0 or higher. I'm having good luck with 3.7.2 and I did have some problem with 3.8.1.
|
|
|
Any updates on batch 2 production status? 0-25% 25-50% 50-75% 75%-finished
75%-finished
|
|
|
I'm seeing a problem with 3.8.1 on an RPi running Rasbian. Twice in the last 24 hours cgminer has stopped running. It appears as if the "q" key was pressed even though I'm sure it was not. This hardware has run solid for weeks before I upgraded to 3.8.1.
Here is a link to instructions. Scroll down to the section that says Rpi freezing up. http://projectklondike.org/how-to-runChad Thanks but that is not the problem I'm seeing. My RPi does not freeze or lock up. Instead it appears as if the 'q' key was pressed and cgminer quits for no apparent reason. It happened again last night. I will revert to an older version. BTW - when getting source from github, now do I request an older version (such as 3.7.2)? I can't just go back to the ancient version I was using (3.4.2).
|
|
|
|