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

I'll get onto updating that now and will report back!

EDIT: Updated! Seems to be working fine. Version still reports as 2.0.5 though, not sure if that's intentional.

Here's a pastebin of the update log, there were a few warnings, not sure if that's standard behaviour but thought I'd post it anyway

https://pastebin.com/g0kXdFv8

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


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!

Yep work closely with con to keep ckpool updated and upstream changes are merged. Lots of these are bugs we find with our user base.

Just reply to your order email, if your switch is bad the whole assembly needs to be swapped out as damage is caused by overheating due to bad contact on the AC plug and that will damage other contacts on the back of the switch.

We are either swapping it out for you or can send you the whole socket assembly if you would rather swap it out yourself. It's not that complicated to swap it, but requires cutting off the tabs from the inside that hold the socket in so need to remove both the bottom and top covers.

I saw there are a number of Fixes in the CKPOOL code.  Not sure how many of them are included in current CKPOOL running on our boxes.
Is there any update from Futurebit regarding these?

ckolivas
d385b74
Fix potential memleak of shares in ckproxy generator code.
2024-08-04
ckolivas
51a9860
Use i64 for objects that may eventually overflow in generator code.
2024-07-02
ckolivas
d629c54
Share message ids should be i64.
2024-07-02
ckolivas
2683078
Free shares that get aged without being used in proxy.
2024-07-02
ckolivas
96bbb56
Make sure we always submit any possible block solve.
2024-04-26

My Apollo II review.  I use a 400 MBPS DL and 10MBPS upload. ethernet connection.  wireless off. No changes to router settings were needed

I received my Futurebit Apollo II relatively quickly after purchase.  I purchased without the 1TB NVME card. Bought my own memory card and chose a 1TB card with the fastest available read write memory.  Installed the card and on first boot the NVME card was correctly formatted.  However, there were some freezing issues with the system after boot and boot wasn't smooth.  Following information here I investigated the microsd card.  There is a piece of shipping tape on the microsd card to hold it in place.  While this tapes safely prevents the card from falling out during shipping, I think it interferes with proper seating of the microsd in the slot.  After removing and reinserting the card the boot was much better and much more stable.  I removed the tape.

IBD(Initial Blockchain Download) started and seemed to be running ok.  Then the random crash began.  This started a 2 week process in finding a way to stabilize the system.  I was solo mining on a pool in eco mode and from what it looks like that worked flawlessly.  However, I would have random system crashes, bitcoind exits and system freezeups.  I purchased a second 1TB nvme card as I now realize it does take a long time for initial download.  I also purchased a second microsd card, high performance, to flash with a fresh system program and as a backup.  I halted solo mining on a pool to remove that as any interference in downloading the IBD.  I would copy/backup the NVME card when I thought I had a stable chain IDB before a crash.

After researching the raspberry pi as a node operator, I realized there are some bugs with the initial download on a raspberry pi.  Many things to remember.  What drove me crazy is when you get 500 GB of data downloaded and then the system crashed.  database corruption.  I tried reindexing the database.  I can be done if you add a command to the node "reindex-chainstate=1"  This does work.  However, the system does slow down with the raspberry pi.  So, just formatting the NVME 1TB card seems to work best and start over may be faster.   I thought maybe I had internal RAM memory problems.  Eventually it came back to the microsd card and its seating in the slot.  I would eject the card and clean the connectors on the card, reinsert it and the system would seem to perform better and more stable.   I didn't need to reflash the card.  My microsd card problems were indicated by system crashes, open browser crashes and windows freezing in the attached monitor.  only turning off eject card and turn on would fix it.  When rebooting, the problem would remain.

One setting I added was "rpcworkqueue-48" seemed to keep IBD running and less crashing.  When I got up above 600K blocks I would have the occasional bitcoind crash and exit.  One of the most important things to look at is the debug.log in the Bitcoin folder.  I would look at that after bitciond would halt.  

The GUI for the Apollo II is pretty good but one feature that would be nice is a pullup window or ticker with the current status bitcoind output or log report of the log file.  This log information is valuable to look at like all the other data.  It could be a window holding a memory of 50 or 100 lines or more so the window could be scrolled to look at the log data for the last few events.  Maybe 5 or 10 lines would scroll as you have node screen or main monitor active. It would show the last events after a crash or exit.

