So i was able to get ahold of them and this is what was said when i asked the status of my miner. It shows in progress. I was like okay well i had recived an email stating that it will ship thursday of last week. they said that that should never been sent via email however they will email me later on today once they find out the status of the factory today.
what kind of BS is that crap?
Topic: Swedish ASIC miner company kncminer.com - page 1200. (Read 3049524 times)
Yeah it's not a matter of CPU time, since top output confute the theory for every version of cgminer/bfgminer I've tested so far. I rather think is something I/O related.
Agreed. I think it's probably the way the spi communication is accounted, yet it doesn't show up in top, and since I happen to have written a few load average meters over the years with the various kernel schedulers I wrote for linux, I know better than most how hard it is to know exactly how much CPU time is in use and where.spi could be the hidden culprit here
time will tell especially when/if knc will release FGPA firmware source code. On a related note as a long time BFS user I really appreciate the work you've done in the linux kernel
Yeah it's not a matter of CPU time, since top output confute the theory for every version of cgminer/bfgminer I've tested so far. I rather think is something I/O related.
Agreed. I think it's probably the way the spi communication is accounted, yet it doesn't show up in top, and since I happen to have written a few load average meters over the years with the various kernel schedulers I wrote for linux, I know better than most how hard it is to know exactly how much CPU time is in use and where. @ckolivas
I am trying your 3.6.6 build on my problem jupiter (which has been downgraded back to 0.95 after worse performance on .96, .961, .97)
I notice the same flushwork hashrate drop with your build on 0.95 and was wondering if only fw 0.97 will fix that issue ?
thanks
Flush speed is fpga firmware related. I've done what I can to minimise software interference but the firmware is the key there.I am trying your 3.6.6 build on my problem jupiter (which has been downgraded back to 0.95 after worse performance on .96, .961, .97)
I notice the same flushwork hashrate drop with your build on 0.95 and was wondering if only fw 0.97 will fix that issue ?
thanks
good to know.
Unluckily I'm not able to connect remotely to my miner at the moment, hence I can't test "orginal" cgminer. As soon as I re-gain access to the machine I will let you know.
In the meantime could some one share the sys load avg while running ckolivas' cgminer?
Withe the KnC version I got something aroung 1.92-1.98 all the time. Using bfgminer sys load lower to something like 1.48-1.52. it would be handy if the same happen with this brand new cgminer.
Top output while it's running:
Code:
Mem: 144880K used, 365692K free, 0K shrd, 3840K buff, 122056K cached
CPU: 2% usr 4% sys 0% nic 93% idle 0% io 0% irq 0% sirq
Load average: 1.93 1.97 2.07 1/77 25802
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
8411 6829 root S 120m 24% 2% ./cgminer -c config/cgminer.conf
58 2 root DW 0 0% 1% [spi1]
6828 6827 root S 2748 1% 0% {screen} SCREEN
CPU: 2% usr 4% sys 0% nic 93% idle 0% io 0% irq 0% sirq
Load average: 1.93 1.97 2.07 1/77 25802
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
8411 6829 root S 120m 24% 2% ./cgminer -c config/cgminer.conf
58 2 root DW 0 0% 1% [spi1]
6828 6827 root S 2748 1% 0% {screen} SCREEN
cat /proc/loadavg
2.02 1.99 2.08 1/77 26030
Whatever's using CPU, it is not cgminer at <=2%
Yeah it's not a matter of CPU time, since top output confute the theory for every version of cgminer/bfgminer I've tested so far. I rather think is something I/O related.
thanks for sharing!
@ckolivas
I am trying your 3.6.6 build on my problem jupiter (which has been downgraded back to 0.95 after worse performance on .96, .961, .97)
I notice the same flushwork hashrate drop with your build on 0.95 and was wondering if only fw 0.97 will fix that issue ?
thanks
Flush speed is fpga firmware related. I've done what I can to minimise software interference but the firmware is the key there.I am trying your 3.6.6 build on my problem jupiter (which has been downgraded back to 0.95 after worse performance on .96, .961, .97)
I notice the same flushwork hashrate drop with your build on 0.95 and was wondering if only fw 0.97 will fix that issue ?
thanks
good to know.
Unluckily I'm not able to connect remotely to my miner at the moment, hence I can't test "orginal" cgminer. As soon as I re-gain access to the machine I will let you know.
In the meantime could some one share the sys load avg while running ckolivas' cgminer?
Withe the KnC version I got something aroung 1.92-1.98 all the time. Using bfgminer sys load lower to something like 1.48-1.52. it would be handy if the same happen with this brand new cgminer.
Top output while it's running:
Code:
Mem: 144880K used, 365692K free, 0K shrd, 3840K buff, 122056K cached
CPU: 2% usr 4% sys 0% nic 93% idle 0% io 0% irq 0% sirq
Load average: 1.93 1.97 2.07 1/77 25802
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
8411 6829 root S 120m 24% 2% ./cgminer -c config/cgminer.conf
58 2 root DW 0 0% 1% [spi1]
6828 6827 root S 2748 1% 0% {screen} SCREEN
CPU: 2% usr 4% sys 0% nic 93% idle 0% io 0% irq 0% sirq
Load average: 1.93 1.97 2.07 1/77 25802
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
8411 6829 root S 120m 24% 2% ./cgminer -c config/cgminer.conf
58 2 root DW 0 0% 1% [spi1]
6828 6827 root S 2748 1% 0% {screen} SCREEN
cat /proc/loadavg
2.02 1.99 2.08 1/77 26030
Whatever's using CPU, it is not cgminer at <=2%
I've just created a kncminer branch on my github and have imported their most current code and built my first binary for this. It is not a full firmware and the only thing users may note is the hashrate won't lie with this one, as it won't count hardware errors as hashrate. Also my hardware error count is significantly lower with this on the Saturn dev machine I was sent.
Here's a direct link to the binary:
http://ck.kolivas.org/apps/cgminer/kncminer/cgminer
You'll have to ssh into the kncminer and copy and use that file directly. Hopefully the libraries all match between my dev environment and the default kncminer operating system which means the binary should just work if you run it like on any other OS.
Here's a direct link to the binary:
http://ck.kolivas.org/apps/cgminer/kncminer/cgminer
You'll have to ssh into the kncminer and copy and use that file directly. Hopefully the libraries all match between my dev environment and the default kncminer operating system which means the binary should just work if you run it like on any other OS.
Any guidance for those of us who like to compile our own software on building for ARM? Are you building on-device or cross compiling on your x86? I've not built your project before, but I see you've got the kncminer branch in github. Thanks!
those are instructions to compile bfgminer from source:
http://codepad.org/QKSeO5zh
basically it explains how to add a few repos from which download pre-compiled stuff (library/tools/dev pakg etc etc), hopefully it could help to build cgminer using directly your miner without the need to cross compile.
@ckolivas
I am trying your 3.6.6 build on my problem jupiter (which has been downgraded back to 0.95 after worse performance on .96, .961, .97)
I notice the same flushwork hashrate drop with your build on 0.95 and was wondering if only fw 0.97 will fix that issue ?
thanks
Flush speed is fpga firmware related. I've done what I can to minimise software interference but the firmware is the key there.I am trying your 3.6.6 build on my problem jupiter (which has been downgraded back to 0.95 after worse performance on .96, .961, .97)
I notice the same flushwork hashrate drop with your build on 0.95 and was wondering if only fw 0.97 will fix that issue ?
thanks
good to know.
Unluckily I'm not able to connect remotely to my miner at the moment, hence I can't test "orginal" cgminer. As soon as I re-gain access to the machine I will let you know.
In the meantime could some one share the sys load avg while running ckolivas' cgminer?
Withe the KnC version I got something aroung 1.92-1.98 all the time. Using bfgminer sys load lower to something like 1.48-1.52. it would be handy if the same happen with this brand new cgminer.
If cgminer 3.6.6 were to crash, I assume that it would not restart automatically?
For some reason I don't understand, on cgminer restarts my primary and secondary (bitminter) pool are "dead" for about 60-90 seconds, but my tertiary pool is alive from the beginning so mining starts there, before switching back to pool 0
Therefore every time cgminer crash/restarts (not that often) I receive an email from pool 2 that my worker has stopped submitting shares.
If you specify a stratum pool without the stratum+tcp:// prefix, cgminer tries a few different ways to connect first. Some pools don't like this and it can take a while before cgminer can connect. So to speed up the connections, add the prefix. For some reason I don't understand, on cgminer restarts my primary and secondary (bitminter) pool are "dead" for about 60-90 seconds, but my tertiary pool is alive from the beginning so mining starts there, before switching back to pool 0
Therefore every time cgminer crash/restarts (not that often) I receive an email from pool 2 that my worker has stopped submitting shares.
If cgminer 3.6.6 were to crash, I assume that it would not restart automatically?
For some reason I don't understand, on cgminer restarts my primary and secondary (bitminter) pool are "dead" for about 60-90 seconds, but my tertiary pool is alive from the beginning so mining starts there, before switching back to pool 0
Therefore every time cgminer crash/restarts (not that often) I receive an email from pool 2 that my worker has stopped submitting shares.
For some reason I don't understand, on cgminer restarts my primary and secondary (bitminter) pool are "dead" for about 60-90 seconds, but my tertiary pool is alive from the beginning so mining starts there, before switching back to pool 0
Therefore every time cgminer crash/restarts (not that often) I receive an email from pool 2 that my worker has stopped submitting shares.
still getting voicemail 
@ckolivas
I am trying your 3.6.6 build on my problem jupiter (which has been downgraded back to 0.95 after worse performance on .96, .961, .97)
I notice the same flushwork hashrate drop with your build on 0.95 and was wondering if only fw 0.97 will fix that issue ?
thanks
Flush speed is fpga firmware related. I've done what I can to minimise software interference but the firmware is the key there. I am trying your 3.6.6 build on my problem jupiter (which has been downgraded back to 0.95 after worse performance on .96, .961, .97)
I notice the same flushwork hashrate drop with your build on 0.95 and was wondering if only fw 0.97 will fix that issue ?
thanks
@ckolivas
I am trying your 3.6.6 build on my problem jupiter (which has been downgraded back to 0.95 after worse performance on .96, .961, .97)
I notice the same flushwork hashrate drop with your build on 0.95 and was wondering if only fw 0.97 will fix that issue ?
thanks
I am trying your 3.6.6 build on my problem jupiter (which has been downgraded back to 0.95 after worse performance on .96, .961, .97)
I notice the same flushwork hashrate drop with your build on 0.95 and was wondering if only fw 0.97 will fix that issue ?
thanks
Don't stuck with Bitcoin.
Underperformed Saturn 180 GH/s
Bitcoin Mining BTCGuild 0,23 BTC (Daily)
PPcoin Solo mining Found 3 Blocks 3 X 207 PPC = 621 PPC X 0.0020200 (Cryptsy Price) = 1.25442 BTC (Daily)
Terracoin Solo Mining 0,3342 BTC (Daily)
And without difficulty worries!!!
Underperformed Saturn 180 GH/s
Bitcoin Mining BTCGuild 0,23 BTC (Daily)
PPcoin Solo mining Found 3 Blocks 3 X 207 PPC = 621 PPC X 0.0020200 (Cryptsy Price) = 1.25442 BTC (Daily)
Terracoin Solo Mining 0,3342 BTC (Daily)
And without difficulty worries!!!
dunno if I'm using it correctly, this calculator
http://www.coinwarz.com/calculators/ppcoin-mining-calculator/?h=500000.00&p=500.00&pc=0&pf=0.00&d=5941288.50405274&r=202.52862206&er=0.00196000&hc=0.00
says me that if I use a jup (circa 500GH/s) to mine PPCoins I'll get 0.67202545 BTC a day at current PPC/BTC exchange rate.
Using the same hashpower mining btc could bring me 0.6432 BTC.
Am I missing something obvious?
Solo mining depends on luck. The calculators use different maths.
Very true the former. Wrong the latter. Math is the same.
And for the exact same reason you could have earned 0 btc...
Don't stuck with Bitcoin.
Underperformed Saturn 180 GH/s
Bitcoin Mining BTCGuild 0,23 BTC (Daily)
PPcoin Solo mining Found 3 Blocks 3 X 207 PPC = 621 PPC X 0.0020200 (Cryptsy Price) = 1.25442 BTC (Daily)
Terracoin Solo Mining 0,3342 BTC (Daily)
And without difficulty worries!!!
Underperformed Saturn 180 GH/s
Bitcoin Mining BTCGuild 0,23 BTC (Daily)
PPcoin Solo mining Found 3 Blocks 3 X 207 PPC = 621 PPC X 0.0020200 (Cryptsy Price) = 1.25442 BTC (Daily)
Terracoin Solo Mining 0,3342 BTC (Daily)
And without difficulty worries!!!
dunno if I'm using it correctly, this calculator
http://www.coinwarz.com/calculators/ppcoin-mining-calculator/?h=500000.00&p=500.00&pc=0&pf=0.00&d=5941288.50405274&r=202.52862206&er=0.00196000&hc=0.00
says me that if I use a jup (circa 500GH/s) to mine PPCoins I'll get 0.67202545 BTC a day at current PPC/BTC exchange rate.
Using the same hashpower mining btc could bring me 0.6432 BTC.
Am I missing something obvious?
Solo mining depends on luck. The calculators use different maths.
I've just created a kncminer branch on my github and have imported their most current code and built my first binary for this. It is not a full firmware and the only thing users may note is the hashrate won't lie with this one, as it won't count hardware errors as hashrate. Also my hardware error count is significantly lower with this on the Saturn dev machine I was sent.
Here's a direct link to the binary:
http://ck.kolivas.org/apps/cgminer/kncminer/cgminer
You'll have to ssh into the kncminer and copy and use that file directly. Hopefully the libraries all match between my dev environment and the default kncminer operating system which means the binary should just work if you run it like on any other OS.
Here's a direct link to the binary:
http://ck.kolivas.org/apps/cgminer/kncminer/cgminer
You'll have to ssh into the kncminer and copy and use that file directly. Hopefully the libraries all match between my dev environment and the default kncminer operating system which means the binary should just work if you run it like on any other OS.
Any guidance for those of us who like to compile our own software on building for ARM? Are you building on-device or cross compiling on your x86? I've not built your project before, but I see you've got the kncminer branch in github. Thanks!
CFLAGS="-Wall -W -O2 -march=native" nice -19 ./autogen.sh --host=arm-angstrom-linux-gnueabi --enable-knc
Setting up the build environment is non-trivial and I had help from hno who wrote the original driver. I'm assuming that at some stage there will be a comprehensive document describing this process.
rpcuser=anyname
rpcpassword=anypassword
rpcallowip=127.0.0.1
rpcallowip=your pc ip
rpcport=9902
daemon=1
server=1
listen=1
gen=0
rpcpassword=anypassword
rpcallowip=127.0.0.1
rpcallowip=your pc ip
rpcport=9902
daemon=1
server=1
listen=1
gen=0
So if I had multiple machines, would I change listen to that quantity?
I dont know, you have to try!
Note that WU also includes the fakedmisrepresented hashrate in the regular binary included in knc firmware.
Faked is too strong a word. They weren't consciously trying to make the hashrate look higher than it was. 
hello and thank you ckolivas (and kano if he was involved in anyway in this new release of cgminer).
2ndly, for those of US that find this new version of cgminer works/improves their mining, please don't forget to send some btc love to ckolivas. Lets keep these important members of the btc community well fed so their minds are tip top.
And finally, ckolivas, did you see anything in knc miners code that would cause lower hashing rates, not just report inaccurate HW errors?
thanks.
You're welcome. I didn't spot anything on a brief glance of the code. I have not done a full audit of the code as of yet. It appears quite sound.2ndly, for those of US that find this new version of cgminer works/improves their mining, please don't forget to send some btc love to ckolivas. Lets keep these important members of the btc community well fed so their minds are tip top.
And finally, ckolivas, did you see anything in knc miners code that would cause lower hashing rates, not just report inaccurate HW errors?
thanks.
I'm sure we are all wondering and if this has been addressed sorry
but
Are you planning on making or taking over knc's version of cgminer (please please say yes) it needs a lot of work imho...stuff like the enabling the all cores stuff and or incorp bertmod or an tag to his setup..i don't code just throwing it out there
I have one of them "supposedly" speedy jupiters and running it on .95 not brave enough to upgrade with the issues some have had on here
imho we need your expertise
just saying
and as a noob side point..i'll wait for your version of cgminer to pop up in the install driver option of the knc downloads of driver
I can probably do such patches like the small one to correct HW error rates to a true point...but when you say binary and I download the file and it is in txt format I go huh and everything goes on hold.....
and hten add Ubuntu on top of that ...so i'm waiting for rescue from .95 cgminer knc flavor
Searing
Thanks alot for writing this. Running 3.6.6 of your code now.
My Jupiter is at 514Gh/s which is likely the real number.
Have not messed with the pressing down on anything yet. Cover is off. Will try putting the cover back on and see if higher temp increases the hash rate.
My Jupiter is at 514Gh/s which is likely the real number.
Have not messed with the pressing down on anything yet. Cover is off. Will try putting the cover back on and see if higher temp increases the hash rate.
hello and thank you ckolivas (and kano if he was involved in anyway in this new release of cgminer).
2ndly, for those of US that find this new version of cgminer works/improves their mining, please don't forget to send some btc love to ckolivas. Lets keep these important members of the btc community well fed so their minds are tip top.
And finally, ckolivas, did you see anything in knc miners code that would cause lower hashing rates, not just report inaccurate HW errors?
thanks.
You're welcome. I didn't spot anything on a brief glance of the code. I have not done a full audit of the code as of yet. It appears quite sound.2ndly, for those of US that find this new version of cgminer works/improves their mining, please don't forget to send some btc love to ckolivas. Lets keep these important members of the btc community well fed so their minds are tip top.
And finally, ckolivas, did you see anything in knc miners code that would cause lower hashing rates, not just report inaccurate HW errors?
thanks.
hello and thank you ckolivas (and kano if he was involved in anyway in this new release of cgminer).
2ndly, for those of US that find this new version of cgminer works/improves their mining, please don't forget to send some btc love to ckolivas. Lets keep these important members of the btc community well fed so their minds are tip top.
And finally, ckolivas, did you see anything in knc miners code that would cause lower hashing rates, not just report inaccurate HW errors?
thanks.
You're welcome. I didn't spot anything on a brief glance of the code. I have not done a full audit of the code as of yet. It appears quite sound. 2ndly, for those of US that find this new version of cgminer works/improves their mining, please don't forget to send some btc love to ckolivas. Lets keep these important members of the btc community well fed so their minds are tip top.
And finally, ckolivas, did you see anything in knc miners code that would cause lower hashing rates, not just report inaccurate HW errors?
thanks.
Jump to: