Liquid Synergy Designs Inc. -ASIC mining hardware

[Rakessh]

I just hope to god SB tax declared it as valueless, or very low value, similar to the refund value or something... (ie paperweight of educational value only) or I have to pay another 200 bucks in VAT on import... that's gonna suck balls... I may consider just refusing to collect the shipment and let it return to Steamboat if that is the case...

It arrives tomorrow, so we'll see...

Yep, I got fucked.  245 USD in value added tax.  I'm not going to collect, so SB probably have to fork out return postage when the miners arrive back in Miami.

Sweet... I paid close to 1500 USD and got nothing to show for.

Steamboat, your goods deprecated close to 90% in value between payment and shipping the miners, why didn't the tax/export form reflect this... I can't take delivery of the miners now. Sorry.

[ionstorm]

I dont see myself earning more that $500 with my 8 Klondike's.  They are running perfectly and are so well made, what a shame, hopefully I can off these on eBay after a month or two or bitcoin doubles in price.

[chadtn]

Guys, if your Pi is freezing while running CGM (complete freeze with ethernet, usb etc), read this http://projectklondike.org/how-to-run#rpi-freeze

I can't believe I missed that on the website.  I just added the slub line in and moved one of my K16's over to test out the change.  I have no idea what kernel version I was running before, but I ran update & upgrade right before I installed the K16's.  That was the first time I had done this since I started mining on the pi a couple of months ago.  3.6.11+ is the kernel I was running when the crashes started.  I'll report back later with my results.

Thanks so much for all of your help and work zipiju!!

Chad

[chadtn]

It only ran for about five minutes before crashing with one K16 installed.  The pi ran stable while not mining for the last 12 hours or so.  Is there a command to verify that I edited cmdline.txt correctly?  I added slub_debug=FP on it's own fresh line.  Should I have just stuck it on the end of that long string of text instead?

Thanks!

Chad

[ionstorm]

I tried running these just now briefly At 375mhz and 383mhz, both settings returned 0ghs, what could be the issue?  They run fine on 350mhz and below.

Also what are the hard coded and supported frequencies? Can I choose like 355 and move on up to see how they perform? I got these running at 39-40c at 350mhz and can probably push them

[chadtn]

I tried running these just now briefly At 375mhz and 383mhz, both settings returned 0ghs, what could be the issue?  They run fine on 350mhz and below.

Also what are the hard coded and supported frequencies? Can I choose like 355 and move on up to see how they perform? I got these running at 39-40c at 35mhz and can probably push them

Mine do the same thing when I try 375mhz.  I asked zipiju about it in the Klondike thread and here is what he said:

The current draw from the 1.2V regulators is probably too high and they are shutting down as soon as clock signal is enabled to the chips - which is with first work item. So try something lower, like 370 or 365 and it should work.

Chad

[zipiju]

It only ran for about five minutes before crashing with one K16 installed.  The pi ran stable while not mining for the last 12 hours or so.  Is there a command to verify that I edited cmdline.txt correctly?  I added slub_debug=FP on it's own fresh line.  Should I have just stuck it on the end of that long string of text instead?

Thanks!

Chad

It's probably not mentioned at the site, but you have to reboot after you change that file.
And the boot partition should be mounted when you're editing that file. You can do "mount | grep boot", and if it shows something like /dev/mmcblk0p1 on /boot type vfat (rw,noatime), it is mounted, otherwise it's not.
If it's not, you have to mount the boot partition - "mount /boot" should be enough if fstab is correctly set.
Then edit that file again. Save and reboot.

[zipiju]

I tried running these just now briefly At 375mhz and 383mhz, both settings returned 0ghs, what could be the issue?  They run fine on 350mhz and below.

Also what are the hard coded and supported frequencies? Can I choose like 355 and move on up to see how they perform? I got these running at 39-40c at 350mhz and can probably push them

You can even choose 351 or 349 - basically it supports 1MHz steps. Firmware will accept frequencies up to 450, which is kinda overshooted, but it was set like that by Chris.

[zipiju]

It only ran for about five minutes before crashing with one K16 installed.  The pi ran stable while not mining for the last 12 hours or so.  Is there a command to verify that I edited cmdline.txt correctly?  I added slub_debug=FP on it's own fresh line.  Should I have just stuck it on the end of that long string of text instead?

Thanks!

Chad

And yes, it should be in one line.

[bigtimespaghetti]

I just hope to god SB tax declared it as valueless, or very low value, similar to the refund value or something... (ie paperweight of educational value only) or I have to pay another 200 bucks in VAT on import... that's gonna suck balls... I may consider just refusing to collect the shipment and let it return to Steamboat if that is the case...

It arrives tomorrow, so we'll see...

Yep, I got fucked.  245 USD in value added tax.  I'm not going to collect, so SB probably have to fork out return postage when the miners arrive back in Miami.

Sweet... I paid close to 1500 USD and got nothing to show for.

Steamboat, your goods deprecated close to 90% in value between payment and shipping the miners, why didn't the tax/export form reflect this... I can't take delivery of the miners now. Sorry.

Ah crap. I was hoping to avoid a huge duty. Well, mine arrived in the UK, I'll know the damage soon enough.

[zipiju]

Guys, if your Pi is freezing while running CGM (complete freeze with ethernet, usb etc), read this http://projectklondike.org/how-to-run#rpi-freeze

