Official FutureBit Apollo LTC Image and Support thread

[DaveF]

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

[crypto_curious]

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

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

[DaveF]

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

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

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

[jstefanop]

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

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

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

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

[Harbingold]

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?

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.

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

[whiteogre]

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?

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.

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

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.

[crypto_curious]

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:

Code:

"failover-switch-delay": "120",

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:

Code:

{
    "pools": [
        {
            "quota": "0;stratum+tcp://eu-01.miningrigrentals.com:x",
            "user": "x",
            "pass": "x"
        },
        {
            "quota": "0;stratum+tcp://litecoinpool.org:3333",
            "user": "x",
            "pass": "x"
        },
        {
            "quota": "0;stratum+tcp://tbdice.org:13333",
            "user": "x",
            "pass": "x"
        }
    ],
    "api-listen": true,
    "api-allow": "W:127.0.0.1",
    "api-mcast-port": "4028",
    "api-port": "4028",
    "expiry": "120",
    "expiry-lp": "3600",
    "failover-switch-delay": "120",
    "log": "20",
    "load-balance": true,
    "no-pool-disable": true,
    "no-client-reconnect": true,
    "no-show-processors": true,
    "no-show-procs": true,
    "queue": "1",
    "quiet-work-updates": true,
    "quiet-work-update": true,
    "scan-time": "60",
    "skip-security-checks": "0",
    "submit-stale": true,
    "scan": [
        "APL:/dev/ttyS1"
    ],
    "set-device": [
        "APL:clock=715"
    ]
}

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

Code:

    "no-pool-disable": true,
    "no-client-reconnect": false,

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

[jstefanop]

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:

Code:

"failover-switch-delay": "120",

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:

Code:

{
    "pools": [
        {
            "quota": "0;stratum+tcp://eu-01.miningrigrentals.com:x",
            "user": "x",
            "pass": "x"
        },
        {
            "quota": "0;stratum+tcp://litecoinpool.org:3333",
            "user": "x",
            "pass": "x"
        },
        {
            "quota": "0;stratum+tcp://tbdice.org:13333",
            "user": "x",
            "pass": "x"
        }
    ],
    "api-listen": true,
    "api-allow": "W:127.0.0.1",
    "api-mcast-port": "4028",
    "api-port": "4028",
    "expiry": "120",
    "expiry-lp": "3600",
    "failover-switch-delay": "120",
    "log": "20",
    "load-balance": true,
    "no-pool-disable": true,
    "no-client-reconnect": true,
    "no-show-processors": true,
    "no-show-procs": true,
    "queue": "1",
    "quiet-work-updates": true,
    "quiet-work-update": true,
    "scan-time": "60",
    "skip-security-checks": "0",
    "submit-stale": true,
    "scan": [
        "APL:/dev/ttyS1"
    ],
    "set-device": [
        "APL:clock=715"
    ]
}

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

Code:

    "no-pool-disable": true,
    "no-client-reconnect": false,

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

Do you have donation set on? This could be an issue for muticurrency pools and mining rental sites, since how I have donations configured via BFGminer might be interfering with these pools. Next version will have donation configured in a less interfering way.

[crypto_curious]

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.

[whiteogre]

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

Code:

    "no-pool-disable": true,
    "no-client-reconnect": false,

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

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.

[crypto_curious]

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

Code:

    "no-pool-disable": true,
    "no-client-reconnect": false,

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

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.

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.

[crypto_curious]

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 ;-)

[stef942]

try to run only MMR, no failover

[crypto_curious]

try to run only MMR, no failover

Spot on, mate. It worked 

https://imgur.com/a/W2MKbxC

At least for now. Dashboard show status as "unknown", but Apollo continues to mine there. Thanks!

[Buddy_hell]

Tomorrow i join the Scottish contingent (!) of apollo miners.

I will have "fly me to the moon" playing the background as i watch the hashrate build up..........

Your Buddy Hell

[jstefanop]

try to run only MMR, no failover

Spot on, mate. It worked 

https://imgur.com/a/W2MKbxC

At least for now. Dashboard show status as "unknown", but Apollo continues to mine there. Thanks!

Yea the issue is how bfgminer handles failovers. Currently it assumes that everything its mining is the same coin (this is based from bfgminers original bitcoin origins, it was never designed to handle multiple coins of the same algorithm).

This gets pronounced when your on a multipoool, then have failover/donation configured to Litecoin. This ASIC is different from the Moonlanders and uses a midstate, so the midstate of one coin is injected into another and stuff gets confused.

Sadly bfgminer is starting to show its age, ill see if there is a short term fix, but for now if your on mutipool/rental pool make sure thats the only pool configured.

[jstefanop]

Tomorrow i join the Scottish contingent (!) of apollo miners.

I will have "fly me to the moon" playing the background as i watch the hashrate build up..........

Your Buddy Hell

You should post a vid of that

[huntingthesnark]

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?

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've just had number 1 happen for the first time in several weeks. Luckily happened to check on the Apollo, fan was off, very hot indeed (painful to the touch). Switched off and on again, front light wouldn't come back on (no boot?), left overnight and is fine this morning. Obviously did overheat significantly. Is this the MCU lockup?

(I'm running on Eco, everything auto, on a 200W Dell PSU brick)

[jstefanop]

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?

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've just had number 1 happen for the first time in several weeks. Luckily happened to check on the Apollo, fan was off, very hot indeed (painful to the touch). Switched off and on again, front light wouldn't come back on (no boot?), left overnight and is fine this morning. Obviously did overheat significantly. Is this the MCU lockup?

(I'm running on Eco, everything auto, on a 200W Dell PSU brick)

Sounds like it. Probably will cut out some features for the next release to just get some bug fixes out quickly by the end of this week and hopefully resolve this.

Since the heatsink so so efficient even with no fan spinning the PCB does not get hot enough to kick in the passive protections and shutdown the regulator...while its very hot to the touch (near boiling temps) its still not hot enough to damage anything, so dont worry if it does happen to anyone else, just shut it down and wait 20-30 min for it to cool down and restart.

[crypto_curious]

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?

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've just had number 1 happen for the first time in several weeks. Luckily happened to check on the Apollo, fan was off, very hot indeed (painful to the touch). Switched off and on again, front light wouldn't come back on (no boot?), left overnight and is fine this morning. Obviously did overheat significantly. Is this the MCU lockup?

(I'm running on Eco, everything auto, on a 200W Dell PSU brick)

Sounds like it. Probably will cut out some features for the next release to just get some bug fixes out quickly by the end of this week and hopefully resolve this.

Since the heatsink so so efficient even with no fan spinning the PCB does not get hot enough to kick in the passive protections and shutdown the regulator...while its very hot to the touch (near boiling temps) its still not hot enough to damage anything, so dont worry if it does happen to anyone else, just shut it down and wait 20-30 min for it to cool down and restart.

Another reason why we need Minimum Fan speed to be adjustable in Auto Fan mode.