Liquid Synergy Designs Inc. -ASIC mining hardware

[RogueLeader]

When my shipment of Klondikes came, I ran out to the nearest discount store and grabbed a handful of iHome 4-port hubs for five bucks each.  It'd be nicer to have fewer hubs, but they are doing the job all the same.  FWIW, some of them are connected to USB3 ports on the host PC.

I recompiled cgminer 3.7.2 with line ~63 changed to:

Code:

#define KLN_KILLWORK_TEMP   61.5 

and now my miners are no longer getting temperature-throttled by cgminer, been running rock solid all day at 350 MHz.  My temps are hovering in the low-to-mid 50s, so the recompile was necessary for me.  Might experiment with further OC'ing in the near future.

I also modified line ~1023 to:

Code:

                                applog(LOG_INFO, "%s%i:%d went idle before work was sent",

I was not infrequently seeing that message from cgminer. It seems important but I noticed my effective hashrate hasn't been negatively impacted.  It was coming often enough to really muck up my logfile, so I disabled it by giving it LOG_INFO priority, instead of LOG_WARNING.  Anyone else seeing a lot of this message?

[1714958073]

1714958073

[1714958073]

1714958073

[1714958073]

1714958073

[rascal777]

"%s%i:%d went idle before work was sent"

I am seeing a lot of this message and was wondering if it would be worth it to recompile with better parameters, if the hash rate would be affected.

Basically the way that I understand it, is that the pending work buffers on the klondike were empty when new work was sent to the Klondike.  So essentially the K16 was either busy working on the last work sent, or was sitting idle waiting for new work.

[cardcomm]

If time is of the essence because of the btc  to usd rate then arbitrage right now.   Say you expect to get $1000  refund,  just buy $1000  in  Bitcoins and then when you get the refund sell those to usd.

Little too late for that. Why should we bear the brunt of the price increase when we've been waiting for months for our refunds?

I saw this same scenario play out when bASIC collapsed.

Everywhere I look people are getting scammed out of BTC, having them stolen, or other wise losing them in unanticipated ways. Whats the latest, lots of people losing money because Inputs.io was hacked?

It's getting really tiresome. I'll admit I'm increasingly disillusioned with BTC in it's current form. Once I get my "small change" back from the assembly leftovers here, I'll prolly give BTC a break for a while.

[zipiju]

When my shipment of Klondikes came, I ran out to the nearest discount store and grabbed a handful of iHome 4-port hubs for five bucks each.  It'd be nicer to have fewer hubs, but they are doing the job all the same.  FWIW, some of them are connected to USB3 ports on the host PC.

I recompiled cgminer 3.7.2 with line ~63 changed to:

Code:

#define KLN_KILLWORK_TEMP   61.5 

and now my miners are no longer getting temperature-throttled by cgminer, been running rock solid all day at 350 MHz.  My temps are hovering in the low-to-mid 50s, so the recompile was necessary for me.  Might experiment with further OC'ing in the near future.

I also modified line ~1023 to:

Code:

                                applog(LOG_INFO, "%s%i:%d went idle before work was sent",

I was not infrequently seeing that message from cgminer. It seems important but I noticed my effective hashrate hasn't been negatively impacted.  It was coming often enough to really muck up my logfile, so I disabled it by giving it LOG_INFO priority, instead of LOG_WARNING.  Anyone else seeing a lot of this message?

Guys, you can significantly reduce the "went idle" states by modifying two defines in cgm driver. I've talked about that in K16 thread, but if anyone missed it there, check http://projectklondike.org/how-to-run#went-idle.

[bigtimespaghetti]

Any one else receive their miners with a rather messy paste job?

[Unacceptable]

Well,it took several "rearrangements" to get the temps down,but I FINALLY got em working in Win7 with just a bat file  

This is what worked,I LOVE Zipties    :







I get those "went idle before work was sent" things too,but dosen't seem to bother my pool hashrate......................

Finally found a use for those old Floppy drives  

[logicbomb666]

nice idea for stacking/arrangement. I might have to set mine up like that too.

[eroxors]

Steamboat, will you please allow the transfer of assembly services so that more boards can be produced at a lower price?

[RogueLeader]

When my shipment of Klondikes came, I ran out to the nearest discount store and grabbed a handful of iHome 4-port hubs for five bucks each.  It'd be nicer to have fewer hubs, but they are doing the job all the same.  FWIW, some of them are connected to USB3 ports on the host PC.

I recompiled cgminer 3.7.2 with line ~63 changed to:

Code:

#define KLN_KILLWORK_TEMP   61.5 

and now my miners are no longer getting temperature-throttled by cgminer, been running rock solid all day at 350 MHz.  My temps are hovering in the low-to-mid 50s, so the recompile was necessary for me.  Might experiment with further OC'ing in the near future.

I also modified line ~1023 to:

Code:

                                applog(LOG_INFO, "%s%i:%d went idle before work was sent",

I was not infrequently seeing that message from cgminer. It seems important but I noticed my effective hashrate hasn't been negatively impacted.  It was coming often enough to really muck up my logfile, so I disabled it by giving it LOG_INFO priority, instead of LOG_WARNING.  Anyone else seeing a lot of this message?

Guys, you can significantly reduce the "went idle" states by modifying two defines in cgm driver. I've talked about that in K16 thread, but if anyone missed it there, check http://projectklondike.org/how-to-run#went-idle.

That's great, thanks!

[rascal777]

SO, what would be the cause of the K16 only putting out hardware errors?

I have a couple like that.  Any ideas?

[chadtn]

SO, what would be the cause of the K16 only putting out hardware errors?

I have a couple like that.  Any ideas?

Mine did that once when I was in the process of setting them up.  Power cycling fixed the problem and I haven't had it happen again.  They can be a pain getting to run some times.  Any time I stop mining on them I have to power cycle and reconnect the fans or I just get connection errors.

Chad

[RogueLeader]

Yep, any time a unit just spits HW errors upon starting, I disconnect its power cable and let it sit for a couple minutes.  When I reconnect it (and dis/reconnect fan), it hashes just fine.  This can be done without restarting cgminer, so if you have other units, they can hash away during the waiting period.  It probably happens 5-10% of the time, but only at the outset of a mining session; long mining uptime is key to minimizing this extra effort.

[cardcomm]

Just out of curiosity, is anyone selling their assembled miners? Wondering what they are selling for, if at all.

[bigtimespaghetti]

Just out of curiosity, is anyone selling their assembled miners? Wondering what they are selling for, if at all.

Going for about £140 on ebay as far as I can tell. That was not with the miners actually in hand, may be slightly more. I'm selling one or two to cover the import duty and subsidize the assembly costs and then gonna mine with the remaining ones for fun.

[intense]

Correct me if I'm wrong but this is what I've gathered from following this thread regarding the assembly / parts / shipping refunds.

Before avalon delayed their chip orders (by selling them to the Chinese instead of those who paid for them, the difficulty increase supports this theory) and crushed any potential of profits for us, steamboat was busy organizing parts in advance so that there would be minimal down time between receiving the chips and getting the miners out the door and on their way.

So all of those who didn't opt for a refund and got their k16's would have had them assembled using this stock pile of parts.

What we need to know is how many parts were prepaid in advance, how many have been used to create the shipped k16's and what is the difference, if stock has run out that's good news for those of us who have opted for a refund as the paid btc would not have been cashed in and should still remain.

So what is the best course of action from here?

I and everyone else in this group buy would like to see the numbers:

How many parts were purchased / stockpiled in anticipation of the avalon chips arriving?
How many k16's have been assembled and shipped using these parts?
Was assembly prepaid? If so, how many units were prepaid for assembly and how many have been shipped?

Whatever the remaining balance should be divided up amongst all of those who opted for a chip refund and also paid for parts / assembly / hosting / shipping.

[paulthetafy]

Personally I'd just like to know why fuck my miner isn't sat in the hosted datacenter hashing away.  This whole group buy is a joke. 

[KS]

AFAIk, Steamboat bought parts for 3000 miners but sold only 2400 before this whole debacle, so he already lost on 1/5th before refunds.

I hope what he's doing is selling back the parts on the open market or getting RMA's from his suppliers (you usually can do that on parts that are still followed in stock, YMMV).

[rascal777]

Mine did that once when I was in the process of setting them up.  Power cycling fixed the problem and I haven't had it happen again.  They can be a pain getting to run some times.  Any time I stop mining on them I have to power cycle and reconnect the fans or I just get connection errors.

Chad

Yep, any time a unit just spits HW errors upon starting, I disconnect its power cable and let it sit for a couple minutes.  When I reconnect it (and dis/reconnect fan), it hashes just fine.  This can be done without restarting cgminer, so if you have other units, they can hash away during the waiting period.  It probably happens 5-10% of the time, but only at the outset of a mining session; long mining uptime is key to minimizing this extra effort.

Cycling the power and reconnecting the fans as well as doing all this after restarting cgminer doesn't work for me.

I have 7 on a machine, maybe there is a driver limit to how many I can connect?  I'm going to try and just plug up the ones that have 100% hardware errors...

[FCTaiChi]

Has steamboat posted recently?

I'm trying to catch up on some of the 'older' companies on my list, trying to figure out what everyone is up to.  I realize none of the listed items are in stock, and I am trying to figure out what I can remove from the main list.

[bigtimespaghetti]

Correct me if I'm wrong but this is what I've gathered from following this thread regarding the assembly / parts / shipping refunds.

Before avalon delayed their chip orders (by selling them to the Chinese instead of those who paid for them, the difficulty increase supports this theory) and crushed any potential of profits for us, steamboat was busy organizing parts in advance so that there would be minimal down time between receiving the chips and getting the miners out the door and on their way.

So all of those who didn't opt for a refund and got their k16's would have had them assembled using this stock pile of parts.

What we need to know is how many parts were prepaid in advance, how many have been used to create the shipped k16's and what is the difference, if stock has run out that's good news for those of us who have opted for a refund as the paid btc would not have been cashed in and should still remain.

So what is the best course of action from here?

I and everyone else in this group buy would like to see the numbers:

How many parts were purchased / stockpiled in anticipation of the avalon chips arriving?
How many k16's have been assembled and shipped using these parts?
Was assembly prepaid? If so, how many units were prepaid for assembly and how many have been shipped?

Whatever the remaining balance should be divided up amongst all of those who opted for a chip refund and also paid for parts / assembly / hosting / shipping.

+1

Good luck with getting that kind of transparency though. I fully expect SB et al priorities are on covering their costs and clawing out a small amount of profit for themselves. Screw the people that wanted refunds and ended up with miners. At least that's my conclusion.

I have no problem with covering their costs, and I wouldn't have minded taking a hit for all the guys that helped make this possible, until I was cut off from getting a refund. It's probably too much to expect getting anything back from this outside of what has been stated. SB could have repeatedly salvaged this, but has made some strange and downright bad decisions.

I'd love to be pleasantly surprised though.