Swedish ASIC miner company kncminer.com

[texaslabrat]

The apropos of "capitalism" does not change...capitalism does not imply fairness.  It only implies the ability of capital to be brought to bear in a market unfettered by forces outside that market.  The market itself then shapes the effectiveness of that capital depending on the conditions at play at that time.

You need to wake up on your fantasy about unfettered capitalism...  so Avalon renegging on sending chips to groupbuys and sending them to someone else is 'unfettered capitalism' or rather cronyism/fraud ?

Rule of Law & Contracts are respected in 'unfettered capitalism' which has eroded

A free-for-all is not a free market

Actually "free for all" IS a free market by definition...it is only through the application of a governing entity that contracts and regulations against fraud/broken promises come into play which makes it not a free market anymore (which is why we don't have a true free market in most of the world these days...people demand protection by the government from fraud and abuse).  Without such governing entities, mechanisms such as escrow and reputation are used in place of binding contract law (common in bitcoin-land, but unfortunately not utilized much with mining equipment).

The "Rule of Law & Contracts" by definition has supplanted the free market because it directly implies government regulation of the market for the enforcement of said contracts..as well as the ability to declare what contractual obligations are enforceable versus not.  Thinking that the Western World's economic system (with its rules, regulations, and contract law) is a free market is the fantasy.

[Phoenix1969]

any jupiter owners running .98 notice that the hashrate is highest when you do a poweroff cycle and reboot, it will hit 565-575gh/s at the pool and then after running for a while the pool listed hash rate will get progressively lower, i dip at 490gh/s

any idea why this is?

This is exactly what happens to mine, maybe even lower, 470, 460... no idea why  

did you ever try 70-75C? after enablecores, on 0.98?

24 hours later.. my 3 sats are 850 at the pool on 12 hour average!
that's 283 each, which is exactly what they show on cgminer!

[texaslabrat]

any jupiter owners running .98 notice that the hashrate is highest when you do a poweroff cycle and reboot, it will hit 565-575gh/s at the pool and then after running for a while the pool listed hash rate will get progressively lower, i dip at 490gh/s

any idea why this is?

This is exactly what happens to mine, maybe even lower, 470, 460... no idea why  

did you ever try 70-75C? after enablecores, on 0.98?

Higher temps can help, true, but it might be a case of simply the boards are too far gone to help and the cores are just getting turned off due to excessive errors.

One thing that I did during the course of my experimentation was to use BFGMiner with v.94 instead of cgminer.  The first release did not have any mechanism to turn off the cores so it just bulled its way through.  Got lots of errors but overall hash rate stayed high (measured at the pool).  Later releases implemented the core disable mechanism, but I modified the source code of the knc driver to effectively turn off that functionality (changed the number of errors in a row needed for a core disabled to 10000, and time spent as disabled to 1 second).  That worked pretty well too (on v.94 with the higher voltage) but the VRMs couldn't hack the extra current so I'd lose whole dies at a time over a few hours of running and would need to restart the mining process.  I haven't tried the "locked" bfgminer trick with .98 because I haven't needed to..but it might prove useful for someone with boards that continue to misbehave with .98.  Tho, honestly, if it's still not working well with .98 it might be time for RMA.

[Phoenix1969]

any jupiter owners running .98 notice that the hashrate is highest when you do a poweroff cycle and reboot, it will hit 565-575gh/s at the pool and then after running for a while the pool listed hash rate will get progressively lower, i dip at 490gh/s

any idea why this is?

This is exactly what happens to mine, maybe even lower, 470, 460... no idea why 

did you ever try 70-75C? after enablecores, on 0.98?

Higher temps can help, true, but it might be a case of simply the boards are too far gone to help and the cores are just getting turned off due to excessive errors.

One thing that I did during the course of my experimentation was to use BFGMiner instead of cgminer.  The first release did not have any mechanism to turn off the cores so it just bulled its way through.  Got lots of errors but overall hash rate stayed high (measured at the pool).  Later releases implemented the core disable mechanism, but I modified the source code of the knc driver to effectively turn off that functionality (changed the number of errors in a row needed for a core disabled to 10000, and time spent as disabled to 1 second).  That worked pretty well too (on v.94 with the higher voltage) but the VRMs couldn't hack the extra current so I'd lose whole dies at a time over time.  I haven't tried the "locked" bfgminer trick with .98 because I haven't needed to..but it might prove useful for someone with boards that continue to misbehave with .98.  Tho, honestly, if it's still not working well with .98 it might be time for RMA.

Those temps are totally within spec... and 28nm's are known to run better @ 70 than 50.
Your loss If you don't try. An RMA would cost you more
Just sayin'

[texaslabrat]

any jupiter owners running .98 notice that the hashrate is highest when you do a poweroff cycle and reboot, it will hit 565-575gh/s at the pool and then after running for a while the pool listed hash rate will get progressively lower, i dip at 490gh/s

any idea why this is?

This is exactly what happens to mine, maybe even lower, 470, 460... no idea why  

did you ever try 70-75C? after enablecores, on 0.98?

Higher temps can help, true, but it might be a case of simply the boards are too far gone to help and the cores are just getting turned off due to excessive errors.

One thing that I did during the course of my experimentation was to use BFGMiner instead of cgminer.  The first release did not have any mechanism to turn off the cores so it just bulled its way through.  Got lots of errors but overall hash rate stayed high (measured at the pool).  Later releases implemented the core disable mechanism, but I modified the source code of the knc driver to effectively turn off that functionality (changed the number of errors in a row needed for a core disabled to 10000, and time spent as disabled to 1 second).  That worked pretty well too (on v.94 with the higher voltage) but the VRMs couldn't hack the extra current so I'd lose whole dies at a time over time.  I haven't tried the "locked" bfgminer trick with .98 because I haven't needed to..but it might prove useful for someone with boards that continue to misbehave with .98.  Tho, honestly, if it's still not working well with .98 it might be time for RMA.

Those temps are totally within spec... and 28nm's are known to run better @ 70 than 50.
Your loss If you don't try. An RMA would cost you more
Just sayin'

I've tried high temps, low temps, multiple miner programs (with and without custom code mods), and every firmware released.  As I said, I've got a nice working rig now with .98.  I was just commenting that higher temps don't always fix the problem (I have hard data to prove it) depending on what is wrong.  They can help, but are not a fix-all solution.

[FeedbackLoop]

any jupiter owners running .98 notice that the hashrate is highest when you do a poweroff cycle and reboot, it will hit 565-575gh/s at the pool and then after running for a while the pool listed hash rate will get progressively lower, i dip at 490gh/s

any idea why this is?

This is exactly what happens to mine, maybe even lower, 470, 460... no idea why  

did you ever try 70-75C? after enablecores, on 0.98?

Higher temps can help, true, but it might be a case of simply the boards are too far gone to help and the cores are just getting turned off due to excessive errors.

One thing that I did during the course of my experimentation was to use BFGMiner instead of cgminer.  The first release did not have any mechanism to turn off the cores so it just bulled its way through.  Got lots of errors but overall hash rate stayed high (measured at the pool).  Later releases implemented the core disable mechanism, but I modified the source code of the knc driver to effectively turn off that functionality (changed the number of errors in a row needed for a core disabled to 10000, and time spent as disabled to 1 second).  That worked pretty well too (on v.94 with the higher voltage) but the VRMs couldn't hack the extra current so I'd lose whole dies at a time over time.  I haven't tried the "locked" bfgminer trick with .98 because I haven't needed to..but it might prove useful for someone with boards that continue to misbehave with .98.  Tho, honestly, if it's still not working well with .98 it might be time for RMA.

Those temps are totally within spec... and 28nm's are known to run better @ 70 than 50.
Your loss If you don't try. An RMA would cost you more
Just sayin'

I've tried high temps, low temps, multiple miner programs, and every firmware released.  As I said, I've got a nice working rig now with .98.  I was just commenting that higher temps don't always fix the problem (I have hard data to prove it) depending on what is wrong.  They can help, but are not a fix-all solution.

This sounds like a problem that previous firmwares had for most people. I wonder if you have some old files that 0.98 is not overwriting. Did you try to downgrade to one that didn't have this problem, like 0.93, do a reset, reboot, re-upgrade from 0.93 back to 0.98? Edit: reading better the things you tried you probably did already but just in case...

[Phoenix1969]

"Fixall" solution?...  Never said that.  Broken is broken...
I see.
The comment was more for shamadz & waterboy2...
Just tryin' to help...
but  it also takes a good 24 hours for Enablecores to do it's job...
Did you "Let it run""... 24 hours?
 wedge the heatsinks down a tad harder?  ** This activated TWO bad dies Permanently***
I have 3 machines, al with different attitudes...
they all came up to "par"...and beyond

[CYPER]

any jupiter owners running .98 notice that the hashrate is highest when you do a poweroff cycle and reboot, it will hit 565-575gh/s at the pool and then after running for a while the pool listed hash rate will get progressively lower, i dip at 490gh/s

any idea why this is?

This is exactly what happens to mine, maybe even lower, 470, 460... no idea why  

did you ever try 70-75C? after enablecores, on 0.98?

24 hours later.. my 3 sats are 850 at the pool on 12 hour average!
that's 283 each, which is exactly what they show on cgminer!

Your 3x Saturn hash faster than mine 2x Jupiters 

[texaslabrat]

"Fixall" solution?...  Never said that.  Broken is broken...
I see.
The comment was more for shamadz & waterboy2...
Just tryin' to help...
but  it also takes a good 24 hours for Enablecores to do it's job...
Did you "Let it run""... 24 hours?
 wedge the heatsinks down a tad harder?  ** This activated TWO bad dies Permanently***
then enablecores can do an even better job...

Yeah granted..I'm just trying to inject some personal experience with that line of experimentation to temper expectations.  I also tried additional pressure from the top...made no difference.  It was the application of additional voltage (which had a side-effect of higher temperatures) that ultimately proved the solution.  I tried higher temperatures in isolation (ie with .95 firmware) by removal of the heatsink fans and it didn't help.  Ditto pressure.  All of these things are easy to try and sometimes work, but folks need to realize that they need to be prepared for an RMA at some point if running the higher voltage of .98 along with a few other "tricks" such as temp and perhaps mild pressure isn't working.

[Phoenix1969]

any jupiter owners running .98 notice that the hashrate is highest when you do a poweroff cycle and reboot, it will hit 565-575gh/s at the pool and then after running for a while the pool listed hash rate will get progressively lower, i dip at 490gh/s

any idea why this is?

This is exactly what happens to mine, maybe even lower, 470, 460... no idea why  

did you ever try 70-75C? after enablecores, on 0.98?

24 hours later.. my 3 sats are 850 at the pool on 12 hour average!
that's 283 each, which is exactly what they show on cgminer!

Your 3x Saturn hash faster than mine 2x Jupiters  

Just so you kno I'm not "Joshing"... hehe
or full of BFL

[CYPER]

Just so you kno I'm not "Joshing"... hehe
or full of BFL

I believe you.

Here are some steps to streamline access to your miner through putty..
1. Open the putty session window, and input your I.P. normally in the hostname field, but DO NOT HIT ENTR.
    a. Instead, take your mouse pointer, highlight the saved sessions field(with a single left-click), and input your miner's I.P. again.
2. on the window/behavior tab to the left, un-check the "warn before exit" box.
3. on the connection/data tab, enter "root" to the auto-login username field.
4. on the SSH tab, enter "screen -r" into the "remote command" field.
5. back on the Session tab, at bottom of page, check the "close window on exit"....... "always"
6. now hit the SAVE button, and close putty
7. Go to your desktop & right-click for a context menu, and go to new/ shortcut.
8. input the location of putty for starting it. Use full file location to execute putty & input your miner's I.P. address as such...    
 C:\Users\Ewik\Desktop\putty.exe -load "123.123.123.4"
click next, input a name for your new shortcut, click finish.

Now, when you click on the shortcut, it will start putty with your miner's ip, and enter "root" for you, and wait for a password. as soon as you enter your password, it does the "screen -r" for you, and jumps into cgminer window.
it all happens very fast then
click on shortcut, enterpass, you're in.
BAM

You can make it even better by including -pw password

[Phoenix1969]

Just so you kno I'm not "Joshing"... hehe
or full of BFL

I believe you.

Here are some steps to streamline access to your miner through putty..
1. Open the putty session window, and input your I.P. normally in the hostname field, but DO NOT HIT ENTR.
    a. Instead, take your mouse pointer, highlight the saved sessions field(with a single left-click), and input your miner's I.P. again.
2. on the window/behavior tab to the left, un-check the "warn before exit" box.
3. on the connection/data tab, enter "root" to the auto-login username field.
4. on the SSH tab, enter "screen -r" into the "remote command" field.
5. back on the Session tab, at bottom of page, check the "close window on exit"....... "always"
6. now hit the SAVE button, and close putty
7. Go to your desktop & right-click for a context menu, and go to new/ shortcut.
8. input the location of putty for starting it. Use full file location to execute putty & input your miner's I.P. address as such...    
 C:\Users\Ewik\Desktop\putty.exe -load "123.123.123.4"
click next, input a name for your new shortcut, click finish.

Now, when you click on the shortcut, it will start putty with your miner's ip, and enter "root" for you, and wait for a password. as soon as you enter your password, it does the "screen -r" for you, and jumps into cgminer window.
it all happens very fast then
click on shortcut, enterpass, you're in.
BAM

You can make it even better by including -pw password

Good idea, thank you

[CYPER]

Just so you kno I'm not "Joshing"... hehe
or full of BFL

I believe you.

Here are some steps to streamline access to your miner through putty..
1. Open the putty session window, and input your I.P. normally in the hostname field, but DO NOT HIT ENTR.
    a. Instead, take your mouse pointer, highlight the saved sessions field(with a single left-click), and input your miner's I.P. again.
2. on the window/behavior tab to the left, un-check the "warn before exit" box.
3. on the connection/data tab, enter "root" to the auto-login username field.
4. on the SSH tab, enter "screen -r" into the "remote command" field.
5. back on the Session tab, at bottom of page, check the "close window on exit"....... "always"
6. now hit the SAVE button, and close putty
7. Go to your desktop & right-click for a context menu, and go to new/ shortcut.
8. input the location of putty for starting it. Use full file location to execute putty & input your miner's I.P. address as such...    
 C:\Users\Ewik\Desktop\putty.exe -load "123.123.123.4"
click next, input a name for your new shortcut, click finish.

Now, when you click on the shortcut, it will start putty with your miner's ip, and enter "root" for you, and wait for a password. as soon as you enter your password, it does the "screen -r" for you, and jumps into cgminer window.
it all happens very fast then
click on shortcut, enterpass, you're in.
BAM

You can make it even better by including -pw password

Good idea, thank you

Or use this: http://www.thegeekstuff.com/2009/03/putty-extreme-makeover-using-putty-connection-manager/

I will test it later on.

[texaslabrat]

https://i.imgur.com/Ic2CE3f.png
Just so you kno I'm not "Joshing"... hehe
or full of BFL

I believe you.

Here are some steps to streamline access to your miner through putty..
1. Open the putty session window, and input your I.P. normally in the hostname field, but DO NOT HIT ENTR.
    a. Instead, take your mouse pointer, highlight the saved sessions field(with a single left-click), and input your miner's I.P. again.
2. on the window/behavior tab to the left, un-check the "warn before exit" box.
3. on the connection/data tab, enter "root" to the auto-login username field.
4. on the SSH tab, enter "screen -r" into the "remote command" field.
5. back on the Session tab, at bottom of page, check the "close window on exit"....... "always"
6. now hit the SAVE button, and close putty
7. Go to your desktop & right-click for a context menu, and go to new/ shortcut.
8. input the location of putty for starting it. Use full file location to execute putty & input your miner's I.P. address as such...    
 C:\Users\Ewik\Desktop\putty.exe -load "123.123.123.4"
click next, input a name for your new shortcut, click finish.

Now, when you click on the shortcut, it will start putty with your miner's ip, and enter "root" for you, and wait for a password. as soon as you enter your password, it does the "screen -r" for you, and jumps into cgminer window.
it all happens very fast then
click on shortcut, enterpass, you're in.
BAM

You can make it even better by including -pw password

For those interested, here is a much (in my opinion) nicer SSH client that is free for home use:

http://www.netsarang.com/products/xsh_overview.html

From my perspective, it combines most of the good things from Putty and many of the more well-known commercial offerings like SecureCRT.  

[The Avenger]

Awesome. So now it's been confirmed that people who paid $2000 less got their miners about 1 day after the people who paid $2000 more
https://bitcointalk.org/index.php?topic=322031.msg3458393#msg3458393

Just fucking awesome! Not only did they ship my faulty unit 10 days late, costing me about $2000 in lost mining revenue and all the BTC I've lost from mining with a sub-standard faulty lemon since then, but now knc have fucked us over again.

Can you imagine being Cyper, who got his October order on the 30th? To hear this?

And the plan is to start shipping Nov orders on 15th, after they promised it would be 30 days after October delivery ended to let people get some benefit from the early order and the fact they paid $2000 extra.

Fuck you KNC. Just that.

P.S.

If everything for Day1, Day2, Day3, and October is pushed back by two weeks, then November orders might not be released until the end of that month instead of in the middle of it.

I've always been concerned that delays to the initial batch of orders could go on so long it runs into the reduced price November miners. Eventually they ship within a few days of each other, only we paid $2000 more  

[Searing]

Two days in and 13 mill shares, bags covering 3/4 of the heat sinks still working great:

Can't bring myself to make them HOTTER... just.. can't.. do.. it...

ditto.....(no idea if I'm right/wrong just glad to see I'm not alone...it is just WRONG...(hurts my tummy to think about making them hotter)
of course that could be due to fear......I've not bricked the unit yet and yelled for help...still at .95.
Searing

[Bargraphics]

Not only did they ship my faulty unit 10 days late, costing me about $2000 in lost mining revenue and all the BTC I've lost from mining with a sub-standard faulty lemon since then, but now knc have fucked us over again.

Can you imagine being Cyper, who got his October order on the 30th? To hear this?

And the plan is to start shipping Nov orders on 15th, after they promised it would be 30 days after October delivery ended to let people get some benefit from the early order and the fact they paid $2000 extra.

Fuck you KNC. Just that.

Pipe down and don't be last in line next time.

[timmmers]

Awesome. So now it's been confirmed that people who paid $2000 less got their miners about 1 day after the people who paid $2000 more
https://bitcointalk.org/index.php?topic=322031.msg3458393#msg3458393

Just fucking awesome! Not only did they ship my faulty unit 10 days late, costing me about $2000 in lost mining revenue and all the BTC I've lost from mining with a sub-standard faulty lemon since then, but now knc have fucked us over again.

Can you imagine being Cyper, who got his October order on the 30th? To hear this?

And the plan is to start shipping Nov orders on 15th, after they promised it would be 30 days after October delivery ended to let people get some benefit from the early order and the fact they paid $2000 extra.

Fuck you KNC. Just that.

P.S.

If everything for Day1, Day2, Day3, and October is pushed back by two weeks, then November orders might not be released until the end of that month instead of in the middle of it.

I've always been concerned that delays to the initial batch of orders could go on so long it runs into the reduced price November miners. Eventually they ship within a few days of each other, only we paid $2000 more  

Can't disagree. They cant afford to delay the Nov people now though, or they'd also be fucked like the 1st batch due to their late delivery. In their eyes it's probably keeping at least one bunch or people sweet. Maybe even "We were a bit late on the initial batch but we produced on time and delivered the 2nd batch on time." Not, "The majority of our customers were disappointed, AND beta tested the rigs so they'd be dandy for the later orders".

Cypher and the other very late delivered (and poor performing) rig peeps are owed some kind of compensation for the huge let down they suffered from KNC.

[cognoscente]

Pipe down and don't be last in line next time.

Just about everyone except you took it in the shorts, timewise.

Whatcha got, three hundred coins now?  And everyone else needs to shut up?

Noggunna, noggunna, noggunna, noggunna happen.

[timmmers]

Not only did they ship my faulty unit 10 days late, costing me about $2000 in lost mining revenue and all the BTC I've lost from mining with a sub-standard faulty lemon since then, but now knc have fucked us over again.

Can you imagine being Cyper, who got his October order on the 30th? To hear this?

And the plan is to start shipping Nov orders on 15th, after they promised it would be 30 days after October delivery ended to let people get some benefit from the early order and the fact they paid $2000 extra.

Fuck you KNC. Just that.

Pipe down and don't be last in line next time.

All orders should have been delivered by Oct 15th. That was the wording on the site. Hosting was supposedly the fastest and most reliable way to run a miner at a large cost ...how is that going for everyone? Seems to me that was a royal fuck up too from posts here. Even so, how come KNC pay hosted peeps compo for lost mining time and not others who suffered the same thing? Too many of them maybe?

Tootle off an delete some posts or something, he's right. Pipe down indeed. Pillock.