xyzzy099
Legendary
Offline
Activity: 1066
Merit: 1098
|
|
October 31, 2013, 06:43:37 PM |
|
whoa, 426m! you solved a block! coooool
Nope. The pool "solved" the block, not him. What he did was to use a machine which generated the SHA-256 number for the pool to "solve" the block. He would only had "solved" the block if he was solo "mining", what is not the case. I don't get the distinction you are making here. It looks to me like he solved a block for the pool in exactly the same way he might have solved a block for himself if he had been solo mining.
|
Libertarians: Diligently plotting to take over the world and leave you alone.
|
|
|
ASIC-K
Sr. Member
Offline
Activity: 280
Merit: 250
Hell?
|
|
October 31, 2013, 06:48:42 PM |
|
whoa, 426m! you solved a block! coooool
Nope. The pool "solved" the block, not him. What he did was to use a machine which generated the SHA-256 number for the pool to "solve" the block. He would only had "solved" the block if he was solo "mining", what is not the case. I don't get the distinction you are making here. It looks to me like he solved a block for the pool in exactly the same way he might have solved a block for himself if he had been solo mining. Augusto just being his crabby, permanent on-his-period self as usual.
|
|
|
|
arlekyn13
|
|
October 31, 2013, 06:49:16 PM |
|
My Jupiter that I finally received today stopped working. I upgraded it to 0.98 and was getting just 414Gh/s so i decided to try several "older" FW's. At some point, after reboot, it stopped hashing. It shows 0Gh/s and the red led is on (instead of the green one). Any suggestions? Also getting only 211Gh/s on both my Saturns on 0.98 FW.
|
1CmrswU7JYpi9WNC8EHWCV3aam1FJsW2Zu - to show appreciation for my work
|
|
|
AFox
|
|
October 31, 2013, 06:55:28 PM Last edit: November 05, 2013, 09:18:10 PM by AFox |
|
0.98 isn't working out for me. Back to 0.97. All the firmware's were run at least 24 hours without any reboot. For that reason firmware 0.90 to 0.93 aren't listed. -------------------- | 0.94 | 0.95 | 0.96 | 0.97 | 0.98 | Average CGminer | 270Gh/s | 274Gh/s | 280Gh/s | 284Gh/s | 278Gh/s | Average Pool | 275Gh/s | 263Gh/s | 278Gh/s | 283Gh/s | 269Gh/s | Consumption | 485 Watts | 305 Watts | 313 Watts | 313 Watts | 348 Watts | Temputure | 54 & 62°C | 42 & 47°C | 42 & 47°C | 40 & 44°C | 44 & 50°C | Rejected | 1.5% | 0.22% | 0.38% | 0.48% | 0.61% | HW | 2.81% | 0.79% | 1.08% | 1.47% | 3.31% | WU | 3975/m | 3717/m | 3933/m | 4021/m | 3825/m |
|
|
|
|
FiatKiller
|
|
October 31, 2013, 07:16:20 PM |
|
Fox, did you try enablecores on top of FM 9.8?
|
|
|
|
naRky
Sr. Member
Offline
Activity: 350
Merit: 250
Bitcoin is the future...
|
|
October 31, 2013, 07:27:01 PM |
|
.98 after ~28hours nice! any special treatments? extra fans etc? nope, just opened window in the room, case on. ASIC slot #1 55.0 ℃ ASIC slot #2 58.0 ℃ ASIC slot #3 61.5 ℃ ASIC slot #4 56.0 ℃ ..from now, I'm scared to change anything.) Same here cgminer version 3.6.6 - Started: [2013-10-29 15:57:04] -------------------------------------------------------------------------------- (5s):611.7G (avg):564.0Gh/s | A:24198400 R:224256 HW:606832 WU:7886.4/m ST: 2 SS: 0 NB: 427 LW: 25833217 GF: 0 RF: 0 Connected to mint.bitminter.com diff 512 with stratum as user xxxxxx Block: 0005308f7206b594... Diff:391M Started: [19:24:06] Best share: 48.1M -------------------------------------------------------------------------------- KnC 0: | 611.8G/564.0Gh/s | A:24198912 R:224000 HW:606842 WU: 7886.5/m
|
|
|
|
DigginDeep
Newbie
Offline
Activity: 59
Merit: 0
|
|
October 31, 2013, 07:35:56 PM |
|
But what I also don't think people realize it's that if your using pre 98 you hash rate it's not accurate, as of pre 98 hardware errors were counted towards your hash rate, and since 98 upgraded cgminer the hash rates are now correct from my understanding.
|
|
|
|
AFox
|
|
October 31, 2013, 07:36:56 PM |
|
Fox, did you try enablecores on top of FM 9.8?
Yes, it doesn't help. CYPER said on an other topic that firmware 0.97 isn't available on KNC's website. Does anybody know why ? Anyways, it's a good thing I keep a copy on my computer. Here's a link for those how want to download firmware 0.97 : http://1t4pro.1fichier.com/en/index.htmlBut what I also don't think people realize it's that if your using pre 98 you hash rate it's not accurate, as of pre 98 hardware errors were counted towards your hash rate, and since 98 upgraded cgminer the hash rates are now correct from my understanding. The only thing I see is that hashrate on the pool is bad with 0.98.
|
|
|
|
DigginDeep
Newbie
Offline
Activity: 59
Merit: 0
|
|
October 31, 2013, 07:44:52 PM |
|
Well if your hash rate on your pool was worse I would definitely be switching back my self, specially since the higher wattage 98 uses, I'm lucky 98 works great for me
|
|
|
|
Crypto_Cumbrian
Member
Offline
Activity: 113
Merit: 10
|
|
October 31, 2013, 07:50:57 PM |
|
Anyone with a Jupiter running 0.98.
I switched back to 0.95, but forgot to take a note of the Stale and Dupe shares at the pool, what figures are 0.98 getting for these.
|
|
|
|
cognoscente
Member
Offline
Activity: 111
Merit: 10
|
|
October 31, 2013, 07:54:21 PM |
|
Does anybody know why ?
Apparently there's no valid case where .97 works better than .96 or .98. It had a bug that was corrected in .98. In my case, .96 has higher peaks, lower valleys, and less power. .98 has fewer low spots, quicker flushwork, but uses more power. I'm on .98 and liking it.
|
|
|
|
Phoenix1969
Legendary
Offline
Activity: 938
Merit: 1000
LIR DEV
|
|
October 31, 2013, 07:59:37 PM |
|
Did you guys leave enablecores running on top of 0.98 to get the good speeds to stay up there?... I've been doing enablecores, but immediately re-flashing 0.98 back after the reboot.... ?
|
|
|
|
arlekyn13
|
|
October 31, 2013, 07:59:51 PM |
|
Anyone can help me with this?
-------------------------------------------------------------------------------- (5s):0.000 (avg):0.000h/s | A:0 R:128 HW:0 WU:0.0/m ST: 2 SS: 0 NB: 1 LW: 281 GF: 0 RF: 0 Connected to mint.bitminter.com diff 128 with stratum as user myuser Block: 000151d9281f7c40... Diff:391M Started: [19:54:59] Best share: 0 -------------------------------------------------------------------------------- [P]ool management ettings [D]isplay options [Q]uit KnC 0: | 0.000/ 0.000h/s | A:0 R:0 HW:0 WU:0.0/m --------------------------------------------------------------------------------
[2013-10-31 19:54:55] Started cgminer 3.6.6 [2013-10-31 19:54:55] Loaded configuration file /config/cgminer.conf [2013-10-31 19:54:55] Error in configuration file, partially loaded. [2013-10-31 19:54:55] Start cgminer with -T to see what failed to load. [2013-10-31 19:54:55] Probing for an alive pool [2013-10-31 19:54:59] Pool 0 difficulty changed to 128 [2013-10-31 19:54:59] Network diff set to 391M [2013-10-31 19:54:59] Stratum from pool 0 detected new block [2013-10-31 19:54:59] Stratum from pool 0 requested work restart [2013-10-31 19:54:59] Rejected untracked stratum share from pool 0 [2013-10-31 19:57:01] Stratum from pool 0 requested work restart [2013-10-31 19:57:01] KnC running flushwork
The red led on the miner stays red after reboot.
|
1CmrswU7JYpi9WNC8EHWCV3aam1FJsW2Zu - to show appreciation for my work
|
|
|
augustocroppo
VIP
Hero Member
Offline
Activity: 756
Merit: 504
|
|
October 31, 2013, 07:59:53 PM |
|
yes, doofus. i know that, thats what i mean you fucktard. why are you still on this forum?
Augusto just being his crabby, permanent on-his-period self as usual.
If that is what you mean, then you would not say that he "solved" the block. Appeal to insults will not change the fact that you made an incorrect statement. It only shows you fail to learn from mistakes. I don't get the distinction you are making here. It looks to me like he solved a block for the pool in exactly the same way he might have solved a block for himself if he had been solo mining. When people participate in pools they are only providing the SHA-256 hash generated by their machines to let the pool find a block header with a number equal or lower than the current target. Therefore participants in a pool cannot "solve" a block because it is the pool who execute this process. What the pool participants only do is to provide the necessary requirements to complete this process, know as Proof of Work, which is just to generate a high rate of SHA-256 hash until the current target is found. Solo "miners" can "solve" a block like pooled "mining" because their are not only generating the SHA-256 hash, but monitoring the block header of every block propagated in the Bitcoin network. https://en.bitcoin.it/wiki/Pooled_miningA share is awarded by the mining pool to the clients who present a valid proof of work of the same type as the proof of work that is used for creating blocks, but of lesser difficulty, so that it requires less time on average to generate.
https://en.bitcoin.it/wiki/Proof_of_workProofs of work that are tied to the data of each block are required for the blocks to be accepted. The difficulty of this work is adjusted so as to limit the rate at which new blocks can be generated by the network to one every 10 minutes. Due to the very low probability of successful generation, this makes it unpredictable which worker computer in the network will be able to generate the next block.
|
|
|
|
Phoenix1969
Legendary
Offline
Activity: 938
Merit: 1000
LIR DEV
|
|
October 31, 2013, 08:04:30 PM |
|
Anyone can help me with this?
-------------------------------------------------------------------------------- (5s):0.000 (avg):0.000h/s | A:0 R:128 HW:0 WU:0.0/m ST: 2 SS: 0 NB: 1 LW: 281 GF: 0 RF: 0 Connected to mint.bitminter.com diff 128 with stratum as user myuser Block: 000151d9281f7c40... Diff:391M Started: [19:54:59] Best share: 0 -------------------------------------------------------------------------------- [P]ool management ettings [D]isplay options [Q]uit KnC 0: | 0.000/ 0.000h/s | A:0 R:0 HW:0 WU:0.0/m --------------------------------------------------------------------------------
[2013-10-31 19:54:55] Started cgminer 3.6.6 [2013-10-31 19:54:55] Loaded configuration file /config/cgminer.conf [2013-10-31 19:54:55] Error in configuration file, partially loaded. [2013-10-31 19:54:55] Start cgminer with -T to see what failed to load. [2013-10-31 19:54:55] Probing for an alive pool [2013-10-31 19:54:59] Pool 0 difficulty changed to 128 [2013-10-31 19:54:59] Network diff set to 391M [2013-10-31 19:54:59] Stratum from pool 0 detected new block [2013-10-31 19:54:59] Stratum from pool 0 requested work restart [2013-10-31 19:54:59] Rejected untracked stratum share from pool 0 [2013-10-31 19:57:01] Stratum from pool 0 requested work restart [2013-10-31 19:57:01] KnC running flushwork
The red led on the miner stays red after reboot.
because you are running the unsupported, unreccommended old cklovas release.... flash 0.98 and be done, it includes the cklovas code.
|
|
|
|
FUKT
|
|
October 31, 2013, 08:06:23 PM |
|
Is it just me but is everyone with faulty/shit units fucked? Are KNC doing anything to fix this?
|
|
|
|
arlekyn13
|
|
October 31, 2013, 08:12:55 PM |
|
Anyone can help me with this?
-------------------------------------------------------------------------------- (5s):0.000 (avg):0.000h/s | A:0 R:128 HW:0 WU:0.0/m ST: 2 SS: 0 NB: 1 LW: 281 GF: 0 RF: 0 Connected to mint.bitminter.com diff 128 with stratum as user myuser Block: 000151d9281f7c40... Diff:391M Started: [19:54:59] Best share: 0 -------------------------------------------------------------------------------- [P]ool management ettings [D]isplay options [Q]uit KnC 0: | 0.000/ 0.000h/s | A:0 R:0 HW:0 WU:0.0/m --------------------------------------------------------------------------------
[2013-10-31 19:54:55] Started cgminer 3.6.6 [2013-10-31 19:54:55] Loaded configuration file /config/cgminer.conf [2013-10-31 19:54:55] Error in configuration file, partially loaded. [2013-10-31 19:54:55] Start cgminer with -T to see what failed to load. [2013-10-31 19:54:55] Probing for an alive pool [2013-10-31 19:54:59] Pool 0 difficulty changed to 128 [2013-10-31 19:54:59] Network diff set to 391M [2013-10-31 19:54:59] Stratum from pool 0 detected new block [2013-10-31 19:54:59] Stratum from pool 0 requested work restart [2013-10-31 19:54:59] Rejected untracked stratum share from pool 0 [2013-10-31 19:57:01] Stratum from pool 0 requested work restart [2013-10-31 19:57:01] KnC running flushwork
The red led on the miner stays red after reboot.
because you are running the unsupported, unreccommended old cklovas release.... flash 0.98 and be done, it includes the cklovas code. I just did, same status. The red led stays on, while the green one goes off after reboot and the machine won't hash. Really no idea what to do
|
1CmrswU7JYpi9WNC8EHWCV3aam1FJsW2Zu - to show appreciation for my work
|
|
|
texaslabrat
Newbie
Offline
Activity: 56
Merit: 0
|
|
October 31, 2013, 08:16:44 PM |
|
Is it just me but is everyone with faulty/shit units fucked? Are KNC doing anything to fix this?
I had two very marginal boards that lost about half their power due to disabled cores when running on 0.7V firmwares. Running .94 (0.9V) allowed all of the cores to run, but then I would lose whole dies over time due to (I believe) the VRM's switching off due to being run over-spec at that voltage. I had created a script run by cron on my linux server to periodically log onto the jupiter and restart cgminer (and for a time bfgminer). The hit from that downtime was more than offset by the higher peak hashrates achieved. Not optimal, and probably not healthy for long-term operation. Then along came .98. It seems to provide more voltage than the .96-.97 firmwares (I haven't checked, but I assume it's probably .8V) which seems to be enough to make my marginal cores happy. But it's not running so hot as to be killing the VRMs. In a 3-bears analogy, the .96-.97 firmware was too cold, .94 was too hot, and .98 is juuuust right. This is what KnC has being doing to fix this. Outside of that, they have an RMA process to replace truly bad hardware that can't be coaxed along with a change of software. Which reminds me, I need to cancel my RMA :p
|
|
|
|
xyzzy099
Legendary
Offline
Activity: 1066
Merit: 1098
|
|
October 31, 2013, 08:16:54 PM |
|
I don't get the distinction you are making here. It looks to me like he solved a block for the pool in exactly the same way he might have solved a block for himself if he had been solo mining. When people participate in pools they are only providing the SHA-256 hash generated by their machines to let the pool find a block header with a number equal or lower than the current target. Therefore participants in a pool cannot "solve" a block because it is the pool who execute this process. What the pool participants only do is to provide the necessary requirements to complete this process, know as Proof of Work, which is just to generate a high rate of SHA-256 hash until the current target is found. Solo "miners" can "solve" a block like pooled "mining" because their are not only generating the SHA-256 hash, but monitoring the block header of every block propagated in the Bitcoin network. https://en.bitcoin.it/wiki/Pooled_miningA share is awarded by the mining pool to the clients who present a valid proof of work of the same type as the proof of work that is used for creating blocks, but of lesser difficulty, so that it requires less time on average to generate.
https://en.bitcoin.it/wiki/Proof_of_workProofs of work that are tied to the data of each block are required for the blocks to be accepted. The difficulty of this work is adjusted so as to limit the rate at which new blocks can be generated by the network to one every 10 minutes. Due to the very low probability of successful generation, this makes it unpredictable which worker computer in the network will be able to generate the next block. 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.
|
Libertarians: Diligently plotting to take over the world and leave you alone.
|
|
|
texaslabrat
Newbie
Offline
Activity: 56
Merit: 0
|
|
October 31, 2013, 08:17:39 PM |
|
Anyone can help me with this?
-------------------------------------------------------------------------------- (5s):0.000 (avg):0.000h/s | A:0 R:128 HW:0 WU:0.0/m ST: 2 SS: 0 NB: 1 LW: 281 GF: 0 RF: 0 Connected to mint.bitminter.com diff 128 with stratum as user myuser Block: 000151d9281f7c40... Diff:391M Started: [19:54:59] Best share: 0 -------------------------------------------------------------------------------- [P]ool management ettings [D]isplay options [Q]uit KnC 0: | 0.000/ 0.000h/s | A:0 R:0 HW:0 WU:0.0/m --------------------------------------------------------------------------------
[2013-10-31 19:54:55] Started cgminer 3.6.6 [2013-10-31 19:54:55] Loaded configuration file /config/cgminer.conf [2013-10-31 19:54:55] Error in configuration file, partially loaded. [2013-10-31 19:54:55] Start cgminer with -T to see what failed to load. [2013-10-31 19:54:55] Probing for an alive pool [2013-10-31 19:54:59] Pool 0 difficulty changed to 128 [2013-10-31 19:54:59] Network diff set to 391M [2013-10-31 19:54:59] Stratum from pool 0 detected new block [2013-10-31 19:54:59] Stratum from pool 0 requested work restart [2013-10-31 19:54:59] Rejected untracked stratum share from pool 0 [2013-10-31 19:57:01] Stratum from pool 0 requested work restart [2013-10-31 19:57:01] KnC running flushwork
The red led on the miner stays red after reboot.
because you are running the unsupported, unreccommended old cklovas release.... flash 0.98 and be done, it includes the cklovas code. I just did, same status. The red led stays on, while the green one goes off after reboot and the machine won't hash. Really no idea what to do Run the enablecores patch and reboot.
|
|
|
|
|