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 |
|
|
|
@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% 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! |
|
|
|
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! those are instructions to compile bfgminer from source: http://codepad.org/QKSeO5zhbasically 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. 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. |
|
|
|
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... |
|
|
|
nice...Id be scared to touch it too, thats great!
on the 2nd pool, I think you can just use putty to do it in cgminer, just remember to save to /config/cgminer.conf, and not the root/default directory. your default pool is pool 0, the backup is 1...
BTW... error rates, 1%, 3%, 3%. wow.
Dumb questions: 1) Did you apply all those hw tricks withe the machine switched on? 2) a part from makes VRM clicks and check the heatsink screws thre's something else to do? Unreleated to this just wanna share that BB sys load lowered to 1.5 from 1.9 when using bfgminer instead of cgminer (bfgminer compiled fro source doeas not include dynamic cores enable/disable mechanism committed on the 25) |
|
|
|
somethings up. I'm fighting with all my machines, someone hates me.
i switched my nonworking machines to eligius, now they work again... .  What was the pool that makes your miners freak out? slush...and it was fine before,....huh I knew it ;P Today slush was down for a while since 4pm utc and it seems that there's still some problem to connect for some miners. The main issue seems to be fixed, thou. |
|
|
|
somethings up. I'm fighting with all my machines, someone hates me.
i switched my nonworking machines to eligius, now they work again... . What was the pool that makes your miners freak out? |
|
|
|
do you need to run enablecores.bin on .97, not sure? Anyone?
as long as you have already run enablecore.bin at least once and/or flashed 0.96 at least once you should not need to run it. /etc/init.d/cgminer.sh before starting cgminer go through all the cores and enable them. I don't rember where (and I don't have time know to look up for the post, pardom me if you can) but I read that one of the first fw (0.90 maybe) wrote the map of bad core on asic eprom and there was no way to overwrite it at runtime. that's the reason why knc release enablecore.bin. |
|
|
|
Mining and website is down.
Anyone got some info ?
No. But the first time i've found a 503 page there where a message that said something like "down for maintemance, mining activity still functioning" "Website is under the maintenance, but mining works without an interruption. You can follow updates on Facebook page." |
|
|
|
my miners are down now  Is all the infrastrcure down or just the web frontend? I can't check my miners now. Both my miners and the web page are off. Of course this has to happen when I'm away with no way to connect to the miners :/ Anyway i can't nobody else than me for having avoided to set a pool failover |
|
|
|
my miners are down now Is all the infrastrcure down or just the web frontend? I can't check my miners now. |
|
|
|
At least this one was only 9 mins, some of the others were over 1 hour. It would be better if the pool could identify a bad block early in the process and then dump it. sure if possible it would be amazing. on another note to balance this high number of invalid blocks it seems we're finding blocks like there's no tomorrow, maybe those two facts are correlated. |
|
|
|
My plug'n'pray device is on it's way
ROTFL I'm glad that is finally arriving... |
|
|
|
Did you try firmware 0.90 then enablecores.bin? Are you forcing air onto the BBB? A warmish BBB will drop your hashrate.
Why would a "warmish" BBB drop your hashrate? Field experience. Several board members report that adding intake airflow at the front bottom improve prformance. Look for DPoS posts in this and "knc jupiter first impression" thread More likely has to do with cooling the VRMs then the BB. Yes it could be one of the possible reasons. |
|
|
|
I would be interested to hear what the theory is behind that "field experience". On the face of it, that sounds ridiculous. I have seen stranger things though, so I am not gonna call BS just yet.
which was the main reason I didn't post it to the boards for 3 days and kept it to myself.... you've probably done the right thing ;-) |
|
|
|
Did you try firmware 0.90 then enablecores.bin? Are you forcing air onto the BBB? A warmish BBB will drop your hashrate.
Why would a "warmish" BBB drop your hashrate? Field experience. Several board members report that adding intake airflow at the front bottom improve prformance. Look for DPoS posts in this and "knc jupiter first impression" thread I would be interested to hear what the theory is behind that "field experience". On the face of it, that sounds ridiculous. I have seen stranger things though, so I am not gonna call BS just yet. I think it was a lone customer... yes... others? As i've already said i'm commuting back home and i'm typing this from my smartphone, as doon as i get access to a proper device i will look up for reference. If memeory serves also trepex found it useful |
|
|
|
|
Show Posts
