|
The long term slow drop in Bitcoin value, is it the result of bad press foist by banks or the dumping of mined Bitcoins by large farms like those associated with KnC?
A long slow decline is bad for miner/investors like myself who don't dump the mined Bitcoins. But, it would seem ideal for owners of large farms who see the decline as reducing the number of users getting into mining and therefore the reduction in private purchase of mining gear and less competition.
Historically, since KnC's gear came on the market, the best thing to have done with the mined Bitcoins is to have dumped the Bitcoins for cash. Did they foresee the result of constantly dumping the Bitcoins? Would the slow decline in value have happened anyway? We know the banks don't object to Bitcoin becoming useless as an investment.
|
|
|
|
|
I think the birds-of-a-feather unethical mob that did frequent the buttyfly labs forums with their reverse pump and dump April of last year verged on criminal.
|
|
|
|
|
Any opinions as to the safest way to apply the MtGox loss to this year's income tax? Perhaps a wash sale/repurchase of all BTC and apply the loss?
|
|
|
|
|
I imagine there are fewer and fewer blockchains at home all the time given its size.
I maintain two blockchains having Bitcoin-QT on two machines. This morning I got a payout and soon after that blockchain came up corrupted. So, I know the corruption is in the last block.
Can I go into the database and remove the last block, then remove the lock on the directory, delete the wallet, and have the blockchain start building from just before the deleted block?
I realize that all the other times this has happened I have had to wipe the whole thing then after copying the blockchain from the other machine, rebuilt from that but it takes weeks even when building from a current blockchain.
soy
Okay, this is odd. I had deleted the wallet and removed the lock then tried but got a corrupt database message again. Then I put the machine on another sub-net here, removed the lock and the wallet and tried again. This time the Bitcoin-QT opened just fine and caught up the blockchain! Putting the wallet having the new payout on the other machine with a blockchain, it opened perfectly with the correct balance and is up to date. So, all fixed and I don't know why.
|
|
|
|
Trying to think  when I first set this one up , it didn't seem right ! in the process of debugging n chking cables one of the new cables smoked ! But then I changed hash brds , controller brd , power brd . basically everything Physical chking of the unit shows the new cable to xd out brd getting quit warm !??? I'd unplug the boards and measure the resistance between the +12v and GND, comparing the two hashing board results. Then I'd look for a reason the one board had a lower figure. Each board has two +12v test point pads so you'll take 4 measurements. |
|
|
|
perfect thank you.
try using freq 212.5 see if you get the hw to drop. you are correct those numbers suck. I have had my hand s on 20 s-3's I have had 3 dog's so to speak nothing made them better above 212.5, but all 3 of them ran decently with freq 212.50 or freq 206.25
Seems like the HW errors are directly related to the 'x' on one of the chips in Miner Status. Once the chip gets X-ed the HW errors stop increasing. This is at 212. I will also try a bit lower and a bit higher and wait for that chip to be thrown out of the pool. x chip is dead and can be for different reasons. clock too high psu too weak if results improve with 212 clock run the 212 clock. i forgot the exact name of the psu that you use. it was a gold 1000 watter but they differ in rail structure. if you have multi rails it can be a problem. I am still testing it as the chip sometimes takes too much time to die. Is there a way to disable it completely? It dies after some time at any clock so it's definitely not a good chip. I was using a PC Power & Cooling Silencer Mk III 1200W and just changed it with Corsair RM850. No difference at all. Both are single rail PSUs. Anyways.. Seems like I got one of the not so good units. I have a similar bad chip tho it doesn't fail as often. It's number 8 on the dragon chain of the board on the left looking at the RJ45 connector end putting it top left of center. I've tried new thermal compound but it didn't help. I suspect the underside heat conducting plate on the ASIC isn't well soldered to the copper allowing it to run hotter than the others because when the room is colder it's better. Still I'm not at all tempted to take out the board, put some drops of flux, and heat the ASIC with a hot air desoldering device. I had used the desoldering device to remove and replace ASICs from USB BEs with only about a 60% success rate. To me it's not worth the time and effort - tho it being from an opened box from a reseller in Florida sure makes me feel burned. |
|
|
|
Hello, good day. I bought 17 S3 miners some months ago. I'm a happy customer so far. One of my miners suddenly stopped working. I pressed the reset button, but nothing happened. Both red and green LEDs are blinking; I can access the miner's web interface and this is what it shows on the "Miner Status" page:  I flashed all my miners with the latest firmware months ago, and all of them were working well so far until now. Can anyone give me some directions on how to fix this miner? Cheers, Try a hard reboot Try ribbons on controller Faulty controller? Shut it down and unplug supply and ethernet, let sit a few minutes, replace cables and fire up. If still doing this then try running nmap <ip-address> from a linux machine and see what ports are open on the device. |
|
|
|
|
I use non-standard power supplies but since I ran into a high voltage problem I won't recommend these. I use the same on a Mercury. When the cooler weather arrived and we started shutting down the air conditioning in the early evening the wall voltage went from 120-122VAC sometimes up to 126VAC. The cheap power supplies would see a rise on the 12vdc output. When it reached 13vdc the S3 shutdown hashing. The miner status page had blanks for all elements.
I run cgminer-avg-monitor on my S3's. When hashing stopped and later cgminer-avg-monitor would run, it would report "$avg" as a bad number and exit the script without running any corrective action. A quick search of linux scripts and bad number found a suggestion to change the "$avg" entry to "0$avg". The avg now reported shows up as for instance 0441. Hopefully if the problem happens again the hashrate will appear as 0 rather than a blank preventing the script from terminating.
Thanks for the new cgminer, am giving it a try.
|
|
|
|
Raspberry pi performance should not be the issue, since Bitfury made miners with hundreds of gigahashes using raspberry controller. Software can be causing low performance though.
Watch for the card to fill up. |
|
|
|
A customer sent me several S3s for hosting. Upon arrival all of them worked except one. Symptoms: - On boot, the fan starts, then immediately stops.
- After booting up, the indicator light on the back stays solid red.
- There is no status information in the antminer section of the status page
- Manually starting cgminer yields "No devices detected" error
I opened up the unit with the customers permission to see nothing out of the ordinary. I expected to see some kind of burn marks on the boards or something along those lines, maybe something completely out of place. What I've done rule out the basics: - Factory reset
- Updated to latest firmware
- Changed power supplies
- Turned it on with all 4 power connectors plugged in
- Turned it on with different combinations of 2 connectors
Any ideas? A normal start would see at least the larger red LED and the fan start; fan would run for a second then stop; the LEDs associated with the ethernet connection would light and change to green possibly turning off and on rapidly; the red LED would turn to green; the fan would start. If you've established an ethernet connection but hashing hasn't started, try ssh'ing in and give the command "ps | grep cgminer" which should get an output of two lines, one the cgminer and its running parameters, and the second line should reflect the grep cgminer command. If you only see the second, then you must start cgminer. Cgminer can be started with this command: /etc/init.d/cgminer start |
|
|
|
Following my training, I applied a thinner, evenly applied, layer of thermal paste to the entire heatsink and ground plane of the board and mated the surfaces. This worked so well that that board maintains the lowest registered temperature.
I think you are onto something here .... thanks for sharing! By applying a full even layer of heatsink compound then cleaning where the heatsink would make contact under the LM75A, the LM75A then is given to have a deceptively higher temperature than otherwise. Remember, the heatsink is cooler than the board. When that LM75A is allowed to read higher due to no heatsink compound in that spot, the higher registered temperature dictates a higher fan speed. The higher fan speed means less chance of lower hashrate.
You are definitely onto something! I had to upgrade a few of my S1's with the kit bitmain offered and rather than apply thermal paste to the chips before screwing on the front heatsink, I applied thermal pads instead. the unit is hashing away without issue, and the cost of the heat pads for each unit came to 1 GBP (negligible cost though a bit fiddly to cut to size thus takes a bit more time to apply than paste). My query is, do you think any heat pad would do for the board-heatsink contact in case I can get it in the 150mm x 250mm dimension(s)? It would then be a simple case of curving out the spot where the LM75A resides. Talking of which, how do I tell which is the LM75A? Is there only one on each board? I don't know. If you find what you need to test I'd like to see the results! Each board has an LM75A in its center. Between the two rows of ASICs. The IC has LM75A printed on its top. |
|
|
|
|
One can't flip the rear heatsink to change the curve relative to the fans as the top fin is above what would then be the bottom - prevents bottom of heatsink from reaching the floor.
|
|
|
|
|
My training in heatsink building back in the late 1970's informed me that there should be no voids between the device and the heatsink and that the purpose of heatsink compound was to fill any voids as the two surfaces aren't perfect but also that the compound moves heat less well than the metals of the devices.
When I repasted my first S3 hashingboard I found the factory installed heatsink thermal compound on the inner heatsink to be what looked like stripes of machine applied compound the length of the heatsink in two groups of stripes, targeting the upper and lower rows of ASICs. The individual stripes had air gaps between them and the two groups of strips had a larger stripe of air gap between them:
_________________________________
_________________________________
_________________________________
_________________________________
_________________________________
_________________________________
_________________________________
_________________________________
Following my training, I applied a thinner, evenly applied, layer of thermal paste to the entire heatsink and ground plane of the board and mated the surfaces. This worked so well that that board maintains the lowest registered temperature.
This would be ideal if there were no hashrate problems. Ideal because it keeps the fans running at a minimum speed so as to conserve energy. If there are hashrate problems one wants cooler ASICs. The fudge to get cooler ASICS is to get higher fan speeds. To get a higher fan speed to have cooler ASICs one might apply a thin even coating on the entire inner heatsink but then clean the area in the middle where the LM75A is situated. The LM75A is what measures the board's temperature. By applying a full even layer of heatsink compound then cleaning where the heatsink would make contact under the LM75A, the LM75A then is given to have a deceptively higher temperature than otherwise. Remember, the heatsink is cooler than the board. When that LM75A is allowed to read higher due to no heatsink compound in that spot, the higher registered temperature dictates a higher fan speed. The higher fan speed means less chance of lower hashrate.
|
|
|
|
Hi, I've always one "x", always at the same place, without overclock: oooooooo ooxooooo oooooooo oooooooo I've clean thermal paste twice, very carefully the second time. I've change PSU with another one. Both are Corsair 750W. Now I want to check the bad chip more carefully. Can someone confirm that the chain in WebUI are the same order as this picture:  I want to confirm that my bad chip is on physical chain #1 before unscrew and cleaning again. And where is the bad chip on this picture :  (sorry if bad english, I'm french) Yes, from the ethernet connection end chain 1 is on the right and generally runs hotter. The ASICs are numbered on the board as if a snake or dragon starting with the top ASIC beneath the fan connection. |
|
|
|
|
FYI after putting thermal compound on the inner heatsink, before mating it with the hashing board, if one takes a bit of solvent and cleans in the area of the LM75A such that there is no thermal compound there, the board will read a higher than expected temperature by about a degree and the fan will run faster.
|
|
|
|
|
I was just thinking, since the copper was exposed there and connection to one or the other of those 2 pins is iffy, any thru hole in that is likely questionable. Then the thought came to me that those 2 pins might be common to one or the other rails. There are 4 clear test points, two +12v and two ground. When it's open I'll check. If common to one or the other I might run a jumper to a TP from the two pins.
....
Those 2 pins, arrow and pin beneath, are common to the 12v rail. The next 2 pins to the left seem to be common to ground.
....
Restart is poor, slowly rising from 430. Right now I have no confidence in this fix and cannot recommend it. Sorry.
....
The board that has dropping hashrate, it had grossly overtightened screws to the inside heatsink and new, somewhat excessive, heatsink compound. The inside heatsink doesn't remove easily sometimes and the board can flex. I wonder if someone flexed it enough to split the underside soldering of an ASIC to the ground plane so it doesn't sink heat properly.
....
Got it done now all there's left to do is let them run. Fast running fan blade paired with the dropping hashrate blade. The fast running fan blade had an A and an A1 as did its partner on the cool side. The troublesome S3 had no A board that I could see and the troublesome dropping hashrate board had an S and an o. Rebooting the dropping hashrate board S3 today before the swap didn't result in an acceptable restart - taking too much time.
|
|
|
|
It was falling quickly. Shut it down, opened it up, made a change, do believe I fixed it. It's been up 1h39m now, will get back later with stats and the fix. Up 4 hours and looking good. If still good later tomorrow I'll post.
Okay, after 10h44m the hashrate is 440.08. That's fixed. When I inspected the questionable S3 hashing board that had cropped to well below 418 the day before, I found that board surface between the last two pins on the right of the ribbon connector rear had raised green material. That's pin 1 with the arrow and the pin immediately below it which I had called pin 20 but is possibly pin 2 being the adjacent conductor. Touching the green material it came away easily and flaked free showing oxidized copper beneath. Those two pins are common on the hashing board but the corresponding pins on the controller board are not. They tested common on the hashing board with the ribbon removed. Still, since it showed minor heat damage, the green material flaking off and the copper discoloration, I put a soldering iron on the pins then fired it up. It was not a fix and the hashrate dropped quicker than usual. Shutting it down and taking the top off, those pins were easily accessible so I soldered a quick jumper between the two pins with #28 wirewrap wire and closed. It's been running ever since. So, if you have an S3 that has a dropping hashrate, e.g. down to below 418GH/s in a few days, check the area of those two pins on the questionable board and if it shows indication of having heated from high current, try the jumper. I believe this is a good fix. soy could you post a picture of that area please, i do have the same problem with one of mine, and the problem S3 does have a higher temp diff between the 2 boards +1 please post a picture! I had been up early as I had to go out but posted first. The 10h44m 440.08GH/s is now a 16hr10m 437.19GH/s so it is still falling but two days ago it would be down to 437 in 3hours not 10 hours. So, clearly there's a big improvement but this isn't a comprehensive fix. To see the area I needed a loupe. The area in question is between the pin having the arrow on the 20 pin connector and the pin below it, this on the ASIC side of the board. Because the area is 1/10" between the pins I am not able to produce an an accurate photo. Take a magnifying glass and a tooth pick and try moving the green surface material. If it had been heated enough to separate it from the copper beneath it, it will flake. If not it will remain in place. But since this didn't last as a fix and is just a good improvement, I'll be opening it up again and will try to get a photo. I'll be opening it up to swap out the right board looking at the RJ45 end because it has a normal fan speed and I have another machine with a board that runs its fan normally above 3000 (3180 at the moment). When I was running the cgminer-avg-monitor app at the stock 439 and at the stock checking rate of every half hour, it was triggering a restart every half hour because it didn't reattain a good hashrate and because the hashrate decline was so steep. I'll run the program now and see how it responds post-jumper. |
|
|
|
The fans give a speed indication output. I don't know what kind, digital or analog. The fan speed is controlled by pulse width modulation. I don't see a corresponding hashing board temperature and fan speed though one goes up so does the other. If I saw three miners having a 40° board temperature and all three have the same speed, I'd say there was a digital feedback loop but this is not the case. So, one might assume that there is a ramp or curve that says when the temperature is A the fan speed supply voltage will be X, temp B gets voltage Y and temp C gets voltage Z. The speed indication just giving an indication of change versus temperature to the user.
The bad hashing board having a declining hashrate and a declining temperature might indicate the fault is elsewhere except that even after a cold start, after significant cooling time such that hashing starts over 442 and works its way down over hours, shows a lower temperature and fan speed early on. If that slower fan speed causes errors away from the temperature sensor, those ASICs may shut down engines and slow hashrate but not quickly effect temperature indication.
So the slow fan speed relative to temperature should be addressed. The problem may be in the pulsed width voltage supply line. A partial open, high resistance, in a plated thru hole, e.g. dull drill bit left fiber in the hole, the hole only partly plated. So, that's where I'll look first when I troubleshoot. I'll follow the pulsed with fan voltage first, then the ground and perhaps the speed indication pair, looking for something amiss. But not today.
Way overly optimistic without a schematic. I shut it down and inspected. Inspected and check grounds. I'd have liked to trace the fan lines but the multilayered board precluded that and without a schematic that's that. The only thing I found amiss is between pins 1 and 20 of the ribbon cable connection - the green covering had been lifted between the two pins as if those pins had carried quite a bit of current at one time and heated that area. So no joy. I would imagine that might happen if someone tried powering the S3 putting connectors to only the one side and the other side tried to hash with current across the controller board. Started falling along regular lines. My first S3, the good unit from the mid-west not Florida, has a hashing board that always runs at over 3k. No unusual noise. Wish I had a strobe tach. My next course of action is to put the fast fan board on the warmer side of the bad S3. So, although the bad board has a slow running fan there may be some compensation tho if it's not a cooling issue.... It was falling quickly. Shut it down, opened it up, made a change, do believe I fixed it. It's been up 1h39m now, will get back later with stats and the fix. Up 4 hours and looking good. If still good later tomorrow I'll post. |
|
|
|
The fans give a speed indication output. I don't know what kind, digital or analog. The fan speed is controlled by pulse width modulation. I don't see a corresponding hashing board temperature and fan speed though one goes up so does the other. If I saw three miners having a 40° board temperature and all three have the same speed, I'd say there was a digital feedback loop but this is not the case. So, one might assume that there is a ramp or curve that says when the temperature is A the fan speed supply voltage will be X, temp B gets voltage Y and temp C gets voltage Z. The speed indication just giving an indication of change versus temperature to the user.
The bad hashing board having a declining hashrate and a declining temperature might indicate the fault is elsewhere except that even after a cold start, after significant cooling time such that hashing starts over 442 and works its way down over hours, shows a lower temperature and fan speed early on. If that slower fan speed causes errors away from the temperature sensor, those ASICs may shut down engines and slow hashrate but not quickly effect temperature indication.
So the slow fan speed relative to temperature should be addressed. The problem may be in the pulsed width voltage supply line. A partial open, high resistance, in a plated thru hole, e.g. dull drill bit left fiber in the hole, the hole only partly plated. So, that's where I'll look first when I troubleshoot. I'll follow the pulsed with fan voltage first, then the ground and perhaps the speed indication pair, looking for something amiss. But not today.
Way overly optimistic without a schematic. I shut it down and inspected. Inspected and check grounds. I'd have liked to trace the fan lines but the multilayered board precluded that and without a schematic that's that. The only thing I found amiss is between pins 1 and 20 of the ribbon cable connection - the green covering had been lifted between the two pins as if those pins had carried quite a bit of current at one time and heated that area. So no joy. I would imagine that might happen if someone tried powering the S3 putting connectors to only the one side and the other side tried to hash with current across the controller board. Started falling along regular lines. My first S3, the good unit from the mid-west not Florida, has a hashing board that always runs at over 3k. No unusual noise. Wish I had a strobe tach. My next course of action is to put the fast fan board on the warmer side of the bad S3. So, although the bad board has a slow running fan there may be some compensation tho if it's not a cooling issue.... |
|
|
|
Tried the suggestion of disconnecting PSU entirely (unplugged both sets of the 6 pins), still not working. Tried it with all 4 6-pin slots used (overclock), still not working. Went back to my original set up (one PSU, 2 sets of 6 pins like the working miner), restarted, and tried to ping it, no response to the ping (also my router doesn't note it like it does with the working miner)
Have you a linux machine, other than the miner, on the network? First try nmap 192.168.1.* | more to see what is on the network. The last line of the nmap output for antMiners will identify as Paragon Technologies or sometimes as Unknown. If nmap doesn't find it and your subnet is something other than 192.168.1.0, then try running tcpdump and watching the traffic looking for an out-of-subnet IP transmitting. |
|
|
|
|
Show Posts
