Swedish ASIC miner company kncminer.com

[soy]

I tried a wireless bridge... it sucked... totally.
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.

sure... all helps...
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.

[texaslabrat]

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.

[xyzzy099]

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.

[texaslabrat]

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.

[Phoenix1969]

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.

Hence, the term "Average"

[xyzzy099]

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.

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

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

[texaslabrat]

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.

[Phoenix1969]

agreed.. the cgminer stats in this case, are a plastic carrot...
Or as Obama would say.. "Smoke & Mirrors"... hehe

[timmmers]

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

[OmegaNemesis28]

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.

[Phoenix1969]

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.

[MrHempstock]

Seems like there is a big difference in "Monday morning" units vs. "Friday afternoon" units. 

[OmegaNemesis28]

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.

It was particularly bad for me because my school's network only supports Cisco NAC compatible operating systems. Obviously this thing wouldn't take that so I had to bridge a laptop to wifi with it. Which is super unstable and hacky. Im afraid to touch the setup in fear of resetting something by mistake and being stuck with a miner that can't connect again because.

[icem3lter]

Seems like there is a big difference in "Monday morning" units vs. "Friday afternoon" units. 

Almost no difference, in 2 and half day you wont mine much, so no big change in ROI if you keep your miner mining long

[Phoenix1969]

Seems like there is a big difference in "Monday morning" units vs. "Friday afternoon" units.  

Almost no difference, in 2 and half day you wont mine much, so no big change in ROI if you keep your miner mining long

you are way off base here.. it's a quality of machine during manufacturing thing...but since you mentioned it..
I'd still rather have it sooner, than later...

but to add to Hemptsock's comment...
or a 3am saturday unit... with 30 folks staring down your back, and deadlines...lol

[soy]

Okay, up and running with a couple of good sized tantalum caps on the module 12v rail.  Will catch up on posts while it settles out on 0.94 then see if 0.95 is any better.  Opps, forgot to enablecores as a few were down on 1 die.

[RoadStress]

I have some noob and semi offtopic questions: 1) how do i check a transaction by the txid?; 2) how do i send a transaction with a message in it?

[Phoenix1969]

I have some noob and semi offtopic questions: 1) how do i check a transaction by the txid?; 2) how do i send a transaction with a message in it?

uuuh, copy & paste worked great for me....?


just kidding...
copy the message they give you..
open your wallet
click on recieve tab
highlight your wallet
at bottom choose sign message
paste message into big box
click sign message
copy the signature over to the signature field in eligius
do not hit save for at least 1/2 hour, as the blockchain will need to send out the signature...
it will tell you if signature failed or succeeded then

[soy]

Okay, up and running with a couple of good sized tantalum caps on the module 12v rail.  Will catch up on posts while it settles out on 0.94 then see if 0.95 is any better.  Opps, forgot to enablecores as a few were down on 1 die.

Now running 0.94, that's .91-.94volts on the core, all cores 100% but I suspect I'll see cores dropping on die 3 as it's drawing 50.6amps while the others are drawing under 50amps.

But the real test isn't if die 3 drops 1-3 cores or not, it's if the cores will stay almost as good on 0.95 with .7volts on the cores.  Big difference, 270watts at the wall versus what was it 148?

Okay, I'm already up to 129GH/s.  0.95 could never get pass 100GH/s so time to give it a test.

----------------

Okay, no good.  Lots of cores being disabled.  No way.