 Show Posts
|
|
Pages: [1] 2 »
|
Anyone experimented with trying cgminer for the S3 on the C1?
You need the cgminer binary for the S4. It will get replaced every time you reboot the machine, so you will have to re-copy it over. You also will want to adjust /config/cgminer.conf and /etc/init.d/cgminer.sh for the correct parameters you would like to use with cgminer (like the queue setting) The firmwares are not interchangeable. Why do you want to do this?
I don't think he's talking about swapping the firmware, just replacing Bitmains broken cgminer fork with one that works properly on pools like p2pool. |
|
|
|
If its time related then start investigating power related things. The PSU would be the first thing to look at. Try powering only the bad blade pair (as long as they're the ones that power the controller) only and see if they still drop out. Alternatively, you could just swap your PSUs over and see if the problem moves.
Sometimes it happens after five minutes, sometimes it is overnight, sometimes on boot. I'll give swapping the power supplies a try next... Swapping the power supplies had no effect. I guess I'll see what Bitmain has to say (they got back to me pretty quickly and asked for screenshots, etc), which I've just sent them. They replied:
Hi,
Please go to "Miner configuration-->Advanced settings" and increase the voltage to a higher value to try.
Would have been helpful to give me a suggestion... there doesn't seem to be much if any documentation on voltage/frequency settings and I already set it to 0760. Any ideas? That being said, I haven't had to restart it since yesterday morning. Single bump -> test. I wouldn't go more than 2 more bumps. I guess what I'm asking is what are the actual values to enter in the field. It's not a dropdown on my miner and I don't see a list of valid values anywhere... |
|
|
|
If its time related then start investigating power related things. The PSU would be the first thing to look at. Try powering only the bad blade pair (as long as they're the ones that power the controller) only and see if they still drop out. Alternatively, you could just swap your PSUs over and see if the problem moves.
Sometimes it happens after five minutes, sometimes it is overnight, sometimes on boot. I'll give swapping the power supplies a try next... Swapping the power supplies had no effect. I guess I'll see what Bitmain has to say (they got back to me pretty quickly and asked for screenshots, etc), which I've just sent them. They replied:
Hi,
Please go to "Miner configuration-->Advanced settings" and increase the voltage to a higher value to try.
Would have been helpful to give me a suggestion... there doesn't seem to be much if any documentation on voltage/frequency settings and I already set it to 0760. Any ideas? That being said, I haven't had to restart it since yesterday morning. |
|
|
|
I will need a new power supply to replace one that died on me today. What do you think of this bad boy at $CAD 179.99? http://www.newegg.ca/Product/Product.aspx?Item=N82E16817182320Rosewill PHOTON Series PHOTON-1200 1200W Single rail +12v@100A I know Rosewill is a not glamorous. But the specs are more than ok for a C1. $CAD 179.99 is the cheapest gold 1200w power supply I can find in Canada. I've got two of the rosewill capstone PSU's which is the 1000W version and were less than $100. They are gold rated, single rail and a C1 is right around 80% of 1000W. I got mine from amazon, but i don't see them in the CA store. Full disclosure, I am having some trouble with one of the C1's but it doesn't seem to care which power supply it is on, so I think it is the C1 causing the issues. I love the idea of modular PSU's too, but nobody makes one and sells the modular cables on the side that I can find. There aren't usually enough PCI-E connections (the capstone comes with three, I had to use an adapter off of one of the molex connectors. If anyone knows where to get the modular cables separately for the PSU, I'd love to know where. edit: Rosewill isn't glamorous, but everything I have bought by them has been good quality even if it was significantly cheaper than other brands (not that I have bought a lot of their products, but the ones I have have been good). Of course, as Dogie says, you can't really go wrong with corsair PSU"s, I've got one of their 750W ones as well. |
|
|
|
If its time related then start investigating power related things. The PSU would be the first thing to look at. Try powering only the bad blade pair (as long as they're the ones that power the controller) only and see if they still drop out. Alternatively, you could just swap your PSUs over and see if the problem moves.
Sometimes it happens after five minutes, sometimes it is overnight, sometimes on boot. I'll give swapping the power supplies a try next... Swapping the power supplies had no effect. I guess I'll see what Bitmain has to say (they got back to me pretty quickly and asked for screenshots, etc), which I've just sent them. |
|
|
|
Did something break? there was a stale block about four hours ago and the payment queue has been empty since then... or is that expected behavior when a stale pops up?
Pool always drops into safety standby when a stale block pops up. While in that mode, the pool sends mined coins to the pool's cold wallet. This is why the payout queue grows over time. Then wk will make a manual payout from the cold wallet, which shrinks the queue back down. We are a bit overdue for such a manual payout at the moment, but I've been mining with the pool for more than a year now, and wk always makes it right in the end. Ahh, ok. thanks. |
|
|
|
|
Did something break? there was a stale block about four hours ago and the payment queue has been empty since then... or is that expected behavior when a stale pops up?
|
|
|
|
If its time related then start investigating power related things. The PSU would be the first thing to look at. Try powering only the bad blade pair (as long as they're the ones that power the controller) only and see if they still drop out. Alternatively, you could just swap your PSUs over and see if the problem moves.
Sometimes it happens after five minutes, sometimes it is overnight, sometimes on boot. I'll give swapping the power supplies a try next... |
|
|
|
|
I have a C1 that I have had for about two weeks. the first week or so it was fine, but it has started to drop chips after a few hours of running. the chips that X out are generally on the 2nd two boards and it can be anywhere from 1 or two per board to and the entire board that goes offline.
Even when the chips are not showing X, the hash rate bounces around between about 700 and 1100ghs.
I have one Rosewill capstone PSU (1000W gold) dedicated to running the C1 and cooling pump.
It came with the 10/16 firmware and was set to 250/0725. I tried updating the software to 11/26 and set the freq/voltage to 250/0760, but it is still very inconsistent.
I have two C1’s, and the other one seems to hash steadily at just over 1000ghs on the 10/16 firmware at the defaults of 250/0725. The second one also has it's own dedicated Roswiill Capstone 1000w.
Any suggestions, or do I have a defective unit?
(i've sent the same content to info@bitmain)
|
|
|
|
Is the relay network down? I can't connect to any of the different nodes.......
My instance of the relay client seems to be working happily... |
|
|
|
new firmware update posted today one of the changes is increased voltage to 760 This is the fix you all are looking for so I suggest anyone with flaky performance on there C1's do this update. I pushed my voltage up to match the new update and my miner is running even better then it was a 745 volts
both of mine came from the factory at 250/0725. Is the new firmware supposed to be running at 250/0760? Did you modify the frequency as well? What exactly was the problem this solved for you? Is there a frequency to voltage table somewhere? I can't seem to find anything published on the frequency/voltage pairs. It also appears that changing the voltage does not change the startup script for cgminer and it still starts with 0725 as the voltage./usr/bin/cgminer --bitmain-dev /dev/bitmain-asic --bitmain-options 115200:32:8:7:200:0782:0725 --bitmain-checkn2diff --bitmain-hwerror --version-file /usr/bin/compile_time --queue 0 --api-listen --default-config /config/cgminer.conf
edit: I guess it changes cgminer.conf and sets the voltage there to 0760. After about 10 minutes, one of my asics x'd out, so I reset it to 0725 for now. thanks! |
|
|
|
Closing bitcoind socket with 127.0.0.1, failed to read message header (104: Connection reset by peer)
Closing bitcoind socket with 127.0.0.1, failed to read message header (0: )
I'm not seeing any errors in my bitcoin debug log, and the port is open on the server. I'm running the latest bitcoind and I pulled the relay client from github this morning (its the c++ version on linux) Have you checked wireshark on your loopback interface, and are you sure bitcoind is listening on loopback and not only on your non-localhost address(es)? I just double checked that and it is listening on both ipv4 and ipv6. If I telnet to the port using localhost it connects and then immediately closes the connection. then the penny dropped: maxconnections is set to 20 in my bitcoin.conf and guess how many peers I have connected?  |
|
|
|
new firmware update posted today one of the changes is increased voltage to 760 This is the fix you all are looking for so I suggest anyone with flaky performance on there C1's do this update. I pushed my voltage up to match the new update and my miner is running even better then it was a 745 volts
I don't suppose they fixed the p2pool issue(s) yet tho... |
|
|
|
Quick update, I replaced the stock cgminer binary on my C1 with ckolivas' s4 binary this morning (about 5 hours ago) and it has been running well since... with two C1's I've been averaging slightly above 2TH/s, with 3-5% rejects and has already found three shares. Temps look good (running about 40C) and the only problems I've seen so far is the GH/s(5s) metric is missing and the discards are high as usual. For comparison, the stock cgminer was running at around 1.9TH/s, with 5-7% rejects and I was finding one or two shares per day. Given the timeframe, I'm not putting much weight behind the number of shares found, but there is clearly a significant improvement in hash rate and reject rate. Temps are about the same. Now, if someone would just find a block I could get paid too |
|
|
|
I'm getting this in the output:
Received transaction of size 226 from relay server
Received transaction of size 373 from relay server
Closing bitcoind socket with 127.0.0.1, failed to read message header (104: Connection reset by peer)
Closing bitcoind socket with 127.0.0.1, failed to read message header (0: )
I'm not seeing any errors in my bitcoin debug log, and the port is open on the server. I'm running the latest bitcoind and I pulled the relay client from github this morning (its the c++ version on linux) edit: I'm starting the relay client like so:
./relaynetworkclient public.us-east.relay.mattcorallo.com 127.0.0.1 8333
I saw some other people were getting similar messages on the relay, but not on bitcoind. Any ideas? Thanks! |
|
|
|
Obviously the architecture is like an S4 then (beaglebone not mips), not an S3.
Fields are different due to random api changes that bitmain felt obliged to do breaking compatibility so it's harmless (but missing).
Huge discards is due to the ridiculous default queue that bitmain set on these devices to 8000 or so. Change it to zero.
yeah. I switched back to the S4 binary and it crashed (the c1 rebooted itself). I had that happen once before on that miner after restarting cgminer several times, so I don't think it was the new binary that caused it. It also completely wiped any changes I made to the filesystem, so either the entire filesystem is running in memory and not committing to "disk", or it reflashes itself on reboot. That's not annoying at all I sent an email to bitmain regarding the stale submission issue and they responded with "engineers are working on it, but in the meantime use antpool"  Done messing with it for tonight... thanks for the input! |
|
|
|
Might be worth while asking ckolivas if the S3 binary he done to fix the stale shares filtering can also be used in the C1? I don't have a C1, but it might be compatible......
If S3 binaries run on the C1, my binary is compatible. Doesn't look like it: root@ant1:~# /usr/bin/cgminer --help
/usr/bin/cgminer: line 1: syntax error: unexpected "("
$ file cgminer
cgminer: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked (uses shared libs), with unknown capability 0x41000000 = 0xf676e75, with unknown capability 0x10000 = 0x70403, stripped
$ file cgminer.orig
cgminer.orig: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped
cgminer.orig is the one that came with the c1. The S4 binary seems to run ok (actually it seems to give quite a boost in hash rate), but the GH/s (5s) field is 0 (the avg field looks right) and the discarded field is really high... p2pool says 1.34THS/s and 5.5% discard rate, and the temperature seemed stable. I've switched back to the original binary for now... it seems like it was running too fast and if the GH/s field isn't working, I'm not sure that I trust the rest of the stats on the miner. ckolivas (or anyone else), any opinion on running the s4 binary on a c1? |
|
|
|
Might be worth while asking ckolivas if the S3 binary he done to fix the stale shares filtering can also be used in the C1? I don't have a C1, but it might be compatible......
If S3 binaries run on the C1, my binary is compatible. Doesn't look like it: root@ant1:~# /usr/bin/cgminer --help
/usr/bin/cgminer: line 1: syntax error: unexpected "("
$ file cgminer
cgminer: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked (uses shared libs), with unknown capability 0x41000000 = 0xf676e75, with unknown capability 0x10000 = 0x70403, stripped
$ file cgminer.orig
cgminer.orig: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped
cgminer.orig is the one that came with the c1. |
|
|
|
Anyone have a C1 pointing at p2pool? Mine seems to behave like my S2 pre-fix ... abysmal.
I was expecting the C1 to act like a S3, but it doesn't, it acts like an S2. Including the annoying "have to set queue to 0 every reboot" problem.
M
I have C1's using P2Pool. Mine are getting the full 1000GH/s, but they do require the same re-setting of queue after a reboot. I also set the pseudo share difficulty. It has been discussed that setting pseudo difficulty does not effect the overall performance, however setting pseudo difficulty will make cgminer and the UI show the expected hashrate. I use +1028 (If you use +1024, Best Share is not displayed. But with +1028, best Share works. I have no idea why.) Regarding setting the queue, S2/S4/C1 all have the same OS configuration. I'm not sure if it also gets wiped after a reboot (I'll let you know the next time I have to reboot) but I found that the "save and apply" button on the miner configuration completely re-writes cgminer.conf on my C1s. I've edited /www/pages/cgi-bin/set_miner_conf.cgi to add the options so that I can fiddle with my settings in the gui and still maintain the configs... That's pretty annoying about the stale shares filtering, have they made any comment regarding that specifcally or are they just ignoring it? |
|
|
|
|
Do you have a source for the quick release fittings? Any idea how much the flow rate is restricted through those (if at all)?
|
|
|
|
|
