Topic: Official FutureBit Apollo LTC Image and Support thread - page 57. (Read 49938 times)

try to run only MMR, no failover

With     "no-pool-disable": true,    "no-client-reconnect": false, Apollo is really struggling. It keeps MMR as main online pool for 3 minutes and then it gives up, to never return to it.

Screenshots:

1. Fresh restart. MMR shows 61% HW errors, miner struggles there:
https://imgur.com/a/F7wi8wT

2. After few minutes, MMR is being abandoned. Litecoinpool wins:
https://imgur.com/a/eC2Ktgp

3. MMR is abandoned for good, hashrate stats are fucked. I don't even know if miner works at this time, or it needs reboot, being stuck in some HW error loop?
https://imgur.com/a/ongEbIs

4. After few minutes, Litecoinpool suddenly shows a lot of Accepted shares, mining recovers and continue. Hashrate creeps back up.
https://imgur.com/a/2kPzcNA

5. At 12 minutes uptime, hashrate is already back at 33 MH/s, HW is 68% and falling, Accepted shares in Litecoinpool growing.
This process continues as I watch it.
It will never attempt to connect to MMR again, but if I click Miner - Restart, it will connect automatically without any problems - means pool is there and online.

jstefanop, I can imagine how you would feel seeing this, bastard users are torturing these poor little shiny apollo miners! Haha ;-)

Thanks! I was looking for that.

I reverted them to False and True, the same result, now I reverted to True and False, miner restart once again to see result.

Looking from https://github.com/luke-jr/bfgminer/blob/bfgminer/miner.c:

no-pool-disable: If false, automatically disable pools that continually reject shares.
no-client-reconnect: If true, ignores pool requests to redirect to another server.

Donation is disabled at this moment. I rebooted it twice, and restarted miner, but result is the same, it definitely mining some wrong rental, HW errors shoot up, but Accepted shares are still being accounted for, at least in the beginning I've seen that.

then it switches to the secondary pool and never comes back to MMR. But it doesn't even try to return = means I don't get credit from MMR.

Hello jstefanop,

I have a problem with Mining Rig Rentals service. I've had a lengthy conversation with admin. We determined, that Apollo bfgminer is not compatible with MMR pool. Reasons:

When renter rents my machine, it switches to renter's pool (MMR acts as a proxy). If settings are wrong, Apollo will start generating HW errors or rejects, for example, if renter chose wrong algo, wrong pool or else. In that case, MMR pool softly disconnects miner and counts that I tried to mine (therefore I got credit regardless of the results of mining). Then, after a period of time, Apollo should come back and try again. This continues, until rental is finished, then MMR doesn't disconnect the miner any more.

Problem is, bfgminer in Apollo DOES NOT come back at all, after soft disconnect from MMR. I waited a long time and it just doesn't try to connect again. I verified that this is the case, with MMR admin.
It's verified, those thousands of other clients, cgminer, bfgminer and other software miners, which are mining on that pool, doesn't have that problem, and if renter settings are wrong they are gone, and when a rental is finished, they just come back and continue mining. Therefore, this behaviour is unique to Apollo.

In my bfgminer.conf I have:
But my Apollo ignores that and does not come back after the pool is online again. Apollo thinks that pool is in "Unknown" state, not "Alive", not "Dead", but Unknown, and it doesn't reconnect.

Screenshot there:
https://imgur.com/a/h9ZiSgS

When I click Miner - Restart then it always comes back to MMR, mining straight away without a problem.

Can you tackle this problem, or maybe have any ideas, how to make mining on MiningRigRentals.com possible?
Also, bfgminer for Moonlanders never had this problem. I didn't even know, that this problem existed (soft disconnects and returns) until now.

Current bfgminer.conf file:

EDIT: Looking at bfgminer.conf, I found two interesting options:

Is it because of them? Can you (or someone) explain what these options do?

