Topic: Swedish ASIC miner company kncminer.com - page 1253. (Read 3049528 times)
Seems like there is a big difference in "Monday morning" units vs. "Friday afternoon" units.
yup, the straight usb seems to be alot easier..
The "plug & play" attempt was a total fail for me
I had an epic battle
it may have worked had the pool workername been correctly transferred, but as they say, hindsight is always 20/20.. I'm still happy with my saturns.
The "plug & play" attempt was a total fail for me
I had an epic battle
it may have worked had the pool workername been correctly transferred, but as they say, hindsight is always 20/20.. I'm still happy with my saturns.
and here I thought I was getting paid per share...
Since a share = 2^32 hashes, the two are interchangeable.
SharePerUnitTime = HashesPerUnitTime/2^32, thus SharePerUnitTime*2^32 = HashesPerUnitTime a.k.a Hashrate if UnitTime= 1s (as seen by the pool via valid submitted shares)
I know you were joking but some people don't seem to grok this so figured I'd spell it out for those folks who might be trying to figure this out for the first time.
I don't think this is strictly true. If I recall correctly, a share of difficulty 1 is defined as a share with 32 leading zeros - which should, on average, require 2^32 hashes to generate, but will, in reality, vary from share to share.
on an individual share, yes you are correct..but over time it converges to 2^32 thus that's what all of the various software stats use for the conversion when they determine how much to pay for a share. Instead, the "fast" or "lucky" share is represented as if your hashrate momentarily spiked so that the math of a share = 2^32 hashes is preserved on the back end. So think of it as your "effective hashrate" which is seen by the pool that goes into those calculations.
Yeah, I understood your point - I just felt challenged to try to match your pedanticism.
haha well played, sir, well played
But I guess the big take-away from all of this is that the stats being displayed on KnC's mod of cgminer are pretty much worthless unless you really want to do a lot of math. Better to just ignore it and focus on what the pool is telling you.
Alrighty, thanks for the attempt for the explanation all haha
Seems a bit silly that its even a thing for it to be wrong. But, with the way its setup, I cant help but feel like its expected. I can see the advantages and disadvantages of their little SoC board stuff for independent mining but I personally would've just preferred a straight to USB connection.
My order is 4114 and apparently it was picked up today. If that means anything to anyone
Yes it does: my 39xx (was paid the same hour it was ordered) is not yet even started to be produced yet.
Let's see if tomorrow will bring any news...Paid mine instantly too, so numbers seem to mean nothing much. You didn't miss much today, there must have been an ASIC party over in Vasteras Sweden which my rig has been to all day...and still is. Look on the bright side mate, if thy can have weekend off they must not feel so rushed and there can't be many left to produce now and they've seen all the mistakes they could possible make hopefully ..so they may take a little more care and send you a well put together machine with decent firmware
agreed.. the cgminer stats in this case, are a plastic carrot...
Or as Obama would say.. "Smoke & Mirrors"... hehe
Or as Obama would say.. "Smoke & Mirrors"... hehe
and here I thought I was getting paid per share...
Since a share = 2^32 hashes, the two are interchangeable.
SharePerUnitTime = HashesPerUnitTime/2^32, thus SharePerUnitTime*2^32 = HashesPerUnitTime a.k.a Hashrate if UnitTime= 1s (as seen by the pool via valid submitted shares)
I know you were joking but some people don't seem to grok this so figured I'd spell it out for those folks who might be trying to figure this out for the first time.
I don't think this is strictly true. If I recall correctly, a share of difficulty 1 is defined as a share with 32 leading zeros - which should, on average, require 2^32 hashes to generate, but will, in reality, vary from share to share.
on an individual share, yes you are correct..but over time it converges to 2^32 thus that's what all of the various software stats use for the conversion when they determine how much to pay for a share. Instead, the "fast" or "lucky" share is represented as if your hashrate momentarily spiked so that the math of a share = 2^32 hashes is preserved on the back end. So think of it as your "effective hashrate" which is seen by the pool that goes into those calculations.
Yeah, I understood your point - I just felt challenged to try to match your pedanticism.
haha well played, sir, well played
But I guess the big take-away from all of this is that the stats being displayed on KnC's mod of cgminer are pretty much worthless unless you really want to do a lot of math. Better to just ignore it and focus on what the pool is telling you.
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.
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.
I thought I read back somewhere that 0.96 was causing issues. Or was it 0.95? I cant find it anymore..... this stuff just goes on forever lol
and here I thought I was getting paid per share...
Since a share = 2^32 hashes, the two are interchangeable.
SharePerUnitTime = HashesPerUnitTime/2^32, thus SharePerUnitTime*2^32 = HashesPerUnitTime a.k.a Hashrate if UnitTime= 1s (as seen by the pool via valid submitted shares)
I know you were joking but some people don't seem to grok this so figured I'd spell it out for those folks who might be trying to figure this out for the first time.
I don't think this is strictly true. If I recall correctly, a share of difficulty 1 is defined as a share with 32 leading zeros - which should, on average, require 2^32 hashes to generate, but will, in reality, vary from share to share.
on an individual share, yes you are correct..but over time it converges to 2^32 thus that's what all of the various software stats use for the conversion when they determine how much to pay for a share. Instead, the "fast" or "lucky" share is represented as if your hashrate momentarily spiked so that the math of a share = 2^32 hashes is preserved on the back end. So think of it as your "effective hashrate" which is seen by the pool that goes into those calculations.
Yeah, I understood your point - I just felt challenged to try to match your pedanticism.
and here I thought I was getting paid per share...
Since a share = 2^32 hashes, the two are interchangeable.
SharePerUnitTime = HashesPerUnitTime/2^32, thus SharePerUnitTime*2^32 = HashesPerUnitTime a.k.a Hashrate if UnitTime= 1s (as seen by the pool via valid submitted shares)
I know you were joking but some people don't seem to grok this so figured I'd spell it out for those folks who might be trying to figure this out for the first time.
I don't think this is strictly true. If I recall correctly, a share of difficulty 1 is defined as a share with 32 leading zeros - which should, on average, require 2^32 hashes to generate, but will, in reality, vary from share to share.
on an individual share, yes you are correct..but over time it converges to 2^32 thus that's what all of the various software stats use for the conversion when they determine how much to pay for a share. Instead, the "fast" or "lucky" share is represented as if your hashrate momentarily spiked so that the math of a share = 2^32 hashes is preserved on the back end.
and here I thought I was getting paid per share...
Since a share = 2^32 hashes, the two are interchangeable.
SharePerUnitTime = HashesPerUnitTime/2^32, thus SharePerUnitTime*2^32 = HashesPerUnitTime a.k.a Hashrate if UnitTime= 1s (as seen by the pool via valid submitted shares)
I know you were joking but some people don't seem to grok this so figured I'd spell it out for those folks who might be trying to figure this out for the first time.
I don't think this is strictly true. If I recall correctly, a share of difficulty 1 is defined as a share with 32 leading zeros - which should, on average, require 2^32 hashes to generate, but will, in reality, vary from share to share.
on an individual share, yes you are correct..but over time it converges to 2^32 thus that's what all of the various software stats use for the conversion when they determine how much to pay for a share. Instead, the "fast" or "lucky" share is represented as if your hashrate momentarily spiked so that the math of a share = 2^32 hashes is preserved on the back end. So think of it as your "effective hashrate" which is seen by the pool that goes into those calculations.
and here I thought I was getting paid per share...
Since a share = 2^32 hashes, the two are interchangeable.
SharePerUnitTime = HashesPerUnitTime/2^32, thus SharePerUnitTime*2^32 = HashesPerUnitTime a.k.a Hashrate if UnitTime= 1s (as seen by the pool via valid submitted shares)
I know you were joking but some people don't seem to grok this so figured I'd spell it out for those folks who might be trying to figure this out for the first time.
I don't think this is strictly true. If I recall correctly, a share of difficulty 1 is defined as a share with 32 leading zeros - which should, on average, require 2^32 hashes to generate, but will, in reality, vary from share to share.
and here I thought I was getting paid per share...
Since a share = 2^32 hashes, the two are interchangeable.
SharePerUnitTime = HashesPerUnitTime/2^32, thus SharePerUnitTime*2^32 = HashesPerUnitTime a.k.a Hashrate if UnitTime= 1s (as seen by the pool via valid submitted shares)
I know you were joking but some people don't seem to grok this so figured I'd spell it out for those folks who might be trying to figure this out for the first time.
I tried a wireless bridge... it sucked... totally.
Want one?...lol
Want one?...lol
There are some crappy ones out there for sure...but the one I linked is pretty awesome for those just now starting to wonder about how to put their miner on wireless and don't want to jump through a lot hoops to do it.
I was not satisfied at all with a bridge, it liked to drop connections randomly...
The laptop's range is like 10x as far, gets waaay better reception, and has never dropped the connection in 6 days so far...
The old WinXP laptop has a wireless that I disabled for testing this RPI router. Since wasn't all too difficult I might try making it the wireless router instead of the RPI. It does only have XP home so auto config is out but with the route command it should be possible.
Just off the treadmill and a couple of thoughts. Must get DHCP working on the RPi assigning addresses to the .2.0 network so I don't have to add a static address to whatever is to the RJ45 connector. But with the hot pepper USB connection, I can just plug it into the RPi and run cgminer on the RPi and it will be handled on the 1.0 network to wlan0. I would need the RPi net .2.0 routing for the Merc tho as that would be to the RPi RJ45.
Simpler is to really draw the heat out of the BBB. I have my first native BBB and haven't fired it up yet. Different by far than Debian/Ubuntu/Rasperian linux, no apt-get to install programs. Still I'm sure it comes native with whyfri pre-configured. I have old racks of three fans that would plug into a CD drive opening, 12v, and as they're small, I think I'll put standoffs on the native BBB, add braces to fit the smaller 12v fan, and swap the native BBB for the Merc BBB. The fan will be blowing down on the wrong side of the BBB pcb to best cool the warmest chip, but should work. Then bringing out the USB on a cable, put in a USB wifi and wake up the Merc with the ASIC disconnected and no RJ45 ethernet connected and see if DHCP assigns an address to the BBB.
and here I thought I was getting paid per share... 
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.
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.
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.
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.
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
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.
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.
eligius back up
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.
Jump to: