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.
Topic: Liquid Synergy Designs Inc. -ASIC mining hardware - page 39. (Read 423279 times)
Wow, thanks. I'll try that out tonight.
That should be in Raspbian to begin with IMO.
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
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.
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.
Yes morris14ccm, Plug it in to the PSU and USB to Computer. Download CGMiner 3.7.0 and run it.
running 360MHz stable
running 360MHz stable
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?
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.
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
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.
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
. 
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...
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.
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
Thanks!
Chad
And yes, it should be in one line.
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
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.
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
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.
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
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
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
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
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
Thanks!
Chad
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 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.
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...
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.
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
BTC payments were instantly converted to dollars by BitPay so SB could pay suppliers in dollars.
I can almost guarantee refunds are going to be processed in dollars, then converted to BTC (with unfavorable results for us). The exchange rate was miserably low when I paid, because like others I was trying to meet the deadline SB had laid out. And I'll likely be punished for that...
I can almost guarantee refunds are going to be processed in dollars, then converted to BTC (with unfavorable results for us). The exchange rate was miserably low when I paid, because like others I was trying to meet the deadline SB had laid out. And I'll likely be punished for that...
That will almost certainly cause a shitstorm. He's already talking about keeping 75% of our assembly costs. Throw in a screw job on the exchange rate, and my assembly funds would be just plain gone.
Hell, do enough voodoo with the exchange rate, and we could all end up owing SB money! ROFL!
This just keeps on getting better and better, eh?
It's _almost_ like this was a high risk investment--I sure wish someone told me that before I consciously sent a stranger on the Internet money! Oh well, maybe I'll learn my lesson one day, and take the wins with the losses....
[edit; grammar is hard]
I agree, I'm not happy about making a loss, but I did know full well how risky this was.
Attn - Steamboat, (or others that can answer the below questions.)
I have hosted miners, presumably soon to be running in the data centre.
Just wanted to know the procedure with regard to transferring title to a third party, and if hosting or shipping can then be decided on by said third party.
I know a bit of it has been covered in the thread, but there has been no concrete info recently on the hosting, payment addresses for payouts etc.
Thanks
Adam
I have hosted miners, presumably soon to be running in the data centre.
Just wanted to know the procedure with regard to transferring title to a third party, and if hosting or shipping can then be decided on by said third party.
I know a bit of it has been covered in the thread, but there has been no concrete info recently on the hosting, payment addresses for payouts etc.
Thanks
Adam
Jump to: