Search content
Sort by
Showing 20 of 1,875 results by aurel57
Re: Official FutureBit Apollo II/BTC Software/Image and Support thread
Won one for the plebs today using an Apollo BTC Full node, Apollo BTC standard, Apollo II standard and one Bitmain S19kpro.
Code:
[2025-03-21 04:31:00.699] Possible block solve diff 393692033929762.687500 !
[2025-03-21 04:31:01.278] BLOCK ACCEPTED!
[2025-03-21 04:31:01.308] Solved and confirmed block 888737 by bc1qa6y279yprwtuthnw0xqu6rzhrf8d6uujcdh9xd.S19k
[2025-03-21 04:31:01.308] User bc1qa6y279yprwtuthnw0xqu6rzhrf8d6uujcdh9xd:{"hashrate1m": "82.6T", "hashrate5m": "93.8T", "hashrate1hr": "102T", "hashrate1d": "57.4T", "hashrate7d": "57.9T", "shares": 76761530792, "authorised": 1735251121}
[2025-03-21 04:31:01.308] Worker bc1qa6y279yprwtuthnw0xqu6rzhrf8d6uujcdh9xd.S19k:{"hashrate1m": "80.8T", "hashrate5m": "86.3T", "hashrate1hr": "92.1T", "hashrate1d": "49T", "hashrate7d": "49.4T"}
[2025-03-21 04:31:01.308] Block solved after 104363805084 shares at 0.1% diff
[2025-03-21 04:31:01.278] BLOCK ACCEPTED!
[2025-03-21 04:31:01.308] Solved and confirmed block 888737 by bc1qa6y279yprwtuthnw0xqu6rzhrf8d6uujcdh9xd.S19k
[2025-03-21 04:31:01.308] User bc1qa6y279yprwtuthnw0xqu6rzhrf8d6uujcdh9xd:{"hashrate1m": "82.6T", "hashrate5m": "93.8T", "hashrate1hr": "102T", "hashrate1d": "57.4T", "hashrate7d": "57.9T", "shares": 76761530792, "authorised": 1735251121}
[2025-03-21 04:31:01.308] Worker bc1qa6y279yprwtuthnw0xqu6rzhrf8d6uujcdh9xd.S19k:{"hashrate1m": "80.8T", "hashrate5m": "86.3T", "hashrate1hr": "92.1T", "hashrate1d": "49T", "hashrate7d": "49.4T"}
[2025-03-21 04:31:01.308] Block solved after 104363805084 shares at 0.1% diff
That is great news. Thank you for the report. Apollo nodes can submit valid block solutions in time when solved. Congratulations. Whose next???
Congrats!
Re: Official FutureBit Apollo II/BTC Software/Image and Support thread
#881423 FutureBit block! Looks to be the same one that hit a block before, #867760 also it looks like they are mining with a lot of miners thru it. Hashrate (24h) 5.1 EH/s
So they did kind of a Bitcoin-block telethon where several miners pointed their hash to this guy's Apollo node and that's how they hit a block. Don't have the details, but it was mentioned on BitsBeTrippin youtube video just released on solo mining.
https://www.youtube.com/watch?v=ICZbOyuLHY0
Theres power in numbers and clearly it works. Ya know, one could suggest we build a telegram team. Donate our hash to one person and when someone hits the next person in line gets the hash... so on and so on. Its probably the only real way to compete with farms who hit every 10 mins.
Sounds like a good idea, but isn't going to work for many reasons.
Is there any mathematical or scientific logic that makes you claim such a statement? Hard or difficult yes, however what took place last week proves it can work. Hard none the less. I didnt suggest it was easy or simple. However the theory has been proven to work not once but twice by the same person.
Simply put, look at how many Apollo's have been sold and how many have hit a block? (zero other than the one that had a lot of outside hash thrown at it) Grouping all the Apollo's together will not change that, and with odds of hundred or thousands of years of hitting one block, who gets the first one? Who gets to pick that first person, and how many would stick it out knowing they are mining for someone else for years? Then what is to keep everyone mining together after 5-10-25 years and not hitting anything? No way would it all stay together as a group. You're trying to structure a pool with it all going to one person, and not enough years for everyone in the group to be that person.
I have hit 2 blocks since 2013 mining on pools, my first was on Slush and then on another pool, both times I only got my % like everyone else mining on the pool. If I wasn't doing so good on my daily pay I would have tried solo and wish I had. Today is so much different than back then. I have also been in small groups of 10 that rented hash and got lucky to hit a couple blocks, about 7-8 years ago, but just did some more a few months back and didn't hit anything.
Re: Official FutureBit Apollo II/BTC Software/Image and Support thread
#881423 FutureBit block! Looks to be the same one that hit a block before, #867760 also it looks like they are mining with a lot of miners thru it. Hashrate (24h) 5.1 EH/s
So they did kind of a Bitcoin-block telethon where several miners pointed their hash to this guy's Apollo node and that's how they hit a block. Don't have the details, but it was mentioned on BitsBeTrippin youtube video just released on solo mining.
https://www.youtube.com/watch?v=ICZbOyuLHY0
Theres power in numbers and clearly it works. Ya know, one could suggest we build a telegram team. Donate our hash to one person and when someone hits the next person in line gets the hash... so on and so on. Its probably the only real way to compete with farms who hit every 10 mins.
Sounds like a good idea, but isn't going to work for many reasons.
Re: Official FutureBit Apollo II/BTC Software/Image and Support thread
Cleaning dust off the APOLLO II.
It's been 3 months since I received my Apollo II. I have mine turned sideways for better airflow through the bottom, which it does. The top vents are clogged from dust accumulation. I suspect that would get worse faster if I had the top vents pointed up.
Shut down my node, got the Air compressor blower and blew the dust back out. Lots of fine dust was blown out the top and bottom. No noticeable cooling difference. I thought there might be but the unit seems to be cooling well even with a small coating of dust. Now good for another 3 months.
running a fresh flash of v2.0.6 does seem more stable than v2.0.6 as long as I don't load up a bunch of other stuff In the browser. And don't try to restore saved settings as this wipes the settings installed in v.2.0.6. When I did this my node became less stable with the settings I saved from v.2.0.5 includes reverting back to 32 node connections. On v2.0.5 when I upped the nodes to 64 the system would crash. Not under v2.0.6.
It's been 3 months since I received my Apollo II. I have mine turned sideways for better airflow through the bottom, which it does. The top vents are clogged from dust accumulation. I suspect that would get worse faster if I had the top vents pointed up.
Shut down my node, got the Air compressor blower and blew the dust back out. Lots of fine dust was blown out the top and bottom. No noticeable cooling difference. I thought there might be but the unit seems to be cooling well even with a small coating of dust. Now good for another 3 months.
running a fresh flash of v2.0.6 does seem more stable than v2.0.6 as long as I don't load up a bunch of other stuff In the browser. And don't try to restore saved settings as this wipes the settings installed in v.2.0.6. When I did this my node became less stable with the settings I saved from v.2.0.5 includes reverting back to 32 node connections. On v2.0.5 when I upped the nodes to 64 the system would crash. Not under v2.0.6.
I also have mine on its side with the large vent and switch pointed up, also sitting on top of a laptop cooler. I notice a few days ago the dust on the top vents and used my vacuum to suck it away. I am still using v.2.0.5 and I have set mine to 64 node connection without a problem. It will bounce between 63-64.
Re: Official FutureBit Apollo II/BTC Software/Image and Support thread
I have a question, is it possible to have a miner solo mine to my node that is not on my local network?
I have ddns setup on my router and port forwarding setup for port 3333
The issue I see right now is when I check if port 3333 is open, it said it’s closed.
I have friends who have miners, we all want to point our miners to a single solo node
Is that even possible?
I have ddns setup on my router and port forwarding setup for port 3333
The issue I see right now is when I check if port 3333 is open, it said it’s closed.
I have friends who have miners, we all want to point our miners to a single solo node
Is that even possible?
Yes it should be if your router/firewall is set to allow it. But I think that is why we use 8333 port forward is it allows the other nodes to connect to our node?
Re: Official FutureBit Apollo II/BTC Software/Image and Support thread
Basically in simple terms, think you're playing the lotto and buy one ticket. You have a chance of winning with just one ticket, but your odds are very low, and they increase if you play with more tickets. (the big mining pools and farms are playing with millions of tickets).
So the number of Best Shares that Apollo shows contains only the Best Shares for my latest attempt (last 10 min) or ALL historical Best Shares since I started mining?Now think if they pull the winning numbers first, ( the difference is instead of only 6 numbers the numbers are thousands) and we need to buy random tickets looking for the right combination of numbers before anybody else does. Your one ticket hits 1 number, not enough to win, but that is your best ticket, now you buy another, and you hit 3 numbers, this is still not enough to win, but this is your new best. Every new block @10 mins is a new lotto drawing, your old best number from another block means nothing toward the new block other than a way to show how close you had come to winning. The lower your hash rate is like only buying one ticket compared to the mega farms/pool buying millions of tickets every 10 minutes or for every new block.
When Apollo shows 13B Best Shares, does it mean that I managed to pull 13B winning tickets, that I managed to FIND a Valid Block at the current network difficulty level BUT did it too late?The winning combination is @the new difficulty number (the winning lotto numbers). Now it's set up to average a block/winner every 10 mins, so if there is a winner faster the difficulty amount of numbers increase to make it harder to find the right numbers and if it goes longer than 10 min the difficulty amount of numbers goes down.
This is clear.When Apollo shows 13B Best Shares, does it mean that I managed to pull 13B winning tickets, that I managed to FIND a Valid Block at the current network difficulty level BUT did it too late?
NO its more like you matched 13 Billion of the 103 Trillion numbers needed to win.
Re: Official FutureBit Apollo II/BTC Software/Image and Support thread
BestShare=Network Difficulty=90-100T=Block
Thank you for your reply, but honeslty that equation is not clear to me.Does it mean my best share number should be between 90 and 100T to have a chance to find a valid block?
And what is the maximum Best Share number that a single Apollo II Full Node Miner can achieve?
Basically in simple terms, think you're playing the lotto and buy one ticket. You have a chance of winning with just one ticket, but your odds are very low, and they increase if you play with more tickets. (the big mining pools and farms are playing with millions of tickets).
Now think if they pull the winning numbers first, and we need to buy random tickets looking for the right combination of numbers before anybody else does. Your one ticket hits 1 number, not enough to win, but that is your best ticket, now you buy another, and you hit 3 numbers, this is still not enough to win, but this is your new best. Every new block @10 mins is a new lotto drawing, your old best number from another block means nothing toward the new block other than a way to show how close you came. The lower your hash rate is like only buying a ticket maybe once a day or month compared to the mega farms/pool buying millions of tickets every 10 minutes or for every block.
Re: Official FutureBit Apollo II/BTC Software/Image and Support thread
I never saw that e-mail. my experience is the CPU/system temp is fine. System temp doesn't go above 70. Fan does increase on its own. without the miner running. Airflow is the key to cooling and those bottom vents and spacing in original design don't give enough airflow trapping heat causing fan to run faster. All dust falling to the tabletop get sucked into those vents. To lay flat there needs to be at least 1" of space below apollo to allow for proper airflow volume as fan speed increases. The top vents would have to be double the width. Fan speed and sound is always my key indicator to how efficient a system is running. Faster fans means higher temps needing more airflow. In this case constricted airflow needs higher fan speeds.
When my miner is running system temp is 43C with cpu idle and miner at 68-70C. 3600RPM. This higher fan speed seems to cool the cpu fine. Laying the apollo flat in eco mode works fine and the fan speed is quiet enough.
RE running miner outside. Other than ambient humidity and environment. I think the Miner should run fine in turbo mode and keep the miners cool. Fan speed is key. You need faster fan speeds to move the air to cool the miners. For longevity of the miner processor i think those temps should stay below 75C. With antminers those fans would keep the miner temp between 60 and 70C. I ran antminers outside in the garage and they ran great with temps below 60F. Lower fan speeds keeping system cool. Running these fans at full speed helps move maximum airflow but does put stress on those fans causing higher risk of failure. Running at 3600RPM/half speed and the fans can last a long time with very low risk of failure. Always listen to the sounds your fans are making.
Case Study: I just turned my apollo down, lay flat running in balanced mode. Temp increase to 72-74C on the miner. Fan increase 4000 to 4500RPM. No change in system temp 43C. So that email suggestion is a big fail on my apollo II. Dust is building up on top slots after 2 months of running so will need to be blown clean soon. Bottom slots on the side operation seem to be clean and cool. Isn't the bottom where the raspberry pi CPU is located?
I agree mine acts the same way as yours. Even the case runs cooler sideways with the heatsink pointed up.
I copied the part of the email they sent out about placing it sideways ( my first thought was your post):
Running your Apollo II in Balanced or Turbo mode requires more airflow over the top slots to keep the power supply cooled with our passive airflow technology.
The Apollo II is designed to be run on a flat surface that restricts the amount of airflow that goes in through the bottom vs top this means:
1) DO NOT place your unit sideways. While this might reduce fan RPMs slightly it will cause your power supply to over heat due to not enough airflow through the top. This is also the case for shelves that have wire mesh or not a flat solid surface
Re: Official FutureBit Apollo II/BTC Software/Image and Support thread
Hello, is there a recommended max Temperature for the Apollo 2 full node and miners that is a healthy steady temp for long-term use? Asking because I'd like to try to maintain BALANCED mode as much as possible, but if the indoor temp increases, I would just reduce it to ECO until indoor temp drops again.
Check out the post from jstefanop on August 16, 2024- #2397 https://bitcointalk.org/index.php?topic=5340015.msg64433384#msg64433384
He addresses some heat limits there.
Cheers!
Thanks, I did see this, I'm also wondering if there is a recommended temp range per mode (ECO, BALANCED, etc.), not just a max of 80c. I'm trying to maximize the lifespan and not just try to stay under the max.
jstefanop, any thoughts?
Turbo mode works, but then it sounds like an antminer with turbo fan.
3600RPM is ok. 3800RPM is a little loud and happens when ambient temp increases above 78F. Check and blow dust out every 2 / 3 months. The fan speed would also indicate this when it increases unexpectedly at lower temps. Listen to your fan as a heartbeat telling you how your miner is doing.
I haven't been able to leave my apollo II alone for extended periods. My unit is still not stable enough. I've had occasional power brownout surge knock my apollo offline and shut down running high speed fan. No remote reset or monitoring beyond the firewall for me. It can run 7 days non-stop with no issues then the node crashes after only 1 or 2 days of a reboot.
v2.0.6 didn't work for me. Apollo would freeze. Crashed more often than v2.0.5. Still running v2.0.5 stable.
eagleye did you get the email from FutureBit telling us not to run them on their side? My temps are defiantly lower on its side but they say it could not properly cool the psu.
Re: Official FutureBit Apollo II/BTC Software/Image and Support thread
I just rebooted the node and everything is up and running on v2.0.5. I'll stay here since my node has been running well and I don't want to fix whats not yet broken on the node until these update bugs are fixed. I don't want to have to go through reflashing a good memory card.
That is my thoughts as well. I am mining with 2 other miners using the node as well, all 3 using diff wallets and no problems. So no reason to chance updating it.
Re: Official FutureBit Apollo II/BTC Software/Image and Support thread
New release is finally out...apologize once again for this being over a month late but this should have squashed a large number of bugs and should be super stable before we start working on a big 2.1 feature release.
As always if you do an OTA update please wait at least half an hour or simply close the tab out and start a new one and wait for the UI to come up (if UI shows 0% update has finishes and you can refresh)
2.1 will also include a new update mechanism that will eliminate update failure and make process way smoother
Apollo OS v2.0.6 - 11/26/24
https://github.com/jstefanop/apolloapi-v2/releases/tag/v2.0.6
New Changes in v2.0.6:
- Redesigned Solo Miner Page making it easy to keep track of multiple miners/wallets mining on the solo pool! Stats are organized by individual wallet addresses, and each wallet address can have multiple workers (ie address.worker1 address.worker2 etc).
- Node connection count has been upped to 64 connections by default for more robust peering especially during solo mining
- Pesky 32bit and graphQL errors have finally been squashed...small number of users that were affected by this should not see this again
- UI improvements, especially for small format screens and mobile UI
- Improved reliability of node startup during boot, which should reduce "Connection Refused" Node errors for some users
- Multiple UI bug fixes, and backend improvements
As always if you do an OTA update please wait at least half an hour or simply close the tab out and start a new one and wait for the UI to come up (if UI shows 0% update has finishes and you can refresh)
2.1 will also include a new update mechanism that will eliminate update failure and make process way smoother
Apollo OS v2.0.6 - 11/26/24
https://github.com/jstefanop/apolloapi-v2/releases/tag/v2.0.6
New Changes in v2.0.6:
- Redesigned Solo Miner Page making it easy to keep track of multiple miners/wallets mining on the solo pool! Stats are organized by individual wallet addresses, and each wallet address can have multiple workers (ie address.worker1 address.worker2 etc).
- Node connection count has been upped to 64 connections by default for more robust peering especially during solo mining
- Pesky 32bit and graphQL errors have finally been squashed...small number of users that were affected by this should not see this again
- UI improvements, especially for small format screens and mobile UI
- Improved reliability of node startup during boot, which should reduce "Connection Refused" Node errors for some users
- Multiple UI bug fixes, and backend improvements
For us having no issues running v2.0.05 is there any reason to update to v2.0.6 and just wait for v2.1 ?
Re: Official FutureBit Apollo II/BTC Software/Image and Support thread
Hi, I have an Apollo 2 (both node and standard miners) and I’m also getting a BitAxe. Question, if I want to connect the BitAxe to my Apollo 2s, would it properly allocate work to the BitAxe? Meaning, I wouldn’t want the BitAxe to repeat hashing the same hashes as the Apollo 2 miners but add additional (unique) hash rate. Is this automatically managed by the Apollo or are there settings to ensure there is no duplicate hashing?
The way I understand it is, all miners are working to solve the same next block, and it's more of a race to see you cracks it first. There are some advantages some have, a few are due to internet connections and some pools/miners are thought to hold back, so they can start on the next one before anybody else. I tend to think this is a possibility when you see a pool/large miner hit 2 blocks minutes apart.
I should have clarified that I am SOLO mining. I am just wondering whether hooking up a different miner (from a different manufacturer like BitAxe) to the Apollo 2 node/miners will result in a proper distribution of work assigned to each of the Apollo and non-Apollo miners. I want to make sure that the BitAxe doesn't replicate the same hashes as the Apollo miners but hashes on a different set of nonces (or extra nonces).
@jstefanop, can you please confirm?
I have 2 Avalon Nano3 miners mining thru my Apollo and so far the Avalon's have hit higher best shares, they are all mining independently of each other.
Re: Official FutureBit Apollo II/BTC Software/Image and Support thread
Hi, I have an Apollo 2 (both node and standard miners) and I’m also getting a BitAxe. Question, if I want to connect the BitAxe to my Apollo 2s, would it properly allocate work to the BitAxe? Meaning, I wouldn’t want the BitAxe to repeat hashing the same hashes as the Apollo 2 miners but add additional (unique) hash rate. Is this automatically managed by the Apollo or are there settings to ensure there is no duplicate hashing?
The way I understand it is, all miners are working to solve the same next block, and it's more of a race to see you cracks it first. There are some advantages some have, a few are due to internet connections and some pools/miners are thought to hold back, so they can start on the next one before anybody else. I tend to think this is a possibility when you see a pool/large miner hit 2 blocks minutes apart.
Re: Official FutureBit Apollo II/BTC Software/Image and Support thread
Basically, you have three options:
1) Wait. It will eventually get to 32, but for how long is anybody's guess. Maybe a minute, maybe more, maybe less.
2) Increase your Max Connections if you want more than 31/32. However, I've seen that it will just as often stay one under even then: 37/38 - 41/42, etc.
3) Go to https://bitnodes.io/ and find some juicy nodes to add to your list using the addnode=IPADDRESS:8333 command. I've found this will usually max out my connection choice: 32/32 - 42/42, etc.
Cheers!
Thank you for response. However, I am ok with the number of outgoing connection. My issue is that there is NO incomming connections, so the numer 32 is grayed out. How can I make sure that I there are incoming connections?1) Wait. It will eventually get to 32, but for how long is anybody's guess. Maybe a minute, maybe more, maybe less.
2) Increase your Max Connections if you want more than 31/32. However, I've seen that it will just as often stay one under even then: 37/38 - 41/42, etc.
3) Go to https://bitnodes.io/ and find some juicy nodes to add to your list using the addnode=IPADDRESS:8333 command. I've found this will usually max out my connection choice: 32/32 - 42/42, etc.
Cheers!
I believed your mistaken as mine is greyed out, but the second number is just your maxed amount of connections you will make. You can look up your node on bitnodes.io using your IP but if your 32/32 then it will show unreachable because your already max at 32 connections with other nodes, check it again if you drop below 32 (31/32) and it should show reachable then.
Re: Official FutureBit Apollo II/BTC Software/Image and Support thread
Well, silly me. I didn't know you could purchase directly from FutureBit so I bought an Apollo II 1TB from BitCoinMerch.
Sam from BitCoinMerch just informed me that there is nothing they will do about my ded Apollo II because it's 3 days out of their 30-day warranty. Yes, 3 days. Delivered on Oct 15, went ded on Nov 17.
So word to the wise, think twice before buying from a place like BitCoinMerch that only offers a 30-day warranty.
I'm hoping for mercy from FutureBit. I filled out their support form yesterday, but last time I did that (to ask a setup clarification), it took them 7-days to respond.
If FutureBit won't help me, I'm out ~ $1200 and now have a stylish paper weight.
In the meantime, BitCoinMerch won't be getting any more of my business.
Sam from BitCoinMerch just informed me that there is nothing they will do about my ded Apollo II because it's 3 days out of their 30-day warranty. Yes, 3 days. Delivered on Oct 15, went ded on Nov 17.
So word to the wise, think twice before buying from a place like BitCoinMerch that only offers a 30-day warranty.
I'm hoping for mercy from FutureBit. I filled out their support form yesterday, but last time I did that (to ask a setup clarification), it took them 7-days to respond.
If FutureBit won't help me, I'm out ~ $1200 and now have a stylish paper weight.
In the meantime, BitCoinMerch won't be getting any more of my business.
Did you buy it with a credit card? If so file a claim against BitCoinMerch.
If FutureBit is no help a VO meter is your best friend to check the PSU and the switch which was mentioned to be a problem.
Re: Official FutureBit Apollo II/BTC Software/Image and Support thread
Well, less than 30 days and this POS is ded. WTF? Apollo II, 1 TB. Came home and it was off. Won't power back on. Unplugged, let it sit, plugged it back in, nothing. Any ideas?
I wonder if the PSU went out?
Re: Official FutureBit Apollo II/BTC Software/Image and Support thread
@ Any Apollo II Gurus,
I have a question about what should have been a simple configuration but it stumped me nonetheless . . .
Background:
I have 9 Apollo II units, 3 of which are full node units, and 6 of which are standard units. Of the 3 full node units, I've attached 2 standard hashing units to each of the full node units. That makes 9 total. I've been running one full node unit as a SOLO node with 2 standard hashing units attached with no problems. The other two full node units with 2 attached hashing units each have been running on an "outside pool" with no problems. However, I decided to change things up and now here's where I encountered an odd issue . . . stay with me . . .
Issue:
I decided to point all of my Apollo II units to my single Apollo SOLO node and keep some other non-Apollo equipment on pool mining. BTW, everything in on LAN network, including all the Apollo's. However, when I enter the IP address (192.xxx.x.x:3333 & Username: <bitcoin address>) of the Solo Node unit into the Apollo II units that I previously had pool mining I get an error stating "invalid pool url" as if the IP entry is of the wrong nomenclature. I noticed there is no delay in the error as if the IP address was never even considered and more like an IP address can't be accepted from one Apollo to another in the interface field. So, just for fun I tested out several of my non-Apollo units and pointed them to the same Apollo SOLO node without issue using just the IP and wallet address. I also reverse tested the other 2 Apollo II full node units to act as the single SOLO node and the exact same problem occurs with the other Apollos when using just an IP and wallet address. However, I did find a workaround (I think) but that still leaves me with more questions than answers . . .
Workaround:
I eventually tried using "stratum+tcp://192.xxx.x.x:3333" in the required pool url field for the other 2 sets (2x node & 4 standard) of the Apollo II units even though all these units are on the LAN network. And it seems to work. What gives? Another FYI, I'm using headless connections via browsers - if that makes any difference. Anyway, I've never had to enter "stratum+tcp://..." on any non-Apollo units on my network to get the Apollo II SOLO NODE to recognize them, so this is confusing as it only occurs between Apollos. Any thoughts?
Lastly:
All the Apollo II units now show up as a "total" of 9 workers using the "stratum+tcp://192.xxx.x.x:3333" in the pool url field but they are not listed under the "SOLO Mining Users" category on the actual SOLO node miner even though they have ".workername" appended to the BC address. Only the combined hashboards from the solo unit are displayed. Thoughts?
Closing:
I am on v2.0.5 on all node machines. I am using headless w/browsers. All 3 nodes machines have good & high quality 16GB MicroSD cards and up-to-date 2TB NVME node cards. So, all's good under the hood there. Thoughts? Maybe a bug?
Cheers!
I have a question about what should have been a simple configuration but it stumped me nonetheless . . .
Background:
I have 9 Apollo II units, 3 of which are full node units, and 6 of which are standard units. Of the 3 full node units, I've attached 2 standard hashing units to each of the full node units. That makes 9 total. I've been running one full node unit as a SOLO node with 2 standard hashing units attached with no problems. The other two full node units with 2 attached hashing units each have been running on an "outside pool" with no problems. However, I decided to change things up and now here's where I encountered an odd issue . . . stay with me . . .
Issue:
I decided to point all of my Apollo II units to my single Apollo SOLO node and keep some other non-Apollo equipment on pool mining. BTW, everything in on LAN network, including all the Apollo's. However, when I enter the IP address (192.xxx.x.x:3333 & Username: <bitcoin address>) of the Solo Node unit into the Apollo II units that I previously had pool mining I get an error stating "invalid pool url" as if the IP entry is of the wrong nomenclature. I noticed there is no delay in the error as if the IP address was never even considered and more like an IP address can't be accepted from one Apollo to another in the interface field. So, just for fun I tested out several of my non-Apollo units and pointed them to the same Apollo SOLO node without issue using just the IP and wallet address. I also reverse tested the other 2 Apollo II full node units to act as the single SOLO node and the exact same problem occurs with the other Apollos when using just an IP and wallet address. However, I did find a workaround (I think) but that still leaves me with more questions than answers . . .
Workaround:
I eventually tried using "stratum+tcp://192.xxx.x.x:3333" in the required pool url field for the other 2 sets (2x node & 4 standard) of the Apollo II units even though all these units are on the LAN network. And it seems to work. What gives? Another FYI, I'm using headless connections via browsers - if that makes any difference. Anyway, I've never had to enter "stratum+tcp://..." on any non-Apollo units on my network to get the Apollo II SOLO NODE to recognize them, so this is confusing as it only occurs between Apollos. Any thoughts?
Lastly:
All the Apollo II units now show up as a "total" of 9 workers using the "stratum+tcp://192.xxx.x.x:3333" in the pool url field but they are not listed under the "SOLO Mining Users" category on the actual SOLO node miner even though they have ".workername" appended to the BC address. Only the combined hashboards from the solo unit are displayed. Thoughts?
Closing:
I am on v2.0.5 on all node machines. I am using headless w/browsers. All 3 nodes machines have good & high quality 16GB MicroSD cards and up-to-date 2TB NVME node cards. So, all's good under the hood there. Thoughts? Maybe a bug?
Cheers!
Has anyone come up with any ideas on the above issues? How about you jstefanop? Am I overlooking something simple?
Cheers!
Re: Official FutureBit Apollo II/BTC Software/Image and Support thread
RE: stuck blocks
Have you checked your debug.log in the bitcoin directory and are there error messages or is it finding and counting blocks? There is a real time counter of events in UTC that should have reports at least every 30 seconds.
is your bitcoind daemon running If its not then it crashed for some reason.
RE : crashing node
My experience from receipt of an apollo II is to make sure you have a fresh formatted pcie memory card. Once the node gets running close all non essential browsers and stop mining. They say you can mine in eco mode but I had more bitcoind crashes with the miner running than not.
I also replaced the microsd supplied with a new card and flashed The supplied microsd card seemed to be less stable than a new faster card
The flaw is the raspberry PI base that this system is built on from research in other forums on the rapsberry pi running nodes. The system is very sensitive.
I monitor the node remotely as it only requests core data that does not load the CPU and memory of the raspberry PI.
the IBD(Initial Blockchain Download) consumes a lot of CPU usage and the bitcoind is sensitive to timing and other apps consuming memory or processor time seems to crash the bitcoind program more often in my case.
Once the IDB is complete(make a backup of your bitcoin database to a second drive), my node v2.0.5 is rather stable and solo mining in normal mode works fine.
Also, heat, i turn my apollo sideways hdmi pointed up. for better airflow and my fan speed drops. It needs a regulated ups. any types of power surges in the electric line can crash the node. If that happens it can crash the database in a possible write event.
pay attention to the debug.log after any system pause. That's your key to what happened. Sometimes when it just drops off you can just restart the node and it continues as expected. If you stop the node half way through IDB and you get a successful stop on the node in the log with no errors you could backup the database to an external usb to pcie memory card to save a point in the download.
every 2 weeks i am backing up my node database to my 2nd drive. you have to stop the node and miner before backing up the data.
Have you checked your debug.log in the bitcoin directory and are there error messages or is it finding and counting blocks? There is a real time counter of events in UTC that should have reports at least every 30 seconds.
is your bitcoind daemon running If its not then it crashed for some reason.
RE : crashing node
My experience from receipt of an apollo II is to make sure you have a fresh formatted pcie memory card. Once the node gets running close all non essential browsers and stop mining. They say you can mine in eco mode but I had more bitcoind crashes with the miner running than not.
I also replaced the microsd supplied with a new card and flashed The supplied microsd card seemed to be less stable than a new faster card
The flaw is the raspberry PI base that this system is built on from research in other forums on the rapsberry pi running nodes. The system is very sensitive.
I monitor the node remotely as it only requests core data that does not load the CPU and memory of the raspberry PI.
the IBD(Initial Blockchain Download) consumes a lot of CPU usage and the bitcoind is sensitive to timing and other apps consuming memory or processor time seems to crash the bitcoind program more often in my case.
Once the IDB is complete(make a backup of your bitcoin database to a second drive), my node v2.0.5 is rather stable and solo mining in normal mode works fine.
Also, heat, i turn my apollo sideways hdmi pointed up. for better airflow and my fan speed drops. It needs a regulated ups. any types of power surges in the electric line can crash the node. If that happens it can crash the database in a possible write event.
pay attention to the debug.log after any system pause. That's your key to what happened. Sometimes when it just drops off you can just restart the node and it continues as expected. If you stop the node half way through IDB and you get a successful stop on the node in the log with no errors you could backup the database to an external usb to pcie memory card to save a point in the download.
every 2 weeks i am backing up my node database to my 2nd drive. you have to stop the node and miner before backing up the data.
Placed mine it side and temp dropped 2-3 degrees. I guess by blowing the hot air up there is less of a chance for it to get drawn back in. Thanks for the tip!