Now after attempting to reindex, I cancelled that approach and started fresh.  reformatting the drive.  I set dbcache=1000 thinking some of the crashes were because the cache will fill up and was what the error message said.  After extensive raspberry pi group node reviews I realized this is not the issue. It is more an issue of the raspberry pi and linux system being clunky in handling cache memory and killing your bitcoind when bitcoin asks for more memory.  I also had problems of the apollo II browser would crash if I left the window open on the keyboard and mouse.  It would consume memory creating conflict.  So, while performing my IBD I would close all windows except performance monitor.  I would monitor the node remotely which minimized resources and was actually more stable.  I would get much longer downloads before something stopped.

Restarting the node after a crash during IBD seems to work best.

Now, I have the whole blockchain downloaded 5 days after a fresh start.  Solo mining has begun and the system is running very smooth.  The apollo resources are minimal cpu usage and the system seems stable.  More stable than initial blockchain download.  I like that I can connect multiple miners locally to solo mine pool on the node.  The solo mine GUI data is what I need and is valuable.

Once you get the IBD completed, I performed a backup onto my second NVME card.  I have a USB to NVME plug in and plugged it into the USB 3.0.  I carefully select the futurebit usb drive, delete the old bitcoin files there then copy the NVME drive complete blockchain to the USB NVME.  Copying is fast with no status indictor other than when it is complete.  I watch the system status which shows the two drives and space available.  Took about 45 minutes.  I also copy the Node backup configuration files to the NVME drive since if I have to reflash the microsd, then I have to restore the settings and they'll be available on the NVME.

I learned more researching running a node on a raspberry pi in the bitcoin forums.

I've upgraded to running balanced performance over ECO mode and the system is running better and the fan is surprisingly quiet at this level.  Temp is 64-66 on miner with 45 on main system.   I turned my system sideways with HDMI faced up.  i can see all the lights inside better for operation and fan runs cooler and slower.  Design flaw is not enough room under bottom when sitting normal flat.  The box needs to be raised another 1/4 to 1/2" to get better airflow on the underside.  Sitting sideways allows maximum airflow.

UPDATE: 10/22
2 days running a mining node and my system crashed/shutdown this morning.  Tried ejecting and reinserting the microsd card.  Didn't work.  Swapped out my microsd card for my backup card I purchased new.  System is back up and running.  The failed card is the one supplied with the Apollo II.  Maybe this older card is less reliable than newer memory cards.

UPDATE 2: 10/26
4 days running solo node mining after fix above and system was very stable.  No issues.  Then my system crashed/froze/exited/shutdown.  Was in high speed fan mode with lights off.  I recycled the power switch and system came back to life and back online after updating current blocks.  Checked logs and only showed an interruption as in a crash.  Normal recovery on boot. system running in balanced mode.

@RotorDriven
Your description sounds on the money for the problem I experienced. As far as an off-the-shelf replacement, that I can't say. However, once you tear into it you may void your warranty. Personally, I'd just send it in and get it fixed. Good luck.

Cheers!

It seems like my switch is failing, as well. It will mine for a couple of hours and shut down. Then when I barely touch the switch, it powers back on.

Rather than returning for repair, is the switch an off-the-shelf part I can replace myself?

This is a misconception propagated (no pun intended ) by those that dont want more solo miners involved or more pools in the mix and scare them off with incorrect information. 

If you are solo mining simply increase your connection count, be on ethernet, and have at least 10mbps upload. Bitcoin was designed to run on systems in 2008 and the block size has roughly doubled since then, with bandwidth and processing 10x.

Mean propagation times have come down from 6+ seconds to nearly a second now...dont take my word for it here is some research we have helped out with: https://www.dsn.kastel.kit.edu/bitcoin/

For most "average" nodes your block will be seen in 1 second especially other bigger miners which are even more well connected. You are probably less than two-three peers away from all major pools.

Thats a 1/600 orphan chance or a tenth of one percent.

Real orphan rates currently are closer to 1/2000 blocks or so.

Statistically its nothing you have to worry about, and the network is designed for exactly that...people with low end hardware to be able to submit a block and have it accepted at nearly the same rate as everyone else, even pools with server grade machines.

The bigger threat is whether the cabal of Bitmain and foundry pools are doing something more sinister, like intentionally withholding blocks from their own nodes in case they find another block (essentially crippling smaller pools and solo miners) and forcing orphans

Research still ongoing on that one...

