still using btc guild and thinking should i change to Eligus any idea?
idea - lets go to p2pool Anyone mines on P2Pool?
many ones have i have some suggestion of P2pool? i have about 1500ghs atm find some suggestion here - http://elizium.name/faq.htmlKNC products don't work well with p2pool. They didn't design work restarts properly, you will lose a lot of work and money. If you have a KNC product, and want to use p2pool, contact them and ask them to fix it. you're referring to this https://bitcointalk.org/index.php?topic=18313.msg3294238#msg3294238 right? it is quite annoying also with normal pool that work with stratum. Everytime a block is found you got this on your cgminer: [2013-10-09 19:42:36] Stratum from pool 0 detected new block [2013-10-09 19:42:36] KnC running flushwork [2013-10-09 19:42:36] KnC: accepted by FPGA 1 works, but only 0 submitted [2013-10-09 19:42:36] Rejected 00815da7 Diff 506/326 KnC 0 (Job '26017' not found)
and your hashrate promptly decrease and it takes time to climb up again to normar rate. it also happen with i use btc guild but it wasnt decrease too many work i think sure you're right it's not that the hashrate fall down to zero and stay there for 10 mins. it's a lot less problematic than this. the problem is that it happens not only when your pool find a block, but every time someone find a block, be it one of the million active pools or a solo miner. this happens quite frequently. edit1: to get an idea on how frequently a block is mined look at https://blockchain.info/blocks
|
|
|
still using btc guild and thinking should i change to Eligus any idea?
idea - lets go to p2pool Anyone mines on P2Pool?
many ones have i have some suggestion of P2pool? i have about 1500ghs atm find some suggestion here - http://elizium.name/faq.htmlKNC products don't work well with p2pool. They didn't design work restarts properly, you will lose a lot of work and money. If you have a KNC product, and want to use p2pool, contact them and ask them to fix it. you're referring to this https://bitcointalk.org/index.php?topic=18313.msg3294238#msg3294238 right? it is quite annoying also with normal pool that work with stratum. Everytime a block is found you got this on your cgminer: [2013-10-09 19:42:36] Stratum from pool 0 detected new block [2013-10-09 19:42:36] KnC running flushwork [2013-10-09 19:42:36] KnC: accepted by FPGA 1 works, but only 0 submitted [2013-10-09 19:42:36] Rejected 00815da7 Diff 506/326 KnC 0 (Job '26017' not found)
and your hashrate promptly decrease and it takes time to climb up again to normar rate.
|
|
|
has a single KNC rep even acknowledged this thread???
I really don't know, and I think that today they have other priorities, namely being able to meet the October 15th deadline and solve the problems they had with KnC's pool. Notwithstanding this morning I've sent an email asking to clarify a few issues we discovered in this thread, let see if and what they reply. As soon as I get something I'll share it here.
|
|
|
tracking numbers are being issued now...
wrong thread ?
|
|
|
the core with 0.95 run asap
or you wait some hours before wake up the dead core?
with 0.94 and 0.95 my ASIC slot #4 give me always this: ASIC slot 4 Temperature sensor: 32.0 C Die ID Cores ON Cores OFF % 0 48 0 100 1 0 48 0 2 47 1 97.9 3 48 0 100 (the temp differ sometimes but only by half a Celsius or so) unfortunately for various reasons I hadn't data for 0.90 to 0.93.
|
|
|
how do 0.95 and only 48 core when i install 0.95 firmware my jupiter have all the asic chip off you how do these with firmware 0.95( i mean only 48 core off) dunno really. it simply works like that. I didn't anything fancy just upgrade from .94 to .95. anyway if your miner work better with 0.91 stick with it.
|
|
|
I have this ASIC slot 4 Temperature sensor: 32.0 C Die ID Cores ON Cores OFF % 0 48 0 100 1 0 48 0 2 47 1 97.9 3 48 0 100 DC/DC ID ON/OFF Status Input Voltage Output Voltage Output Current 0 ON OK 11.9 V 0.738 V 38 A (28 W) 1 OFF OFF 11.9 V 0.714 V 0 A 2 ON OK 11.9 V 0.821 V 14.8 A (12.2 W) 3 OFF OFF 11.9 V 0.816 V 0 A 4 ON OK 11.9 V 0.742 V 38.5 A (28.6 W) 5 OFF OFF 11.9 V 0.71 V 0 A 6 OFF OFF 11.9 V 0.74 V 0 A 7 ON OK 11.9 V 0.752 V 41.3 A (31.1 W)
|
|
|
sickpig
what psu you have for jupiter?
also what fimware now you run at jupiter? you have 48 core off at board with sticker number 3?
psu: cooler master v850 fw: 0.95 yes I have 48 core off at with sticker number 3
|
|
|
Major update: (a VRM comes back to life, lots of rambling, no sleep, sorry)
Since I really want to split up jupiters into saturns some day, I ran some more solo and paired tests. It is true that when you run one or two modules they seem to fly. It seems the controller board has some explainin' to do. I was able to get ~270Gh paired and ~135Gh solo but when putting those three together it was a disaster. Cores flopping on one chip that seems really picky when not running solo or paired. Instead of a total over ~400 it would be under ~360 or worse for the three boards
Then as I was putting everything back in resignation, setting up my auto-restart script again for .94 and settling for ~410Gh... I saw the dead VRM show output current again (instead of < 1)
quickly I updated to .95 (yes that is what started this mess, but now I believe I could preserve it by not overclocking it anymore) also, that board was a #1 sticker board which usually have perfect ASICs in them (hardly any cores go down) so it was good to see that VRM wake the hell up again and use more the 3 dies
and here I stand with ~480Gh running the safer .95 which was only getting ~360Gh before. I am not back to the ~520 it was running overclocked, and it is tempting, but I'll just take the lower wattage and being close to what I had for now.
time to get some sleep
(ps - if you ever want to save a file on the miner, put it in /config since most everything gets rewritten on reboot)
by chance did you measure BeagleBloard load (using uptime) while you test the "Saturn" configuration?
|
|
|
I'm having the opposite problem with my bad Jupiter.
I have the three good ones have a sticker 2 on them. The bad one is a sticker of 1.
My other two Jupiters running perfectly fine though have the same configuration.
1 2 2 2
I have 4 VRM's per board fyi.
mine has 8 VRMs per board. did you have any chance to use bertmod to get an idea of cores status on your board? if not look at this mini-guide to get asic status without the need of installing the bertmod fw https://bitcointalk.org/index.php?topic=306969.msg3320948#msg3320948
|
|
|
Firmware 0.95 made mine stable (cgminer would crash and error out on all the other firmwares after 15-20 minutes), but at the cost of hashrate of 20-30Gh/s.
Does anyone know how to setup a cron job in the config via ssh to restart cgminer every ~30 min, so I can see which firmware achieves the best results?
Unfortunately there's no cron installed on the machine so there's no way of doing it in an autonomous way. You need another host that will connect to the miner and the work (e.g. another linux machien where you set cron to do it every 30 mins). another way to do it is installing cronie on your miner: http://www.angstrom-distribution.org/repo/?pkgname=croniedownload it and use this guide to install the package: https://sites.google.com/site/bifferboard/Home/howto/install-opkg-files
|
|
|
An Update on my Jupiter: After taking some advice on the KNC forum I updated to .95, rebooted then did a "hard reset" as outlined in the KNC manual. I saw .95 wasn't working out and switched to .94. I'm now stable at .94 with a cool room where before the hard reset it would drop ghs to unacceptable levels. I'm getting this on Eligius.st right now 3 hours 473.45 Gh/s 1190528 22.5 minutes 475.64 Gh/s 149504 256 seconds 551.80 Gh/s 32890 128 seconds 523.45 Gh/s 15600
My only issue now is this module marked with a "3" sticker on it. My other three modules have "1" and are fine.
Temperature sensor: 31.5 C Die ID Cores ON Cores OFF % 0 48 0 100 1 0 48 0 2 48 0 100 3 48 0 100 DC/DC ID ON/OFF Status Input Voltage Output Voltage Output Current 0 ON OK 11.8 V 0.744 V 34.9 A (26 W) 1 OFF OFF 11.9 V 0.712 V 0 A 2 ON OK 11.9 V 0.815 V 15.1 A (12.3 W) 3 OFF OFF 11.9 V 0.825 V 0 A 4 ON OK 12 V 0.745 V 38.6 A (28.8 W) 5 OFF OFF 11.9 V 0.695 V 0 A 6 OFF OFF 11.8 V 0.739 V 0 A 7 ON OK 11.9 V 0.732 V 40.2 A (29.4 W)
Same here. 3 board with a '1' sticker on top. The fourth is marked with a '3'. Bertmod show me that one my asic slot has a die with all 48 cores disabled. So i thought that knc did this because they didnt have enough well functioning chips for everybody. Last piece of info. All my board have 8 VRM. I'm not able to run .92 e .93. .90 run only for the first few mins, then upgrade to .91. Both .94 and .95 with almoste the same perf Same with my Jupiter, 3 good boards with white label #1 and 1 bad board with label #3 with one of the dies that has all 48 cores off. So all 4 of us (mininganon, jelin1984, sickpig and me) seem to have the same issue. it seems so. If I upgrade my Jupiter to anything other than firmware .91, then this entire board is deactivated and not hashing at all.
my miners can't digest 0.92 and 0.93 due to the fact the cgminer restart every few secs. 0.94/95 both "works". The label #3 slot works as with 0.91 with a die completely disabled, but the other 3 work normally. I think it is safe to say that it is confirmed KNC has been testing each hashing board separately and intentionally mount 1 bad board with 3 good boards per Jupiter. Now the question is if there is anyway to reactivate some of the cores in the non-hashing die.
P.S. One more observation I notice is KNC seems to intentionally place the bad board close to the front of the case where 2 case fans are. This might have done to ensure it has lower temp and a better chance to hash better.
yeah seems logical thing to do. Unfortunately I wasn't aware of bertmod while using 0.91 so I had no data about number of disabled cores. The only thing I know about 0.90 and 0.91 is: - 0.90 makes my jup drains almost 3.3 Ampere @ 220 V ~>730W - 0.91 makes it consumes a lot less energy (~ 2.2 Ampere)
|
|
|
Can anyone running the factory 0.90 (no upgrades ever made) please share a full image of their firmware?
No unfortunately. So you think that the 0.90 they provided is different from the original?
|
|
|
Power-consumption I read in here is now down to 0.85W => you can run your miner way longer than thought. More like >1.1 J/GH. Still that is a lot better than the original 2 J/GH estimate. You pay for wattage at the wall, that is the number that matters. I haven't seen a single report by end user of kill-a-watt showing <500W for system @ 500 GH/s. with 0.94 my two jups give me (5s):513.1G (avg):496.6Gh/s and they drained at the wall 4.4 Ampere @ 220 V --> 968 Watts. (and this includes fans/controll board/BBB etc etc). next time I'll go to the colo I'll redo the measure for 0.95. if KnC will fix the flushwork implmentation I think I can squeeze the ramining GH/s to get 500 on avg, edit: all my PCBs board have 8 VRMs
|
|
|
.95 overnight ASIC slot #1: 54.0 ℃ ASIC slot #2: 54.5 ℃ ASIC slot #3: 58.0 ℃ ASIC slot #4: 52.5 ℃ cover on, ambiente ~22 ℃ have you ever remove you jup cover? if yes did you check which sticker they have? if my theory is correct all of your boards would have a #1 sitcker.
|
|
|
also, to toss a conspiracy theory out there, the one board that is perfect has sticker #1. the other three all have sticker #2 and have atleast a few cores off and one die that 50% are off
it's not a theory in my miners all boards with siticker #1 are almoste perfect. I had one with sticker #3 and it has one die with all 48 cores disabled.
|
|
|
An Update on my Jupiter: After taking some advice on the KNC forum I updated to .95, rebooted then did a "hard reset" as outlined in the KNC manual. I saw .95 wasn't working out and switched to .94. I'm now stable at .94 with a cool room where before the hard reset it would drop ghs to unacceptable levels. I'm getting this on Eligius.st right now 3 hours 473.45 Gh/s 1190528 22.5 minutes 475.64 Gh/s 149504 256 seconds 551.80 Gh/s 32890 128 seconds 523.45 Gh/s 15600
My only issue now is this module marked with a "3" sticker on it. My other three modules have "1" and are fine.
Temperature sensor: 31.5 C Die ID Cores ON Cores OFF % 0 48 0 100 1 0 48 0 2 48 0 100 3 48 0 100 DC/DC ID ON/OFF Status Input Voltage Output Voltage Output Current 0 ON OK 11.8 V 0.744 V 34.9 A (26 W) 1 OFF OFF 11.9 V 0.712 V 0 A 2 ON OK 11.9 V 0.815 V 15.1 A (12.3 W) 3 OFF OFF 11.9 V 0.825 V 0 A 4 ON OK 12 V 0.745 V 38.6 A (28.8 W) 5 OFF OFF 11.9 V 0.695 V 0 A 6 OFF OFF 11.8 V 0.739 V 0 A 7 ON OK 11.9 V 0.732 V 40.2 A (29.4 W)
Same here. 3 board with a '1' sticker on top. The fourth is marked with a '3'. Bertmod show me that one my asic slot has a die with all 48 cores disabled. So i thought that knc did this because they didnt have enough well functioning chips for everybody. Last piece of info. All my board have 8 VRM. I'm not able to run .92 e .93. .90 run only for the first few mins, then upgrade to .91. Both .94 and .95 with almoste the same perf
|
|
|
What denial? What head in the sands?? They worked their asses off to improve the issue. The extra fans just waste electricity. The temps quoted from Bertmod were from the VRMs not the ASIC. Please explain what trainwreck exactly? They, in a week have delivered more hashrate than BFL have to date, and more boxes than Avalon ever achieved. They have just released an update that massively improves hashrate. It was a firmware, not a cooling issue. One week. Fair enough if you don't want to deal with them again, their engineering partners on this project think they are incredible, really. That's not hype.
'Orama I'm well aware of this, and I think they did a terrific work. Kudos to KnC crew. Having said that try walking in KnC's customers shoes, really. There were long days without no news at all a part from piece of info that comes from emails received by customers, Anotherohst.se admins on IRC channels. You can imagine that this the best situation for pure and wild speculation. Do you agree? To this add the pressure everybody felt due to diff going higher and higher. That's why people are freaking out. Finally I wanna thank you personally for the work you've done so far. it was very helpfull to me.
|
|
|
I'm running 0.93. Just tried to upgrade to 0.95, and it seems to work, but after restart the web interface still says that the current firmware revision is 0.93. I tried to upgrade (downgrade) to other versions but it's the same.
It is possible that the upgrade was successful and the web interface displays the wrong version number? Is there a way to check firmware version through ssh?
at least you can access the miner page/tab....I cant... i get "ERROR 500 Internal server error" When I added my backup pools in CGMiner itself, I broke the web interface. I'm assuming that's the common cause for most people. hmm, i have to physically start cgminer thru ssl because the workername was input incorrectly from the factory, which may be the cause then?... it's catch22, because i cant change it on the gui...lol I would guess that the configuration is still saved in a text file you can hand-edit. is it possible to putty in twice simultaneously? just fire two putty instances and login in. you'll get to "parallel" session in two different windows. remember linux ha has anchestor unix.
|
|
|
Someone knows what does it mean "FAULT 17" on status of VRM's? never seen before. how many cores are enabled for that die/asic? fw 0.95 was just released. give it a try.
|
|
|
|