Topic: Swedish ASIC miner company kncminer.com - page 102. (Read 3049528 times)

So I have several sets of Titan Batch 2 cubes I got in june 2015, and they were brand new sealed in the box. 13 cubes have failed in different ways. Ive owned a few computer repairs shops over 20 years , so I have a ton of experience with thermal issues. So far I have 2 cubes with burned PCI-E connectors that I was able to restore and one cube that has 2 dies that read .8v (idle) that I tried the fix KNCminer kept saying would work, and that was to remove the single screw nearest the exhaust and remove the standoff too, and put a screw through a nut that is underneath the cube. The goal was to tighten the pressure on the heatsink. I had 8 cubes that had this issue and it did not work. All it did was start to bend the board in the middle. Ive applied my own fix after listening to KNCminer for over 45 days, and MY fix worked on the first cube I tried. So KNCminer now claim my warranty is void and refuse to help me. I will eventually repair all of these, and then file my class action suit to the tune of $70,000. Guys if you own ANY kncminer product, the deadline to file a lawsuit for the FULL amount YOU paid for them is August 20th 2015. I will be emailing everyone on this thread and letting them know. Im also optimizing my website for many keywords for google so others can see who KNCminer really are. My website bitcoinlasvegas.net is very high ranking on google as I get about 5000 visitors a week. Im already on page one for the search term "Kncminer Batch 2" , so Ill be posting most of the horror stories there. http://bitcoinlasvegas.net/kncminer-titan-batch-2-up-and-running/

Vegas

thanks not exactly sure if it is much use to me ..i suppose if it is stable I could run it even with my 2 cubes with dies set to OFF postion. in JUST IN CASE MODE
if when a different die not set to off dumps out.....but
truthfully don't have that isssue (yet..knock wood...) the every 2 days die dumping and needs a re-boot problem that some folk have..this is a good fix for their issues
in that KNC won't address them

hmmmm.....what else could you do to tweak (i suspect) the somewhat lack laster KNC code....hmmmmm..for all of us?

others ..thoughts on what can be tweaked (got to keep the guy busy......heh..)

again if even on the sidelines I appreciate your efforts

will have to ponder what ifs that could be added to knc miner code for Titans on github since KNC has officially abandoned it it seems

over clocking comes to mind but that seems to be 'dead' as far as I have heard at 325 settings I read from others on here that is prety much maxed out

I have heard of some Titan owners who have run their units full out from day one at 325 settings at 1 click below the standard 0.0366 or whatever the default voltage is

not sure if that means anything just found it interesting

probably what we need next is a youtube video on completely taking apart a cube..checking the die showing a good brand of thermal paste and how to do a re-do
and or other standard tests on shoddy workmanship to look for .....anyway a guess on some of why these beasts are so flaky

which I suspect shoddy workmanship is probably the reason I have 2 dies set to off the last 8 months on my orig titan ..but again pretty high stakes for a dweeb
like me to dive into something like that or other hardware tweaks.......likely after the titan(s) are doorstops I will find I could have should have done so...but I suppose
with a video and enough folk finding that this WAS an issue I would probably then be brave enough to look as well..anyway these are just my suspicions

anyway others with ideas on what to add/look into/ or tweak on titan firmware as long as it seems some people have some willingness and expertise to do so?
toss some ideas out here if you don't mind....i only have lame guesses myself

I would so like to over clock these buggers and show the users here can/fix/make/mod better firmware then those knc hacks just because..but alas the last
thing I programmed was an apple ][ back in the day

anyway better minds then my own on this .....chime in please

Alright Ive modified the code, think I got it working properly w/ dies that are flagged OFF now.
Ive confirmed it successfull detects dies that are manually turned off and shows it in the logs, therefore it skips the die detection test on that die.
The question is will it work when a die actually drops off still...gotta wait for that  to happen, but if my code is written properly(which I think it is) it should work as expected =)

yeah a lot of us have 1 die dead on a cube and set to OFF (knc will not rma only 1 dead die on a cube) pricks  I have 2 cubes with 1 dead die each set to OFF so this in present
form probably wont do much for me

