Liquid Synergy Designs Inc. -ASIC mining hardware

[hoss]

https://tradehill.com/auctions

Zero bids so far - sorta makes me happy/sad at the same time.

Bottom line is even these gen2 55nm chips from avalon can't even hold up to current bitfury 55nm chips

AVALON 55nm GEN2 1.5-1.6 GH/s    2.0W
BITFURY 55nm ASIC chips, Demonstrated performance 2.7 GH/sec @ 0.835V (0.8W/Ghps) (quoting this link: https://bitcointalk.org/index.php?topic=266235.0 )

For BOTH of the above estimates I have not seen real life 'proof' of values. However, in any case buying form these Avalon G2 chips seem stupid unless they are almost given away for free ( or a perfect drop in replacement for the 110nm chips).
 
The sad part for me is that I was hoping for an awesome gen2 pin/chip compatible to solder on to my over $4k pre ordered K16 boards. I hear these G2 chips require board modifications! ( can the steamboat camp confirm this? ).   In any case I project these new chips would need to come down to about 5BTC per 500chips (now - as in now now before next 100mill diff jump) just to have a potential breakeven on ROI with my pre ordered $4k k16s.

Other thoughts - can we mount BITFURY chips on the K16s?

I will post again after a good night sleep.....

 

[1714884635]

1714884635

[1714884635]

1714884635

[1714884635]

1714884635

[1714884635]

1714884635

[1714884635]

1714884635

[fasmax]

https://tradehill.com/auctions

Zero bids so far - sorta makes me happy/sad at the same time.

Bottom line is even these gen2 55nm chips from avalon can't even hold up to current bitfury 55nm chips

AVALON 55nm GEN2 1.5-1.6 GH/s    2.0W
BITFURY 55nm ASIC chips, Demonstrated performance 2.7 GH/sec @ 0.835V (0.8W/Ghps) (quoting this link: https://bitcointalk.org/index.php?topic=266235.0 )

For BOTH of the above estimates I have not seen real life 'proof' of values. However, in any case buying form these Avalon G2 chips seem stupid unless they are almost given away for free ( or a perfect drop in replacement for the 110nm chips).
 
The sad part for me is that I was hoping for an awesome gen2 pin/chip compatible to solder on to my over $4k pre ordered K16 boards. I hear these G2 chips require board modifications! ( can the steamboat camp confirm this? ).   In any case I project these new chips would need to come down to about 5BTC per 500chips (now - as in now now before next 100mill diff jump) just to have a potential breakeven on ROI with my pre ordered $4k k16s.

Other thoughts - can we mount BITFURY chips on the K16s?

I will post again after a good night sleep.....

 

Unfortunately the gen2 chip is not pin compatible with gen1.
I don't see much hope that SB will be able to integrate or make use of the gen2 chips.
Some K16 parts could be used in a new design but I don't see that happening at this point.

Same story for the BITFURY chips.

[laughingbear]

Any news on the status, for those of us that are waiting on fully finished units?

[ionstorm]

I am getting allot of KLNX:X went idle before work was sent messages, why does this happen and how can it be avoided?

[zipiju]

I am getting allot of KLNX:X went idle before work was sent messages, why does this happen and how can it be avoided?

There is a work buffer in firmware, and when CGM is sending new work data to the board and that buffer is empty, this message is shown.
It basically means nothing else than the board is idle when new work is pushed to it.
It can be probably avoided by increasing work buffer in firmware and CGM driver.

[Rakessh]

So it's hashing too fast? 

[Xian01]

I am getting allot of KLNX:X went idle before work was sent messages, why does this happen and how can it be avoided?

 Ditto. Also, seems to force an overheat sitatuion @ ~ 54C and ignores whatever I've set in --klondike-options clock:temp

 Running with "--klondike-options 325:65"

 Should I just ensure that these guys are in an environment that runs near 50C ?

[zipiju]

I am getting allot of KLNX:X went idle before work was sent messages, why does this happen and how can it be avoided?

 Ditto. Also, seems to force an overheat sitatuion @ ~ 54C and ignores whatever I've set in --klondike-options clock:temp

 Running with "--klondike-options 325:65"

 Should I just ensure that these guys are in an environment that runs near 50C ?

Temp in klondike-options is target temperature which firmware tries to hold by adjusting fan speed. It has nothing to do with overheat - this is a value in CGM driver. When that temperature is reached, CGM disables the board untill temperature falls to around 45°C.
You can edit it in CGM driver-klondike.c at line 63

#define KLN_KILLWORK_TEMP        53.5

Try to set it for example to 63.5 and recompile cgm.

[logicbomb666]

 Running with "--klondike-options 325:65"

Are these values usable in the conf file, or do you have to compile with this option?

[zipiju]

 Running with "--klondike-options 325:65"

Are these values usable in the conf file, or do you have to compile with this option?

You can start CGM with those values or place them in config. There is no such option when compiling.

[Xian01]

Temp in klondike-options is target temperature which firmware tries to hold by adjusting fan speed. It has nothing to do with overheat - this is a value in CGM driver. When that temperature is reached, CGM disables the board untill temperature falls to around 45°C.
You can edit it in CGM driver-klondike.c at line 63

#define KLN_KILLWORK_TEMP        53.5

Try to set it for example to 63.5 and recompile cgm.

 TYVM for this. Very helpful.

[ionstorm]

Got 7 Fusion 16's running at 40-45Ghs


Any tips on improving the speed and keeping temps down?

[steamboat]

Update:
 
With the addition of the latest revisions to CGM, we have several test units running stable for several days using the latest firmware, with error rates less than .001%.
 
We are nearing completion of the USB bootloader, and have discovered a potentially serious issue. We believe we will be successful in porting a bootloader for use with the onboard PIC16 controller, but may not be able to install it and the board firmware at the same time due to memory constraints. The PIC16 has 16k of available memory. Our calculations estimate the finished bootloader will consume roughly 4k of the available memory, which will not leave enough room for the firmware in its present state. We have begun removing unused portions of the firmware code to reduce its size, and will be testing pro versions of the Microchip compiler to further reduce its size, but it is currently unclear as to whether or not this will be enough.
 
While we will continue to do everything in our power to deliver full functionality to the units, our options are limited by the design, and there is a real possibility the hardware simply will not be able to support a USB bootloader. As such, if the ability to update the firmware via usb or chain the units via the I2C connector is not a priority for you, the best option at this point may be to request shipment of the units as-is.
 
As before, to request your units be shipped as-is, without the ability to update the firmware via USB, please ensure the shipping address provided on your liquidsyndesigns.com account is correct, and reply to this email with the subject “Please ship my units without USB bootloader”.
 
Hosting:
 
We have begun setting up hosting for those customers who have purchased this service. Several modifications were necessary due to the unfinished I2C functionality, as well as the lack of individually serialized units. With the arrival of additional hardware and successful testing of the latest firmware, we are now building out the cluster. We have had to modify our original hosting design completely, which is now complete. Additional information and instructions will be sent to those with hosted units.
 
Assembly refunds:
 
Many of you are still waiting for information regarding the assembly refund process. We understand the wait is aggravating, and appreciate your patience in this matter. Our resources are finite, and the work load for this project has increased substantially due to reasons outside our control. We will be publishing more information when we are able, and can assure you the solution will be as fair as possible. You will not be punished for our lack of timely response in this matter.

[logicbomb666]

 Running with "--klondike-options 325:65"

Are these values usable in the conf file, or do you have to compile with this option?

You can start CGM with those values or place them in config. There is no such option when compiling.

Now that I used the option, the miners are listed, but not actually mining.  what the crud?  I just used --klondike-options 350:60.  I dont know why they would stop completely.


EDIT:  looks like I am getting the "KLNX:X went idle before work was sent" messages.  I knew I should have left them alone the second they starting working in the first place.

[Keefe]

Thanks for the update steamboat! It's good to hear exactly what's still being worked on.

[logicbomb666]

Ok, got them working again.  I'm pleased with results. (with exception to current difficulty of course) 

[rascal777]

If I get the units shipped in their current state, that means
1.  No chaining units. I2C not working.  So, can I use a USB hub and just plug every unit in via usb and that works fine?

2.  No bootloader.   So that means that I cannot easily download new firmware, I have to use a special pickit controller?  So, say a firmware with a bootloader got created, I would have to solder a header onto the board for a PICkit controller, then use the controller to download the firmware to each board?

I'm fact checking here.  Anyone who can verify, please go for it.

[rammy2k2]

Any news on the status, for those of us that are waiting on fully finished units?

+1

[Unacceptable]

If I get the units shipped in their current state, that means
1.  No chaining units. I2C not working.  So, can I use a USB hub and just plug every unit in via usb and that works fine?

2.  No bootloader.   So that means that I cannot easily download new firmware, I have to use a special pickit controller?  So, say a firmware with a bootloader got created, I would have to solder a header onto the board for a PICkit controller, then use the controller to download the firmware to each board?

I'm fact checking here.  Anyone who can verify, please go for it.

To your first point: Correct,no chaining as of now,& yes a hub works just fine  

Second point:You'll need a Pickit3,its the red one,no soldering,the "pads" on are back by the USB port.You will need a POGO adapter.

http://www.ebay.com/sch/i.html?_trksid=p2050601.m570.l1313.TR3.TRC1.A0&_nkw=PICkit+3&_sacat=0&_from=R40

Edit:All info should be here:

http://projectklondike.org/how-to-program

[cardcomm]

Thanks for the update, Steamboat. It's very much appreciated.

I have to hand it to you, you've done a great job in a terrible situation. From what I see and read, you've done really nice work salvaging the project and producing the boards.

I know I've been very vocal here, and also somewhat negative at times. Obviously, my main issue has been with lack of communication. I DO realize you've had your reasons though.

So, thanks again for sticking it out through the mess. The outcome has been far from what we all hoped it could be, but I do believe you've done your best for us all. I'm certainly disappointed that I didn't get miners, but that's life.

I'll try and be patient for the next little while waiting for the assembly refund announcement.