I can't believe I missed that on the website.  I just added the slub line in and moved one of my K16's over to test out the change.  I have no idea what kernel version I was running before, but I ran update & upgrade right before I installed the K16's.  That was the first time I had done this since I started mining on the pi a couple of months ago.  3.6.11+ is the kernel I was running when the crashes started.  I'll report back later with my results.

Thanks so much for all of your help and work zipiju!!

Chad

I've edited it on the site to make it more clear. And it wasn't there, I added that today after I read here that someone's pi is freezing, so you didn't missed that before .
Still work in progress .

[ionstorm]

I tried running these just now briefly At 375mhz and 383mhz, both settings returned 0ghs, what could be the issue?  They run fine on 350mhz and below.

Also what are the hard coded and supported frequencies? Can I choose like 355 and move on up to see how they perform? I got these running at 39-40c at 350mhz and can probably push them

You can even choose 351 or 349 - basically it supports 1MHz steps. Firmware will accept frequencies up to 450, which is kinda overshooted, but it was set like that by Chris.

thanks for the info, I seem to be running stable at 360mhz right now, gonna leave it like that a few hours, also, I get "KLN0:0 went idle before work was sent" spam, is this an issue or just a statement that it finished work from the pool?

[TomKeddie]

Firmware will accept frequencies up to 450, which is kinda overshooted, but it was set like that by Chris.

I think the 450 comes from Avalon, Chris just exported the limits from the chip.

[morris14ccm]

Should be getting the one K16 I ordered on Thursday. I don't need to hook it up to a RPi or anything special, right? I can just hook it up to my PSU and plug it in to my computer via USB?

[jesse11]

Yes morris14ccm, Plug it in to the PSU and USB to Computer. Download CGMiner 3.7.0 and run it.
running 360MHz stable 

[zipiju]

I tried running these just now briefly At 375mhz and 383mhz, both settings returned 0ghs, what could be the issue?  They run fine on 350mhz and below.

Also what are the hard coded and supported frequencies? Can I choose like 355 and move on up to see how they perform? I got these running at 39-40c at 350mhz and can probably push them

You can even choose 351 or 349 - basically it supports 1MHz steps. Firmware will accept frequencies up to 450, which is kinda overshooted, but it was set like that by Chris.

thanks for the info, I seem to be running stable at 360mhz right now, gonna leave it like that a few hours, also, I get "KLN0:0 went idle before work was sent" spam, is this an issue or just a statement that it finished work from the pool?

As I said before, it just means that when new work is being pushed to the K16 work buffer, that buffer was already empty (like the board is working on last work item or was idle for a while).
By default that buffer is 4 items long, but probably can be increased to like 8. I have that on to-do too, so when I'll test that and it will help and doesn't take too much space, I'll push it to the Git.

[Bogart]

Guys, if your Pi is freezing while running CGM (complete freeze with ethernet, usb etc), read this http://projectklondike.org/how-to-run#rpi-freeze

Wow, thanks.  I'll try that out tonight.

That should be in Raspbian to begin with IMO.

[chadtn]

Yes morris14ccm, Plug it in to the PSU and USB to Computer. Download CGMiner 3.7.0 and run it.
running 360MHz stable 

Adding slub to the end of cmdline.txt has my pi back up and running like it's old self again.  It's been hashing away without any problems for the last hour or so.  I started playing around with the clock settings and 360mhz was the highest value that my K16's would actually hash at.  What is weird is that at 360mhz they only hash at about half speed.  I get around 2.5 to 2.8 gigahashes at 360mhz.  The highest I can go on mine and still have full speed is 352mhz.  If I change it to 353mhz the hash rate drops dramatically.

Chad

[jesse11]

Yes morris14ccm, Plug it in to the PSU and USB to Computer. Download CGMiner 3.7.0 and run it.
running 360MHz stable 

Adding slub to the end of cmdline.txt has my pi back up and running like it's old self again.  It's been hashing away without any problems for the last hour or so.  I started playing around with the clock settings and 360mhz was the highest value that my K16's would actually hash at.  What is weird is that at 360mhz they only hash at about half speed.  I get around 2.5 to 2.8 gigahashes at 360mhz.  The highest I can go on mine and still have full speed is 352mhz.  If I change it to 353mhz the hash rate drops dramatically.

Chad

Every time you change the value of the clock speed you must reboot the K16's. I'm sure new firmware will fix this minor problem in the near future.  jesse11 

[zipiju]

Yes morris14ccm, Plug it in to the PSU and USB to Computer. Download CGMiner 3.7.0 and run it.
running 360MHz stable 

Adding slub to the end of cmdline.txt has my pi back up and running like it's old self again.  It's been hashing away without any problems for the last hour or so.  I started playing around with the clock settings and 360mhz was the highest value that my K16's would actually hash at.  What is weird is that at 360mhz they only hash at about half speed.  I get around 2.5 to 2.8 gigahashes at 360mhz.  The highest I can go on mine and still have full speed is 352mhz.  If I change it to 353mhz the hash rate drops dramatically.

Chad

Since the board uses two groups of 8 chips, and each group has it's own regulator, it is possible that regulator on one side (for one group) cant keep up with the other one - so one side is without power when clocked that high and another one is hashing. That would explain why you get half of the hashrate at higher clocks.