Swedish ASIC miner company kncminer.com

[Phoenix1969]

FWIW, this bertmod mod seems to work for .96....http://forum.kncminer.com/forum/main-category/main-forum/6183-bertmod-0-2-unofficial-firmware-mod-feedback-thread/page3


also, I am starting to conclude that my Saturn is pretty close to maxing out at 250GH/s on CGminer = 210-225GH/s server side w/ around 20% hardware errors on CG with 3800 WU (best so far has been .96)

I think that the Saturns like Phoenix1969's where they are hashing at 275GH/s at the server is because they have the 8 VRMs....I don't know diddly, but maybe those early units were meant to IMPRESS those higher rates while the rest were shipped as "satisfactory units" w/ only 4 VRMS.

Hopefully the next firmware will improve on FLUSHWORK SPEED, and the error rate/WU, since I am all HASHED OUT

all 6 boards are 4vrm
one sat likes to run @ 255, one at 265, and one at 275...  all that flashing & unlock cores, eventually dwindles down to origonal speeds after a day for me...did it 3 days in a row...

thanks for the correction phoenix1969 on the 4 VRM, so I strike my prior KNC comment.

Phonenix, are those hash rates at the server side, and how long before those figures go steady on the server after a reboot?

I notice my unit is usually fully operational after about 15 - 30 mins when it seems to stabilize and settle on hash rate/WU and op. temp.
also, the longer between BLOCKS found the better, as flushwork seems to kill performance....its kinda like racing the indy500 and everytime a block is found you have to pit.....weak!

I'm having EXACTLY the same experience.
the pool always polls the wrong avg field in cgminer, but I watch them thru putty, and the GUI, and they pretty much jive, the pool (eligius)always polls crazy numbers.....over a terrahash, and under 500, then shows a bogus average, lol
Yeah, the "Flushwork" is ridiculous....
I'd rather that function was totally turned off, and got rejected shares when the correct block came....lolz
sure would waste alot less time

[1714077244]

1714077244

[1714077244]

1714077244

[adrd]

Keeping with the depressing theme of late....

https://i.imgur.com/cnRLbWx.png

We all know where it's coming
https://i.imgur.com/600WdOA.png
Thanks KNC...

[Phoenix1969]

 not quite... but feels that way...   

[chrono030]

Only about 9 day too late whereas I could have made ROI AND PROFIT if it my jupiters were delivered on the 8th instead of the 17th. Now, i am trying to sell both of them. That was the difference between being a day 1 and not being that

B.S... I got a saturn on the 10th, and it's nowhere close to roi

For what it is worth, I received my Jupiter on October 4th and have not yet made ROI.  Anyone that claims any different is either lying or is solo mining and has insane luck.  

Also - I applied .96 and it seems to have sped up my Jupiter.

I ran the math using the bit minter work efforts and noted a 3.5% increase in hashrate over 24 hours.  Something to consider for the individuals sitting on .95.  I (still) have 4 cores on one die that are sitting in disabled mode - wish i could get them working.

[Phoenix1969]

Only about 9 day too late whereas I could have made ROI AND PROFIT if it my jupiters were delivered on the 8th instead of the 17th. Now, i am trying to sell both of them. That was the difference between being a day 1 and not being that

B.S... I got a saturn on the 10th, and it's nowhere close to roi

For what it is worth, I received my Jupiter on October 4th and have not yet made ROI.  Anyone that claims any different is either lying or is solo mining and has insane luck. 

Also - I applied .96 and it seems to have sped up my Jupiter.

I ran the math using the bit minter work efforts and noted a 3.5% increase in hashrate over 24 hours.  Something to consider for the individuals sitting on .95.  I (still) have 4 cores on one die that are sitting in disabled mode - wish i could get them working.

"Enablecores" didn't work for you?

[texaslabrat]

FWIW, this bertmod mod seems to work for .96....http://forum.kncminer.com/forum/main-category/main-forum/6183-bertmod-0-2-unofficial-firmware-mod-feedback-thread/page3


also, I am starting to conclude that my Saturn is pretty close to maxing out at 250GH/s on CGminer = 210-225GH/s server side w/ around 20% hardware errors on CG with 3800 WU (best so far has been .96)

I think that the Saturns like Phoenix1969's where they are hashing at 275GH/s at the server is because they have the 8 VRMs....I don't know diddly, but maybe those early units were meant to IMPRESS those higher rates while the rest were shipped as "satisfactory units" w/ only 4 VRMS.

