|
ZiG
|
 |
October 10, 2014, 06:22:06 PM |
|
HA HA HA
just saw it now they ask shipping for two miners for EU 0.419 BTC
Yes am going to proceed with my order now bitmain just wait for me
Sorry to see this company going down....
...BIG time...unfortunately...  ZiG |
|
|
|
|
|
|
|
|
|
|
|
|
|
It is a common myth that Bitcoin is ruled by a majority of miners. This is not true. Bitcoin miners "vote" on the ordering of transactions, but that's all they do. They can't vote to change the network rules.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
|
|
bspurloc
|
|
October 10, 2014, 08:06:45 PM |
|
After what I learnt from the S4 investigation, I checked the S3s, and they have a very diminished version of the problem with pools that start at low diffs. Here's an updated binary for the S3s. http://ck.kolivas.org/apps/cgminer/antminer/s3/4.6.1-141009/cgminerThis might make startup/pool switching a bit smoother, especially if your pools start at diff 1 and take a while to increase their vardiff. EDIT: Hashrates even seem a little faster after a few minutes... EDIT2: No it's not any faster after longer running, it's the same overall performance. Only the startup won't overload the S3 controller on low diff starting pools. well, seems it did some magic to one of my S3s, before it was stable at 478 (250 MHz) now, its at 501 after almost 1 hour running... Lucky. Mine actually went the opposite direction. My 3 S3+ Antminers were steady at 478-500GH/s and after the update consistently below or just under 450GH/s 4.6.1 doesnt speed mining up it just takes the load off the CPU, people reporting it sped up mining were just being giddy and not lettings smoothout. I noticed when changing up to 250 on a few miners, I had to let the chips cool down first to below 35C before trying to 250 again or they would tank below 480. no clue why but at least 2 did it so it isnt an anomaly well one issue may be poor heatsink compound, the ones I upgraded dont have this issue and mine at 250 smoothly |
|
|
|
|
philipma1957
Legendary
 Offline
