 Show Posts
|
|
Pages: [1] 2 3 4 5 »
|
|
It’s very hard to predict their actions unless you know them.
|
|
|
|
|
Moderator please delete this. I pressed submit accidentally.
|
|
|
|
Press Release: http://www.prweb.com/releases/Bitcoin0mining0terrahash/bitcoin0asic0mining/prweb11093344.htmSanta Clara, CA (PRWEB) September 05, 2013 In a move to significantly reduce the costs for mining Bitcoins, TerraHash has announced a hosted solution of 2 PetaHash mining power at the rate of $6 per Giga Hash. The company will create a Bitcoin mining farm, and sell portions of the mining power to its customers. Matt, the company spokesman explained, “We are in the final stages of signing a groundbreaking deal with a leading Bitcoin ASIC manufacturer. Leveraging their 28nm chip technology, we plan to host a mining farm starting with at least 2 PetaHash in November. Our customers will be able to buy blocks of 500 GigaHash of mining power for $3000 each. This will include all manufacturing and storage costs for hosting the equipment. Customers will pay a small monthly fee, which will cover electricity, maintenance etc. Our data center will have a 99.9999% up time guarantee. Being located in the Santa Clara county, we have access to some of the lowest cost of electricity. This allows us to create economies of scale for the mining world.” Terming it as the next natural evolution of Bitcoin mining, he compared the plan with services provided by other cloud computing companies. “For instance, we have seen the computing industry evolve in a similar fashion. Initially, companies hosted their own servers in their offices. Then, we saw the emergence of data centers which provided with the optimum infrastructure to run your servers efficiently. Finally, a few major players (like Amazon, RackSpace) began providing the end user with the flexible concept of renting storage space, without being bound to the physical hardware. We expect a similar transition in the Bitcoin mining world,” he said. At a time when most Bitcoin mining equipment manufacturers seem to be more focused on accumulating maximum pre-order money, TerraHash is once again planning an innovative strategy. They plan on only taking 25% of the money upfront, and the rest when the hardware is ready to be hosted. Pre-orders will open up this coming week, and mining is set to begin by end of November. The company also plans on offering an “insurance” plan for the customers, to cover up any potential delays in the timeline for mining. Matt further said that, “We have learnt a lot from our experience assembling Avalon ASIC chips. Customers want a solution that can be delivered very fast, because of the ever increasing network difficulty. On the same hand, they do not want to risk a lot by investing in an unproven technology. By only demanding a 25% reservation fee, we are reducing their risk significantly.” At $6 per GigaHash, the pricing is nearly half of the nearest competitor. Along with that, a November timeline would promise delivery much earlier than any other company. In an industry where time to delivery is the most critical element, TerraHash claims to be heading for the final evolution in Bitcoin mining. More details will be coming soon. |
|
|
|
|
Is the I2C code disabled right now? How to enable it?
|
|
|
|
It is most likely a hardware bug in the circuit. During our testing we realized that the Dual NOR gates used in the design are too fast, and there needs to be some propagation delay. Using a cheap NOR gate chip from Fry's did the trick. We are still trying to see if this can be fixed in the firmware.
Maybe you may also want to try to use a bigger capacitor for the phase shifter in front of the NOR gate. A circuit should not depend on the propagation delays or fabrication tolerances of logic gates. I also tried to use the internal comparator of the PIC as a NOR gate, which is even better since it has some clock synchronization register. But it has shown that the comparator is not fast enough... Already tried using bigger capacitor. Does not work. The only work around we have found is using a slower gate, so far. I'm sorry to tell you, but you're wrong. I'm using v0.3.1 board with bigger cap (currently about 260pF) and it's hashing quite well. Without it, the clock signal is not delayed enough - just about 5ns and bad nonces are returned. BTW terrahash, what modifications did you made to the 4 chip firmware to hash with all 16 chips? You are using 260pF for C274 right? In order to hash with 16 chips, you need to make the following modifications in klondike.c, from line 159: Status.ChipCount = 16;
// pre-calc nonce range values
BankSize = (Status.ChipCount+1)/2;
Status.MaxCount = WORK_TICKS / BankSize / 2;
NonceRanges[0] = 0;
for(BYTE x = 1; x < BankSize; x++)
NonceRanges[x] = NonceRanges[x-1] + BankRanges[BankSize-1];
Yes thats correct. Thanks for the code, will try it out. BTW, have you tried connecting more than one K16 to CGM? I2C code is not working out of box. Thats exactly what we are working on right now. |
|
|
|
It is most likely a hardware bug in the circuit. During our testing we realized that the Dual NOR gates used in the design are too fast, and there needs to be some propagation delay. Using a cheap NOR gate chip from Fry's did the trick. We are still trying to see if this can be fixed in the firmware.
Maybe you may also want to try to use a bigger capacitor for the phase shifter in front of the NOR gate. A circuit should not depend on the propagation delays or fabrication tolerances of logic gates. I also tried to use the internal comparator of the PIC as a NOR gate, which is even better since it has some clock synchronization register. But it has shown that the comparator is not fast enough... Already tried using bigger capacitor. Does not work. The only work around we have found is using a slower gate, so far. I'm sorry to tell you, but you're wrong. I'm using v0.3.1 board with bigger cap (currently about 260pF) and it's hashing quite well. Without it, the clock signal is not delayed enough - just about 5ns and bad nonces are returned. BTW terrahash, what modifications did you made to the 4 chip firmware to hash with all 16 chips? You are using 260pF for C274 right? In order to hash with 16 chips, you need to make the following modifications in klondike.c, from line 159: Status.ChipCount = 16;
// pre-calc nonce range values
BankSize = (Status.ChipCount+1)/2;
Status.MaxCount = WORK_TICKS / BankSize / 2;
NonceRanges[0] = 0;
for(BYTE x = 1; x < BankSize; x++)
NonceRanges[x] = NonceRanges[x-1] + BankRanges[BankSize-1];
|
|
|
|
It is most likely a hardware bug in the circuit. During our testing we realized that the Dual NOR gates used in the design are too fast, and there needs to be some propagation delay. Using a cheap NOR gate chip from Fry's did the trick. We are still trying to see if this can be fixed in the firmware.
Maybe you may also want to try to use a bigger capacitor for the phase shifter in front of the NOR gate. A circuit should not depend on the propagation delays or fabrication tolerances of logic gates. I also tried to use the internal comparator of the PIC as a NOR gate, which is even better since it has some clock synchronization register. But it has shown that the comparator is not fast enough... Already tried using bigger capacitor. Does not work. The only work around we have found is using a slower gate, so far. |
|
|
|
Hey Guys. Im trying to do some testing with ktest but don't seem to get any desirable results. At one point, I got the "W" command to work, but it resulted in a BAD response , which I would think should be accepted, if Im reading the code right using Below Var: Work = ["4375c3b7a27cc936f295a6140358e965319322e7cfd11e137df42ea60864a675", "218d522051d547d51a00c94e", "b2cc9f74", "accept"]
Now, I run W command (aftere restarting ktest) and I get no response at all! Trying to find out if theres a proper method to using ktest or if there could be something wrong with the K16. I added a small debug output in sendcmd under the dev.write line: dev.write(0x01, cmd + chr(addr) + data, 0, 500)
print "tried %s %s %s" % (cmd,addr,data)
python ktest
Klondike device opened
tried I 0
Version:10, ProductID:K16, Serial#:deadbeef
Cmds [WAISCE.Q]:
S
State:R, ASICs:16, Slaves:0
WorkQ:0, WorkID:04, Temp:158, Fan:0, ErrCount:0, HashCount:2048, MaxCount:2048tried S 0
Cmds [WAISCE.Q]:
w
tried W 0 Cu÷?|?6?X?e1?"???}?.d?u!?R Q?G??N
State:W, ASICs:16, Slaves:0
WorkQ:0, WorkID:01, Temp:158, Fan:0, ErrCount:0, HashCount:0, MaxCount:2048
Cmds [WAISCE.Q]:
Is there something I am missing here, or something else I should be checking out? thanks It is most likely a hardware bug in the circuit. During our testing we realized that the Dual NOR gates used in the design are too fast, and there needs to be some propagation delay. Using a cheap NOR gate chip from Fry's did the trick. We are still trying to see if this can be fixed in the firmware. |
|
|
|
|
Thanks.
Going through the code, I noticed the Identity ID is still set to "0xDEADBEEF". I assume we have to manually change this for each chip, or is there any a way to write an automatic script? Also, I think I read somewhere that you got a range from Microchip. Are you going to allot any ranges to the manufacturers who bought licenses from you?
|
|
|
|
|
BkkCoins,
The latest kicad files show R24 and R25 module values as 1K. Whereas, the last revision showed 2.2K and even the BOM says 2.2K. Is that an error, or did you change those registers to 1K?
|
|
|
|
Having a look at the 74AUP2G02 data sheet it looks like the SOT996-2 package is very close to the VSSOP8 (SOT765-1) package. For DIY I think you could easily use that part on the same footprint. It's a QFN style pkg, no leads.
Be careful though as there is a variety of similar packages.
This one is the 74AUP2G02GD which Digikey has 2860 in stock, min. 1pc.
I looked at the datasheet in detail, and turns out that 74AUP2G02GD can be used for SMT assembly as well, without modifying the board in any way. The following is basically the same thing, except for the operating temperature rate (40 to 85 Celsius, as compared to 40 to 125 Celsius). I have no idea how it will behave if the temp rises 85 C. http://www.digikey.com/product-detail/en/74AUP2G02DC,125/568-9186-2-ND/1300786It shouldn't get that hot, and you wouldn't want to let it as if it gets there, then for sure the ASICs are well beyond, and they are rated for 85C as well. So any 125C parts are simply for enhanced durability / longer life. Wow, people are fast. There were like 1600 of them, and they are all taken too. BkkCoins, can you look for the Murata Power Inductor alternative? How about this one: http://www.digikey.com/product-detail/en/SPM10040T-R36M170/445-3603-6-ND/1856770Or if we have to look for an alternate, what is most important? Inductance, Current Rating, DC Resistance or Frequency? |
|
|
|
Having a look at the 74AUP2G02 data sheet it looks like the SOT996-2 package is very close to the VSSOP8 (SOT765-1) package. For DIY I think you could easily use that part on the same footprint. It's a QFN style pkg, no leads.
Be careful though as there is a variety of similar packages.
This one is the 74AUP2G02GD which Digikey has 2860 in stock, min. 1pc.
I looked at the datasheet in detail, and turns out that 74AUP2G02GD can be used for SMT assembly as well, without modifying the board in any way. The following is basically the same thing, except for the operating temperature rate (40 to 85 Celsius, as compared to 40 to 125 Celsius). I have no idea how it will behave if the temp rises 85 C. http://www.digikey.com/product-detail/en/74AUP2G02DC,125/568-9186-2-ND/1300786 |
|
|
|
Having a look at the 74AUP2G02 data sheet it looks like the SOT996-2 package is very close to the VSSOP8 (SOT765-1) package. For DIY I think you could easily use that part on the same footprint. It's a QFN style pkg, no leads.
Be careful though as there is a variety of similar packages.
This one is the 74AUP2G02GD which Digikey has 2860 in stock, min. 1pc.
I looked at the datasheet in detail, and turns out that 74AUP2G02GD can be used for SMT assembly as well, without modifying the board in any way. |
|
|
|
Most of you know that we have successfully assembled a K16 (Klondike design by BkkCoins) and are one of the first to get it mining (video below). Our design is based on BkkCoin's Klondike board. He has finalized the design and it is ready for production. We have decided to start taking pre-orders for assembly, for those who have ordered Avalon chips and would like to get them assembled. We will be assembling both K16 and K64 boards (K64 is just 4 K16s printed on the same board, connected with I2C cables/jumpers). K16 requires 16 Avalon chips, ad K64 requires 64 Avalon chips. Our boards will come with heatsinks and I2C cables (to daisy chain multiple boards). The boards can be daisy chained together, and only one of them has to be connected to a computer or a RasPi board running cgminer (cgminer driver is almost ready). The software required to run the boards will be available for free download. http://www.youtube.com/watch?v=GOZ22GfUdzsHere are our prices for assembly: K16: $90.00 / board.
K64: $250.00 / board.
Although our assembly facility can assemble up to 250 K64 boards a day (or 1000 K16 boards a day), we are expecting a huge rush initially due to a large number of chips being shipped by Avalon. 50% of the assembly resources will be dedicated to orders where TerraHash supplies the chips (full orders), and other 50% to the orders where you provide chips to TerraHash (assembly-only orders). With this we can ship the already pre-ordered full orders within the promised time of 2 weeks of receiving the chips. And for assembly-only orders, we will do our best to ensure a two week turnaround as well. However, it could be a little more during the initial rush. That is why we have decided to let people reserve a spot for assembly. Here is how the assembly-only orders will be processed: For all the orders for which we have received the chips, we will start assembling the order which was placed first. We will not start processing an order until we receive all the chips required to process that order. Also, we will not be doing partial assembly, that is, we need 64 chips for the K64 and 16 chips for the K16. We can not assembly a K16 with less than 16 chips. We can not assemble a K64 with less than 64 chips. Therefore, when your order gets processed depends upon two factors: When you placed the order, and when your chips are delivered to us. We will start taking assembly-only pre-orders later this week. In order to reserve your spot for assembly you have to pay only 5% right now. You can pay the balance any time before we receive your chips. However you have to pay in full for us to start processing your order. Website: https://terrahash.com |
|
|
|
I'm treating your use of all 16 chip locations as verification of the current PCB, so that I can revise and release an update without myself having to put 12 more on. Every day counts right now. I've completed the NOR gate, inverter and fan control revisions. Next up is ferrite beads and moving the thermistor. Then the PIC QFN version, and new logo. I'm also going to move the big caps in the middle just a smidge since the latch for the PCIe connector is a bit close.
Yea, you can count on it. Our error rate is still quiet high, but all the chips are hashing. Below is the latest stat: {
"Fan RPM 0": 0,
"STATS": 0,
"Clock 0": 150.0,
"Calls": 0,
"Min": 99999999.0,
"Max": 0.0,
"USB Delay": "r0 0.000000 w0 0.000000",
"Errors / Chip 0": "0326 0327 0307 0323 0323 0306 0312 0350 0311 0304 0303 0327 0340 0344 0337 0319",
"Nonces / Chip 0": "2538 2514 2480 2505 2500 2556 2530 2434 2435 2432 2354 2439 2539 2521 2512 2436",
"USB Pipe": "0",
"Elapsed": 42506,
"Fan Percent 0": 50,
"Temp 0": 41.72,
"ID": "KLN0",
"Wait": 0.0
},
|
|
|
|
|
Our sample board is now working at all the way up to 347 MHz. I was using a NTE NOR gate IC that I bought at FRYs, for both NORs (I wasn't using the one on the board). Looks like its fall or rise times are a little too much. I played around with a lot of capacitors. I finally modified the circuit to use the on-board nor gate chip for the first NOR and the FRYs one for the second. And now everything is working fine. The board is hashing very well at 300 MHz.
|
|
|
|
I was able to debug the hardware. The board is hashing at 347 MHz right now. That is the highest I could go. cgminer version 3.3.1 - Started: [2013-07-13 03:24:17]
--------------------------------------------------------------------------------
(5s):2.294G (avg):2.406Gh/s | A:2096 R:6 HW:420 WU:70.7/m
ST: 2 SS: 0 NB: 6 LW: 2893 GF: 0 RF: 0
Connected to stratum.btcguild.com diff 2 with stratum as user terrahash_pps1
Block: 00736c6f5c3f355a... Diff:26.2M Started: [03:40:51] Best share: 2.03K
--------------------------------------------------------------------------------
[P]ool management [S]ettings [D]isplay options [Q]uit
KLN 0: 42C 1.2V | 2.738G/2.413Gh/s | A:2098 R:6 HW:420 WU: 70.8/m
--------------------------------------------------------------------------------
I am gonna tweak it a little bit more. I'll shoot another video tomorrow. |
|
|
|
Your method works!!!
I added
nmsleep(100); \
and everything works like a charm.
128M ~ 8/m WU
256M ~ 17/m WU
BBKCoins, please be noticed. This might be a common issue.
Are you guys both on Windows? I noticed that the Windows timeout values are defined much longer and I wonder if this is related. For Linux the timeout is 200mS but WIN32 is 999 mS. Note that I do all my testing on Linux and libusb could behave differently here. I am on Ubuntu. Update: I changed the delay to 1 usec only (that is one micro sec), and its still working. Removing the delay again breaks it, and cgminer starts hanging for 1-2 minutes. I am quiet positive there is an issue with threading/locking. #define DEVLOCK(cgpu, _pth_state) do { \
pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &_pth_state); \
nusleep(1); \
wr_lock(cgpu->usbinfo.devlock); \
} while (0)
|
|
|
|
Good info, thanks for the update terrahash.
What's needed to cool the board at 275-300?
Right now I am using an old AMD processor fan/heatsink. I applied some heatsink paste, however, the board is not screwed to the heatsink, its just placed on top of it. Its working! |
|
|
|
|
