Definitely not dead, I’ll have something quite interesting in a few weeks

make sure screen is installed (sudo apt install screen)

create a file in your home directory with nano like this:


inside this file put something like this


then turn startup script to executible


and add this to crontab


go down after all the ## and add this line


then


once rebooted just do


and you should see bfgminer running. Press control then A then D at the same time to exit screen without terminating process.

That should do it  

Unless your talking about AMDs APU's from years ago, AMDs current APUs they just released with vega cores blows anything Intel has out of the water.

Wow, bastards took out nice polymer caps for aluminum ones. That is saving them like 25 bucks per board.

And they sent me like a zillion $100 coupons lol.

Hes accessing the PCIE registers directly, which exposes nice things like timings and a bunch of other cool goodies Have to say its pretty impressive, my head almost exploded last time I was looking at the pcie memory space on the linux kernel  

Good luck on that when all the miners are shipped out

Simply put yes. Except that these transistors are physically "etched" into the silicon. These logic blocks are not "movable" once the silicon is made thats it.

FPGAs on the other hand have millions of these gates you show in that figure, but the connections between them can be physically changed. This is why FPGAs are kind of like GPUs, and can approach ASIC level performance because you can physically change the logic at the hardware level.

Most pools wont set diff anything lower than 4k-8k these days, if you can convince them to set it to at least 512 or 1024 thats enough for a moonlander to send a share every minute or so.

Cool, thanks for sharing. FYI you don't need to install the VCP UART drivers for pi's, linux kernel already has it pre-installed.

Thats a waste of money...all bitmain controllers are just beaglebones...these have USB outputs. Connect a wifi dongle and configure the linux system for wifi and boom, you got a wireless miner.

Yea, in those cases just shoot an email to the pool and ask for a low diff port for USB Asics. I know miningpoolhub already lowered the diff for us, and I'm sure other pools would too if enough requests are sent.

The rate accepted shares has nothing to do with how "fast" its mining. Its simply the difficulty the pool has set the shares too. Higher diff, less accepted shares, which is what pools want since their servers would be overloaded if everyone mined low diff shares. Higher shares have more "value" so you mine more litecoin.

Most pools use vardiff, so accepted shares are averaged to around 1 share per minute, regardless of wether you mining with a Moonlander or an L3+.

Lol good luck with that...see the main problem with bitmain is not bitmain itself, its that everyone else in crypto is not here for the tech and what it means for society, but are just as greedy if not more than bitmain.

You tell me if you buy their ASICs or not when the one guy next you is making 100 bucks a day because he did.

You read the article? Sounds to me like they are shutting down a bunch of residential customers that think its fine to load an apartment or makeshift shed full of miners and think they can tap 200kw from a residential grid. I warned of this before, but no one took it seriously. A couple rigs in your house is fine an no one will bother you, but if your going to try and stick a couple dozen in a residential area and think no one will notice think again.

This wont kill eth mining anytime soon. These are not A3's/D3's etc. Anyone worried about these has no sense of the magnitude of Ethereum's current hashrate.

Its currently at 270 TERAHASHES. Thats NINE MILLION 570's/580's

In order to double the hashrate, bitmain would have to make and sell 1.5 MILLION E3's. At most these batches have 10-20 thousand units, which wont even make a dent in the hashrate. To put things in perspective, Litecoin's entire hashrate is made up of a couple hundred thousand L3+'s and some of that hashrate is shared by innosilicon and BW.

The only reason A3's and D3's killed GPU mining is because they were orders of magnitude faster and more efficient than the GPUs they replaced. E3's are exactly the same speed and efficiency as GPUs, they only advantage they have is that they cost less than current GPUs, and Bitmain does not have to be at the mercy of getting GPU packages from AMD/NVIDIA( and thats about the only advantage an ethereum ASIC can have, maybe slightly higher effenciey if they go full custom cores which they wont since eth will go POS before then).

Lets all calm down

Just talked with Luke, figured out whats going on here. bfgminer is designed to mine to a single blockchain by default, so if you specific failoverpools, its assuming all failoverpools are mining to the same blockchain, and using those pools for blockchain updates (which would normally be a good thing since if a block update comes from one pool faster, you'll switch work faster and avoid stale shares).

In this case if your failovers are pools which are mining different coins/blockchains then you need to specify bfgminer to not track blockchain messages from other failover pools with "--pool-goal" option.

For example:

bfgminer -o http://pool1:port -u pool1username -p pool1password --pool-goal default -o http://pool2:port -u pool2usernmae -p pool2password --pool-goal freicoin


You can name pool goal whatever you like, as long as they are different for each failover pool that does not mine to the same blockchain. So you could have two litecoin pools, in which case you can put "--pool-goal litecoin" after each pool config, and have a third pool that tracks some random coin which you should put "--pool-goal randomecoin" after the pool config.

Can you post a pic of what your talking about?

Unless this is a pool issue, this would be a bug in bfgminer stratum code. I only code the "driver" for the moonlander, so unfortunately anything outside that would be a bfgminer issue that you should filea issue on Luke-jr's git (I would post this in his bfgminer thread as well). Ill bring it up to him and take a look at it and see if we can find an issue as well.

In the meantime add "-D" option to the command line, and pastebin a log with the issue with the debug output enabled.  


EDIT: Also try adding --failover-only option when using failover pools, and see if that resolves the issue.

Bunch of BIOS mods and some good tuning