Activity: 4116
Merit: 7824
'The right to privacy matters'
|
|
October 10, 2014, 08:13:12 PM |
|
HA HA HA
just saw it now they ask shipping for two miners for EU 0.419 BTC
Yes am going to proceed with my order now bitmain just wait for me
Sorry to see this company going down....
I can buy s-3 miners on ebay for less then I can buy them from bitmaintech. Last week I paid 240 usd for 1 s-3 miner at 358 a coin 2 miners to the usa New Jersey are 1.539 so 1.539 x 358 = 550.96 usd for 2 that comes to 275.48 usd a miner. I paid 240 and got about 11 usd back in discount so 229 from ebay with a 45 day ebay warranty or 275 from bitmaintech and no recourse since you pay in btc. makes no sense at all. |
|
|
|
Biodom
Legendary
Offline
Activity: 3752
Merit: 3853
|
|
October 10, 2014, 08:33:30 PM |
|
HA HA HA
just saw it now they ask shipping for two miners for EU 0.419 BTC
Yes am going to proceed with my order now bitmain just wait for me
Sorry to see this company going down....
I can buy s-3 miners on ebay for less then I can buy them from bitmaintech. Last week I paid 240 usd for 1 s-3 miner at 358 a coin 2 miners to the usa New Jersey are 1.539 so 1.539 x 358 = 550.96 usd for 2 that comes to 275.48 usd a miner. I paid 240 and got about 11 usd back in discount so 229 from ebay with a 45 day ebay warranty or 275 from bitmaintech and no recourse since you pay in btc. makes no sense at all. well, point taken, but it was last week. This week, after B10 announcement, some price recovery and flat difficulty, you would have to pay at least $275, maybe $299 on ebay, almost nobody will sell for $240. In fact, only newbs would sell used S-3 for next 7-9 days because difficulty stayed flat, so it pays to delay. |
|
|
|
|
|
MissouriMiner
|
|
October 10, 2014, 08:57:26 PM |
|
Just passing on a warning to pay very close attention to the shipping and handling terms on eBay purchases. One guy seems to be selling at a bargain price, but you won't get the miner for almost a month after you buy it. He states; "Will ship within 10 business days of receiving cleared payment. The seller has specified an extended handling time for this item." The sale ends today and the estimated delivery date is between Oct 28 and Nov 10. I saw some other fishy items with Miner sales, but I don't recall the specifics off the top of my head. Just be very careful and pay attention to every detail.
|
|
|
|
|
philipma1957
Legendary
Offline
Activity: 4116
Merit: 7824
'The right to privacy matters'
|
|
October 10, 2014, 10:31:22 PM |
|
|
|
|
|
Biodom
Legendary
Offline
Activity: 3752
Merit: 3853
|
|
October 10, 2014, 10:52:37 PM |
|
good catch, but the latter guy does not have any performance guarantees and obviously wants to deal in BTC, which is outside of ebay. The first one is a good deal, especially since he says-make an offer. I don't know why he is so desperate to get rid of them at the low considering everything. Many other people ask for ~300 plus minus a few ($275-339). |
|
|
|
|
|
nst6563
|
|
October 10, 2014, 10:53:15 PM |
|
Is anyone else putting their S3's on LeaseRig? I have a couple on there and everything works great using the bitmain original cgminer. However, if I replace that with the new cgminer Ckolivas posted I get very erratic behavior when someone rents the miner. Things like low or 0 hashrate, it reboots, or otherwise just stops mining. If I swap out Ckolivas' new build of cgminer with the Bitmain original it all runs fine again.
Am I missing something? Setting something wrong?
|
|
|
|
|
|
faetos
|
|
October 10, 2014, 10:57:06 PM |
|
Is anyone else putting their S3's on LeaseRig? I have a couple on there and everything works great using the bitmain original cgminer. However, if I replace that with the new cgminer Ckolivas posted I get very erratic behavior when someone rents the miner. Things like low or 0 hashrate, it reboots, or otherwise just stops mining. If I swap out Ckolivas' new build of cgminer with the Bitmain original it all runs fine again.
Am I missing something? Setting something wrong?
chmod +x cgminer Did you make it executable? |
|
|
|
|
|
pekatete
|
|
October 10, 2014, 11:02:12 PM |
|
Is anyone else putting their S3's on LeaseRig? I have a couple on there and everything works great using the bitmain original cgminer. However, if I replace that with the new cgminer Ckolivas posted I get very erratic behavior when someone rents the miner. Things like low or 0 hashrate, it reboots, or otherwise just stops mining. If I swap out Ckolivas' new build of cgminer with the Bitmain original it all runs fine again.
Am I missing something? Setting something wrong?
chmod +x cgminer Did you make it executable? To add to the above, low hashrate in the UI sometimes happens when you restart cgminer rather than reboot. After updating to the new cgminer and making it executable, reboot the S3 via SSH not the UI. |
|
|
|
|
MissouriMiner
|
|
October 10, 2014, 11:04:55 PM |
|
Is anyone else putting their S3's on LeaseRig? I have a couple on there and everything works great using the bitmain original cgminer. However, if I replace that with the new cgminer Ckolivas posted I get very erratic behavior when someone rents the miner. Things like low or 0 hashrate, it reboots, or otherwise just stops mining. If I swap out Ckolivas' new build of cgminer with the Bitmain original it all runs fine again.
Am I missing something? Setting something wrong?
Same here. All of mine run better with the Bitmain version (3.12.0). The 4.6.1 (and 4.6.0) starts off faster, but after letting it run 24 hours, the miner side average was a little lower than the Bitmain version. And the pool-side average with 4.6.x was also lower. I'm mining with ghash.io. EDIT. I did not mean to say much lower. I meant also lower. Just saying I checked both cgminer reported average and pool-side reported average. The actual difference was not much at all. But I didn't care for the sporadic behavior of the 4.6 version. It would report crazy high numbers, like over 600 Gh/s, then very low numbers. lol... They would not start mining if cgminer was not executable. |
|
|
|
|
|
pekatete
|
|
October 10, 2014, 11:15:19 PM |
|
Is anyone else putting their S3's on LeaseRig? I have a couple on there and everything works great using the bitmain original cgminer. However, if I replace that with the new cgminer Ckolivas posted I get very erratic behavior when someone rents the miner. Things like low or 0 hashrate, it reboots, or otherwise just stops mining. If I swap out Ckolivas' new build of cgminer with the Bitmain original it all runs fine again.
Am I missing something? Setting something wrong?
Same here. All of mine run better with the Bitmain version (3.12.0). The 4.6.1 (and 4.6.0) starts off faster, but after letting it run 24 hours, the miner side average was a little lower than the Bitmain version. And the pool-side average with 4.6.x was much lower. I'm mining with ghash.io. lol... They would not start mining if cgminer was not executable. What batch of S3's do you have and do they have the latest firmware installed? I did some tests after the original 4.6 was published (see link in my signature) and I experienced reduced hashrate and rolled back to the stock cgminer. However, when I upgraded my S1's with the upgrade kit, the upgraded (with the latest firmware) ones were hashing faster than my S3's, and the only difference was the firmware which I decided to upgrade and voilla, order was returned with the proper S3's hashing slightly higher (and consistently) than my upgrades. When 4.6.1 was published, I installed it on both factory S3's and my upgrades and BOTH hash better and faster than before. So, to get the best / most out of cgminer 4.6.1 I'd ensure you have the latest firmware AND reboot via SSH after updgrading cgminer rather than restart. EDIT: - Note that if you flush the latest firmware, you'll have to re-install cgminer 4.6.1 as the firmware has the stock version. |
|
|
|
|
Phosphorous
|
|
October 10, 2014, 11:42:11 PM |
|
I've got an S3+ and it works fine but I have a problem:
When the unit has been hashing for a few days and I turn it off and re-start it, it won't re-start. It won't come back on the network. However, if I let the unit cool for about an hour and turn it back on, it just starts working like it should. I have gone through this a couple of times and it works like that consistently. It's not a huge deal because it works once it gets going, but I did run into an issue where after running for several days I could no longer access the control interface with my web browser, but it was still hashing away just fine.
Would this indicate some kind of thermal problem with the controller board? Is there a good way to get this fixed? I think if I send it in for RMA they will plug it in and it will work fine. To minimize downtime I'd prefer to buy a controller board and then return the defective one for a refund.
|
|
|
|
|
|
nst6563
|
|
October 11, 2014, 02:19:18 AM |
|
Is anyone else putting their S3's on LeaseRig? I have a couple on there and everything works great using the bitmain original cgminer. However, if I replace that with the new cgminer Ckolivas posted I get very erratic behavior when someone rents the miner. Things like low or 0 hashrate, it reboots, or otherwise just stops mining. If I swap out Ckolivas' new build of cgminer with the Bitmain original it all runs fine again.
Am I missing something? Setting something wrong?
chmod +x cgminer Did you make it executable? To add to the above, low hashrate in the UI sometimes happens when you restart cgminer rather than reboot. After updating to the new cgminer and making it executable, reboot the S3 via SSH not the UI. Yes - it's executable....it wouldn't be mining and giving the erratic behavior if it wasn't able to execute it. What I'm meaning specifically is the erratic behavior (at least for me) ONLY happens when the miner gets leased. It will go on and offline and reboot and do all sorts of nonsense when the miner is on lease with cgminer 4.6+. As soon as I switch back to the Bitmain version (and reboot - I've rebooted both via ssh as well as webgui and both result the same), everything returns to normal. Nothing else is changed - only the cgminer binary. Which is why I'm thinking I'm either missing something or maybe the new cgminer binaries don't support or require a different command line options. I don't think it's the pools the miners are leased on either, I've seen different pools being used by different people leasing it. |
|
|
|
|
visdude
Legendary
Offline
Activity: 1081
Merit: 1001
|
|
October 11, 2014, 05:54:23 AM
Last edit: October 11, 2014, 12:46:18 PM by visdude |
|
I've got an S3+ and it works fine but I have a problem:
When the unit has been hashing for a few days and I turn it off and re-start it, it won't re-start. It won't come back on the network. However, if I let the unit cool for about an hour and turn it back on, it just starts working like it should. I have gone through this a couple of times and it works like that consistently. It's not a huge deal because it works once it gets going, but I did run into an issue where after running for several days I could no longer access the control interface with my web browser, but it was still hashing away just fine.
Would this indicate some kind of thermal problem with the controller board? Is there a good way to get this fixed? I think if I send it in for RMA they will plug it in and it will work fine. To minimize downtime I'd prefer to buy a controller board and then return the defective one for a refund.
I've always felt that since the controller sits directly on top of the heat sinks, its whole surface area is taking the brunt of the heat that's radiating/rising from them, hence I opted to set up my units in a vertical configuration (controller in vertical position, adjacent to the heat sinks instead of on top of them and at the bottom half of the unit/enclosure): https://bitcointalk.org/index.php?topic=671189.msg8227268#msg8227268https://bitcointalk.org/index.php?topic=671189.msg8471571#msg8471571I have no conclusive scientific proof that it's helping but I have been able to operate my S3s with ambient temps up to 42C (107F) while clocked at 243.75M with no issues. Alternatively, you can run the S3s on its side (controller in vertical position and adjacent to the heat sinks instead of on top of it) or perhaps even upside down (controller underneath the heat sinks). I suggest to try these configurations out before you decide to RMA/replace the controller and see if it helps. It couldn't hurt. |
|
|
|
|
moss
Member
Offline
Activity: 98
Merit: 10
|
|
October 11, 2014, 10:26:34 AM
Last edit: October 11, 2014, 09:22:51 PM by moss |
|
Is anyone else putting their S3's on LeaseRig? I have a couple on there and everything works great using the bitmain original cgminer. However, if I replace that with the new cgminer Ckolivas posted I get very erratic behavior when someone rents the miner. Things like low or 0 hashrate, it reboots, or otherwise just stops mining. If I swap out Ckolivas' new build of cgminer with the Bitmain original it all runs fine again.
Am I missing something? Setting something wrong?
Same here. All of mine run better with the Bitmain version (3.12.0). The 4.6.1 (and 4.6.0) starts off faster, but after letting it run 24 hours, the miner side average was a little lower than the Bitmain version. And the pool-side average with 4.6.x was much lower. I'm mining with ghash.io. lol... They would not start mining if cgminer was not executable. What batch of S3's do you have and do they have the latest firmware installed? I did some tests after the original 4.6 was published (see link in my signature) and I experienced reduced hashrate and rolled back to the stock cgminer. However, when I upgraded my S1's with the upgrade kit, the upgraded (with the latest firmware) ones were hashing faster than my S3's, and the only difference was the firmware which I decided to upgrade and voilla, order was returned with the proper S3's hashing slightly higher (and consistently) than my upgrades. When 4.6.1 was published, I installed it on both factory S3's and my upgrades and BOTH hash better and faster than before. So, to get the best / most out of cgminer 4.6.1 I'd ensure you have the latest firmware AND reboot via SSH after updgrading cgminer rather than restart. EDIT: - Note that if you flush the latest firmware, you'll have to re-install cgminer 4.6.1 as the firmware has the stock version. That's interesting. I held back on updating my under-performing S3 after reading your original post about reduced hash rate, but if 4.6.1 fixes that, I'll give it a go. Thanks.  Edit: when you say latest firmware, do you mean this one - antMiner_S320140826.bin which it says supports S3+? I am using ordinary S3s. Cheers. Edit2: Confirmed by pekatete in another thread. Thanks again. |
|
|
|
|
Xian01
Legendary
Offline
Activity: 1652
Merit: 1067
Christian Antkow
|
|
October 11, 2014, 09:46:20 PM |
|
I have no conclusive scientific proof that it's helping but I have been able to operate my S3s with ambient temps up to 42C (107F) while clocked at 243.75M with no issues. Alternatively, you can run the S3s on its side (controller in vertical position and adjacent to the heat sinks instead of on top of it) or perhaps even upside down (controller underneath the heat sinks). I suggest to try these configurations out before you decide to RMA/replace the controller and see if it helps. It couldn't hurt.
I have nothing beyond an anecdotal "gut feel", but over the last few hours since reading this post, rotating all my S3's so they are laying on their side (Bitmain logo facing up), they do seem to be running slightly more stably and cooler... Will continue monitoring. |
|
|
|
|
Moria843
Sr. Member
Offline
Activity: 442
Merit: 250
Found Lost beach - quiet now
|
|
October 11, 2014, 09:53:49 PM |
|
Get the version via ssh. The webUI will always say the older version  Looks like something obviously changed because both S3s seem to be hashing faster, showing best share in miner status, now showing stratum+tcp instead of http, and load numbers have dropped. What's the command to show version from SSH? /usr/bin/cgminer-api scroll to the top to see the cgminer version. M Must have worked; both showing 4.6.0. Will this version work on my undervoltaged S1s? I'm not sure. I do know Kano published an update for S1s to make things better. Not sure how much better it is, but it's something. https://github.com/kanoi/cgminer-binaries/tree/master/AntS1M Thanks M for your help and your great Ant Monitor program. Would I load similar to how done for the S3 earlier with the mod below? cd /usr/bin mv cgminer cgminer.bak wget https://github.com/kanoi/cgminer-binaries/tree/master/AntS1mv AntS1 cgminer chmod +x cgminer #Reboot |
Hot time, summer in the city, back of my mine getting hot & gritty!!!
|
|
|
visdude
Legendary
Offline
Activity: 1081
Merit: 1001
|
|
October 11, 2014, 10:58:34 PM |
|
I have no conclusive scientific proof that it's helping but I have been able to operate my S3s with ambient temps up to 42C (107F) while clocked at 243.75M with no issues. Alternatively, you can run the S3s on its side (controller in vertical position and adjacent to the heat sinks instead of on top of it) or perhaps even upside down (controller underneath the heat sinks). I suggest to try these configurations out before you decide to RMA/replace the controller and see if it helps. It couldn't hurt.
I have nothing beyond an anecdotal "gut feel", but over the last few hours since reading this post, rotating all my S3's so they are laying on their side (Bitmain logo facing up), they do seem to be running slightly more stably and cooler... Will continue monitoring. I know what you mean. I have always wanted to stick some temp sensors around the controller and get readings in different configurations/orientations in an effort to conclusively determine if they do make a difference but I can't afford the down time ("if it ain't broke, don't fix it" mentality on my part). However, the one thing that we can go by to make sense out of it is that we do know that heat rises and in an enclosed environment, it would accumulate at the top. |
|
|
|
|
|
pekatete
|
|
October 11, 2014, 11:26:21 PM |
|
I have no conclusive scientific proof that it's helping but I have been able to operate my S3s with ambient temps up to 42C (107F) while clocked at 243.75M with no issues. Alternatively, you can run the S3s on its side (controller in vertical position and adjacent to the heat sinks instead of on top of it) or perhaps even upside down (controller underneath the heat sinks). I suggest to try these configurations out before you decide to RMA/replace the controller and see if it helps. It couldn't hurt.
I have nothing beyond an anecdotal "gut feel", but over the last few hours since reading this post, rotating all my S3's so they are laying on their side (Bitmain logo facing up), they do seem to be running slightly more stably and cooler... Will continue monitoring. I know what you mean. I have always wanted to stick some temp sensors around the controller and get readings in different configurations/orientations in an effort to conclusively determine if they do make a difference but I can't afford the down time ("if it ain't broke, don't fix it" mentality on my part). However, the one thing that we can go by to make sense out of it is that we do know that heat rises and in an enclosed environment, it would accumulate at the top. Forgive me for budging in on this. I totaly understand that most of the observations here are anecdotal, but I have never known any of my S3's to run without any of the fans turned on. Even when they are not hashing but connected to the pool, the fan still turns, albeit slowly. So my question is, how would the heat then have a chance of building up at the top? Having said that, I'll give it a shot too. |
|
|
|
|
