Swedish ASIC miner company kncminer.com

[FiatKiller]

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

[1715094453]

1715094453

[1715094453]

1715094453

[waterboi92]

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

whats your temp readings?

[xyzzy099]

If you think "that who gets the reward for a block, and who "solves" it are two different questions", then I am certain you do not comprehend that even in pool "mining" there must be an entity to receive the reward, what is not the pool participant. The reward needs to be transmitted (first transaction) to the entity which "solves" the block. You are failing to understand that the receiver (thus the "solver") it is not the pool participant.

That is not a correct statement.   p2pool and eligius are evidence of that.

The pool creates a coinbase entry assigning the block reward to itself.  When the block is solved, by whichever pool member submits a share of sufficiently high difficulty, that solution is transmitted along with the filled-in coinbase.  Once accepted onto the blockchain, the mined BTC and fees are sent to the address that the pool assigned as the receiver in their coinbase entry.

if you are solo mining, you are creating a coinbase with your own wallet ID in it specifying where the reward goes (into your wallet) when you submit a block solution.

P2Pool and Eligius don't do that.  The coinbase transaction has outputs for every miner that will get paid, and a share of the payment goes to each miner as a 'mined' transaction.

The piece highlighted in green is the part Mr. Augusto Croppo refuses to understand.  He is trying to redefine "solving" a block as receiving the block reward, which to any reasonable person is clearly a different thing.  It is analogous to redefining 'work' as 'getting a paycheck'.  One would hope that the latter would accompany the former, but it is clearly inaccurate to say they are the same thing.

[FiatKiller]

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

whats your temp readings?

mid-40s shockingly, and I won't risk any further increase, except maybe putting the case on with no bags or fans. Too much chance of a really warm day ruining my miner. I think they should consider downsizing the heatsinks for sure.
Happy with the current performance, as it is way over the 200 promised.

[sbfree]

The pool provides you with a block header to work on.  You double-hash the block header iteratively while incrementing the nonce, and return any results that are of higher difficulty than the pool difficulty to the pool.  If one of those results happens to also be higher difficulty than the network difficulty, you have solved the block for the pool.  The pool does not do any of the calculations associated with solving a block, so I don't see how you think the pool "solved" the block.

Yeah, but guess who got the 25 BTC + fees?

augusto, seems like you have now conceded that he did indeed FIND the block, BUT now are asking about payout in regards to the block, totally different subject.

[DPoS]

 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

[dlasher]

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...

[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.