Enigma81
|
|
May 31, 2013, 07:59:31 AM |
|
Each K16 have a power connector, power plug or suggestions 2.5/5.5mm Type D Molex power connector.
Each K16 has a PCI Express power connector. That's the 6 pin standard one seen on most PCI Express cards, and commonly available on ATX power supplies. Molex adapters are cheaply available, as are PCIe splitters, but be sure to use ones that have thick enough wire to handle 4A without getting hot. ATX power only two PCI Express power connectors, how can connect 16 K16? I'm new to this myself, but I think you can buy a molex to PCIe adapter. Or.. Like BKKCoins said.. sɹǝʇʇıןds ǝsn
|
|
|
|
Biomech
Legendary
Offline
Activity: 1372
Merit: 1022
Anarchy is not chaos.
|
|
May 31, 2013, 08:02:28 AM |
|
Each K16 have a power connector, power plug or suggestions 2.5/5.5mm Type D Molex power connector.
Each K16 has a PCI Express power connector. That's the 6 pin standard one seen on most PCI Express cards, and commonly available on ATX power supplies. Molex adapters are cheaply available, as are PCIe splitters, but be sure to use ones that have thick enough wire to handle 4A without getting hot. ATX power only two PCI Express power connectors, how can connect 16 K16? I'm new to this myself, but I think you can buy a molex to PCIe adapter. Or.. Like BKKCoins said.. sɹǝʇʇıןds ǝsn yeah... came up as I posted. I'd delete it, but hey, I ain't too proud to show some foolishness This thread frequently goes WAY over my head, so when I know what I'm talking about I gotta at least try.
|
|
|
|
Enigma81
|
|
May 31, 2013, 08:04:08 AM |
|
No worries.. The world is a learning experience.
|
|
|
|
KS
|
|
May 31, 2013, 08:15:10 AM |
|
Given the boards use less than 60W, I'd venture you can even get *single* molex -> 6-pin PCI-E adapters.
NB: you should NOT connect a GPU with that, you risk blowing things up. NB2: dual molex to 6-pin PCI-E are probably cheaper too (if you can live with unconnected wires "everywhere")
You can also use one or two 8-pin to 6-pin Y cables, but they are more expensive.
|
|
|
|
|
linuxmonkey
Newbie
Offline
Activity: 27
Merit: 0
|
|
May 31, 2013, 09:59:40 AM |
|
I totally agree with that, I know for one if I am able to get some boards/chips made or bought I will send some your way. P.s. ANY ETA when shit will be ready? I'm going to release the firmware and driver code once it's working. I was thinking of all that stuff to protect it but to be honest that's just is a hassle. I'm going to just trust that people will choose to support the vendors that kick back a small fee. Or even better maybe they'll mine a few hours for me by their own choice. I'll put the mine-to address out there when it's time. I'm getting a lot of help/support from forum members here and I think it's better to respect that by not having locked code at all.
|
|
|
|
BkkCoins (OP)
|
|
May 31, 2013, 10:12:15 AM |
|
I totally agree with that, I know for one if I am able to get some boards/chips made or bought I will send some your way. P.s. ANY ETA when shit will be ready? I'm going to release the firmware and driver code once it's working. I was thinking of all that stuff to protect it but to be honest that's just is a hassle. I'm going to just trust that people will choose to support the vendors that kick back a small fee. Or even better maybe they'll mine a few hours for me by their own choice. I'll put the mine-to address out there when it's time. I'm getting a lot of help/support from forum members here and I think it's better to respect that by not having locked code at all.
No ETA. Other than it's looking probable that when chips arrive I'll be ready to test them. That means probably a few weeks. It still looks feasible to be ready for bulk chip arrivals.
|
|
|
|
KS
|
|
May 31, 2013, 10:15:20 AM |
|
Possibly but then again possibly not. The SATA connector was not chosen because it needed 1.5A per pin and parts were available with only 1A or in 15+7 form (power+data) and ended up costing more than the PCI-E. The Molex can push 11A per pin. You might even be able to use a Molex splitter (you'd still be testing the power limits though).
|
|
|
|
terrahash
Member
Offline
Activity: 86
Merit: 10
|
|
May 31, 2013, 10:33:56 AM |
|
I'm going to release the firmware and driver code once it's working. I was thinking of all that stuff to protect it but to be honest that's just is a hassle. I'm going to just trust that people will choose to support the vendors that kick back a small fee. Or even better maybe they'll mine a few hours for me by their own choice. I'll put the mine-to address out there when it's time. I'm getting a lot of help/support from forum members here and I think it's better to respect that by not having locked code at all.
That's awesome. I have a lot of experience in micro-controller programming. I have a MicroChip universal programmer, and just received the module for PIC16LF1459-I/SS, and a few chips. I can help with programming, so let me know if you need any help both for the controller and cgminer driver. Just so you know, we will still be paying a license fee to you for every board we sell.
|
|
|
|
Bicknellski
|
|
May 31, 2013, 10:41:34 AM |
|
I'm going to release the firmware and driver code once it's working. I was thinking of all that stuff to protect it but to be honest that's just is a hassle. I'm going to just trust that people will choose to support the vendors that kick back a small fee. Or even better maybe they'll mine a few hours for me by their own choice. I'll put the mine-to address out there when it's time. I'm getting a lot of help/support from forum members here and I think it's better to respect that by not having locked code at all.
That's awesome. I have a lot of experience in micro-controller programming. I have a MicroChip universal programmer, and just received the module for PIC16LF1459-I/SS, and a few chips. I can help with programming, so let me know if you need any help both for the controller and cgminer driver. Just so you know, we will still be paying a license fee to you for every board we sell. +1 Terrahash +1 BKKCoins Yes same here. I think the easiest way for me will be burn in hash and get fees to him that way and to for mining software developers as well. Hoping to get the MPBM working on the boards I make here with TheSeven's help.
|
|
|
|
Ente
Legendary
Offline
Activity: 2126
Merit: 1001
|
|
May 31, 2013, 11:29:27 AM |
|
Anyone know how the chips are supplied in reel or tray? In avalon specs do not mention this I'm sure it won't be in a reel; most likely a tray, The samples might be in a tube. I found these pictures from asicminer asic's. https://bitcointalk.org/index.php?topic=99497.msg2268332#msg2268332 Bitfountain uses TMSC foundry too. And friedcat told me "Our chips use 6mmx6mm QFN40 package." while avalons are 7x7mm. So i think its possible that all chips come in tubes. I mean the tubes could easily be put into a packet and shipped. And i think the reason why the sample chips per batch are exactly 30 are that the tubes contain 30 chips... at least AM's tubes contained 30 too. I have to know too how avalon ships because i have to buy the needed packaging for my groupbuy... Good work, sherlock! :-) Ente
|
|
|
|
sensei
|
|
May 31, 2013, 12:37:46 PM |
|
I really like the hashing idea as well. Every board I manufacture here needs to be tested before shipping. I can mine for a few hours to test to bkk's address or whatever is required.
|
|
|
|
evilscoop
|
|
May 31, 2013, 12:41:35 PM |
|
I had the same thought... There will def be a % of my testing phase going to bkk
|
|
|
|
kano
Legendary
Offline
Activity: 4620
Merit: 1851
Linux since 1997 RedHat 4
|
|
May 31, 2013, 12:42:23 PM |
|
BkkCoins, Are you sure the firmware can handle everything ok? It only has 1Kbytes of SRAM. I'm about to order boards for the Quarter Stick DIY and I wanted to make sure.
thanks.
I believe so. Work so far indicates that it will be very close with a work queue of 4 items (192 bytes), and a 108 byte buffer for pushing work. So if it gets too tight for that I may have to drop to only 2 work items queued. Compiled with the USB stack it's using about half the RAM, without my code and work queue, (and 727 bytes with my code but no push buffer yet), but I also think that could be optimized and reduced a some if really need be (the stack seems a little bloated in C instead of assembly. I can't fathom why they didn't do it in assembly for something that could be included in every PIC - though maybe they expect their users to optimize their own versions). By slowing down the push-work a bit with a buffer switch mid-way, I could cut 48 bytes and keep the queue at 4 but I haven't gone over everything looking to optimize RAM. Also, I haven't tried the Pro XC-8 yet. Apparently it cuts down a lot of code space, though whether it can get much better at RAM use is questionable. I'll have a better estimate later this afternoon after I integrate in the "push work" assembly code. I'd code everything in assembler before giving up. An output queue also reduces the work required by the miner dramatically. The BFL SC code we wrote has an independent thread that simply checks for results and times those checks to attempt to minimise the polling - this makes the process of getting results optimal in the extreme. If we know the queue is 2 (or 4 or 8 ) in size then we know we only have to poll at most twice per expected result (or even less if the time per result is less than 100ms) to ensure work is getting returned and the queue isn't filling up If, on the other hand, there is no queue, then we need to poll as required to avoid losing results and to keep synchronisation - and 'as required' can be good or bad depending on how the output works.
|
|
|
|
BkkCoins (OP)
|
|
May 31, 2013, 12:53:27 PM |
|
An output queue also reduces the work required by the miner dramatically.
The BFL SC code we wrote has an independent thread that simply checks for results and times those checks to attempt to minimise the polling - this makes the process of getting results optimal in the extreme.
If we know the queue is 2 (or 4 or 8 ) in size then we know we only have to poll at most twice per expected result (or even less if the time per result is less than 100ms) to ensure work is getting returned and the queue isn't filling up If, on the other hand, there is no queue, then we need to poll as required to avoid losing results and to keep synchronisation - and 'as required' can be good or bad depending on how the output works.
I currently have a result queue of 2 items. But when a result occurs I send it off via USB and the queue is mostly in case another result occurs before the first one has been accepted/cleared. Is there no way with libusb to put a hook on received data so that when something arrives it can callback one of the driver functions? That would seem ideal to me as then you never have to poll - just write a handler for result data as it arrives. I've coded a variant of the bflsc identify function for klondike. I haven't got back to do more yet. I added an I cmd in firmware to output an identity record with serial# and product code. I'm sure I can get more of the driver functions filled in over the next few days.
|
|
|
|
menace_one
Newbie
Offline
Activity: 32
Merit: 0
|
|
May 31, 2013, 01:14:27 PM |
|
Hello, i have a simple question for real life use case. will it be possible to connect different ASIC plattforms (e.g. your an Burnins Board) to the same host (single/multiple cgminer instances)?
thanks
p.s. +1 mining to your address for a couple of hours
|
|
|
|
kano
Legendary
Offline
Activity: 4620
Merit: 1851
Linux since 1997 RedHat 4
|
|
May 31, 2013, 01:21:20 PM |
|
An output queue also reduces the work required by the miner dramatically.
The BFL SC code we wrote has an independent thread that simply checks for results and times those checks to attempt to minimise the polling - this makes the process of getting results optimal in the extreme.
If we know the queue is 2 (or 4 or 8 ) in size then we know we only have to poll at most twice per expected result (or even less if the time per result is less than 100ms) to ensure work is getting returned and the queue isn't filling up If, on the other hand, there is no queue, then we need to poll as required to avoid losing results and to keep synchronisation - and 'as required' can be good or bad depending on how the output works.
I currently have a result queue of 2 items. But when a result occurs I send it off via USB and the queue is mostly in case another result occurs before the first one has been accepted/cleared. Is there no way with libusb to put a hook on received data so that when something arrives it can callback one of the driver functions? That would seem ideal to me as then you never have to poll - just write a handler for result data as it arrives. I've coded a variant of the bflsc identify function for klondike. I haven't got back to do more yet. I added an I cmd in firmware to output an identity record with serial# and product code. I'm sure I can get more of the driver functions filled in over the next few days. The BFL protocol works as a polling protocol (so yeah not the best, but because they have a 20 output queue it's not really a problem) Of course we could write a very different driver that has a separate thread that simply waits for ALL results on a single end point and processes them based on the results type - and other thread(s) send out requests as needs and wait on replies from the results thread. Probably even better that any of the current I'm just not sure if that would work on the same endpoint pair sending the requests. If there were multiple end point pairs (like the FTDI 0x8350) then that may be it? I'm not sure until I try it. At the moment there is no real MCU protocol that would suit that on any other device yet (but I haven't looked closely at the Avalon code so I'm not sure in detail how that handles replies, I just helped with the USB code and the new cgminer usb library) but if that works with a chip with only a single end point pair (or if not, use something like the FTDI 0x8350 with 4 endpoint pairs) then that may be even better. But again I don't know coz I don't have any devices that use this, the Cairnsmore1 does use the FTDI 0x8350 on the recent boards, but I don't have one to test.
|
|
|
|
kano
Legendary
Offline
Activity: 4620
Merit: 1851
Linux since 1997 RedHat 4
|
|
May 31, 2013, 01:23:50 PM |
|
Hello, i have a simple question for real life use case. will it be possible to connect different ASIC plattforms (e.g. your an Burnins Board) to the same host (single/multiple cgminer instances)?
thanks
p.s. +1 mining to your address for a couple of hours
Yes, cgminer can run multiple devices at the same time. I can run 7 different devices on a single cgminer: 1xJalapeno, 1xAsicminer USB, 1xBlack Arrow Lancelot, 1xModMinerQuad, 1xIcarus, 1xBFL FPGA Single, 1xATI 6950 GPU
|
|
|
|
Sophokles
|
|
May 31, 2013, 01:38:42 PM |
|
I'm going to release the firmware and driver code once it's working. I was thinking of all that stuff to protect it but to be honest that's just is a hassle. I'm going to just trust that people will choose to support the vendors that kick back a small fee. Or even better maybe they'll mine a few hours for me by their own choice. I'll put the mine-to address out there when it's time. I'm getting a lot of help/support from forum members here and I think it's better to respect that by not having locked code at all.
Great idea ! I will certainly point some of my miners towards your donation address, as soon as they are working. Thanks for your great efforts in supporting the community !
|
|
|
|
sensei
|
|
May 31, 2013, 03:08:29 PM |
|
@BkkCoins It looks like the PIC16LF1459-I/SS in the TSSOP is in short supply do you have a source for this part? Is there similar PIC chip that might work in its place? Thanks!
Yes, the PIC16LF1459-I/ML is the QFN version of the part and in stock. There will be a version of each of the Klondike boards with this footprint so this part can be substituted.
|
|
|
|
|