Hopefully the next firmware will improve on FLUSHWORK SPEED, and the error rate/WU, since I am all HASHED OUT

all 6 boards are 4vrm
one sat likes to run @ 255, one at 265, and one at 275...  all that flashing & unlock cores, eventually dwindles down to origonal speeds after a day for me...did it 3 days in a row...

thanks for the correction phoenix1969 on the 4 VRM, so I strike my prior KNC comment.

Phonenix, are those hash rates at the server side, and how long before those figures go steady on the server after a reboot?

I notice my unit is usually fully operational after about 15 - 30 mins when it seems to stabilize and settle on hash rate/WU and op. temp.
also, the longer between BLOCKS found the better, as flushwork seems to kill performance....its kinda like racing the indy500 and everytime a block is found you have to pit.....weak!

I'm having EXACTLY the same experience.
the pool always polls the wrong avg field in cgminer, but I watch them thru putty, and the GUI, and they pretty much jive, the pool (eligius)always polls crazy numbers.....over a terrahash, and under 500, then shows a bogus average, lol
Yeah, the "Flushwork" is ridiculous....

the pool doesn't "poll" anything from cgminer.  The pool displays a calculated hashrate based on shares that you submit (1 share of diff_1 = 2^32 hashes).  If you get "lucky" and submit 3 shares back-to-back-to-back with the miner having done fewer than average hash calculations in the process, it will appear to the pool as if your hashrate spiked much higher.  Likewise, if your miner is having a bad luck streak and has to crunch through more hashes than average in order to submit a share, it will appear to the pool as though the hashrate slowed down.  This is completely independent from the actual speed of the miner in going about its business of calculating SHA256 hash values.

[chrono030]

Only about 9 day too late whereas I could have made ROI AND PROFIT if it my jupiters were delivered on the 8th instead of the 17th. Now, i am trying to sell both of them. That was the difference between being a day 1 and not being that

B.S... I got a saturn on the 10th, and it's nowhere close to roi

For what it is worth, I received my Jupiter on October 4th and have not yet made ROI.  Anyone that claims any different is either lying or is solo mining and has insane luck. 

Also - I applied .96 and it seems to have sped up my Jupiter.

I ran the math using the bit minter work efforts and noted a 3.5% increase in hashrate over 24 hours.  Something to consider for the individuals sitting on .95.  I (still) have 4 cores on one die that are sitting in disabled mode - wish i could get them working.

"Enablecores" didn't work for you?

Nope - Tried that a number of times.  It doesn't fix the issue.

[DPoS]

Also - I applied .96 and it seems to have sped up my Jupiter.

so far .96 is the king of lowering HW errors for those prone to them...  if you have some golden build you probably hate .96 slowness compared to .95 as far as WU goes

(and yes, I am trying to stop talking about pre-95)

[Phoenix1969]

Only about 9 day too late whereas I could have made ROI AND PROFIT if it my jupiters were delivered on the 8th instead of the 17th. Now, i am trying to sell both of them. That was the difference between being a day 1 and not being that

B.S... I got a saturn on the 10th, and it's nowhere close to roi

For what it is worth, I received my Jupiter on October 4th and have not yet made ROI.  Anyone that claims any different is either lying or is solo mining and has insane luck. 

Also - I applied .96 and it seems to have sped up my Jupiter.

I ran the math using the bit minter work efforts and noted a 3.5% increase in hashrate over 24 hours.  Something to consider for the individuals sitting on .95.  I (still) have 4 cores on one die that are sitting in disabled mode - wish i could get them working.

"Enablecores" didn't work for you?

Nope - Tried that a number of times.  It doesn't fix the issue.

same here, but worked temporarily, and dwindles back after 24 hrs

[Phoenix1969]

FWIW, this bertmod mod seems to work for .96....http://forum.kncminer.com/forum/main-category/main-forum/6183-bertmod-0-2-unofficial-firmware-mod-feedback-thread/page3


also, I am starting to conclude that my Saturn is pretty close to maxing out at 250GH/s on CGminer = 210-225GH/s server side w/ around 20% hardware errors on CG with 3800 WU (best so far has been .96)

I think that the Saturns like Phoenix1969's where they are hashing at 275GH/s at the server is because they have the 8 VRMs....I don't know diddly, but maybe those early units were meant to IMPRESS those higher rates while the rest were shipped as "satisfactory units" w/ only 4 VRMS.

Hopefully the next firmware will improve on FLUSHWORK SPEED, and the error rate/WU, since I am all HASHED OUT

