NOTE: ASICBoost is not compliant with the BIP310 standard, thus incompatible (for now) with pools other than the Bitmain owned/controlled pools. So, until the other pools adopt compatibility, all this does is make the Bitmain...not Bitcoin...network stronger.
I refuse to use Bitmain controlled pools, so it's a "no go" for me until broad adoption. That shouldn't be long, however.
Maybe incompatible on Slushpool, but working fine on Kano ( www.kano.is). Come on over and enjoy the 15% power savings and quieter mining. |
|
|
|
|
Just guessing here, but it sounds like you have a 120amp breaker box. e.g. A breaker at the top of the box that is labeled 120 amps. If so, that breaker means the total of all circuits running off that box can not exceed 120 amps short term (like over a second or two), or 120 * 80% = 96 amps continuous pull.
Under that breaker is either more smaller breakers (15 amp, 20 amp, 30 amp being common) or fuses that protect individual circuits coming out of that box.
Because miners pull power constantly, you can not use more than 80% of that 15/20/30 amp rating on any individual circuit.
|
|
|
|
I can also confirm that all shares are rejected at slushpool with or without LPM checked. I have also seen that bmminer has been modified with this LPM update.
For those that are doing power and hashrate analysis, is this with or without LPM checked? I'm trying to determine if you are getting more hashrate with less power while in low power mode. Also, if someone can do analysis with and without LPM checked that would be helpful.
With (and I've updated the post to reflect that). About to try without and see what happens. Update: Toggling the LPM checkbox and applying appeared to have no impact. e.g. Power and performance stayed the same. Power cycling now to see if that changes things. Update2: Power usage is identical with and without the LPM button being selected. Might be normal statistical variations, but performance might be SLIGHTLY (like 75GH) faster with it selected. Running a few more cycles of the test to be sure. |
|
|
|
Tested a 14TH S9 that was received a year ago. Before stats:   After stats:   Items of note: All cards are running at exactly the same auto-frequency. Power is down a lot, almost 15%. Chips are running a bit cooler, fans are running a bit slower This puts the "At-the-way" power efficiency of S9s at 0.088j/GH This is with LPM Checked - although the checkbox doesn't appear to do anything For those preferring fixed-frequency, the minerAdvanced.cgi non-menu page is still there, but only appears to set the top speed for auto-searching. (However, any fixed frequency values previously specified are carried over, and often appear to be modifiable without reverting to auto-freq) (5) of (119) miners had problems upgrading, likely due to having older controller cards. |
|
|
|
|
Remember that your going to have to sell a fair amount of your BTC to cover your electric bill every month.
The real killers are the unknowns:
1) How fast will difficulty go up? Compounding is a real nightmare. At one point I figured difficulty had gone up about 7X in 1 year.
2) What will happen to the price of BTC? If it goes up in parallel to difficulty, life is wonderful. If not, eventually you will go out of business.
Lets take an example:
Say you put up a system today that burned $15,000 worth of electricity a month and earned $20,000 in BTC month 1.
Month 2 comes along and BTC has had (2) 4% increases in difficulty, just call it 8% for the month.
That means your earning 8% LESS month 2 than you did month 1, so you $1600 less in BTC.
Month 1 netted you $20,000 earned - $15,000 in power = $5000 profit
Month 2 netted you $18,400 earned - $15,000 in power = $3400 profit, a decrease of 32%.... unless BTC prices also go up.
Basically, your electricity (and rent, taxes, building insurance, etc.) remain fixed, but your income is always going down.
In order to stay stable, with a non-increasing BTC value, you would have to grow your farm by the difficulty increase every TWO weeks. Looking at that math:
Assume you invested $150K in miners (the rest for the building, wiring, etc.), and lets use that 8%/month number from above. Means you would need to invest an additional $12,000 month 1, and more than that ever month thereafter. But you only have month 1 profit of $5000, so you are dependent on two things you have no control over (items 1 and 2 above).
Obviously a lot of assumption in those numbers. The biggest one being that you could make a 33% profit over electric cost month 1...
|
|
|
|
|
I have PSU issues much more frequently than I have miner issues. If the PSU was built-in my farm reliability would really go down.
|
|
|
|
I don't think switching to an asic resistant algorithm would make a difference.
Some of the coins that where supposed to have this feature have already shown that once they are worth it an asic is developed. That is one benefit to the fact that there are stubborn miners out there or even enough larger miners of differing views to keep the hash fairly spread out.
I'm glad to see more hardware manufacturers have entered the space, as they will obviously compete against one another. This will hopefully help maintain a somewhat decentralized network. In the long run though I unfortunately see things becoming more of a "board" mentality as rising difficulty will phase out a large portion of the population from being able to economically run equipment. This will widdle things down to a few outliers but essentially a handful of extremely large scale miners, who in the end will likely be made up of the manufacturers.
There are some little known coins, like IMACredit ( www.imacredit.org) that remain ASIC resistant due to large memory footprints. Alas, they were too "different" back in 2014 to be accepted by the major exchanges. People back then couldn't wrap their heads around a coin that hashed in the 100s of hashs a second instead of in the megahash realm. You know... like zcash SOLs do today? Alas, they were written by smaller groups of developers and never caught on - although a few diehards still CPU mine them for the fun of it. |
|
|
|
I ran and LOVED the AMS system when I had farms full of A6 units. The newer 3d more visual version that came after has never worked for me. I can get it to the same point as you, where you can login to the web console but nothing happens. I was never able to get it working and have tried multiple times over the last 2 years
Thanks... that makes 3 of us. I'm in touch with another person (running 30X what I'm running), and they are in the same boat. So does ANYONE have a contact within Canaan who can help? |
|
|
|
|
As some of you know, I've been tracking invalid rates with my Avalons. They were about double my S9s when I was running (5) per string (20 per controller). That came back on the high end of normal when I reduced it to (3) per string. I'm happy to report that (4) per string runs just as well as (3). Apparently only (5) causes the problem.
This really helps spread out the cost of controllers and AUC3s, reducing their overhead substantially.
|
|
|
|
great that we found a block. Pitty is that i added 2 more miners, and my 5N is halfway now, increased with 10+Th already, and payout is less then previous block, while my percentage is equal... Most is understandable, but its highly annoing to see...  Its lake a race you know you can't win...  If your percentage is exactly equal... all that means is that the block didn't have much in the way of transaction fees associated with it. I believe that is what Kano was referring to when he said it was a 7 second block... it was found 7 seconds after the previous block on the Bitcoin blockchain, so not many transactions had accumulated in the mempool. |
|
|
|
|
36600268 for S9s that entered on 11/18/17.
|
|
|
|
haha, we were hoping to get a github response since june, looks like you just posted on our issue.
Just created a thread in the "mining software" section of bitcointalk. Perhaps you could join in there for AMS stuff? (presuming the mods don't purge my post for some reason) |
|
|
|
|
Has anybody gotten this software up and running?
I'm to the point that the web page pops up, but trying to login doesn't do anything.
I tried to use the "amscli controller" command to add my controllers (although I expected to be able to do that via the web page) and it tells me it can't parse what I put in.
Also unclear about the [farm] and [JWT] sections in /etc/ams.conf.
Sure would appreciate some sample file formats with explainations. The github issues area for the product seems pretty dead.
|
|
|
|
I've been watching your posts here and there is a very simple approach to all of this...all pools will find the expected number of blocks (100%) over time (unless there is block withholding going on) as luck will always even out. The real difference between pools is transaction and pool fees. For example, antpoo does not give the transaction fees to the miners so you would lose big time there. Pools like KanoPool and Slush both give transaction fees back to the miners so the difference is 0.9% pool fees here vs 2.0% at slush. The math is painfully simple and test runs are not necessary as diff changes effects everyone's payouts ...if you want to get the most out of your hashrate, point all of your machines here.
I fully agree with this. The ONLY way you can accurately compare earnings between pools is to have a small pool of miners (say a dozen or more) running on one pool, and another set concurrently running on a 2nd pool. Even then, you would have to work on balancing the pool of miners so their total hashrates were below your error acceptance level. E.g. If your interested in a 0.1% difference in earning, the two pools of miners would need to be balance to within 0.05% worst case. 0.01% would be a lot better. Then you would need to run them for several hundred blocks worth, with whichever pool does the least blocks/month being the governer. Just run the math... for instance, I have some 841s that only pull 13.3TH, others pull 13.6TH. If I just used one of each of those, one per pool, there would be a built in bias of over 2.25% in earnings between the two - independant of which pools I pointed them at. If you take one miner and point at one pool for a few days or weeks, then use that same miner to point at another pool for a few days or week, your results are going to be corrupted by both the likely difficutly change that occured during the test period, and the dumb luck the pools had for that short period of time. The only thing that holds true is what the quoted author states. |
|
|
|
|
e-bay them. I always keep a few spares. The older S9s will still be running for some time. Heck, I've heard of one guy still running S3s...
|
|
|
|
Canaan clarified a week or so ago, I think I posted about it here or another thread. Lily is our main contact.
6 month comprehensive warranty, 2 year limited. Now I sound like an insurance agent.
It would be good if they posted that on their website. Suggest mentioning that to Lily if you get the chance. ps. If you happen to be talking to her, please ask her to have someone address the issues posted on the Avalon Management System github forum. |
|
|
|
|
Hi all - I'm currently running 31 Avalon 841s and a whole bunch of S9s.
While doing a daily check I noticed one of the 841s, in a 3 deep chain, is missing. The controller has 13 machines on it (now 12 showing up). I went out to the data center to visually inspect and all 13 on that controller have blue indicator lights.
I have not come across this before.
Any suggestions? Of course, I tried rebooting the controller, but that didn't help.
Figured it out: I just turned all the LEDs on to find the odd-man-out. It was actually dead after rebooting the controller, so would have been obvious had I gone back into the data center. In any case, power cycled the box and it came right back up.
|
|
|
|
Canaan's 2 year limited warranty applies to the 921.
From https://canaan.io/product/avalonminer-921/"AvalonMiner 921 includes a 180-day warranty, starting from the date goods are received. Canaan guarantees a 180 days warranty from the first date you receive the goods. We promise to replace defective or faulty parts with new parts, but mining earnings will not be compensated. Buyers pay inbound shipping and we will pay the return shipping. Please note that we are not responsible for any loss caused by customs delays, losses or charges." Sounds like 6 months to me... |
|
|
|
Canaan requested KYC information as well. If you did order from them you'd know that.
Would be happy to continue to share insights that come across on what we find or are working on regarding relief and exemption but the transparency here is wearing thin and I have no patience for terribly orchestrated marketing.
Then the whole fear mongering aspect, 25% tariff are substantial but there's nothing that complicated about it if you're already used to prior ruling.
Maybe I should just be direct and say that you, *insert company name* guys can do better than this, plus what a melancholy thread to shill on.
Good to know. I'm not big enough to order from them directly... sometimes close, but never quite there. Thanks for the heads up! |
|
|
|
We have the same retroactive corrections, six figures as well, cant fight in court. At the end of the day, if you import, its your job to know what hts code to use, and correct the import docs if incorrect. The ruling is only technically a clarification of a status that already existed.
This is a huge cash grab now for the gov, they will eventually hit every import from bitmain ever.
Yeah, I'm only going to owe a few thousand, but that still sucks bigtime. Fortunately I've already sworn off of buying anything from Bitmain, which was reconfirmed in my mind when they started all this KYC stuff. From now on, I'll only order from Blokforge and let you guys deal with CBP. Am rather curious if they are going to hit me for smaller orders, or just called this one out since it was for over $100K worth of gear (back then...). |
|
|
|
|
Show Posts
