Though on a side note my hardware error rate is slowly creeping back up to 6.8 already. Going to try and downgrade to 9.6.1 my self and see if its any better.
Also bear in mind that if the hashrate looks higher artificially on the kncminer version, then the hardware error % rate will also look artificially lower. Thanks... So i take it i have to keep putty running to keep this version of cgminer? i notice when i close putty my miner stops and i got to reboot it to get it back online again. Or is there a way to run this so i don't have to have my laptop on? Also is there a way so it starts with this version after a restart? thanks If you start cgminer with this instead: screen -dm ./cgminer -c cgminer.conf it will start in the background in a "screen session" so it will keep running. Then you can "attach" to the screen with to see what's happening Even if you close your ssh session or putty it will keep on running. |
|
|
|
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. 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: 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
cat /proc/loadavg 2.02 1.99 2.08 1/77 26030 Whatever's using CPU, it is not cgminer at <=2% |
|
|
|
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. |
|
|
|
@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'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/cgminerYou'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! Built native on the device directly with 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. |
|
|
|
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. |
|
|
|
Then would you say that pool stats like what BTC Guild provides you with would be more accurate then their CGMiner?
Yes, if it's a large enough time period. Days. So it seems to me that only 1/3 of my Jupis are up the advertised speed of 550  530-550 480-500 230-300 (Runs really hot at 300 so hot that the case is almost uncomfortable to touch.) Indeed that's a perfect example of why the default binary was substandard in that regard. If you have that much heat as a problem, check they didn't mistakenly leave a bit of plastic between the device and the cooler... that's happened to someone on this thread. |
|
|
|
any idea when you will of fixed the new Avalon firmware as I noticed Bad next to it
I'm a bit worried because I didn't change anything from how I usually built firmware and it was fine for me, yet it was bad for the 2 users who tried it, so until I can figure out what the actual issue was, I won't release a newer one. ck - Always been a huge fan of your releases, thanks for all the great work! I had a buddy just upgrade his to the latest release no issue, I was about to until I saw the -bad also... Is it just not coming back up on restart for people or  He says he gets better performance with the new firmware so I really wanted to try it probably will do so tomorrow on one of the minis since it sounds like we can still recover. Anyone else tried it with either success or fail? You're welcome. Mine certainly took longer than usual to come up after flashing to that one, but it's been working very well except for my status line not showing up as per normal. However if you read the posts from the two people who tried it, theirs didn't come up at all (no idea why!?). It's fixable if that happens though (see my post later on on how to reset it), it's not like it bricks the avalon. |
|
|
|
Though on a side note my hardware error rate is slowly creeping back up to 6.8 already. Going to try and downgrade to 9.6.1 my self and see if its any better.
Also bear in mind that if the hashrate looks higher artificially on the kncminer version, then the hardware error % rate will also look artificially lower. |
|
|
|
Then would you say that pool stats like what BTC Guild provides you with would be more accurate then their CGMiner?
Yes, if it's a large enough time period. |
|
|
|
Note that I've also updated the binary slightly though it may not be noticeably different. However I know people love to try every little change, so feel free to repeat the instructions  |
|
|
|
Use putty connection to 192.168.1x instead of using ssh for the first step ssh into your kncminer if you know its IP address is 192.168.1.X: ssh -l root 192.168.1.X
screen -d -r
q
wget http://ck.kolivas.org/apps/cgminer/kncminer/cgminer
chmod +x cgminer
./cgminer -c /config/cgminer.conf
q is to quit the already running cgminer |
|
|
|
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/cgminerNote that WU also includes the fakedmisrepresented hashrate in the regular binary included in knc firmware. |
|
|
|
ssh into your kncminer if you know its IP address is 192.168.1.X: ssh -l root 192.168.1.X
screen -d -r
q
wget http://ck.kolivas.org/apps/cgminer/kncminer/cgminer
chmod +x cgminer
./cgminer -c /config/cgminer.conf
q is to quit the already running cgminer Note also that this is perfectly safe and only saves the cgminer binary to the ramdisk which means that if you have any issues or reboot it will just go back to the usual cgminer built in. It is also compatible with any of the kncminer firmwares, though I find 0.96.1 to be the best for me. |
|
|
|
any idea when you will of fixed the new Avalon firmware as I noticed Bad next to it
I'm a bit worried because I didn't change anything from how I usually built firmware and it was fine for me, yet it was bad for the 2 users who tried it, so until I can figure out what the actual issue was, I won't release a newer one. |
|
|
|
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/cgminerYou'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. I'm still learning linux, but would love to try this... I'll let someone post a clear procedure before I try... ug.Thank you cklovas! I second this. ssh into your kncminer if you know its IP address is 192.168.1.X: ssh -l root 192.168.1.X
screen -d -r
q
wget http://ck.kolivas.org/apps/cgminer/kncminer/cgminer
chmod +x cgminer
./cgminer -c /config/cgminer.conf
q is to quit the already running cgminer |
|
|
|
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/cgminerYou'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. |
|
|
|
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/cgminerYou'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. |
|
|
|
|
Show Posts
