Miner and 5 solo units has been running fine for weeks and weeks.
Today the dashboard showed no data. It looked like every unit was offline even though they were still running (fans) normal speed and all had flashing red lights.
I tried stopping and starting, then rebooting everything and finally I loaded a new image on a new micro SD and the miner still won't start.
The node is running fine. Every time I click start on the miner, the fan starts to spin up for about 0.5 second and then goes back to idle mode. I disconned all the standard units but that changed nothing. Checked all the plugs, green led is is on.
To recap: new SD & all units have red flasking LEDs but the miner won't start. Node runs fine.
What is my next step?
Topic: Official FutureBit Apollo BTC Software/Image and Support thread - page 83. (Read 40843 times)
September 01, 2021, 01:42:34 AM
August 31, 2021, 09:00:05 AM
...
When I took mine apart to replace the SBC fan it had Bitfury on the chips underneath the hashboard.
Thanks!When I took mine apart to replace the SBC fan it had Bitfury on the chips underneath the hashboard.
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
I mean, maybe they didn't obtain pinouts etc. via reverse engineering, but directly from BitFury under NDA. In that case, it might include something like no mention whatsoever anywhere, ever, can be made that you got our chips and datasheets etc.. Just a guess
But sidehack did mention that some chip manufacturers do indeed agree to give documentation under NDA (which I wouldn't have guessed myself to be honest).
Obviously we are under NDA…can stop our customers from stating the obvious though 😜
I was in two minds whether to say anything. But someone would've done at some point lol.
August 31, 2021, 08:42:51 AM
...
When I took mine apart to replace the SBC fan it had Bitfury on the chips underneath the hashboard.
Thanks!When I took mine apart to replace the SBC fan it had Bitfury on the chips underneath the hashboard.
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
I mean, maybe they didn't obtain pinouts etc. via reverse engineering, but directly from BitFury under NDA. In that case, it might include something like no mention whatsoever anywhere, ever, can be made that you got our chips and datasheets etc.. Just a guess
But sidehack did mention that some chip manufacturers do indeed agree to give documentation under NDA (which I wouldn't have guessed myself to be honest).
Obviously we are under NDA…cant stop our customers from stating the obvious though 😜
August 31, 2021, 06:27:37 AM
...
When I took mine apart to replace the SBC fan it had Bitfury on the chips underneath the hashboard.
Thanks!When I took mine apart to replace the SBC fan it had Bitfury on the chips underneath the hashboard.
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
I mean, maybe they didn't obtain pinouts etc. via reverse engineering, but directly from BitFury under NDA. In that case, it might include something like no mention whatsoever anywhere, ever, can be made that you got our chips and datasheets etc.. Just a guess
But sidehack did mention that some chip manufacturers do indeed agree to give documentation under NDA (which I wouldn't have guessed myself to be honest).
August 31, 2021, 06:23:39 AM
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.
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.
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)Thanks! Was wondering if I get in early and setup a lighting node and then overtime as transaction volume grows for BTC that it would be worth it.
There is certainly a point for getting in early: If you create a LN channel now with let's say 1M satoshi, it will cost you around 400 bucks and people can transact up to that amount in this channel back and forth. But let's say you keep that channel for multiple years, the value that can be transacted with 1M sats is ever increasing and e.g. might reach a point where it's the equivalent of thousands of $.
This way, channels created early (even small ones, <1M sats) gain usability and 'size' (in value terms) as Bitcoin value increases over time.
However, I don't think it will ever be something very profitable, even with many more transactions, since fees are by design low (1 satoshi - realize how little that is
per hop) and the market is competitive the better the network is connected. The protocol tries to automatically use the routes with lowest fees - the more routes, the less chance people will use an expensive node since they'll find cheaper ones that bring them to their destination. August 31, 2021, 01:25:07 AM
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.
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.
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)Thanks! Was wondering if I get in early and setup a lighting node and then overtime as transaction volume grows for BTC that it would be worth it.
August 30, 2021, 08:46:07 PM
...
When I took mine apart to replace the SBC fan it had Bitfury on the chips underneath the hashboard.
Thanks!When I took mine apart to replace the SBC fan it had Bitfury on the chips underneath the hashboard.
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
August 30, 2021, 05:40:56 PM
Quote
Each of our ASICs have ~4k SHA256 engines in them (so ~175k in each Apollo)
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!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.
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?
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.
When I took mine apart to replace the SBC fan it had Bitfury on the chips underneath the hashboard.
August 30, 2021, 04:39:17 PM
Quote
Each of our ASICs have ~4k SHA256 engines in them (so ~175k in each Apollo)
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!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.
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?
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.
August 30, 2021, 04:09:46 PM
Quote
Each of our ASICs have ~4k SHA256 engines in them (so ~175k in each Apollo)
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!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.
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?
August 30, 2021, 04:04:04 PM
Quote
Each of our ASICs have ~4k SHA256 engines in them (so ~175k in each Apollo)
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!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.
August 30, 2021, 03:14:57 PM
Quote
Each of our ASICs have ~4k SHA256 engines in them (so ~175k in each Apollo)
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! August 30, 2021, 03:07:01 PM
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.
Thanks a lot, got it now! Very good insight 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.
And relieving to customers ofc even though a good total hashrate should be enough good sign anyway August 30, 2021, 02:54:04 PM
Quote
One hashboard has 44 cores (thousands? where does that number come from?
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 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.
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.
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.
August 29, 2021, 05:39:29 PM
Questions:
1. How many Standard (hashboard only) units can be managed from the Full package (controller) unit? I already have one full package unit which I ordered in Batch 1, and have two standard hashboard-only units on order from Batch 2. I want to know if I could manage a third standard unit from my existing controller unit, or is two the maximum?
2. I am currently using the Futurebit PSU in Turbo mode. Is there a significant advantage to upgrading the PSU to achieve 3.8Th/s or does running the Apollo BTC at this level dramatically reduce their lifespan, and cause them to overheat?
3. On the basis that the answer to question 2 is Yes, can anyone recomend a PSU that can power three Apollo BTC devices (one full package unit and two hashboard-only units)?
4. Is there any news when the Batch 2 Units will reach Europe?
Thanks in advance.
1. How many Standard (hashboard only) units can be managed from the Full package (controller) unit? I already have one full package unit which I ordered in Batch 1, and have two standard hashboard-only units on order from Batch 2. I want to know if I could manage a third standard unit from my existing controller unit, or is two the maximum?
2. I am currently using the Futurebit PSU in Turbo mode. Is there a significant advantage to upgrading the PSU to achieve 3.8Th/s or does running the Apollo BTC at this level dramatically reduce their lifespan, and cause them to overheat?
3. On the basis that the answer to question 2 is Yes, can anyone recomend a PSU that can power three Apollo BTC devices (one full package unit and two hashboard-only units)?
4. Is there any news when the Batch 2 Units will reach Europe?
Thanks in advance.
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
August 29, 2021, 05:17:52 PM
Quote
One hashboard has 44 cores (thousands? where does that number come from?
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 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.
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.
August 29, 2021, 05:12:08 PM
Quote
One hashboard has 44 cores (thousands? where does that number come from?
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.
August 29, 2021, 03:30:58 PM
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.
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.
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? August 29, 2021, 02:45:14 PM
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?
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?
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.
August 29, 2021, 11:44:44 AM
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?
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?
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.
Jump to: