BrokenTractor
Newbie
Offline
Activity: 11
Merit: 0
|
 |
November 19, 2024, 09:33:33 PM |
|
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? The default Outbound connections a Bitcoin Core node will make is 10, sometimes 11. This is hard coded into the application. You can force it a little higher with the addnodes command. All the rest of the connections you have are Inbound connections. 31/32 means you have 10 Outbound and 21 Inbound connections.
|
|
|
|
PennyBit
Jr. Member
Offline
Activity: 104
Merit: 8
|
 |
November 19, 2024, 10:10:19 PM Last edit: November 19, 2024, 10:24:16 PM by PennyBit |
|
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? You can always check your own node as being available and reachable to other nodes on the network by going to the website I gave you: https://bitnodes.io/With regards to the right-hand-side number being grayed out, it is just a reference displaying how many nodes you have chosen as a maximum. It doesn't change unless you change the maximum and it will always be grayed out. It's just for looking at and smiling. Cheers!
|
|
|
|
PennyBit
Jr. Member
Offline
Activity: 104
Merit: 8
|
 |
November 19, 2024, 10:12:52 PM |
|
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? The default Outbound connections a Bitcoin Core node will make is 10, sometimes 11. This is hard coded into the application. You can force it a little higher with the addnodes command. All the rest of the connections you have are Inbound connections. 31/32 means you have 10 Outbound and 21 Inbound connections. Thanks for that information. Good to know. Cheers!
|
|
|
|
MakerAZ
Jr. Member
Offline
Activity: 46
Merit: 5
|
 |
November 20, 2024, 03:02:46 AM |
|
The default Outbound connections a Bitcoin Core node will make is 10, sometimes 11. This is hard coded into the application. You can force it a little higher with the addnodes command. All the rest of the connections you have are Inbound connections. 31/32 means you have 10 Outbound and 21 Inbound connections.
This is great! Thank you so much!
|
|
|
|
eagleye
Jr. Member
Offline
Activity: 114
Merit: 1
|
 |
November 20, 2024, 02:08:40 PM |
|
Your node connections constantly change as they can get stale. Check out the debug.log in the bitcoin directory. It will show you your connections. You will see block only connections and full node connections. There is also a count of the connections made while your node has been live that shows over a day or two it can make hundreds of new connections. This is more decentralized as it doesn't rely upon a single node connection for a long period of time to verify data.
|
|
|
|
LeoFist
Newbie
Offline
Activity: 15
Merit: 0
|
 |
November 21, 2024, 12:50:16 AM |
|
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?
|
|
|
|
aurel57
Legendary
Offline
Activity: 1344
Merit: 1001
|
 |
November 21, 2024, 02:55:11 AM |
|
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.
|
|
|
|
LeoFist
Newbie
Offline
Activity: 15
Merit: 0
|
 |
November 21, 2024, 09:26:29 PM |
|
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?
|
|
|
|
MegatronOHMICAVT
Newbie
Offline
Activity: 7
Merit: 0
|
 |
November 21, 2024, 09:36:57 PM |
|
You need to format the new 2TB drive with the format command in settings. Don't format your old data drive. Just to make sure all is good. I did that with my new drive. Then if you have a usb to pcie adapter, copy your 1TB drive to your new 2TB drive. takes about 45 mins. then shutdown, swap and reboot and it should work fine. THat's my experience. Keep the 1TB as a backup. That's what I have.
I did the reindex-chainstate , took longer. I found it to slow down the process on the raspberry pi. The raspberry cpu isn't fast enough for reindex-chainstate. Also lack of ram slows the process. Seems to actually be quicker to start an IBD after a formatted drive and it is quicker. However, I highly recommend a backup like above. Once my IBD was complete I copied the drive for a backup. I also would backup the nvme drive mid IBD download when I was having problems with the raspberry pi crashing mid download. That made recovery quicker in future crashes. My hardest part was the IBD. Once done my system is now running much better.
I have low trust in the reliability of the included microsd card. The original is possibly a much older 16GB microsd. I purchased a new one cheap and with much higher bandwidth and more memory, Cheapest one I could find. I flashed it and find it more stable than the included card was.
An unexpected issue occurring upon system startup. The NVME SSD is not mounting. It's not detected in Disks, or GParted, or command line prompts like -lsblk. The node will start upon -reindex with the data-dir at /media/nvme/bitcoin, but that data is existing on the SD card. The NVME SSD remains unreachable. Might this be something to address in BIOS settings? The SSD itself is in working order and will mount via USB in another Ubuntu laptop.
|
|
|
|
aurel57
Legendary
Offline
Activity: 1344
Merit: 1001
|
 |