all 6 boards are 4vrm
one sat likes to run @ 255, one at 265, and one at 275...  all that flashing & unlock cores, eventually dwindles down to origonal speeds after a day for me...did it 3 days in a row...

thanks for the correction phoenix1969 on the 4 VRM, so I strike my prior KNC comment.

Phonenix, are those hash rates at the server side, and how long before those figures go steady on the server after a reboot?

I notice my unit is usually fully operational after about 15 - 30 mins when it seems to stabilize and settle on hash rate/WU and op. temp.
also, the longer between BLOCKS found the better, as flushwork seems to kill performance....its kinda like racing the indy500 and everytime a block is found you have to pit.....weak!

I'm having EXACTLY the same experience.
the pool always polls the wrong avg field in cgminer, but I watch them thru putty, and the GUI, and they pretty much jive, the pool (eligius)always polls crazy numbers.....over a terrahash, and under 500, then shows a bogus average, lol
Yeah, the "Flushwork" is ridiculous....

the pool doesn't "poll" anything from cgminer.  The pool displays a calculated hashrate based on shares that you submit (1 share of diff_1 = 2^32 hashes).  If you get "lucky" and submit 3 shares back-to-back-to-back with the miner having done fewer than average hash calculations in the process, it will appear to the pool as if your hashrate spiked much higher.  Likewise, if your miner is having a bad luck streak and has to crunch through more hashes than average in order to submit a share, it will appear to the pool as though the hashrate slowed down.  This is completely independent from the actual speed of the miner in going about its business of calculating SHA256 hash values.

makes sense, but that could be bad news, because my 3 & 12 hour avg's are around 750 for all 3 sats combined..

[DPoS]

 I (still) have 4 cores on one die that are sitting in disabled mode - wish i could get them working.

not all cores are worth bringing back..  if they flap on and off all the time your HW errors fly up.  .96 seems to balance a lower WU but much lower HW errors for better avg.

would be nice to have release notes right??

I am guessing that it may 'give up' on some cores which is good for problem ones.   but would be nice to control that ourselves.  It would make sense that they have the enable_cores feature now to go along with this design instead of earlier firmware that always tried to bring everything back

[texaslabrat]

FWIW, this bertmod mod seems to work for .96....http://forum.kncminer.com/forum/main-category/main-forum/6183-bertmod-0-2-unofficial-firmware-mod-feedback-thread/page3


also, I am starting to conclude that my Saturn is pretty close to maxing out at 250GH/s on CGminer = 210-225GH/s server side w/ around 20% hardware errors on CG with 3800 WU (best so far has been .96)

I think that the Saturns like Phoenix1969's where they are hashing at 275GH/s at the server is because they have the 8 VRMs....I don't know diddly, but maybe those early units were meant to IMPRESS those higher rates while the rest were shipped as "satisfactory units" w/ only 4 VRMS.

Hopefully the next firmware will improve on FLUSHWORK SPEED, and the error rate/WU, since I am all HASHED OUT

all 6 boards are 4vrm
one sat likes to run @ 255, one at 265, and one at 275...  all that flashing & unlock cores, eventually dwindles down to origonal speeds after a day for me...did it 3 days in a row...

thanks for the correction phoenix1969 on the 4 VRM, so I strike my prior KNC comment.

Phonenix, are those hash rates at the server side, and how long before those figures go steady on the server after a reboot?

I notice my unit is usually fully operational after about 15 - 30 mins when it seems to stabilize and settle on hash rate/WU and op. temp.
also, the longer between BLOCKS found the better, as flushwork seems to kill performance....its kinda like racing the indy500 and everytime a block is found you have to pit.....weak!

I'm having EXACTLY the same experience.
the pool always polls the wrong avg field in cgminer, but I watch them thru putty, and the GUI, and they pretty much jive, the pool (eligius)always polls crazy numbers.....over a terrahash, and under 500, then shows a bogus average, lol
Yeah, the "Flushwork" is ridiculous....

the pool doesn't "poll" anything from cgminer.  The pool displays a calculated hashrate based on shares that you submit (1 share of diff_1 = 2^32 hashes).  If you get "lucky" and submit 3 shares back-to-back-to-back with the miner having done fewer than average hash calculations in the process, it will appear to the pool as if your hashrate spiked much higher.  Likewise, if your miner is having a bad luck streak and has to crunch through more hashes than average in order to submit a share, it will appear to the pool as though the hashrate slowed down.  This is completely independent from the actual speed of the miner in going about its business of calculating SHA256 hash values.

