No. Heat travels best thru metal. Abutting perfectly flat metal surfaces should conduct heat best but the surfaces are never perfect. Heatsink compound or tape of a heatsink compound with high thermal conductivity is sometimes placed between the metal surfaces to fill in air gaps. No heatsink compound or tape conducts heat as well as the metal itself. If one were to put heatsink thermal tape on the outside of a heatsink the heatsink would become less effective at losing heat. |
|
|
|
just now...
Just as a little test... I gently just pressed on the vrm's on the slo sat, and rocked them side to side a tad with the tip of my finger. One of the vrm's gave a little "Click".
within 30 seconds, a couple cores were re-enabled in cgminer... and it has gained about 20 WU's in about 5 minutes, and 2-3 gh/s Will keep updated...
few mins later... couple more WU. 1 more gh/s
While my internet was down I shut down the miners and put a bit of cardboard between the VRMs and the ASIC cooler. I looked closely and the metal tops are epoxy'd in place with thin lines of epoxy. The snap could be one of those epoxy lines breaking. I'd like to take the tops off and see if an expensive thermal tape would help any, then re-epoxy. This seems to be very odd. I am guessing that pressing a VRM wouldnt fix an issue with 1 -4 cores being out. Has anyone else done this? I have 4 cores that seem to be consistently off. The theory is that the die is being heated closest to a VRM that is losing heat more than it should from the bottom rather than the top. Its clip-on metal heat sink is epoxied in place with thin dots and lines of epoxy, possibly since the whining noise complaint. If the warm VRM is losing heat primarily via the bottom the heat is moving thru the PCB then adding to the heat of the ASIC. If a technician were holding the PCB by the VRM while carefully placing the epoxy, he could be lifting the heatsink away from the underlying components it's suppose to draw heat from. Then you have a little gap between the heatsink and the underlying components. Some take the board out, and, after placing it on a flat surface so the PCB doesn't flex and break BGA solder points under the ASIC, apply pressure to the top of the VRM but not too much. They try and make better contact of the heatsink plate with the underlying components and in the process sometimes break the epoxy whence they hear a snap. |
|
|
|
soy, .90 crashed....and everything below .94 didn't work or help me...back to .95 square 1 again see what happens....
.90, knc if you are listening had great numbers for me, but not sure what why it crashed....
If they were to answer I'd guess they guess it's your power supply can't handle it. |
|
|
|
just now...
Just as a little test... I gently just pressed on the vrm's on the slo sat, and rocked them side to side a tad with the tip of my finger. One of the vrm's gave a little "Click".
within 30 seconds, a couple cores were re-enabled in cgminer... and it has gained about 20 WU's in about 5 minutes, and 2-3 gh/s Will keep updated...
few mins later... couple more WU. 1 more gh/s
While my internet was down I shut down the miners and put a bit of cardboard between the VRMs and the ASIC cooler. I looked closely and the metal tops are epoxy'd in place with thin lines of epoxy. The snap could be one of those epoxy lines breaking. I'd like to take the tops off and see if an expensive thermal tape would help any, then re-epoxy. |
|
|
|
But I don't understand why if the warm BBB backs up Merc's why it wouldn't back up a Jupiter 4x as much.
I agree... It just doesn't make any sense... I think it's the VRM's getting cooled by playing with the cardboard, etc... as mentioned earlier.. No, in fact my arrangement probably warms the VRMs a little as I've now got a kind of wind tunnel to the ASIC module and that first passes over the BBB - note the small 120vac 3 watt at the wall fan pushing in from the far left and the two front fans. So, the ½ fan width cardboard down over the BBB might be better buy I ain't fooling with mine. ...trying to get on the dreadmill.. KnC 0: | 130.2G/135.7Gh/s | A:7589658 R:346355 HW:441631 WU:2091.4/m not sure but I may have seen a 136GH/s avg earlier. That first figure cycles up and down. about 4 mph and watching bering sea gold - gonna cash in my BTC and head up to them there hills. Stepped off the dreadmill and the internet goes down. Happened yesterday just as I got back from a jog. The local highway is being widened from 2 lane to divided highway. Fiber is run along the road. Cable was down 2 hours at least. Bummer. |
|
|
|
But I don't understand why if the warm BBB backs up Merc's why it wouldn't back up a Jupiter 4x as much.
I agree... It just doesn't make any sense... I think it's the VRM's getting cooled by playing with the cardboard, etc... as mentioned earlier.. No, in fact my arrangement probably warms the VRMs a little as I've now got a kind of wind tunnel to the ASIC module and that first passes over the BBB - note the small 120vac 3 watt at the wall fan pushing in from the far left and the two front fans. So, the ½ fan width cardboard down over the BBB might be better buy I ain't fooling with mine. ...trying to get on the dreadmill.. KnC 0: | 130.2G/135.7Gh/s | A:7589658 R:346355 HW:441631 WU:2091.4/m not sure but I may have seen a 136GH/s avg earlier. That first figure cycles up and down. about 4 mph and watching bering sea gold - gonna cash in my BTC and head up to them there hills. warming up in here and need air movement while running so on comes a fan. won't be after bering sea gold as I swim like a rock. and the bitcoin may buy me a new car one day |
|
|
|
But I don't understand why if the warm BBB backs up Merc's why it wouldn't back up a Jupiter 4x as much.
I agree... It just doesn't make any sense... I think it's the VRM's getting cooled by playing with the cardboard, etc... as mentioned earlier.. No, in fact my arrangement probably warms the VRMs a little as I've now got a kind of wind tunnel to the ASIC module and that first passes over the BBB - note the small 120vac 3 watt at the wall fan pushing in from the far left and the two front fans. So, the ½ fan width cardboard down over the BBB might be better buy I ain't fooling with mine. ...trying to get on the dreadmill.. KnC 0: | 130.2G/135.7Gh/s | A:7589658 R:346355 HW:441631 WU:2091.4/m not sure but I may have seen a 136GH/s avg earlier. That first figure cycles up and down. about 4 mph and watching bering sea gold - gonna cash in my BTC and head up to them there hills. |
|
|
|
But I don't understand why if the warm BBB backs up Merc's why it wouldn't back up a Jupiter 4x as much.
I agree... It just doesn't make any sense... I think it's the VRM's getting cooled by playing with the cardboard, etc... as mentioned earlier.. No, in fact my arrangement probably warms the VRMs a little as I've now got a kind of wind tunnel to the ASIC module and that first passes over the BBB - note the small 120vac 3 watt at the wall fan pushing in from the far left and the two front fans. So, the ½ fan width cardboard down over the BBB might be better buy I ain't fooling with mine. ...trying to get on the dreadmill.. KnC 0: | 130.2G/135.7Gh/s | A:7589658 R:346355 HW:441631 WU:2091.4/m not sure but I may have seen a 136GH/s avg earlier. That first figure cycles up and down. |
|
|
|
soy are these temps and current outputs ok?
are they similar to your stats?
how long have you been on .90?
I don't have an answer for your first question, as for the rest it's posted a few pages ago. |
|
|
|
|
Perhaps the warm BBB is changing data and the pool is communicating back the work is wrong.
(...trying to get on my dreadmill.)
|
|
|
|
|
But I don't understand why if the warm BBB backs up Merc's why it wouldn't back up a Jupiter 4x as much.
|
|
|
|
|
The increased temps is increased hashing. The warm BBB is overloaded and backing up I suppose which makes work just sit blocking new work from getting done is a possibility.
|
|
|
|
|
I'm happy with mine. Almost like it's time to get my life back. Odd things to do like run cat5 to a back room I don't plan to heat.
|
|
|
|
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? I don't know why only that it does. Perhaps overworked. Found it thru experimentation. In fact I'm thinking of replacing the cardboard I have forcing the intake air down onto the BBB with a small standoff-mounted fan. |
|
|
|
I go with (HW*100)/A
HW error % = HW/A+R+HW where HW = number of hw errors A = number of accepted R = number of rejected with 0.97 I got something like 10-11% after almost 20 hours, whereas before the same miner running with 0.95 I used to have 5-7% Thanks. That changes mine from ~4.4% down to ~4.1%. Although it doesn't agree with BertMod: Device Hardware%=4.9875 Device Rejected%=4.1048 Pool Rejected%=4.3372 Pool Stale%=0.0000 thanks, that means I am still at 21%, spinning my wheels it feels Did you try firmware 0.90 then enablecores.bin? Are you forcing air onto the BBB? A warmish BBB will drop your hashrate. |
|
|
|
I go with (HW*100)/A
HW error % = HW/A+R+HW where HW = number of hw errors A = number of accepted R = number of rejected with 0.97 I got something like 10-11% after almost 20 hours, whereas before the same miner running with 0.95 I used to have 5-7% Thanks. That changes mine from ~4.4% down to ~4.1%. Although it doesn't agree with BertMod: Device Hardware%=4.9875 Device Rejected%=4.1048 Pool Rejected%=4.3372 Pool Stale%=0.0000 |
|
|
|
KNC GUI & puTTy both show me at 541 all day - BTCG shows 480-500 most of the day.
am i missing something?
Yes you are. Stop measuring speeds at cgminer or go through Kano's posts for how to get the hashrate numbers using the hardware error numbers and so on. It's really annoying all these people posting meaningless hashrates... i think it is even easier, look at cgminer output (GH/s), then go to your pool server stats and look at that hash rate and if they are the same, you are doing very well, if they are not even close then you have a problem. Except the pool number jumps around. I saw a difference of 20 within two minutes at the pool. Average hashrate at the status screen barely moved. I do have 19% HW errors on 9.7 though. Fiatkiller, when other KNC Saturn owners are reporting 260GH/s-275GH/s at the server(and on CGminer), while my Saturn reports 215-235GH/s max, I feel that it has something to do with that high error rate our Saturns suffer from. Yes! It's all about the hardware error rate. The values on KNC's cgminer do not seem to take that into account. I don't know if other versions do. The difference between machines seem to come mostly from the level of hardware errors so when someone says "my jupiter/saturn is doing X/Y in hashrate with this FW" you end up empty handed because you don't know if they are measuring that at cgminer or and actually getting much less at the pool (as you would measure from averages). In fact it misleads other people and possibly devs into thinking that they are progressing with the software. 0.97 for me and other people seems to ramp up the hardware rate and the reported hashrate at cgminer (depending how bad your machine actually is) but you see all these pointless reports of "yey +10 GH/s" without stating the source. edgar: cry me a river! i dont know who you are referring to with your vague waffle about meaningless hashrates & not knowing what information has been given but i personally gave all the info regarding cgminer, KNCs GUI and BTCGs pool rate. i also asked specifically where to find the HW% and you prefer to troll the tread rather than give a knowledgeable response. i'll cry you a river mate!! so long as u hop in a canoe & fuck off down stream in it I go with (HW*100)/A |
|
|
|
|
The early complaint of whining from the ASIC module, tho probably from one or more VRMs, were there many complaints proportionally? The firmware upgrade corrected that. My Merc arrived with 0.95, had input voltages of 11.8 on all VRMs and output voltages ranging from 0.738 to 0.748. It couldn't get out of its own way, never reaching 100GH/s average.
To correct this I first went to 0.90 initial firmware. I had already read the high praise the initial firmware had gotten over firmware upgrades by users who remained quite disappointed until finally the enablecores.bin became available. I ran enablecores.bin with 0.90 firmware and was finally pleased with >100GH/s hashing, and pretty quickly I might add.
I went thru the upgrades one at a time looking for the 0.740 voltage change and found it in 0.95 but my hashrate again returned to sub-100GH/s. So, back to 0.94 and I'm happy with it relatively speaking. The extra >100watts at the wall will mean something more than $5.50/month in electric but a cold front has reached this area and it's a tradeoff instead of the propane heat - besides, that extra
KnC 0: | 149.7G/135.5Gh/s | A:7273677 R:328049 HW:420447 WU:2088.1/m
35.5GH/s will earn quite a bit more than that in BTC.
So, I'm not going to be getting any higher hashing from my Merc unless I buy an ASIC module and transform it into a Saturn.
But, now I wonder. The initial firmware was likely treating the VRMs with an optimal frequency for their design. As I never heard that whine voiced by some that prompted the first firmware upgrade 0.91, and not knowing what advantages I'm seeing in 0.92 or 0.93 or what I'm presently using 0.94, maybe 0.90 is the best? ...at least until warm weather returns.
And who knows, maybe the VRM whine had been slightly displaced VRM heatsink tops that resonated but stopped resonating with the frequency change.
|
|
|
|
concerning the changelogs, you could compare code on https://github.com/KnCMiner to get a clue what has been changed - but for sure it's not the same like a simple changelog you read in short time. ---------- Any tips how solve the random miner stoping / freezing after 30-60min ? Pleseeee? It doesn't manke sense waisting more electricity then you mine back  + a fact .97 decrease the speed from 100 to a 1.7Ghas After reading yesterday's reports about 0.97 I was really close to upgrade - was just too tired in the evening and not in the mood to deal with possible issues. Meanwhile I'm quite happy I'm still on 0.95. UPDATE YOUR MINER TO THE LATEST FIRMWARE
Somehow I'm not sure how to rate KnCMiner's software development and quality assurance in general, as it seems they do neither proper testing, nor understand the root causes of issues since each time there's one solved, but another appears.. I'm happy they're better in hw development, otherwise Jupiter would hash with 290GH/s only while consuming 1kW, I guess Honestly I'm getting more and more disappointed about this. Especially when considering that cgminer's devs could have prevented it very very likely, but KnCMiner was so self confident they will do it better, cheaper, faster (?!). I do not like to think about the difference in mined coins until now.  i think this( cheaper) was their only concern. faster & better are non-existent terms with these guys - confidence - bucketsfull I can't agree with your assessment. I just upgraded a Jalapeno fan. That company was the first Bitcoin ASIC manufacturer in production and a KnC designer may have tried taking a Jalapeno apart and putting it back together. Probably the reason so many Jalapeno users opt not to put it back in the case. All the room in a KnC product almost shouts in comparison that Jalapeno case designer was a sadist. |
|
|
|
|
Alongside the list of firmwares available for download and installation, I'd like to see a list of changes each firmware has compared to the previous. I could then decide if what the upgrade offers is in my interest to apply or skip if it addresses a problem I'm not experiencing.
|
|
|
|
|
Show Posts
