...
Not sure how else to explain it to you, rolling version ASICBOOST is not supported on the hardware so there is no reason to work on this codebase until it is supported by the ASICs themselves....
The code's ability to handle asicboost is what matters. Versions sent and received work, but alas with a bug. Getting any performance gain using asicboost is not relevant. I've already given you the bug fix to your code so I've no idea why you wont implement it. There are cases where the miner needs to be able to handle asicboost because not every mining target on the planet supports both: on and off. With the VERY simple fix added, that issue disappears, the person running an apollo can have it turned on or off as required. Though I will quote you that probably explains you have no idea what you are talking about: ...
There is no bug, the miner supports version rolling for new ASICs but its not implemented in the current ASIC hardware. This is why you are seeing incorrect version data.
No, it's using the wrong display of the version data - %x - instead it should be the equivalent of %08x Not sure why im bothering replying to you when you keep insulting me, but since you keep spouting false accusations ill further explain what's going on in the interest of being as open as possible, and correcting you since you are the one that has no idea what your talking about. That version rolling flag should not even be enabled on the public builds, its used only for internal testing. We have a proprietary implementation internally, which that code is designed to work for our internal servers and testing. You have no idea what we do internally, nor do you even have the faintest clue why that string you pulled from our code is coded that way. If we had that flag hidden you would be none the wiser. Stop spreading miss-information and confusing our customers. These miners do not support asicboost period, and every major pool supports non-asicboost miners. |
|
|
|
|
We are finishing PCB production this week, and will hopefully start shipping next. Really wanted to get these out in November but supply chain issues once again put a damper on that (PCBs we’re stuck for weeks trying to get a flight).
Should still have the majority of orders placed on the Aug 31st out by end of the year, and the rest the first few weeks of January.
|
|
|
|
... and still the bug is there: strings apollo-miner | grep '%x'
{"id":%d,"method":"mining.submit","params":["%s","%s","%s","%s","%s","%x"]}
As I already explained, it's supposed to be %08x Though I guess without showing you the exact line, it was too difficult to understand ... I really wonder about this software, that also isn't properly tested either according to your own statement. Sigh. You guys should know about software releases that are due next week by now  You said it was due back in May ... Excellent, thanks! Downloading and running binary was very easy on normal Linux system. That being said however, I have quite good Raspberry Pi 2, quad core ARM, which is still running strong, and that's where I want to run Apollo. I don't have Raspberry Pi 4. I could not find source code for your apollo-miner binary. Will there be code released for apollo-miner binary, so I can compile it myself and run on Raspberry Pi 2? Hardware says: OS: Raspbian GNU/Linux 10 (buster) armv7l
Host: Raspberry Pi 2 Model B Rev 1.1 But I also have plenty of Pi zeros, would love to run miner on that too. Yea thats on the list, should have binaries for 32bit arm next week. Not sure how else to explain it to you, rolling version ASICBOOST is not supported on the hardware so there is no reason to work on this codebase until it is supported by the ASICs themselves.... |
|
|
|
You guys should know about software releases that are due next week by now Updated Binaries for Standard Unit users are below: https://github.com/jstefanop/Apollo-Miner-Binaries/releases/tag/1.1This release has a lot of bug fixes and resolves the issue people with unstable internet connections were having. These should now be super stable and run for weeks/months. 32 Bit Arm support was also added, if you want to run these on your raspberry pi make sure you updated to the latest Rasbian system release (otherwise you'll need to update libstdc++6 to latest version if your running an older version and don't want to upgrade). Same updated binaries will be pushed to Apollo Full Node users with the next software update due "next week"...seriously though we are wrapping up some UI testing for the next release and should have it out soon. |
|
|
|
...
There is no bug, the miner supports version rolling for new ASICs but its not implemented in the current ASIC hardware. This is why you are seeing incorrect version data.
Incorrect. The bug in the code is that you use %x instead of %08x for writing out the version. That is all it is. Try reading the code. Just like if you sent out a block without the leading zeros, no one on the network would accept it. Lol ok buddy...want to take over writing the driver code for me will save me lots of time since you know what's on our ASICs die better than me  |
|
|
|
Is there a reason why these miners don't have asicboost enabled?
That's pretty much the same as throwing away 10% of your hash rate you'd get for the same power.
Because its not implemented in the ASIC obviously. Incorrect. It turns out these miners can do asicboost. You need to add the option "-roll_version" However, the miner code has a bug in it that sends incorrect version data regularly so you lose lotsa shares. I've put a hack into my pool to correct the bad data so you don't lose the shares/blocks  So solo mining on my pool with an apollo can use asicboost with the "-roll_version" option. There is no bug, the miner supports version rolling for new ASICs but its not implemented in the current ASIC hardware. This is why you are seeing incorrect version data. |
|
|
|
Apologies if this is mentioned elsewhere in this thread:
How can I tell if my node supports the taproot upgrade?
HI all, question from a non-technical person happily mining from home with this device to try and learn and support the decentralization of the network. Forgive my question if it is an obvious one to most of you, but with all the talk of Taproot finally coming today, what does that mean for our nodes running with Futurebit? Is there anything we are supposed to do? If there is, if you could share the steps I would really appreciate it. Thank you, much appreciated, I am really just in over my head with the software/programming side, but genuinely want to learn and here for it!
Your bitcoin core instance needs to be v22.0 for taproot I think the Apollo has v0.21.1 Taproot support is actually in 21.1, will be upgrading the node to v22 soon though. |
|
|
|
Any news on when the 32bit version is coming out?
Wrapping up testing on updated binary today, and should have it out by next week! |
|
|
|
Back to my earlier question, which got lost in the shuffle:
Any updated to when LN will be available?
There wasn't even a single update to miner binary software since initial release in May 2021, and you are talking about LN?! miner binary crashes almost everyday, no Raspberry Pi releases as promised... I wouldn't count on LN this year. I understand jstefanop and team are busy, so I wait - but just replying realistically to you - leave it running for a few months, maybe something (hopefully) will be released then. Lots of work going on in the background. Unfortunately were still focused on scaling production, but that will shift to software once we start shipping Batch 3 in the next few months. That being said 0.3.2 will be released in the next few weeks with updated miner binaries, lots of GUI fixes, 32 and 64bit RPi binaries etc. |
|
|
|
Hi there, I use version: 0.3.1 3 devices. 1 x master and 2 slave The problem is the following. In TURBO mode, I can not get all 3 devices online Does anyone still have such problems? How can I solve them?  So it looks when I start normally. Hasboard#1 + #2 are the slaves.  When I click "Miner => Restart" both slaves and Hasboard # 0 (Master) does not work anymore. Can you ever run 3 devices at the same time? When will the next update come? 0.3.1 is already over 1/2 year old. Does anything happen? ECO-Modus => runs longer than one day stable  BALANCED => Mostly no 24h. Then one falls out. Restart of all 3 devices => then it runs again for 1/2 - 3/4 day  P.s. Has someone gave TeamViewer to install? P.p.s. Per LAN directly to the Fritzbox via 500MBIT/s connection Id wait a little longer than a few minutes for all hashboards to come online. It sometimes takes them a bit to show up on the dashboard. Are you running them on the FutureBit PSUs or do you have your own? |
|
|
|
Hiya @jstefanop...good to see you posting here on the forum...wanted to let you know that I upgraded the NVMe SSD to a 1TB and reflashed the sd card and restarted the node and let it resync and both node and miner are doing just fine...looking forward to the two additional miners I ordered arriving towards the end of the year...I hope you and the staff are doing great and well Happy Halloween... Thanks! Yea any 1-4TB NVMe drive should work fine on these. FYI to anyone that Pre-Ordered a Batch 3 full unit order your in for a treat! We were able to score 1TB drives for a good price so we will be upgrading everyones order to a 1TB version for free! Hello, I got a full node unit a while ago and it was working well for me so I picked up 2 standard units as well. For the most part things run smoothly, though on occasion I'll notice my hashrate loses 3 TH/it seems like one of the units stops hashing randomly but the other two keep going fine. This has happened pretty consistently for a while and generally I have to reboot the unit from the interface to get things working again. Does anyone know if there's a reason this might be happening or any way to increase the reliability of the units when they're linked together?
Also, it's awesome to see such active support in here. Excited about future updates!
This is a known issue on the standard units, if you have an unstable internet connection they will drop if your internet does not come back online fast enough. There will be a fix pushed soon, but in the meantime id either check your wifi connection and bring it closer to your router and/or switch to ethernet, or check your ISP on why its dropping its internet connection. |
|
|
|
Yes it is a full desktop, but that does not mean its designed to run crazy intensive desktop applications. Goal of the device is to run Bitcoin apps/wallets in an easy to use manner on top of the full node/miner. Even when we start offering things like Lightning Apps these won't take up all the CPU resources.
Your free to game on it if you want, but expecting it to work flawlessly while doing so and running the hashboard in turbo is definitely not what we advertise and way beyond the scope of the device. Ive also explained many times that you should not run in in turbo while doing the initial sync. While we have tested it and works fine in our test setups, there are environments (over 35C ambient) where the CPU could overheat. It only takes the device 24-48 hours to complete a full sync with a good internet connection so the downtime is not much if you really want to run turbo 25/7.
As with everything there are tradeoffs we have to make and for what the device is used for.
Thanks for your reply. Any chance you ship miners with 5V on OrangePi fan? I see no reason why this has been slowed down to boil the SBC and cause this discussion. It's inaudible compared to top exhaust fan anyway. Its actually pretty loud @5v. That fan runs ~ 12k RPM at that voltage, and its way louder than the main fan in ECO mode. You have to remember most of our customers run our devices on their desks/small rooms in ECO mode. Near silent operation is top design decision. |
|
|
|
...
Problem of running turbo while syncing is not CPU bottleneck, its thermals. The CPU could overheat and shutdown if its running at 100% while syncing, and the hashboard is in turbo mode. That's a serious problem with the device then. You are saying we can't run desktop computer in the device at 100% while Turbo mode is on in the miner part. What if YouTube is on for a few minutes and CPU spikes to 100%, or any other more CPU intensive task is running, not just bitcoin node but anything else, it means sudden shutdown? ... Um, these are miners and a dedicated BTC node -- not a desktop computer! The computer part is designed to be just an embedded controller and as a BTC node which normally are rather light CPU usage operations but more to the point they are also to a good extent time-sensitive. It is not intended for streaming video, gaming, or anything else which can/will as you noted steal critical CPU cycles from the main operations... The miner & node work as intended and are not flawed in respect to what they are designed to do.. Sorry that's where you are wrong - they are advertised as such. "FutureBit Apollo BTC is the world’s first vertically integrated platform brining the full power of Bitcoin and it’s mining infrastructure in a small, quiet, easy to use desktop device designed for everyday people." "PRE-ORDER: Apollo BTC - A Bitcoin ASIC Miner and Desktop Class Computer running a Full Node and Much More!" Desktop Class Computer. Looks pretty clear to me. Also: "We did this with our optimized PCB design that has carefully placed all 44 hash cores underneath our custom cold-forged aluminum induction heatsink, which draws up to 200 Watts of heat away from the device with our new nearly silent 25mm fan. This results in the Apollo BTC in Turbo Mode being just as quiet as the Apollo LTC in Eco Mode!" " Can be used as a full Desktop computer with a monitor keyboard and mouse (not included), or through our Web UI" Nowhere it says you can't run Apollo BTC in Turbo Mode and actually use that Desktop Class Computer at the same time because it will shutdown. Therefore, shutting entire device because you actually use it as advertised (Turbo Mode + Desktop use, or Turbo Mode + Bitcoin Node syncing) is a factory defect. I resolved defect in my unit myself (rewired small fan back to 5V supply), but I can imagine surprise of many less experienced enthusiasts who wake up to see their brand new miner, set to Turbo Mode, dead cold in the morning, because it has shutdown during normal as-advertised operation. Or even more disappointment when a customer would actually try to use that Desktop Class Computer for a minute and it would shutdown suddenly. And before you ask - Turbo Mode is one of advertised operation modes, nowhere it says it's overclocking, no warranty, or causes shutdown/overheating/do not use etc.. It's just listed there as one of the modes for people to use. No offence to jstefanop and team - I love this device because I can workaround problems, but these are just facts. Yes it is a full desktop, but that does not mean its designed to run crazy intensive desktop applications. Goal of the device is to run Bitcoin apps/wallets in an easy to use manner on top of the full node/miner. Even when we start offering things like Lightning Apps these won't take up all the CPU resources. Your free to game on it if you want, but expecting it to work flawlessly while doing so and running the hashboard in turbo is definitely not what we advertise and way beyond the scope of the device. Ive also explained many times that you should not run in in turbo while doing the initial sync. While we have tested it and works fine in our test setups, there are environments (over 35C ambient) where the CPU could overheat. It only takes the device 24-48 hours to complete a full sync with a good internet connection so the downtime is not much if you really want to run turbo 25/7. As with everything there are tradeoffs we have to make and for what the device is used for. |
|
|
|
I restored my configuration from a backup. The node is up and downloading the blockchain. The miner is up, but inactive and the original pool information seems to be stuck in the settings, despite changing to my new one. Any ideas? Thanks!
Try restarting in the miner software. Seems a hard restart sometimes does not restart right That did it, thank you. I'll let it run in eco mode until the chain syncs-up. You can run in Turbo mode immediately. Bitcoin Node synchronizing has nothing to do with miner itself, it's just more CPU time on OrangePi 4. Miner process itself use barely any CPU time and RAM, regardless of Eco or Turbo mode. Problem of running turbo while syncing is not CPU bottleneck, its thermals. The CPU could overheat and shutdown if its running at 100% while syncing, and the hashboard is in turbo mode. |
|
|
|
Literally swap them out. You can clone the data so you don't have to resync the blockchain but if you have a decent internet connection I'd just let it go redownloading everything from scratch
Hey, thanks. I have gigabit service to the house and I believe my initial sync took a few days. I can get the ssd for $89. The cloning device adds another $100 to the bill - and I only received my miner last month. I don't need to format or anything? I was under the impression that the image needed to be installed first. Just reflash the image to stock state, then put the freshly imaged SD card and new SSD and it will auto formate and set everything up. Well have a button in settings that does this instead of needed to reflash in the next update. |
|
|
|
I have two full package Apollos and would like to know how I can disable the controller in one so I can control both with one HDMI monitor, keyboard. etc...
Thanks
You can just remove the harness cable from the hashboard, then plug that unit via USB to your other unit. Thats a waste of a full node though... |
|
|
|
I have a Full Unit that I'm running one Standard unit off of right now. I'm planning on adding one more but if I use a USB hub can I add more then TWO Standard units to the Full Unit?
dWiGhT
Yes you can. https://ibb.co/s9S5NVcIs that 7 Standards on one Full unit? We have not event tested that many internally  |
|
|
|
@jstefanop is there any reason (except maybe the sleekness of the device) to use the GPIOs? Maybe better hashrate? For keeping the device's sleek design, but allowing users to run own OS, it might be cool to offer the GPIO connection software as a package to install! I don't know for sure, but this must be for aesthetics only. Everything fits under miner skirt. No extra USB cable required. Hashrate is the same in both cases, I've tried that, no differences in performance. Functionality also seems to same, hashrate readings, speed, fans, temps, power use. So feel free to give your Full unit a USB cable so you can install system of your choice. You can always revert to Futurebit system if you don't like it, by reformatting SD card and removing USB cable. No coms through GPIO or USB is the same. Unfortunately the GPIOs require kernel level changes to make coms work with the board, so its not an easy change. Main reason is for ease of use. Most people buying our device are new to mining so a plug and play all in one solution was the main design choice (we were debating having a separate controller (remember the KNC days , but this is way more cleaner and easier to use). |
|
|
|
FYI After having units running from Batch 1 and units from batch 2 I have found a difference in temps and fans speeds from the two batches. Although I was concerned I'm not to concerned now, just for fan longevity of batch 1 fans. It all started when I added a batch one unit to my batch 2 setup Batch 1 Setup https://imgur.com/a/A0KMm1H Batch 2 Setup not as fancy, https://ibb.co/s9S5NVcAll batch 2 unit temps were 68c-69c and fan speeds 2800-2900rpm constant across the 7 units from batch 2 When I added a batch 1 unit to the other 7 units one unit was 62c-63c and fan speed 3000-3100rpm (so lower temp with faster rpm) The question to myself was why is one unit so far apart from the others (originally didnt know it was the batch 1 unit yet) Through process of trouble shooting I isolated the lower temp unit and swapped the fan for one of the others of the consistent temps and fan speed like the others. I found out that it was not the unit but the fan itself as the lower temp and faster rpm followed the fan from unit to unit. I further looked at the fans closer and notice a distinctive difference. Batch 1 (4 units) I got had these fans with smaller gauge wires and a different wiring pattern. Blue yellow red black https://ibb.co/GTGwJkHBatch 2 units had larger gauge wires Black red yellow blue https://ibb.co/NZkKXWBBoth fans do have the same order at the plug to the board just different going into the fan. (different brand of fan I take it) In conclusion the difference between the fans from Batches is quite noticeable so if your seeing this too, here is what I found. There are a few differences between batches and even units within batches. We have multiple van vendors and their PWM curves are not exact match, so some fans will be faster. |
|
|
|
I'm not sure if I'm the only one that is experiencing this but searching this thread is a nightmare, I'm finding that every few days my standard hashboard unit will fade off leaving only my main controller unit working. Obviously, this takes my hashrate from 4.5 to 2.0'ish but for no apparent reason.
My 2 boxes are in an air conditioned environment, I've run Bitmain ASIC's in that same room with no issue and they are on a UPS for power consistency.
The fix is simple, reboot the boxes and I'm up and running but now I'm finding that I'm having to play babysitter.
Is this something that anyone else is experiencing?
Thanks!
ML
This is a known issue that will be fixed next update. Its caused by an unstable internet connection, so you can improve this if your on wifi, but if your ISP is causing it there is not much you can do until we issue the fix. |
|
|
|
|
Show Posts