makes sense, but that could be bad news, because my 3 & 12 hour avg's are around 750 for all 3 sats combined..

Well, since the 750 is what eligius is actually paying you for (averaged over time through their capped PPS payout algorithm), that's the number you should be paying attention to IMHO  You're still doing better than my Jupiter on a per-board basis (thanks to 2 sick asics)...I'm getting about 450 430 at the pool versus my long-term average as shown in cgminer of 492-ish.

[Biffa]

Any significance to the sticker numbers? All my Jupiter boards have a "1" and I've been running 525-550GH/s fairly consistently.

I don't think so, I have two #2 and two #3 in mine and its been solid at 555Ghs since I got it

[texaslabrat]

 I (still) have 4 cores on one die that are sitting in disabled mode - wish i could get them working.

not all cores are worth bringing back..  if they flap on and off all the time your HW errors fly up.  .96 seems to balance a lower WU but much lower HW errors for better avg.

would be nice to have release notes right??

I am guessing that it may 'give up' on some cores which is good for problem ones.   but would be nice to control that ourselves.  It would make sense that they have the enable_cores feature now to go along with this design instead of earlier firmware that always tried to bring everything back

Should be able to manually control which cores are disabled in .96 by reverse engineering the mask from the asic_test file.  It looks like it works similarly to a netmask from ip networking.  Convert the mask to binary, and line up the bits with an array of 192 bits representing each core...do an XOR between the two..values that end up as a 1 are active and 0 are disabled.  Or so goes the theory, anyway.

[Phoenix1969]

eligius back up

[OmegaNemesis28]

So I got my Mercury up and running with 0.95
It says its running via SSH at 144GH/s~
Slush pool is reporting 120GH/s~
40C~

Is it worth going to 0.96? Should I apply the enablecores patch? I dont quite understand its use...

And by the way, why would Slush report 20GH/s less than wha cgminer is reporting? My BFL using BFGminer reports exactly what Slush reports.

[chrono030]

 I (still) have 4 cores on one die that are sitting in disabled mode - wish i could get them working.

not all cores are worth bringing back..  if they flap on and off all the time your HW errors fly up.  .96 seems to balance a lower WU but much lower HW errors for better avg.

would be nice to have release notes right??

I am guessing that it may 'give up' on some cores which is good for problem ones.   but would be nice to control that ourselves.  It would make sense that they have the enable_cores feature now to go along with this design instead of earlier firmware that always tried to bring everything back

Yeah - .96 is definitely working the best for me.  I didn't think it was at first, but that was 100% related to my internet being flaky (i ran the cable through a surge protector) and apparently that was introducing a lot of noise.

http://imgur.com/YVg8BGm

[texaslabrat]

So I got my Mercury up and running with 0.95
It says its running via SSH at 144GH/s~
Slush pool is reporting 120GH/s~
40C~

Is it worth going to 0.96? Should I apply the enablecores patch? I dont quite understand its use...

And by the way, why would Slush report 20GH/s less than wha cgminer is reporting? My BFL using BFGminer reports exactly what Slush reports.

From what I can tell, the statistics that KnC's mod of cgminer is including the hw errors into the hash rate.  If you work the math backwards and include the A + R + HW values over set amounts of time, you get the long-term averages displayed.  Ditto the WU values.  I think it's been explained that the driver that KnC wrote is picking out the wrong values for cgminer to display and thus is theoretically fixable (though in the mean time it makes it look as though the miner is faster than it really is).

The most important number is the number displayed at your pool...that's the only number that you get paid for.

[OmegaNemesis28]

So I got my Mercury up and running with 0.95
It says its running via SSH at 144GH/s~
Slush pool is reporting 120GH/s~
40C~

Is it worth going to 0.96? Should I apply the enablecores patch? I dont quite understand its use...

And by the way, why would Slush report 20GH/s less than wha cgminer is reporting? My BFL using BFGminer reports exactly what Slush reports.

From what I can tell, the statistics that KnC's mod of cgminer is including the hw errors into the hash rate.  If you work the math backwards and include the A + R + HW values over set amounts of time, you get the long-term averages displayed.  Ditto the WU values.  I think it's been explained that the driver that KnC wrote is picking out the wrong values for cgminer to display and thus is theoretically fixable (though in the mean time it makes it look as though the miner is faster than it really is).

The most important number is the number displayed at your pool...that's the only number that you get paid for.

Yeah I figured as much. Thanks
I just didnt want to be missing some potential GH/s somewhere somehow with some black magic.

[Phoenix1969]

and here I thought I was getting paid per share...