i check all the connectors everything
something is do with firmware
or with chip board
dunno could be a faulty chip board dunno. tomorrow once I'll apply mods to airflow I'll report back anyway for each of my jups: 3 out of 4 asic are ok, the other one has only 3 die out of 4 working so 75% perf. how is your hashing?
you have 2 good and 1 faulty or not?
(5s):509.4G (avg):496.7Gh/s |
|
|
|
i have the same problem
with you?
what we can do?
check if internal fun are correctly mounted. which firmware you have?
0.94 when i install 0.94 firmware is total dead the chip
when install 0.91 work at 75%
good to know. with 0.94 I get an overall 4-5% increase in performance. before I tried both .92/.93 but no luck since cgminer restart every few seconds. unluckily I don't have data point for 0.91 since I wasn't aware of bertmod :/ |
|
|
|
how many asic chips is dead? only one or and the 4 chips have dead 1/4?  on both my jups 3 out 4 ASIC run almost at 100%, the forth one run at 75% |
|
|
|
I don't want to complain too much as I am a DAY1 customer that did receive one Saturn at home and another one online hashing at the KnC datacenter. I also received my (first ?) bonus/compensation from KnC. But I also thought I post this comparision (as reported by Bitminter):  http://postimg.org/image/82x69elyj/bad! If I were in your shoes I would try bertmod. it' not a real fw upgrade, it doesn't require a reboot, it just replace the status web page with a new one with a lot of more info. (see: http://forum.kncminer.com/forum/main-category/main-forum/6183-bertmod-0-2-unofficial-firmware-mod-feedback-thread) if you think it's too risky... the .bin file is just a tar.gz, extract it, copy asic_status.pl on your miner and then run: perl ./asic_status.pl > status.html
My Saturn unit at home runs 0.93, case closed (but optimized the flaps/wings inside the case = bent them to not disturb the airflow)
and uses 270W (at 230V).
do you mind to up a pic of your internal airflow optimization? |
|
|
|
I have extracted from bertmod (thanks for your work dude very well done) the perl script that test for ASIC cores/consumption. And I've discovered that each jups of mine has an ASIC chip with a die completely disabled: Die ID Cores ON Cores OFF %
0 48 0 100
1 0 48 0
2 47 1 97.9
3 48 0 100
Temperature sensor: 36.0 C
Die ID Cores ON Cores OFF %
0 48 0 100
1 0 48 0
2 48 0 100
3 48 0 100
both are marked as ASIC board 4. I'm running with stock configuration (no extra fan, no lid removed etc) with fw 0.94. tomorrow I will be at the colo and I'll do a few experiments. firstly I just want to remove the lid and try to find a fun to punt on top. something like this:  i'll report back if the better airflow will resurrect the dead die  |
|
|
|
First pic shows a simpler airflow mod on the second miner by putting the fan down a little in the front at an angle blowing towards the back (but not resting on all heatsinks) Also, added a small USB fan you cant see that is opposite the box shroud. It helps push air that can get caught up front Eagle eyes can see the back right board is the odd 8 VRM one I got, and since that board runs 10c cooler than others, it is probably why I can do less modding for good tempshttps://i.imgur.com/zSIkrAf.jpgSecond pic shows the other miner and was my first design. This one was hashing terribly from the start and ran a bit hotter than the other one so I used a small window fan on the far side to blow crosswind through. Also rested the big fan on top of all 4 heatsinks. Here you can see the small USB fan that I also have in the other miner do the same duty. The cardboard here helped keep the cool air towards the heat. You do not want to cover any heat. https://i.imgur.com/qTB2Pyy.jpgoh, about those style points... here's that Hale 850W PSU by NZXT powering the second miner. (first has a EVGA 1000W in a PC) https://i.imgur.com/cJ0QvHP.jpgmod at your own pace and risk  thanks for the pics bro ! |
|
|
|
OK just popped out and grabbed some 20cm fans to sit on top, i'll just let the results speak for themselves...for $20 fan!
Before - 528.4 Average/ 6% HW/ 1% Rejects
After - 545 Average /4% HW / 0.2% Rejects
Temps
No fan 55 1 min 56 3 mins 53 10 mins 51.5 (7% drop)
No fan 59 1 min 51 3 mins 47 10 mins 46 (22% drop)
No fan 57 1 min 48.5 3 mins 44 10 mins 43 (24.5% drop)
No fan 50 1 min 44 3 mins 41 10 mins 40 (20% drop)
Temps stabalised after the 10 min mark as I assume the max heat load had been reached
Note: I have only seen 1 core disable note the entire hour i've been watching! This is also a huge improvement.
On my second Jupiter the average hash also increase about 20Gh/s (540->560) and similar temp drops of 10-20% across all ASICs.
Could you up a pics of the miner in such conf? That way i'll be sure to understand correctly |
|
|
|
Looks like next difficulty will be 257mill = 0.2 btc per 100 gh. Missed the boat by a few weeks to get our money back looks like
I know that it's early and the estimate become better the more we move towards the next jump. but bitcoincharts is telling me next diff willbe 208mil while blockchained gives me 228. where did you find 257 mil? serious question. Difficulty 189,281,249.28
Hash Rate 1,872,435.17 GH/s
Electricity Consumption * 29,209.99 megawatt hours
Electricity Cost $4,381,498.29
Mining Profits
Operating Profit $-3,679,339.93
Operating Margin -524.00%
Profit Margin ** -890.03%
All statistics are for the previous 24 hour period unless otherwise stated thanks for the link, I know current diff is 189 mil, we were talking about estimate for the next jump. sorry misleading you but my english is a little bit rusty. |
|
|
|
Looks like next difficulty will be 257mill = 0.2 btc per 100 gh. Missed the boat by a few weeks to get our money back looks like
I know that it's early and the estimate become better the more we move towards the next jump. but bitcoincharts is telling me next diff willbe 208mil while blockchained gives me 228. where did you find 257 mil? serious question. |
|
|
|
I'm still stable between 510-520 Gh for both miners which is a joy to see
this seemed like a wishful dream yesterday
DPoS I'm really glad for you. Did you modify the airflow the same way Sitarow did? (remove the lid, add a fun over the box that push down air). One last question  Did you checked your ASICs slot status using this: http://forum.kncminer.com/forum/main-category/main-forum/6183-bertmod-0-2-unofficial-firmware-mod-feedback-thread? it's not a real firmware update, infact you do not have to reboot your miner after applying those update. it simply uses the firmware upload interface to modify the cgi script that generate interface web pages. if you're curious you can inspect the file that actually is a tar.gz despite the fact its extension is .bin to make a long story short it use cgminer remote api, i2c-get command, a little bit of perl and a little of reverse engineering to get a more datailed information about your miner. using this thing I've discovered that every single KnC ASIC chip is compsed by four die and each die has 48 cores. another thing I've discoverd it that one of my jup has a die with all 48 cores disabled and infact it's the one with the lower temp. |
|
|
|
|
ps | grep cgminer
Ps ax doesn't work. It's nit the usual ps. It is the one that come with busybox
|
|
|
|
I'm mining @ slush... and this is what I get for a block that last for only 7 minutes: 0.08573308 btc with 2 jups.
usually I got something like 0.19/0.24.
most probably that is because of PPLNS reward system. Using this system you must know that max payouts will be reached after 24 hours. thats resist of pool hoping Also PPLNS means that sometimes it can find a few blocks a day, other time no for a day. Yes, that is more variance accordingly to other reward systems, but in more long period PPLNS miners has higher payouts And of course it is better to use p2pool to avoid centralized pools fee that is usually 3-7% I agree an all points. What I'm saying is unrelated, thou. Every time your pool stratum request to do the "flushwork" KnC cgminer driver instead of flushing it finish old work and submitting it, this lead to a prompt decrease of your hash rate. And it takes 10 secs at min to climb up to normal level. This happens every time a new block is found (not only blocks found by your pool). The damage get worse when your your pool find a block within a few minutes/seconds from the last "flushwork" request. Since every reward system is based on the number of shares you submit, independently from your particular reward sys you'll get less btc in the case described above think it must be reported to KnC engineers while they fix it reported already, this is the reply I get Dear xxxxxx, We aware about this issue. Please be informed, there should be new modified firmware released later on today. It should help you to make it more stable. Med vänlig hälsning | Best regards Anna Jagdhar Kncminer www.kncminer.comOffice: +46 8559 253 20 |
|
|
|
I'm mining @ slush... and this is what I get for a block that last for only 7 minutes: 0.08573308 btc with 2 jups.
usually I got something like 0.19/0.24.
most probably that is because of PPLNS reward system. Using this system you must know that max payouts will be reached after 24 hours. thats resist of pool hoping Also PPLNS means that sometimes it can find a few blocks a day, other time no for a day. Yes, that is more variance accordingly to other reward systems, but in more long period PPLNS miners has higher payouts And of course it is better to use p2pool to avoid centralized pools fee that is usually 3-7% I agree an all points. What I'm saying is unrelated, thou. Every time your pool stratum request to do the "flushwork" KnC cgminer driver instead of flushing it finish old work and submitting it, this lead to a prompt decrease of your hash rate. And it takes 10 secs at min to climb up to normal level. This happens every time a new block is found (not only blocks found by your pool). The damage get worse when your your pool find a block within a few minutes/seconds from the last "flushwork" request. Since every reward system is based on the number of shares you submit, independently from your particular reward sys you'll get less btc in the case described above |
|
|
|
How many btc per day per Jupiter?
mine is mining @490 GH/s and I got about 1.3 a day (it depends on pool's luck) |
|
|
|
Do not use Eligius, I had the same problems. The miner doesn't flush the old work when asked and continues to submit them to the pool.
It seems P2Pool is also impacted.
If MINER "doesn't flush the old work when asked and continues to submit them to the pool" than it doesn't matter what pool to use because that's miner problem I'm now using another pool with Stratum and it hashes nicely. I just changed pools, the firmware is the same. which pool are you using now? I'm mining @ slush... and this is what I get for a block that last for only 7 minutes: 0.08573308 btc with 2 jups. usually I got something like 0.19/0.24. every time we found a block very early I got less than I use to have with longer block because "The miner doesn't flush the old work when asked and continues to submit them to the pool." every time stratum notify a new block this is what I get: [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)
after those log my hasrate takes a while 10-20sec to climb up to usual level. quoted the post where gigavps (admin of giga's semiprivate poll) confirm this behaviuor Well Jupiters don't play well with p2pool. They remind me of the early BFL FPGAs, they are extremely slow to recover when they get new work. Anyone have any settings to to try out?
What's exact stats you're getting? How many DOA? I am seeing higher stale rates from KNC equipment so it looks like they are not flushing work when the stratum server requests but are instead finishing old work and submitting it. |
|
|
|
Hi all, my Jupiter was nasty last night: Today i woke up and he wasnt hashing anymore and i cant access the miner per web/ssh anymore either. I didnt want to switch off the PSU cause there was a rumor that switching off and on again could possibly hurt those caps that burn from time to time. So i just pulled the network plug and put it back on. And now thats STRANGE: he immediatelly started to hash again at full speed BUT the case-front fans stopped working at the same time. When i pull the network plug again they start running again. I plug them in they stop. And so on..... Whats wrong here?  ? it's getting stranger and stranger.... there's some electrical problem somewhere. try to call/email KnC about this issue |
|
|
|
Do not use Eligius, I had the same problems. The miner doesn't flush the old work when asked and continues to submit them to the pool. It seems P2Pool is also impacted. how about SLUSH'S POOL anyone know or is this just across the board? Slush works for my jups. |
|
|
|
root@Jupiter-5A6:~# uptime
08:49:44 up 21:08, load average: 1.94, 1.91, 1.90
root@Jupiter-5A6:~# ps | grep spi
58 root 0 DW [spi1]
61 root 0 SW [spi2]
thanks! |
|
|
|
uptime ?
ps | grep spi ?
Saturn @ 0.93 root@Saturn-C78:~# uptime 08:47:04 up 2 days, 20:58, load average: 1.87, 1.89, 1.92 root@Saturn-C78:~# ps | grep spi | grep -v grep 58 root 0 DW [spi1] 61 root 0 SW [spi2] (removed top output) so it seems it is a common scenario, and maybe it's normal and nothing is wrong. but I can't be helped cause every time I see high load my gut feeling is that thre's something wrong going on. it's a real pity there's no source code somewhere, just for audit purpose. anyhow my theory (pure speculation) based on the high IO time (spi procces state = uninterruptible sleep) is that communication with the ASIC core is not optimal. time will tell. |
|
|
|
|
Show Posts
