Swedish ASIC miner company kncminer.com - page 1169.

FeedbackLoop

hero member

Activity: 742

Merit: 500

Quote from: texaslabrat on November 01, 2013, 11:57:03 AM

Quote from: Phoenix1969 on November 01, 2013, 11:54:46 AM

Quote from: texaslabrat on November 01, 2013, 11:51:56 AM

Quote from: Phoenix1969 on November 01, 2013, 11:41:49 AM

Quote from: shmadz on November 01, 2013, 08:14:19 AM

Quote from: waterboi92 on November 01, 2013, 07:27:29 AM

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 Huh

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

texaslabrat

newbie

Activity: 56

Merit: 0

Quote from: Phoenix1969 on November 01, 2013, 11:54:46 AM

Quote from: texaslabrat on November 01, 2013, 11:51:56 AM

Quote from: Phoenix1969 on November 01, 2013, 11:41:49 AM

Quote from: shmadz on November 01, 2013, 08:14:19 AM

Quote from: waterboi92 on November 01, 2013, 07:27:29 AM

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 Huh

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.

Phoenix1969

legendary

Activity: 938

Merit: 1000

LIR DEV

Quote from: texaslabrat on November 01, 2013, 11:51:56 AM

Quote from: Phoenix1969 on November 01, 2013, 11:41:49 AM

Quote from: shmadz on November 01, 2013, 08:14:19 AM

Quote from: waterboi92 on November 01, 2013, 07:27:29 AM

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 Huh

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

newbie

Activity: 56

Merit: 0

Quote from: Phoenix1969 on November 01, 2013, 11:41:49 AM

Quote from: shmadz on November 01, 2013, 08:14:19 AM

Quote from: waterboi92 on November 01, 2013, 07:27:29 AM

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 Huh

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

legendary

Activity: 938

Merit: 1000

LIR DEV

Quote from: shmadz on November 01, 2013, 08:14:19 AM

Quote from: waterboi92 on November 01, 2013, 07:27:29 AM

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 Huh

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

newbie

Activity: 56

Merit: 0

Quote from: DPoS on November 01, 2013, 11:11:21 AM

Quote from: texaslabrat on October 31, 2013, 09:46:18 PM

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.

dlasher

sr. member

Activity: 467

Merit: 250

Quote from: FiatKiller on November 01, 2013, 09:13:54 AM

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

DPoS

sr. member

Activity: 462

Merit: 250

Quote from: texaslabrat on October 31, 2013, 09:46:18 PM

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

sbfree

sr. member

Activity: 336

Merit: 250

Quote from: augustocroppo on October 31, 2013, 04:19:33 PM

Quote from: xyzzy099 on October 31, 2013, 03:16:54 PM

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.

FiatKiller

sr. member

Activity: 378

Merit: 250

Quote from: waterboi92 on November 01, 2013, 09:31:17 AM

Quote from: FiatKiller on November 01, 2013, 09:13:54 AM

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.

xyzzy099

legendary

Activity: 1066

Merit: 1098

Quote from: -Redacted- on November 01, 2013, 08:11:31 AM

Quote from: DeathAndTaxes on November 01, 2013, 01:46:59 AM

Quote from: augustocroppo on October 31, 2013, 06:25:24 PM

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.

waterboi92

member

Activity: 82

Merit: 10

Quote from: FiatKiller on November 01, 2013, 09:13:54 AM

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

whats your temp readings?

FiatKiller

sr. member

Activity: 378

Merit: 250

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

waterboi92

member

Activity: 82

Merit: 10

Quote from: Paladin69 on November 01, 2013, 09:08:06 AM

Quote from: waterboi92 on November 01, 2013, 07:27:29 AM

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?

I am noticing the same problem.

glad to know im not the only one, im just doing a manual reboot every time the hash rate dips too low.

im running my jupiter at btc guild, 2.5% error rate and core temps: 53, 63, 55.5 and 52.5.

anyone have a fix?

Paladin69

hero member

Activity: 784

Merit: 1000

Quote from: waterboi92 on November 01, 2013, 07:27:29 AM

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?

I am noticing the same problem.

chrono030

member

Activity: 114

Merit: 10

Quote from: shmadz on November 01, 2013, 08:14:19 AM

Quote from: waterboi92 on November 01, 2013, 07:27:29 AM

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 Huh

I don't seem to have this issue w/ my jup running .98.

http://imgur.com/TrW6zoo

shmadz

legendary

Activity: 1512

Merit: 1000

@theshmadz

Quote from: waterboi92 on November 01, 2013, 07:27:29 AM

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 Huh

-Redacted-

hero member

Activity: 574

Merit: 501

Quote from: DeathAndTaxes on November 01, 2013, 01:46:59 AM

Quote from: augustocroppo on October 31, 2013, 06:25:24 PM

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.

waterboi92

member

Activity: 82

Merit: 10

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?

sickpig

legendary

Activity: 1260

Merit: 1008

Quote from: Nemo1024 on November 01, 2013, 04:56:54 AM

I am mining on BitMinter in that race, but I am also giving some of my mining time to a small pool (the way BitMinter used to be).
This small pool is https://give-me-coins.com/
Its merged-mined BTC sub-pool is at 6THs right now, 0% fees, and they still have one bounty left for the next BTC block finder of 0% fees for life + 1BTC reward. The other sub-pools they operate are LTC and FTC, so if you still GPU-mine those, you can have everything in one dashboard.

I will give them a try, it's the second time someone use them as an example of well crafted small minig pool.

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