 Show Posts
|
|
Pages: [1] 2 3 »
|
|
Overclocking: You have to edit /config/asic-freq.config, not /etc/asic-freq.config
After you make your edits, go to the miner configuration page and click save & apply to restart cgminer without rebooting.
Files may or may not revert to their original state after a reboot.
Does anyone know what values to use for option 'freq_value', option 'chip_freq', and option 'timeout' if you want a 225M clock?
|
|
|
|
Logins web: root/root SSH: root/admin Overclocking You have to edit /config/asic-freq.config, not /etc/asic-freq.configAfter you make your edits, go to the miner configuration page and click save & apply to restart cgminer without rebooting. Files may or may not revert to their original state after a reboot. For info about what values to put for freq_value and things see https://github.com/AntMiner/AntGen1/blob/master/cgminer/README.md and https://bitcointalk.org/index.php?topic=348327.msg4549088#msg4549088 (these links are for the S1, but should also be applicable to the S2). EDIT: I just wanted to cross post this here from the other thread since my batch 1 S2 also experienced the symptoms described below, and I solved it by following these steps. I've mirrored the SD card image here: http://ec2.stew.dk/bitmain.img.zipsha1sum of the zip: b784d546095bc35eb693b0948a11c11df4cdd21d sha256sum of the zip: c0a2d89b342b880dbc960c1a6d42b22c583df523cc548771f132303dca0c5d9b After having no setup issues and running great for the last couple of weeks, I woke up this morning to find my batch 1 AntMiner S2 not hashing, fans going full speed, panel dim and the red light solid. Recalling that others here have had the same issue, I went back and skimmed over the previous posts and found that the likely issue was probably a corrupt SD card. That was indeed the case, as I am now back up and running, and I figure the problem started when a brief power outage occurred here this morning. Thought I would briefly summarize what I did to recover, which may be of special interest to those folks using a Mac to write to their SD cards: - ran to the store and bought a 4gb Sandisk microSD card. They didn't have any class 10 cards, only class 4, but it seems to work (ordered a couple class 10s from Amazon for backup). - Downloaded onto my MacBook the latest firmware from the bitmaintech website, as well as the SD card image from https://dl.dropboxusercontent.com/u/16075357/bitmain.img.zip (thanks 1l1l11ll1l) - put the new microSD card in the adapter, shoved it into my MacBook, read through the guide at http://elinux.org/RPi_Easy_SD_Card_Setup, and then ran these commands in Terminal: cd Desktop (my bitmain.img was on the desktop) diskutil list (to find the disk name of SD card, mine was disk2, so replace disk2 below with what yours is) diskutil unmountDisk /dev/disk2 sudo dd bs=1m if=bitmain.img of=/dev/disk2 (this took 30 minutes to complete) - once SD card was ready, I opened up the AntMiner, pulled out the BeagleBone card, swapped SD cards and reassembled - powered up, and it started hashing again. Connected to the miner from the browser, uploaded the latest firmware, changed to point to my pool, and everything was golden. Much thanks to all of previous posters that talked about this issue, as your help got me back up in hours as opposed to days. |
|
|
|
Yesterday I upgraded to 0.9.0 64bit (Windows).
My "dead" dropped from 130-160G to about 60G !
Nice! What does your Bitcoind GetBlockTemplate Latency graph look like? |
|
|
|
[Firmware Version] => 20130923
cgminer: 48681dd
cgminer-openwrt-packages: 3527ce4
luci: 296b358
Socket connect failed: Connection refused
anyone know why tp-link says this after configuring the user?
Double check your worker/pool settings. cgminer refuses to start up all the way if there aren't any valid pools specified, leading to that error message. |
|
|
|
Can someone check the main board. I have this three wire thing plugged into P3. And it's like 30 inches long and capped at the end. What the hell is it?
Pics? Could it be the temperature sensor? EDIT: Oh wait, I just looked at my main/fpga board. P3 is the LED. EDIT2: Nope, sorry, P3 is actually the temperature sensor on my board. Forgive my temporary stupidity. P1 is the LED. Funny story - if I heat up my temperature sensor the fans actually slow down. |
|
|
|
Cap would be open circuit right not short.
Not if the capacitor was installed backwards. Which it was. More details to follow after I get the blade back online... IF I get it back online. Things are looking better now than a couple of hours ago at least. Backwards?!? Ouch, their QC doesn't seem to have worked for the Q or the C for the non-early orders. Reversed polarity. As bass ackwards as it gets. After some tinkering, I finally got both blades up and hashing again. Like I said before, I narrowed it down to a short between 12V and GND on one of the modules. I temporarily removed the faulty module so I could run the good one while figuring out the problem. At first I though it was due to the shitty soldering job:  https://i.imgur.com/3NYDjKE.pngBut as it turns out it was actually due to the shitty soldering job. Electrolytic capacitors don't like to be connected backwards, contrary to what BTMine thinks. I'm honestly surprised it ran for as long as it did. This picture was after I had removed the C1 since I was doing the process of elimination.  https://i.imgur.com/dsmEwfn.pngI snapped a picture of the other working module. This is what it's supposed to look like:  https://i.imgur.com/GLxEWon.pngBoth caps removed:  https://i.imgur.com/0V4gx4z.pngHave a look at the schematic for this board http://downloads.canaan-creative.com/hardware/A3256/avalon/2013-11-30/HASH_PANEL/PDF/hash_panel.pdfC1 is decoupling the 3.3V rail, and C2 is decoupling the 12V rail, and I confirmed this with my multimeter on the working module. The old C2 was obviously fried, and I just so happened to have a spare 470uF capacitor on hand. It's rated for 10V, not 16V, but that's okay, I just used it for C1. It was a bitch to solder since the ground plane acts like a huge heatsink.  https://i.imgur.com/5af6CAm.pngIf you're looking for replacement capacitors for yourself, you could use mouser as mtnminer suggested, or I personally like digikey.com. |
|
|
|
Cap would be open circuit right not short.
Not if the capacitor was installed backwards. Which it was. More details to follow after I get the blade back online... IF I get it back online. Things are looking better now than a couple of hours ago at least. Backwards?!? Ouch, their QC doesn't seem to have worked for the Q or the C for the non-early orders. Reversed polarity. As bass ackwards as it gets. |
|
|
|
Cap would be open circuit right not short.
Not if the capacitor was installed backwards. Which it was. More details to follow after I get the blade back online... IF I get it back online. Things are looking better now than a couple of hours ago at least. |
|
|
|
|
One of my BTmine units went offline late last night. Fans were off, PSU fans were also off, and the LED from the fpga board was solid red. Could still access the tp-link interface. Tried different PSUs, nothing changed. After some poking around with a multimeter, it turns out that I definitely have a short between 12V and GND on one of the blades/modules. I unplugged the faulty module and I'm back up and running with only one module for now.
|
|
|
|
Has anyone had any success overclocking in increments smaller than 100? For example, 1410? I don't want to jump to 1500 right away since people are reporting blown SMD fuses at 1500. I've tried 1410, but it doesn't seem like that and only hashes 8-10 GH/s total or so...  twib2, where are you downloading firmware images from? Different topic: I wait I wait, nothing happens.
Could someone upload a backup of a working machine ?
I think it will solve that sh***...
I've noticed that cgminer won't start if you don't have any valid pools specified. For example, I mistakenly entered stratum+tcp://mining.bitcoin.cz:3333 instead of stratum+tcp://stratum.bitcoin.cz:3333, and the cgminer API log would keep getting stuck on "Socket connect failed: Connection refused" until I figured it out. "Socket connect failed: Connection refused" just means that cgminer isn't starting properly. If all else fails, try the reset button on the TP-link board, or there is also a factory reset option in the UI, which I think resets the IP to 192.168.0.100, and you'll have to re-enter the chip frequency, chip count, etc. If you still really really need a configuration backup of a working machine, PM me (not sharing publicly since the configuration backup has my worker info). If you're running into problems because you want to get wifi working, you're on your own. I'd recommend sticking to hardwired for now. |
|
|
|
Why are you guys using a secondary stratum proxy when BFGMiner already has a stratum proxy built in? Because bfgminer's proxy does not support long poll. |
|
|
|
... but even knowing the minimum CFM rating it needs would be very helpful.
Well, I can tell you that 60 CFM is not quite enough. Just wanted to share my experience with fan replacements. I put some Cougar Vortex HDB fans ( http://www.newegg.com/Product/Product.aspx?Item=N82E16835553005) in my cubes, and they sure do run nice and silent but at the expense of pushing a lot less air than the stock fans. The cubes do run on high with these fans (I ran them for over a day like that) but it gets way too hot for my liking. I touched a thermometer to one of the heatsinks and it read over 90°C (ambient is ~21°C). So I put the original fans back in and they're running much cooler now. Whatever fan you decide on, make sure it has the standard three pins. Please share your experience. |
|
|
|
ICMP is not guaranteed way to test connection over internet - many routers have ICMP limit, which causes the packet to be dropped
Check with mtr and there will be no losses on the last hop
Good point. Sorry about making an unfair assumption. Regardless, I'd still like to check the reliability of my connection to stratum.mining.cz. I tried running mtr stratum.bitcoin.cz a couple of times, and it seems to resolve to different addresses each time. Looks to me like some load balancing of some sort is going on, but it seems odd to me that it wouldn't just resolve to the closest geographical server to me every time. Sometimes it's smeu01.bitcoin.cz, sometimes it's 192.198.107.178, and sometimes it's 54.225.68.97 (ec2-54-225-68-97.compute-1.amazonaws.com). Do you think manually specifying 54.225.68.97:3333 in my miner would be a good idea? 54.225.68.97 seems to have the lowest latency for me. If it works yes, but keep in mind tomorrow something else may be better. No connection is perfect. Yep, it works. I can successfully submit shares using all three of those addresses. It's not a good idea to use a static IP on my opinion.
The main reason to use load balancing is to distribute the load and failover to the remaining live servers in case of problems, which you will loose in this case.
Lowest latency does not mean 'best' ... what if the server is close but overloaded?
If you insist on fixed IP - it's recommended to at least add the hostname for failover
Of course I'll still have stratum.bitcoin.cz as a failover pool specified in the miner since that's the supported address. I'm just trying to outsmart the load-balancer to get the best connection. However, if I'm reading the output from mtr right, there is actually some loss at the last hop. More so for 54.225.68.97 than the other two. Maybe smeu01.bitcoin.cz is actually the best address for me even if it has the highest latency? EDIT: Yeah, I realize this isn't a solution if the server is overloaded... But you said there shouldn't be any loss at the last hop? EDIT2: In case the bitcointalk image proxy doesn't work: https://i.imgur.com/RjbI23B.pnghttps://i.imgur.com/BsR2ZBi.pnghttps://i.imgur.com/aR7eFpU.pngTry not to quote the images.    |
|
|
|
ICMP is not guaranteed way to test connection over internet - many routers have ICMP limit, which causes the packet to be dropped
Check with mtr and there will be no losses on the last hop
Good point. Sorry about making an unfair assumption. Regardless, I'd still like to check the reliability of my connection to stratum.mining.cz. I tried running mtr stratum.bitcoin.cz a couple of times, and it seems to resolve to different addresses each time. Looks to me like some load balancing of some sort is going on, but it seems odd to me that it wouldn't just resolve to the closest geographical server to me every time. Sometimes it's smeu01.bitcoin.cz, sometimes it's 192.198.107.178, and sometimes it's 54.225.68.97 (ec2-54-225-68-97.compute-1.amazonaws.com). Do you think manually specifying 54.225.68.97:3333 in my miner would be a good idea? 54.225.68.97 seems to have the lowest latency for me. |
|
|
|
do some research please
Certainly. I've overall been happy with slush's pool, but this is why I'm thinking about switching to another pool. Here are the results from "ping -t stratum.bitcoin.cz":  The time-outs happen regularly. The problem is NOT with my own internet connection. I had another ping session running simultaneously (ping -t stratum.btcguild.com), and BTC Guild only had one time-out the entire time. My location is USA. |
|
|
|
I reported block ID 21408 showing as none, none.
Same here. And again with # 21410 block height 27951721410 is fixed, still none for 21408Fixed! |
|
|
|
Today, I visited BTMine factory. All people is nice. They are so busy to process many orders from their country and abroad orders too by sequence. Be patient to get your tracking. BTMine will ship on time.
Some pictures about their factory:
Imgur mirror: http://imgur.com/a/vkEPu |
|
|
|
For those who are running multiple cubes through a single instance of slush's proxy and your pool of choice has vardiff, beware that slush's proxy has a bug resulting in unsubmitted shares. Workaround: one instance of slush's proxy per cube. Each instance needs a unique --getwork-port. More info is over at Dogie's setup thread: https://bitcointalk.org/index.php?topic=352658.msg4371031#msg4371031 |
|
|
|
I've got 2 instances of the proxy for two pools - so it's 4 instances of the proxy running. The Blades and the Cube go to their own pair of proxies.
So, I have 4 shortcuts in Windows startup - Cube Eligius, Cube BTCGuild, Blades Eligius and Blades BTCGuild. This allows the miners to swap between pools automatically if one pool is down. All 4 shortcuts point to the same .exe so no real issues.
2 blades sharing a proxy? Eligius is vardiff last i checked, so you may want to consider having yet another proxy instance or two so the blades aren't sharing... I will reiterate yet again that slush's proxy does not handle well multiple workers with different share difficulties, resulting in unsubmitted shares and lost profits. Luke-JR, please please please add long poll to the bfgminer proxy so we don't have to deal with this... Or if slush would fix the stratum proxy, that would be great too. Or ASICminer could implement stratum natively in the firmware - I'd be okay with that too. |
|
|
|
|