November 22, 2024, 02:17:39 AM |
|
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.
|
|
|
|
bubbAJoe
Newbie
Offline
Activity: 105
Merit: 0
|
 |
November 22, 2024, 02:24:50 AM |
|
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?
There was a batch of miners with a bad power switch. You might need to flip/jiggle it to get it to work. I actually opened my unit up and bypassed the switch, so it feeds power directly from the plug into the PSU. But they'll replace the switch if you send it back. Still waiting to hear from Futurebit to see if they will warranty my unit. I don't want to open it up before I hear from them, but what are the steps to get to the switch?
|
|
|
|
eagleye
Jr. Member
Offline
Activity: 114
Merit: 1
|
 |
November 22, 2024, 08:34:54 PM |
|
You need to format the new 2TB drive with the format command in settings. Don't format your old data drive. Just to make sure all is good. I did that with my new drive. Then if you have a usb to pcie adapter, copy your 1TB drive to your new 2TB drive. takes about 45 mins. then shutdown, swap and reboot and it should work fine. THat's my experience. Keep the 1TB as a backup. That's what I have.
I did the reindex-chainstate , took longer. I found it to slow down the process on the raspberry pi. The raspberry cpu isn't fast enough for reindex-chainstate. Also lack of ram slows the process. Seems to actually be quicker to start an IBD after a formatted drive and it is quicker. However, I highly recommend a backup like above. Once my IBD was complete I copied the drive for a backup. I also would backup the nvme drive mid IBD download when I was having problems with the raspberry pi crashing mid download. That made recovery quicker in future crashes. My hardest part was the IBD. Once done my system is now running much better.
I have low trust in the reliability of the included microsd card. The original is possibly a much older 16GB microsd. I purchased a new one cheap and with much higher bandwidth and more memory, Cheapest one I could find. I flashed it and find it more stable than the included card was.
An unexpected issue occurring upon system startup. The NVME SSD is not mounting. It's not detected in Disks, or GParted, or command line prompts like -lsblk. The node will start upon -reindex with the data-dir at /media/nvme/bitcoin, but that data is existing on the SD card. The NVME SSD remains unreachable. Might this be something to address in BIOS settings? The SSD itself is in working order and will mount via USB in another Ubuntu laptop. If you have access to media/nvme/Bitcoin, then you have access to your nvme drive, that is your nvme drive. You may have to reformat the nvme card within the Apollo GUI. Wait for the message, completed as it takes some time to format with no indicator its working on it. The microsd is the main drive for system files. Please clarify which drive you are talking about. SD card to me is microsd and no bitcoin data is stored there other than apollo program files. I had a corrupted chainstate file recently. My best solution was to delete the chainstate files, which is done by reindex-chainstate anyway, and copy the old chainstate files from my backup from a month ago. My database files were ok. the node updated the chainstate and caught up to the current blocks. I then backed up the nvme with the newest block set. my node and miner have been running non-stop for 7 days with no errors. RE: other miners The solo apolllo node is a pool miner. Apollo node bitcoind sends the information the other miners who request the data from the node. The miner within the apollo is a program like any othe miner requesting data from a pool it just so happens the pool is the apollo node itself. You can see this in the logs. just like any other pool on the bitcoin network, but it's your own private pool. Each miner has its own success rate. no prioirty or privilage. Each miner on your node will receive updated live transaction blocks used to mine the next successful block. The pool doesn't know what equipment is trying to connect. it will only see the difficulty of the miner that requests the data and adjust difficulty for performance. Success? I had a small futurebit moonlander running for over a year and it hit best shares upwards of 1 billion and once hit over 1 trillion(still not enough to solve a block).
|
|
|
|
jstefanop (OP)
Legendary
Offline
Activity: 2198
Merit: 1401
|
 |
November 23, 2024, 01:18:20 AM |
|
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?
There was a batch of miners with a bad power switch. You might need to flip/jiggle it to get it to work. I actually opened my unit up and bypassed the switch, so it feeds power directly from the plug into the PSU. But they'll replace the switch if you send it back. Still waiting to hear from Futurebit to see if they will warranty my unit. I don't want to open it up before I hear from them, but what are the steps to get to the switch? Of course we will warranty, all Apollo II units have at least 6 months of warranty left. If you have a bad switch we can either setup an RMA or send you the replacement if you feel like swapping it out yourself to save downtime. It's a pretty easy snap in module, but you need to cut off the tabs or take both top and bottom covers off to squeeze the old one through the case.
|
|
|
|
bubbAJoe
Newbie
Offline
Activity: 105
Merit: 0
|
 |