THat happened to me.  What I did was remove the shipping tape on the microsd card and click the card out and back in first.  IF that doesn't work you may need to reflash the microsd card from the futurebit instructions.  That is always a good idea to make sure the memory card is freshly programmed.  Even if the apollo boots up I think sometimes the memory in the flash is corrupted and a fresh reflash is a good move.  also get a backup microsd card and flash that one in case you need to swap out.  I also got a second 1TB memory stick, high performance, and use it to backup the blockchain after downloading so if any corruption in that memory happens, I can format the attached 1TB and copy the backup onto it to save download time.  I also have my unit laying sideways with HDMI port up so there is better airflow and fan runs slower/ cooler.  plus many more blinking lights to look at from the bottom. And I figured out the red light on the bottom means the memory card is active and shouldn't be removed.

Any recommendations? My apollo 2 node when I swtich it on is stuck in the boots phase and the loud fan wont stop and i can't connect to it via ip address. i had to shut off the unit because we had an electrician come to the house.

shaotai,

Lol, I actually received the repaired unit this afternoon (without any tracking or notice from Futurebit). FedEx just showed up after I got an email stating I had a delivery coming today. Well . . . swell. Wasn't sure what I was getting or from whom. Surprise!

In any case, the unit has not yet been plugged-in or tested, but the switch itself is much firmer and actually "clicks" when flipped. The original was very soft and just kind of "rolled"over without making any click or "rocker-lock" feel. Just an FYI as it appears to take at least a couple of weeks for the repair and you have to pay for the return shipping as well.

Cheers!


UPDATE: 10/13/24

So far so good on the repaired unit. Been running between ECO & BAL for the whole day and no problems. The switch seems to be functioning as expected. No strange shutdowns or resets or any other issues . . . so far. And, the cords are inserted all the way  . So, get your RMA and feel confident (and patient) that it will be repaired.

Cheers!

Is there a way to test the internal memory?  There should be some utilities included for testing purposes. 

 I have a new apollo II full node.  I've got through 2 microsd flashed cards, and two 1TB pcie cards to debug a crashing system.  The crash is random.  Happens more often when I am using the keyboard and screen on the raspberry pi  Leaving the browser and other programs open increases the crash occurance of the system.  So, I suspect it's not the microsd or pcie memory card.  I can leave the firefox browser open monitoring the node and firefox page will crash and sometimes completely drop out.  open file folders will freeze up.   I"ve formatted both drives and started node download on both.  i've reflashed both microsd cards to make sure thoses were not the issue.  System still randomely crashes.  The miner works perfectly and keeps running after a crash.  Sometimes, Im able to remote access and monitor the system even after the main display crashes.  A serious crash will freeze the system and require turning system off and on. 

The system crashes when I have miner running temperature is up.  64 on miner and system flucturates 50-64 depending on load.  This is why I think maybe the internal memory could have a defect.  I wanted to run a memory test to stress the system.  I have backup power supplies with line conditioning on the apollo II.

Right now, im reindexing my crashed node.  I keep everything on the raspberry pi keyboard screen closed and memory usage is only 30%.  I had the system monitor opened and even that has frozen up.  Remote monitoring and the node is still running.  This makes me think there is a problem with upper RAM memory on the raspberry pi.  Miner is not running to keep whole system cool.  system temp is 40-50.

I'm with you PennyBit, this is a switch issue for sure.  Since I own a RTX 4090, I've become OCD about plugging ALL my cords in fully until I hear a click, no matter what it is. 
It was more like the switch was tripping out on the load, not on the plug issue.  As soon as it began hashing and the watt/amps would go up, it would kill the connection while still "on".
Also, since you have mentioned in the forums about plugging the cord full in, I actually went back and double checked all my units. They were all fully seated...

jstefanop,
I don't entirely agree. The issue does not always stem from people not plugging in the power cable all the way into the socket. Yes. maybe a few, but certainly not all. I have been the recipient of such units and I certainly plug my units in completely. As a matter of fact, I'm still waiting for a return for this very problem that's been over two weeks since you received it. And, I'm monitoring another that may also need an RMA. Just to let you know.

Regards

We have had a few power switches fail and yours could be one of them. The issue seems to stem from people not plugging in the power cable all the way into the socket which causes the AC pins to overheat and eventually fails the switch.

Now that its heater season will probably send out another email to everyone to remind to make sure you are checking the AC cable for overheating especially when changes power modes from eco to balances/turbo