0.97 seems to hate p2pool less than earlier versions did, but still there is too much hate, cannot reasonably use p2pool still.
Although not improved enough to work right with p2pool yet, 0.97 has overall been an improvement for me.
-MarkM-
I am mining on P2Pool right now with a Saturn, getting 275 GH/s with WU of 4152 right this sec. Using the web interface? Or did you go in with ssh and fiddle with the cgminer timeouts and such? (I have only been using the web interface as the ssh does not seem to like the username/password the web interface shipped with.) -MarkM- Did you try admin/admin or root/admin or both? |
|
|
|
Hello,
I received a Saturn today.
It comes with FW 0.95.
I update to 0.97 and show 1GH/s hashing.
I try hard reset (according to manual), enable cores, but nothing happens. When I trying 0.96 a red light appears on the controller board. When I do enable cores again the red light disappears.
So, 0.96, 0.96.1, 0.97 does not work.
Right now only 0.95 works. But with many HW (about 30%). My hashing is about 195 GH/s. Also the cgminer restart often.
I have another Saturn that works just fine. 0.97 282 GH/s 3% HW.
Any suggestions?
Thank you very much.
Go back to 0.90 and run enablecores. |
|
|
|
after less than 3 hrs on 0.97 my fuse at the junction box blew, shutting down everything while i was asleep.
woke up to dark silence - creepy.
switched the tripped fuse back onand we;re back up and hashing.... any reports of similar issues/raised W pulled at the wall?
other than that 540 is now 536 - and WU is now 8147 from 7877
anyone added enablecores to .97 yet?
New trend: KnC miner owners get raided as suspect indoor pot farms. |
|
|
|
Just back from 7 miles with my dog and found my miners down. Must have been cable work nearby.
So, here's what I think. If an ASIC module has one or more dies showing high cores being disabled, shut down the system, let sit a minute before unplugging cables from the module. Remove the module's heatsink, remove the board from the unit. Then with some gentle support under 1 VRM at a time, exert pressure down on the flat metal top. Continue with each VRM supporting under that module as you do so. Reassemble the unit. Run enablecores.bin and if you see improvement it's not that the VRMs are providing improved power but that the VRMs are losing more heat from their top rather than there bottom. When they lose heat from the bottom the heat travels by way of the PCB to the nearby ASIC module and the nearest die will come up with errors. That one reason the lower the fans to the deck method works so effectively - it passes air between the VRMs and ASIC module.
You all are welcome. I know this is helping my competition but then I've never been an overachiever.
And if it works, the tops of the VRMs may have been jogged away from the underlying components when the fans got knocked free in transit or struck by a bouncing fan in transit. If those tops do just snap on/off I wouldn't go just using any old heatsink compound. I had noticed earlier this year when I built a heatsink for a USB Block Erupter, the heatsink contacting both the CP2102 and the ASIC, if the compound came in contact with the ASIC pins the hashrate suffered. The stuff is suppose to be non-conductive but who knows. If you remember the mid-west miner company, they chose the wrong FETs, the problem then wasn't so much the FETs but that the buck-converter got hot and I bet it was the ASIC closest to the overheating buck converter that got most often populated. I can't understand when the buck converter datasheet clearly stated it will overheat if the wrong fets. Then that most often populated ASIC would have high errors and they perhaps wondered why. Nope, I am wrong. I've had an expensive replacement fan for the Jalapeno sitting here from well before the jalapeno arrived. I hadn't opened the Jalapeno until just now. And no, they aren't populating the ASIC space closest to the buck converter in the Jalapeno. I was wrong. Case design by a sadist. Looks like the buck converter is now manufactured by a no-name company as the chip designations were inscrutable and not having the time to research. I put an aluminum stick-on heatsink on the chip I recall as being pointed out in a photo and put it back together with the new fan. No improvement but my place is cool so it wouldn't see a great improvement from less heat. Haven't run their software to determine how many "engines" are functional as I'm using linux and they don't cotton to linux. I should tho so as to figure out if installing new firmware will be worthwhile. But this isnt the forum for that. |
|
|
|
Just back from 7 miles with my dog and found my miners down. Must have been cable work nearby.
So, here's what I think. If an ASIC module has one or more dies showing high cores being disabled, shut down the system, let sit a minute before unplugging cables from the module. Remove the module's heatsink, remove the board from the unit. Then with some gentle support under 1 VRM at a time, exert pressure down on the flat metal top. Continue with each VRM supporting under that module as you do so. Reassemble the unit. Run enablecores.bin and if you see improvement it's not that the VRMs are providing improved power but that the VRMs are losing more heat from their top rather than there bottom. When they lose heat from the bottom the heat travels by way of the PCB to the nearby ASIC module and the nearest die will come up with errors. That one reason the lower the fans to the deck method works so effectively - it passes air between the VRMs and ASIC module.
You all are welcome. I know this is helping my competition but then I've never been an overachiever.
And if it works, the tops of the VRMs may have been jogged away from the underlying components when the fans got knocked free in transit or struck by a bouncing fan in transit. If those tops do just snap on/off I wouldn't go just using any old heatsink compound. I had noticed earlier this year when I built a heatsink for a USB Block Erupter, the heatsink contacting both the CP2102 and the ASIC, if the compound came in contact with the ASIC pins the hashrate suffered. The stuff is suppose to be non-conductive but who knows. If you remember the mid-west miner company, they chose the wrong FETs, the problem then wasn't so much the FETs but that the buck-converter got hot and I bet it was the ASIC closest to the overheating buck converter that got most often populated. I can't understand when the buck converter datasheet clearly stated it will overheat if the wrong fets. Then that most often populated ASIC would have high errors and they perhaps wondered why. Nope, I am wrong. I've had an expensive replacement fan for the Jalapeno sitting here from well before the jalapeno arrived. I hadn't opened the Jalapeno until just now. And no, they aren't populating the ASIC space closest to the buck converter in the Jalapeno. I was wrong. |
|
|
|
update...
the slowest saturn, (255)normally, reported earlier as 260, is still inching upward, and now at 262.
The others, are 267 & 280 at present... Thumbs up
Who fucking cares! Are you trying to break a forum speed record for the most of inane/autistic posts per hour. Maybe everyone who has a Saturn and is debating whether to update or not? Stop being such an ass. Absolutely. Mashed the ignore. |
|
|
|
Just back from 7 miles with my dog and found my miners down. Must have been cable work nearby.
So, here's what I think. If an ASIC module has one or more dies showing high cores being disabled, shut down the system, let sit a minute before unplugging cables from the module. Remove the module's heatsink, remove the board from the unit. Then with some gentle support under 1 VRM at a time, exert pressure down on the flat metal top. Continue with each VRM supporting under that module as you do so. Reassemble the unit. Run enablecores.bin and if you see improvement it's not that the VRMs are providing improved power but that the VRMs are losing more heat from their top rather than there bottom. When they lose heat from the bottom the heat travels by way of the PCB to the nearby ASIC module and the nearest die will come up with errors. That one reason the lower the fans to the deck method works so effectively - it passes air between the VRMs and ASIC module.
You all are welcome. I know this is helping my competition but then I've never been an overachiever.
And if it works, the tops of the VRMs may have been jogged away from the underlying components when the fans got knocked free in transit or struck by a bouncing fan in transit. If those tops do just snap on/off I wouldn't go just using any old heatsink compound. I had noticed earlier this year when I built a heatsink for a USB Block Erupter, the heatsink contacting both the CP2102 and the ASIC, if the compound came in contact with the ASIC pins the hashrate suffered. The stuff is suppose to be non-conductive but who knows. If you remember the mid-west miner company, they chose the wrong FETs, the problem then wasn't so much the FETs but that the buck-converter got hot and I bet it was the ASIC closest to the overheating buck converter that got most often populated. I can't understand when the buck converter datasheet clearly stated it will overheat if the wrong fets. Then that most often populated ASIC would have high errors and they perhaps wondered why. |
|
|
|
Just back from 7 miles with my dog and found my miners down. Must have been cable work nearby.
So, here's what I think. If an ASIC module has one or more dies showing high cores being disabled, shut down the system, let sit a minute before unplugging cables from the module. Remove the module's heatsink, remove the board from the unit. Then with some gentle support under 1 VRM at a time, exert pressure down on the flat metal top. Continue with each VRM supporting under that module as you do so. Reassemble the unit. Run enablecores.bin and if you see improvement it's not that the VRMs are providing improved power but that the VRMs are losing more heat from their top rather than there bottom. When they lose heat from the bottom the heat travels by way of the PCB to the nearby ASIC module and the nearest die will come up with errors. That one reason the lower the fans to the deck method works so effectively - it passes air between the VRMs and ASIC module.
You all are welcome. I know this is helping my competition but then I've never been an overachiever.
And if it works, the tops of the VRMs may have been jogged away from the underlying components when the fans got knocked free in transit or struck by a bouncing fan in transit. If those tops do just snap on/off I wouldn't go just using any old heatsink compound. I had noticed earlier this year when I built a heatsink for a USB Block Erupter, the heatsink contacting both the CP2102 and the ASIC, if the compound came in contact with the ASIC pins the hashrate suffered. The stuff is suppose to be non-conductive but who knows. |
|
|
|
Roughly one second.
I'm talking 1-3 revolutions of the fan.
It's on, then it's instantly off.
It's not even getting to boot, so can't see it being firmware.
This seems squarely a hardware / me screwing it up somehow-ware issue.
Run one module at a time. |
|
|
|
|
Just back from 7 miles with my dog and found my miners down. Must have been cable work nearby.
So, here's what I think. If an ASIC module has one or more dies showing high cores being disabled, shut down the system, let sit a minute before unplugging cables from the module. Remove the module's heatsink, remove the board from the unit. Then with some gentle support under 1 VRM at a time, exert pressure down on the flat metal top. Continue with each VRM supporting under that module as you do so. Reassemble the unit. Run enablecores.bin and if you see improvement it's not that the VRMs are providing improved power but that the VRMs are losing more heat from their top rather than there bottom. When they lose heat from the bottom the heat travels by way of the PCB to the nearby ASIC module and the nearest die will come up with errors. That one reason the lower the fans to the deck method works so effectively - it passes air between the VRMs and ASIC module.
You all are welcome. I know this is helping my competition but then I've never been an overachiever.
|
|
|
|
|
Wow, my first found block. On Slush. A few days ago, I just noticed. Can't think of any other reason this one Found Block is listed on my profile page. The block number 265105.
|
|
|
|
|
I see network hashrate that was 3.25PH/s when I looked late yesterday was a moment ago only 2.72 and now is 2.9. I wonder if it's KnC miner users shutting down and restarting with the new firmware.
|
|
|
|
If you got hired for a job that advertised 550 a week, and they gave you 510 instead, you'd be ok with that?
or better yet, you simply got a cut in pay, and they call it an upgrade
we have a name for your type around here...sheeple
wow. up til now I thought you were just too emotional. Now I know you are an idiot. Well, if you were hired at 400 and expecting to make 550 after tips .... |
|
|
|
recommended. not required.
Your miners were working very well before yet you still decided to tinker with it anyway by updating the firmware.
The main rule of thumb when updating any drivers/firmware for anything is that things can break or go wrong.
recommended. not required.
Your miners were working very well before yet you still decided to tinker with it anyway by updating the firmware.
The main rule of thumb when updating any drivers/firmware for anything is that things can break or go wrong.
I don't really appreciate the satire, especially since the two were underperforming to begin with... so everyone should just not update anything cause you said so, eh? Even when KNC recommends it.. . I hope it happens to you as well. Did you try light pressure on the VRM tops of the ASIC performing poorly, but not enough pressure to flex the board threatening to break ball grid array points under the ASIC? Better to take the board out and place on something flat to prevent flex then press on the VRM tops. If those tops are heatsinks then better contact improves operation. Didn't make sense removing the fans on the side of my module improved cores 'till I remembered I did press on the VRM tops. |
|
|
|
I'm pissed off now for sure.
.97 SLOWED 2 of 3 SATURNs
wtfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
enjoy?... yeah, right.
You knew the risks when you chose to update it  If you're not prepared for doom, just leave it the way it is.  The author making the upgrade suggestion is probably running 10 jupiters with the 0.94 firmware in the hosting area getting free power as an employee. |
|
|
|
 This seems to be what I'm pulling on stock Hash Rate on Mercury does this look good for WU?...right now it's 139GH 2020 WU Also, I'm curious to know if dropping the stock fan helped at all in terms of hashrate? Looks low but not as low as mine when running >0.94 firmware. Here's mine with 0.94. cgminer version 3.4.0 - Started: [2013-10-21 23:03:28] -------------------------------------------------------------------------------- (5s):148.8G (avg):138.0Gh/s | A:4523872 R:190782 HW:246840 WU:2115.7/m ST: 2 SS: 0 NB: 375 LW: 4840834 GF: 1 RF: 0 Connected to stratum.bitcoin.cz diff 100 with stratum as user BillJ.worker1 Block: 000fd8e18b830ff2... Diff:268M Started: [14:07:48] Best share: 3.55M -------------------------------------------------------------------------------- [P]ool management ettings [D]isplay options [Q]uit