November 23, 2024, 02:13:56 AM |
|
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?
There was a batch of miners with a bad power switch. You might need to flip/jiggle it to get it to work. I actually opened my unit up and bypassed the switch, so it feeds power directly from the plug into the PSU. But they'll replace the switch if you send it back. Still waiting to hear from Futurebit to see if they will warranty my unit. I don't want to open it up before I hear from them, but what are the steps to get to the switch? Of course we will warranty, all Apollo II units have at least 6 months of warranty left. If you have a bad switch we can either setup an RMA or send you the replacement if you feel like swapping it out yourself to save downtime. It's a pretty easy snap in module, but you need to cut off the tabs or take both top and bottom covers off to squeeze the old one through the case. Thanks very much for the reply. I'm still waiting for your support team to reply to my support request (via your support page widget). I would like to replace the switch myself.
|
|
|
|
Poker8
Newbie
Offline
Activity: 10
Merit: 0
|
 |
November 23, 2024, 04:41:41 PM |
|
Two questions: Any eta on this error being fixed?
Logo Overview Miner SOLO Mining Node System Settings [GraphQL error]: Message: Int cannot represent non 32-bit signed integer value: 4193135690
Any good instructions on pointing my bitaxe to my Apollo2 solo node?
|
|
|
|
Sledge0001
|
 |
November 23, 2024, 05:55:36 PM |
|
Two questions: Any eta on this error being fixed?
Logo Overview Miner SOLO Mining Node System Settings [GraphQL error]: Message: Int cannot represent non 32-bit signed integer value: 4193135690
Any good instructions on pointing my bitaxe to my Apollo2 solo node?
Please see the ssh instructions on how to update below: 2.0.6 is finally merged on production and doing a public test before pushing to everyone next week If anyone wants to test ssh into your device (futurebit/password you set for your dashboard) and cd /opt/apolloapi/backend/
sudo ./update to manually force an update reminder can take up to 20 min to rebuild the system and it will auto reboot when finished. Close your UI tab and clear cache so your browser does not load the old version. Please shoot any build issue or bugs...this will definitely fix all the graphql errors small number of users have seen Sorry this took way longer than planned! Then all you need to do is point your bitaxe to the IP address listed at the top of your solomining page on your apollo... "SOLO LAN Mining Point any Bitcoin Miner on your local network to your Solo Pool with the following URL: x.x.x.x:3333 Username: <bitcoin address>" So your stratum URL in the BitAxe will be the IP address of your Apollo. Port will be 3333 stratum user will be your bitcoinaddress.workername Save the settings on your bitaxe and restart. And that should do it!
|
|
|
|
Poker8
Newbie
Offline
Activity: 10
Merit: 0
|
 |
November 23, 2024, 07:52:46 PM |
|
Two questions: Any eta on this error being fixed?
Logo Overview Miner SOLO Mining Node System Settings [GraphQL error]: Message: Int cannot represent non 32-bit signed integer value: 4193135690
Any good instructions on pointing my bitaxe to my Apollo2 solo node?
Please see the ssh instructions on how to update below: 2.0.6 is finally merged on production and doing a public test before pushing to everyone next week If anyone wants to test ssh into your device (futurebit/password you set for your dashboard) and cd /opt/apolloapi/backend/
sudo ./update to manually force an update reminder can take up to 20 min to rebuild the system and it will auto reboot when finished. Close your UI tab and clear cache so your browser does not load the old version. Please shoot any build issue or bugs...this will definitely fix all the graphql errors small number of users have seen Sorry this took way longer than planned! Then all you need to do is point your bitaxe to the IP address listed at the top of your solomining page on your apollo... "SOLO LAN Mining Point any Bitcoin Miner on your local network to your Solo Pool with the following URL: x.x.x.x:3333 Username: <bitcoin address>" So your stratum URL in the BitAxe will be the IP address of your Apollo. Port will be 3333 stratum user will be your bitcoinaddress.workername Save the settings on your bitaxe and restart. And that should do it! Thank you so very much!!
|
|
|
|
rayday11
|
 |
