Topic: Official FutureBit Apollo BTC Software/Image and Support thread - page 80. (Read 39791 times)

Thanks!
No idea why jstefanop is so secretive about info like that but hey - his project, his rules. I do know that BitFury is pretty tight about releasing their datasheets so that may be part of his  

When I took mine apart to replace the SBC fan it had Bitfury on the chips underneath the hashboard.

Heheh, idk - they're so secretive about which chips are used (no mention anywhere, whereas GekkoScience has it openly in shop, bt thread etc.), and this comment (our ASICs) really put the nail in the coffin for me about these being custom chips

But yeah, last I checked, it also was extremely expensive to have custom chips made.

Not a chance in hell. It cost millions of $$$ to design and produce a mining ASIC chip.
That said it *would* be interesting to know just who's chip you use. eg are they from BM, MicroBt, Canaan, Bitfury, Inosilicon et al?

Btw @jstefanop you're saying 'our ASICs' - do you actually develop your own ASIC chips? Quite interesting since the other guys building home-suited pod miners, GekkoScience, use Bitmain chips.

Woof! I figured that with today's node sizes there would be a lot more cores per-chip that what was to be had in 2014 but 4k of them? Wowzers!

Thanks a lot, got it now! Very good insight And relieving to customers ofc even though a good total hashrate should be enough good sign anyway

Each of our ASICs have ~4k SHA256 engines in them (so ~175k in each Apollo). Only one of these need to be bad to throw a really high error rate.

Error rate is calculated against good solutions based on an internal solution difficulty, not ALL solutions produced by the ASIC (would be impossible/waste of resources to do integrity check on each SHA256 pass). What happens with a bad logical core is that ALL solutions it produces are spit out as valid solutions, then the miner software does a check on them which are determined to be bad solutions, so the calculated error rates ends up inflating higher than it really is.

Normally each core produces an random amount of error that just has to do with spontaneous logical errors that happen in the chip due to low gate voltage, this is what the error rate is supposed to convey, but we cant easily catch the kind of errors that have to do with a bad logical cores.

Hope that explains it a bit.

1. How many Standard (hashboard only) units can be managed from the Full package (controller) unit?

a. Can I add a 3rd standard unit from my existing controller unit? or 2 standard units the maximum?

- Have 1 full package unit which I ordered in Batch 2

Right, right, it's confusing since the website says 44 ASIC cores 

Still confused about how a few dead cores result in a number of 70% 'error rate' in GUI, somehow the given explanation didn't clear it up much for me at least.

While I do not own one should be safe to assume there are 44 chips per-hashboard. Each chip has hundreds of cores in it. Even the A1 chip from 2014 had 256 cores per-chip and no doubt jstefanop can tell folks how many are in chip. Along that line, who's and what chip is used?

And yes, it is not uncommon for not all cores in a chip to not work though it should at worst be just a few dead cores. That said, most chips should have 100% functional cores.

I am not the one with the issue, but I don't fully understand what you're saying. One hashboard has 44 cores (thousands? where does that number come from?  ). If one of them has 70% bad solutions, that's what will be reported for the whole hashboard in the GUI? So just the core with the highest error rate is reported, is what you're saying?

No how error rate is being reported is a little deceptive right now. It counts all bad solutions coming from a core even if one core is bad out of the thousands of cores inside one ASIC (ie producing 100% bad solutions). This causes the error rate to be higher than it really is. Error rate is there to find bad solutions due to low voltage for tuning purposes. We should be filtering out bad cores but this is complicated to do in practice.

For now its better to look at your hashrate, ie if your hashrate is 70% lower than your other units then your unit is really defective, if hashrate matches your good which is what your seeing. This only affect a very small number of units. 

If you haven't done yet, try unplugging the good unit and only let the one with the 70% error rate stay connected to the node. If the faulty board is hashing good now, it's likely a power supply issue.
You could also try swapping USB cables and/or switch the ports on the node vice versa between the units. Principle of exclusion always helps to pinpoint the problem.

If nothing helps, it may be a hardware or manufacturing issue. In that case, best contact the futurebit customer support.

Posted earlier about instability issues in balanced and a high error rate.  

Screenshot from my dashboard today.  The one with the ~70% error rate is also the one that fails.  It has consistently been that unit, and the error rate has remained consistently around that.

Is this a defective unit or something I can fix?

https://i.postimg.cc/jjG8XkL4/Screenshot-20210829-062730-2.png

Hey there, LN node operator here! Don't expect to make any significant amount of money from routing LN payments.

I am quite sure you can install lnd or c-lightning on the Apollo (don't have mine yet), and you should definitely do it, it always helps! But payments are meant to be cheap, so users usually pay 1 satoshi per hop, some node operators even run their nodes fee-less.

A payment takes a max. of 10 hops in my experience, so you're looking at 'locking in' millions of satoshis in channels just to gain a few (single-digit amounts we're talking about) satoshis in fees. So you won't really 'earn BTC' - you'd earn more Bitcoin working 1hr as a waiter and buying BTC with the money you got there  (rough calculation: 10$ ~ 20KSat)

For Question #5 What can we do with our Node?
Can we choose to designate our Node into a Lightning Network Node?
This will help us earn extra BTC and Devs can take a fee from it.

For anyone experiencing issues connecting to pools, this info might help...

If, in your house you happen to own an ASUS wifi router/firewall, check and see if your model has a feature called 'Two-Way IPS' - which is part of the firewall and packet filtering settings and if you do, try disabling it.

I run an ASUS GT-AX11000 Router - one of their high end gaming routers and evidently the 'Two-Way IPS' logic inside the router was blocking the connection to slushpool. Of course there was NOTHING in the firewall's network protection dashboard that indicated this to be the case, but as soon as I disabled 'two-way IPS' the miner worked.

The background on this is as follows... I was pulling my hair out for two weeks or more trying to understand why I couldn't connect to any pool and then tried testing it using a VPN and discovered the connections were successful if using a VPN.

Since I knew that running the miner inside a VPN tunnel works, the question is, what is not 'seeing' the traffic due to the VPN? - Well, Comcast isn't seeing it, that's true and my ISP was what I was afraid was causing the issue. But with the VPN in use, the port filtering on my firewall/router ALSO isn't seeing traffic to e.g. slushpool, and that's why subsequent connection attempts worked. Turns out it wasn't Comcast, it was my firewall.

Turns out other miners also have experienced this issue. Check this old post on Reddit:  https://www.reddit.com/r/MoneroMining/comments/m1g0y1/cannot_reach_any_pool_without_tls/

Any off the shelf ATX PSU (sized appropriately) should work fine. You just need to be aware that for the PSU to power itself up when the power switch is moved to the ON position requires you to jump two pins on the 24-PIN motherboard cable. This of course means that in addition to the PCIe power cables, if it's a modular PSU you also need to connect the 24-pin cable to the PSU.

reference:  https://www.instructables.com/How-to-power-up-an-ATX-Power-Supply-without-a-PC/

-good luck!