however if you could get it to work not paying attention to the dies that are OFF it could be helpful in about 1x every month or two ..never more then 1x one of my titans drops a die and a power down reboot brings it back up but does not happen to me very often  

in other words it would be a nice "JUST IN CASE" another die goes flaky ..the unit would reboot

anyway thanks for your efforts




In my case the dies never worked from almost day one on my orig titan so they have been manually set to off at least 8 months w/o issues so it is stable in this format
when I muck with them it seems to make my cubes worse never did find a way to get them back up

i suspect that it is a heat paste issue i heard that the orig titans were slapped together and this would probably fix it but too chicken to try to do so i somehow
manage with the other titan I got used to get 650.1mh out of both so screw it ..it is a miracle these raspberry pi science fair projects work that good imho

anyway so yeah you set them to OFF and at least in my case all is stable ...the 1 die that drops maybe once every 1 or 2 months is on a different cube anyway and has
not really been an issue

again thanks for your efforts

Yeah, they're toast. Nothing I've tried has been able to get them to hash at all since they died.

Question for ya, are those dies permanently damaged or do they just stop randomly working while mining?

I found the issue w/ the script, it seems when dies are manually disabled the script erronously detects that as the dies also have being failed and trying to restart them(the old way before my script) haha
So, Ill have to come up w/ a way to detect them manually being off or not.

I realize I could SSH to it, but the thing is the SD card with the log file is sitting on my desk, not in the Titan.  Anyways, doesn't matter since you replicated the issue.

What I was really after was the stats in any event, since with the 3 dies disabled the Titan is stable for weeks at a time.

Nevermind, I confirmed the behaviour on my titan as well when manually disabling dies. Grrr, I will have to rewrite the fix somehow lol. Ill keep ya posted.

You can SSH into the miner and do this at command line: cat /var/log/monitordcdc.log
Highly the text it spits out, switch window to notepad and paste.

Is there any way for me to read it off of the SD card from my PC? Or would I have to go and swap it back into my Titan? If I have to swap it, try manually disabling a die on your Titan first. You should see the same behavior, but if you don't I'll go swap the cards and get you the log.

Any chance you can copy n paste /var/log/monitordcdc.log ? post it here?
Thanks

Thats one thing I didnt test was dies which were manually turned off, not sure how my code would react in that case. Ill have to possibly look into it further. My titan has no manually disabled dies.

Any options or machine for make my electricity bill at half???.l

Thanks for your efforts so far, GenTarkin.

In my case on a Titan with 3 dead dies, the firmware was unusable as it would continually restart BFGminer even though the offending dies were set to "OFF" in the advanced page and all other working dies were hashing.

Are you sure your changes are rebooting individual cubes and not the whole shebang? From what I understood observing through SSH, what was happening was a restart of BFGminer and all 4 cubes if there was not 4 working dies per cube.

Please go back through like the last couple pages of this topic and read everything Ive mentioned.
Again, all this firmware does is bring "dropping dies" "sleeping dies" "braindead dies" ... or whatever you wanna call it.... back to life by automatically power cycling the cube that has the dropped die.
I also added more stats to the STATUS page of webgui when you log in.

I made this firmware primarily because of all the complaints about titan owners constantly experiencing dies that stop mining and they have to power cycle the whole miner in order to bring them back up. I experienced the same issue and had a feeling that the DCDC's were programmable and therefore could be issued a command to powercycle themselves and hopefully bring the die back into an operational state w/o any interference from the operator. It was successful and hence I decided to make my own release =)

Future changes may be an updated bfgminer and ability to OC to 350mhz, but Ive seen nowhere on how to do this. I do see some areas in the source code provided on KNC's github that MAY affect clocks but I dont know if simply adding a 350mhz value would do anything at all. I would like to see working documentation or examples of this from known sources OR from KNC's other products and perhaps I can figure it out from that.

Any better performance with these firmware?

Ah, my bad, didnt realize it was changed from default haha...  admin/99e99

GenTarkin,

I just tried your image, but the default login and password is not admin/admin so I couldn't log in to the Titan. What is the proper user name and password for your image?

I posted this a lil while back:

what better options have from original firmware?

Quick update my firmware is now available for download here:
https://github.com/GenTarkin/Titan/releases/tag/v.85