November 24, 2024, 10:15:00 AM |
|
2.0.6 is finally merged on production and doing a public test before pushing to everyone next week If anyone wants to test ssh into your device (futurebit/password you set for your dashboard) and cd /opt/apolloapi/backend/
sudo ./update to manually force an update reminder can take up to 20 min to rebuild the system and it will auto reboot when finished. Close your UI tab and clear cache so your browser does not load the old version. Please shoot any build issue or bugs...this will definitely fix all the graphql errors small number of users have seen Sorry this took way longer than planned! Do you have an idea of approximately when 2.06 will be ready for prime time?
|
|
|
|
MegatronOHMICAVT
Newbie
Offline
Activity: 7
Merit: 0
|
 |
November 24, 2024, 09:42:58 PM |
|
You need to format the new 2TB drive with the format command in settings. Don't format your old data drive. Just to make sure all is good. I did that with my new drive. Then if you have a usb to pcie adapter, copy your 1TB drive to your new 2TB drive. takes about 45 mins. then shutdown, swap and reboot and it should work fine. THat's my experience. Keep the 1TB as a backup. That's what I have.
I did the reindex-chainstate , took longer. I found it to slow down the process on the raspberry pi. The raspberry cpu isn't fast enough for reindex-chainstate. Also lack of ram slows the process. Seems to actually be quicker to start an IBD after a formatted drive and it is quicker. However, I highly recommend a backup like above. Once my IBD was complete I copied the drive for a backup. I also would backup the nvme drive mid IBD download when I was having problems with the raspberry pi crashing mid download. That made recovery quicker in future crashes. My hardest part was the IBD. Once done my system is now running much better.
I have low trust in the reliability of the included microsd card. The original is possibly a much older 16GB microsd. I purchased a new one cheap and with much higher bandwidth and more memory, Cheapest one I could find. I flashed it and find it more stable than the included card was.
An unexpected issue occurring upon system startup. The NVME SSD is not mounting. It's not detected in Disks, or GParted, or command line prompts like -lsblk. The node will start upon -reindex with the data-dir at /media/nvme/bitcoin, but that data is existing on the SD card. The NVME SSD remains unreachable. Might this be something to address in BIOS settings? The SSD itself is in working order and will mount via USB in another Ubuntu laptop. If you have access to media/nvme/Bitcoin, then you have access to your nvme drive, that is your nvme drive. You may have to reformat the nvme card within the Apollo GUI. Wait for the message, completed as it takes some time to format with no indicator its working on it. The microsd is the main drive for system files. Please clarify which drive you are talking about. SD card to me is microsd and no bitcoin data is stored there other than apollo program files. I had a corrupted chainstate file recently. My best solution was to delete the chainstate files, which is done by reindex-chainstate anyway, and copy the old chainstate files from my backup from a month ago. My database files were ok. the node updated the chainstate and caught up to the current blocks. I then backed up the nvme with the newest block set. my node and miner have been running non-stop for 7 days with no errors. The reformat option in the UI will give me the "success" message and states the node will restart. But it will not start and sync. The computer does not detect the NVME SSD at all it seems. To further explore this I restarted the system without any NVME connected at all. The machine restarts and when I pass the -reindex command, the location /media/nvme/bitcoin will populate with the correct default files and the node will start and begin to sync. With no SSD attached, I guess I conclude this is going onto the microSD. I've done this with the current Apollo OS and the original OS. With an adapter, the NVME SSD can be detected on the Apollo and on another linux laptop. Seems like it could be an internal NVME connector hardware problem in the Apollo. But if anything else comes to mind please advise.
|
|
|
|
jstefanop (OP)
Legendary
Offline
Activity: 2198
Merit: 1401
|
 |
November 25, 2024, 07:03:51 PM |
|
2.0.6 is finally merged on production and doing a public test before pushing to everyone next week If anyone wants to test ssh into your device (futurebit/password you set for your dashboard) and cd /opt/apolloapi/backend/
sudo ./update to manually force an update reminder can take up to 20 min to rebuild the system and it will auto reboot when finished. Close your UI tab and clear cache so your browser does not load the old version. Please shoot any build issue or bugs...this will definitely fix all the graphql errors small number of users have seen Sorry this took way longer than planned! Do you have an idea of approximately when 2.06 will be ready for prime time? Finishing the image build today before we push the update...want to make sure images are out in case of OTA update failures.
|
|
|
|
|