I most likely had the same situation happen as the Apollo stopped hashing according to pool status. My unit is also in eco mode but with the fan set to 15%. Uptime was little over 10 days. I was only able to diagnose the situation remotely so I have no idea what the fan was doing. The MCU still had some wired network connectivity as ping replies were sent but ssh login wasn't possible. The funny thing is, the two Moonlanders connected to the MCU were still working happily and visible as active from the pool point of view. The unit is connected to a remotely controllable power socket so I was able to power cycle it and it started working again. No syslogs available due to how ramlog behaves in such situations.

Just stock eco mode. No tweaks to anything. Auto everything.

The UI controls all the background processes that run the miner, so the short answer is no.

Yeah I know that, but can I run the miner itself.
I can't look from where I am to check.
-Dave

Of course, you can do SSH. Username and password are both the same, "futurebit".

From the tl;dr department of this thread. Mostly because I'm not on my desktop.
Is there a way to run the Apollo through SSH instead of through the GUI?
I am looking to test something that probably will not work but can't be sure and would like to see the raw output of what is coming from the node / pool.

Thanks,
Dave

What mode are you running the miner in?

This is probably related to the MCU lockup issue we know about that can happen in a rare occasion. It should be fixed in the next update we are releasing soon.

I have a new Apollo. It works great for a few days then one of two things happen.
1. The fan stops completely and start smelling. I have to unplug and plug back in. Glad I?m around when that has happened because I fear it was heating up.
2. Fan speed jumps to full speed. Can?t log in to reboot. Have to unplug etc.
These happen regularly.
Glad I?ve been around in each case. Thoughts?

I think I've solved the reason why the fan rpm doesn't sound stable even when the fan is manually set to some specific speed and have a solution to fix it.

The fan is being controlled with software generated pwm as there doesn't appear to be any hw pwm capable pins unused on the board. The software solution needs to keep a stable timing with the pwm in order for the fan to keep the same rpm. At the same time, the MCU can have a frequency of several values between 240 MHz and 1.20 GHz. By default, this works so that if there's zero load then the frequency will eventually drop to 240 MHz and when there's any load spike then the frequency jumps directly to 1.20 GHz no matter how small the actual cpu demand was. I used the following command to monitor the frequency and it's clear that it's constantly jumping between minimum and maximum even when nobody is using the dashboard:


The constant cpu frequency variation makes it difficult for the software pwm to maintain exact rpm. It's close but still the variation is audible. Looking at the frequency usage stats with the "cpufreq-info" command, we can also see that the cpu is spending much time at maximum frequency:


The solution itself is rather simple. The default behaviour is to react instantly to any processing power demand and bump the frequency to maximum. However, other behaviours are also available and switching to the one called "conservative" results in slower changes in the frequency is processing power is needed. It turns out that the demand with the current software content is so low in reality that with the "conservative" setting the frequency rarely increases resulting in the software pwm staying stable and the audible changes in the manually set fan rpm going away.

First, without saving the change, the behaviour (frequency governor) can by changed with:

If that doesn't help then the change can be reverted back with:

Making the change permanent requires modifying /etc/default/cpufrequtils and replacing "GOVERNOR=ondemand" with "GOVERNOR=conservative". The other positive side effect is that since the higher frequencies are no longer used that often, the MCU temperature also stays a little bit lower.

With the changed governor, "cpufreq-info" now shows (after a stats reset):

that's what I'd try first mate re-flash the image to the current sd card or a new one

I've had issues on my pi's where an unclean shutdown just knackers the image

Hello all,

My apollo is not showing dashboard any more and it's not mining.
Ethernet port have both LEDs on.
When turned on from cold, Apollo is flashing orange for 10 seconds or so, and then flashing green and stays like that. No IP via DHCP registered, Apollo is not on the network.

Any advice? My guess it's the SD card?

or buy this one

https://www.amazon.com/gp/product/B07DXN85LW/ref=ppx_yo_dt_b_asin_title_o01__o00_s00?