KnC 0: | 146.0G/138.0Gh/s | A:4523872 R:190782 HW:246843 WU:2115.7/m
--------------------------------------------------------------------------------
[2013-10-23 14:10:44] Accepted 02816c21 Diff 102/100 KnC 0 pool 1
[2013-10-23 14:10:51] Accepted 022bdffe Diff 117/100 KnC 0 pool 1
[2013-10-23 14:10:51] Accepted 00b98834 Diff 353/100 KnC 0 pool 1
[2013-10-23 14:10:54] Accepted 01a02e61 Diff 157/100 KnC 0 pool 1
============================================================
My best was ssh into miner, shut down cgminer, run 0.94 upgrade, run enablecores.bin, halt, turn off power, maybe press a little on the tops of the vrms but not so hard as to flex the PCB, wait a minute, restart. Also I have a piece of cardboard in the center of the two front fans between above the fans and down to the base in front of the module(s) forcing air down on the center of the BBB. |
|
|
|
I see, you tried 0.96 and then 0.94 gave you the .7 volt VRM output voltage?
a hard reset and power cycle brought it back to high voltage again it is screaming now holding ~525 at BTCGuild (just think if I had the other 59 cores) 10 min mark: Block: ...fac0e16a #265429 Diff:268M ( 1.92Ph/s) Started: [01:10:24] ST:2 F:0 NB:3 AS:0 BW:[ 50/ 34 B/s] E:2764.94 I:38.45mBTC/hr BS:141k 4/709 50.0C | 571.0/504.2/506.6Gh/s | A:167 R:10+0(5.6%) HW:6766/6.8% -------------------------------------------------------------------------------- KNC 0: 46.0C | 142.5/136.8/133.8Gh/s | A: 45 R: 3+0(6.2%) HW:1140/4.4% KNC 1: 43.0C | 142.2/135.6/133.4Gh/s | A: 41 R: 6+0( 13%) HW:3804/ 12% KNC 2: 42.0C | 134.8/129.1/134.5Gh/s | A: 45 R: 0+0(none) HW:1112/4.5% KNC 3: 50.0C | 106.2/102.7/104.3Gh/s | A: 36 R: 1+0(2.7%) HW: 712/3.7% -------------------------------------------------------------------------------- 20 min mark: Block: ...fac0e16a #265429 Diff:268M ( 1.92Ph/s) Started: [01:10:24] ST:2 F:0 NB:3 AS:0 BW:[ 48/ 34 B/s] E:2903.21 I:39.55mBTC/hr BS:141k 4/709 50.0C | 549.3/511.4/511.0Gh/s | A:272 R:15+0(5.2%) HW:10175/6.4% -------------------------------------------------------------------------------- KNC 0: 47.0C | 144.0/138.7/136.6Gh/s | A: 75 R: 4+0(5.1%) HW: 1762/4.2% KNC 1: 43.0C | 143.8/137.9/137.8Gh/s | A: 67 R: 8+0( 11%) HW: 5858/ 12% KNC 2: 42.0C | 135.6/131.2/131.7Gh/s | A: 73 R: 2+0(2.7%) HW: 1557/4.0% KNC 3: 50.0C | 107.7/104.6/105.6Gh/s | A: 58 R: 1+0(1.7%) HW: 1025/3.3% -------------------------------------------------------------------------------- Observations: temps are up about 7-10C each board (to be expected) the one board (KNC 1) that was really low on HW errors when not overclocking, has the highest, while the others are all under 5%  similar amount of cores as last test (gained that one back to 709) we'll see how this goes after a few hours...since my temps are still lower than many people's non-overclocked jupiters it looks sustainable. (all 4 VRM boards) Dropping the fans to the crossbars does help in these situations I should change the PSU though, it is only an 850watter Update: close to an hour and running strong on BTCGuild - 533.87 GH/s 546304 (99.72%) 1536 / 23040 / 0 I'm not sure I'm running the same version of cgminer, 3.4.0 from the top line. My cgminer doesn't note the temp. Yes, running the earlier firmware now sure makes more sense than trying to avoid the 100 watt difference I saw on my Mercury. It costs me $5.50/month for the extra 100 or so watts while the extra 37.8GH/s is like 3½ Blades. So, do you measure your power at the wall? What do you get at .7v and at .9v? I don't understand what you mean by drop the fans to the crossbars - removing the front fans and grills completely? KnC 0: | 140.4G/137.8Gh/s | A:3295472 R:133982 HW:173578 WU:2108.2/m |
|
|
|
I hear the figure 30PH/s tossed around for this coming January. Then to stay current we need to buy 10x the hashing power we have now. Ouch.
to stay current, you need to double the amount of your miners with every difficulty rise  Double? Impossible of course. But looking at hashrate versus earnings, double the hashrate and halve your earnings for a given hashrate. So, if the network hashrate hits 30PH/s in January and it's well over 3PH/s right now, then just to stay even one would need at least 10x the hashrate just to earn the BTC one earned today. Get that? What's impossible even with the 10x scenario is that it will only earn the same BTC/day that one is earning now - and how much would it cost to increase one's hashrate ten times? And to get delivery in January, when would one need slap down the coin for the equipment purchase? |
|
|
|
I don't understand how you are getting .7 out of the VRMs on firmware 0.94. I'm running 0.94 and have .9+v and don't see .7 unless I run 0.95.
I believe you have to do the secret handshake to get it to switch back to high volts once you go to .95+  It might need a hard reset or perhaps going to an earlier firmware first.. i kinda forget myself the surefire way of switching them back MY 8 vrm Jupiter never has the output voltage above .7*v Is this the case with everyone else? I'm on .94 I've never taken a reading on .93 or .91 so I don't know if its better or worse. I don't want to play either as I'm getting 508gh/s showing on eligius 12hr! Now 24+hr with out reboot as well. Can't answer your question but I did test all 0.90-0.95 looking to see where the voltage dropped and saw the last .9v was .094. |
|
|
|
I don't understand how you are getting .7 out of the VRMs on firmware 0.94. I'm running 0.94 and have .9+v and don't see .7 unless I run 0.95.
I believe you have to do the secret handshake to get it to switch back to high volts once you go to .95+ It might need a hard reset or perhaps going to an earlier firmware first.. i kinda forget myself the surefire way of switching them back I see, you tried 0.96 and then 0.94 gave you the .7 volt VRM output voltage? Then I'll stick where I am until after the next diff increase and likely beyond that. KnC 0: | 151.5G/137.8Gh/s | A:2934673 R:118225 HW:153613 WU:2107.5/m |
|
|
|
|
Show Posts
