WiFi optimizations and libbsd to FreeBSD 12 update #46
Conversation
This reduces the amount of task switches in libbsd and thus improves throughput.
Enable a custom stack allocator which uses the internal SRAM for the task stacks if available.
|
Any progress on this, Freebsd12-release has published a few days ago |
Are you having issues that you hope to be fixed by this @mko-io ? |
@sebhub I fail to see how this is done. All I see some smaller stacks and the inclusion of stackalloc.h We would like to replicated this for the GRiSP image too (in addition to moving heavily used RTEMS and Erlang modules into internal SRAM once we figure out how that is done -- hints welcome ;-) |
|
@peerst no, I just curious about whether the new Freebsd release would improve grisp or not |
|
@mko-io I don't expect FreeBSD 12 to bring much new things for us. This PR is mainly about the WiFi and other optimisations which just happen to be made on the latest libbsd, which happens to be based on FreeBSD 12. What we would get is all security updates since the last update of libbsd if there are any in the kernel network stack. |
|
The libbsd upstream is based on FreeBSD head 2018-12-20. The FreeBSD 12 release was 2018-12-11: https://www.freebsd.org/releases/12.0R/announce.html It includes an update of wpa_supplicant to version 2.7. It includes an update of the OpenSSL baseline to version 1.1.1a. |
The inclusion of <bsp/stackalloc.h> in the configuration source file just enables a custom stack allocator. It uses the internal SRAM. The earlier a task is created the more likely its task stack is allocated from the internal SRAM. An alternative would be to use POSIX threads with a user defined task stack or a new API for Classic tasks which allow a user defined stack. |
|
Builds fine on Linux, but still having issues on macOS, need to have a closer look... |
|
@peerst I've read about Freebsd has some improvement on MMC/SDIO stack (base on CAM), does this mean we can use SDIO based wifi chip on grisp board? |
A note regarding that from me: We had a GSoC student in 2018 who worked on the topic of using the FreeBSD-SDIO stack on RTEMS. He had some success on a Beagle Bone Black with a normal SD storage card. But there was still some work left. I would expect that about the following would be necessary:
So SDIO WLAN modules should theoretically be possible but they would need quite some work. |
|
@sebhub @c-mauderer I'm having trouble building this toolchain version on macOS 10.14.2: This could be related https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86724 It's quite possible that GCC 7.3.0 does not play nice with ISL 0.20 / whatever is installed in macOS 10.13... Any suggestions? |
|
The branch has already slightly fallen behind RTEMS upstream. Sebastian updated gcc to 7.4.0 in Dezember. Would you expect that 7.4.0 would work? In that case it might would be a good idea to update rtems, libbsd and rsb in this branch and try with that. |
|
@c-mauderer It seems it should be fine in 7.4 according to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86724#c6
So it sounds like a good idea to update all of them to the latest version. |
|
@c-mauderer Can you tell me how to do that, or help me do it? |
|
To update the submodules, the following steps are necessary (written out of my head so no guarantee for no typos):
|
|
Note that you should always use rtems, rtems-libbsd and rtems-source-builder from about the same date. Sometimes there are dependencies - especially from libbsd to newlib and rtems. |
|
@c-mauderer Got further this time, but another error appeared when compiling GCC 7.4.0: Some casual searching suggests libstdc++ is not available in macOS Mojave (10.14)... |
|
Seems Apple decided to remove Next problem (or is it the build successful?) is this: |
|
I'm not entirely sure because it is missing some context but I would assume that RTEMS did build fine but the libbsd build went wrong. Can you do three things:
Basically 1 and 2 would be the following changes: The -v should be removed after the problem is solved. The other changes would be good to keep. |
|
@c-mauderer You're correct that it was in the libbsd build. Unfortunately the waf change didn't solve it: Full output here: https://gist.github.com/eproxus/2b60f59c50ac74f05c3c93147ef58d27 |
|
Somehow I remember that I had that output once too. I'm currently not sure when or why. Could you try to clean the rtems-libbsd directory? For that I would suggest the command |
|
@c-mauderer After cleaning the repo from scratch with |
|
Do you have the branch somewhere so that I could try a build on my Linux machine? |
|
@c-mauderer Pushed my changes to |
|
@sebhub @c-mauderer Do you know the source of the failure? I think it is connected to limited RAM of 4GB inside the Docker container of the CI system. We are currently requesting more from CircleCI. |
|
@nextl00p Could be the OOM killer in Linux |
|
I would too assume the OOM killer. Compiling gcc needs quite a lot of memory. And it seems that some process (most likely cc1plus) has been killed and therefore the output stream has been aborted. That resulted in the Do you have the possibility to get a |
|
@c-mauderer @nextl00p You can debug with SSH: https://circleci.com/docs/2.0/ssh-access-jobs/ |
|
If you plan to integrate these changes, I recommend to update to the libbsd/5-freebsd-12 branch. This branch tracks FreeBSD stable/12. |
|
The problems I'm having might be related to this bug: https://devel.rtems.org/ticket/3709 |
Note: Python 3 is now needed to build libbsd (because of the bug https://devel.rtems.org/ticket/3709).
|
Note: Python 3 is now (temporarily) needed to build libbsd as a workaround for https://devel.rtems.org/ticket/3709 @sebhub @c-mauderer Can you confirm my latest commit looks okay, in regards to the versions used of RTEMS, libbsd and RTEMS source builder? |
Revert "Test OTP build with new toolchain" This reverts commit cd73e8f. Revert "Add dmesg output to CI artifacts" This reverts commit 7f51e9e. Revert "Store rsb-report artifact when build fails" This reverts commit 81dd5fd. Revert "Add status badge" This reverts commit bed8dd7. Revert "Add CircleCI config" This reverts commit a56f8f5.
|
@eproxus: Are you sure you want to switch back to the upstream repository instead of mirroring the branches in your repo? |
|
@c-mauderer Since some sub repos point to git.rtems.org anyway, there's no point in having our own forks for just some repositories, right? |
|
I think the only one left pointing to git.rtems.org has been the rtems_waf in libbsd. Please don't understand me wrong: I'm OK with the repos pointing to git.rtems.org. I think the original change was due to some server outage on the RTEMS server. I'm sure that happens more often than an outage on github. |
|
PS: Maybe it would be good then to somehow mark the mirrored repos to only be left in the GRiSP project for building old versions (especially the ones that used the grisp-branches). No idea how to do that on github but I'm sure there is something that can be done. |
|
@c-mauderer I thought so as well, but didn't like the idea of having a separate branch of libbsd master just to be able to point to a fork of rtems_waf as well. It gets recursively messy 😕 You can mark repositories as no longer active/maintained somehow. I'll do that in that case. |
|
I had suggested once that we use a relative URL for rtems_waf in libbsd. But then I noted that the git version used in old but still maintained CentOS versions can't handle these. So the absolute URL has been left. Maybe in a distant future when even a distribution like CentOS handles the relative URLs we will change that in libbsd ;-) Please mark the repos only after the merge. |
|
Yeah, sounds good. There are so many external dependencies in this toolchain anyway, so having one more is fine for now. We don't build that often. |
|
Trying to attack this again now, and am following this procedure on macOS 10.15.3 (using Homebrew for all the dependencies):
It fails building Output@c-mauderer @sebhub Any ideas? |
|
It could be a non-matching RTEMS and libbsd version. The |
|
Maybe we should test the Grisp stuff with the RTEMS 5.1 release candidate
once it is available.
…On Wed, Mar 11, 2020 at 9:38 AM Christian Mauderer ***@***.***> wrote:
It could be a non-matching RTEMS and libbsd version. The MSEC_2_TICKS has
been added in commit c6d8589bb00a9d2a5a094c68c90290df1dc44807 in RTEMS
into cpukit/include/machine/_kernel_time.h. I assume that libbsd would
use that definition.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#46?email_source=notifications&email_token=AAHDRWFWL4RY63I7FFPPGYDRG5EWXA5CNFSM4FZAJJ6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOOUCFY#issuecomment-597508375>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHDRWD7ZMTSM26PQRFG5V3RG5EWXANCNFSM4FZAJJ6A>
.
|
|
@c-mauderer Any idea how that could have happened? I haven't changed the versions since last time (only I'm now testing on macOS 10.15). Newbie question: How can I check which version of RTEMS I'm using? |
Not really. It's also just a guess that it could be a version mismatch. I looked back at your commands:
and
There is a mismatch in the folder name. Just to make sure: Did you build the version that you wanted to build or is there a mismatch for some reason?
First you can take a look at version you checked out. But I assume that you do know that method and therefore you are searching for a method to analyze the generated binaries? Since 2017 we have a version API: Another method is to analyze the binary files. You want the content of |
|
@c-mauderer Sorry, my bad. The correct hash is of course 8f7399b. I'm building this PR branch directly (not my old fork). This is what my submodules show: Something is fishy here. Not sure why we have RTEMS code from March 2019 (7a1934da) which depends on code from November 2019 (c6d8589b). That doesn't make sense. |
Yes, you are right. That seems unlikely except if a long lasting bug has been fixed with it. But then it would be odd that it worked some-when in the past on my system... Like @sebhub said:
If you are thinking about that too, I would suggest to not take a too detailed look at the current problem but wait for the update instead. |
|
@c-mauderer I'd rather get this PR out of the way first than upgrading RTEMS once again (especially to a version that is not released yet). I've confirmed that the submodules are their same old version from early 2019, how come we get references to some new RTEMS feature that we don't use? Could something newer been pulled in in a way that we don't have control over by the build script (e.g. not via submodules configuration, but some download or samething)? |
|
I did try to re-build the branch on my machine and I get the same error. I'm really not sure why the error occurs now. I'm not even sure whether the error did not occur after the last pushes to that branch. From what I can read in the history of this PR, I can't say that I tested these updates. So it's quite possible that it never worked. Regarding the msecs_to_ticks: The error only occurs if someone links in WLAN. And I think it's quite possible that you are the only regular users of that. So the bug can be hidden since quite some time. Again: I would suggest to do a step to a recent version where the error is already fixed instead of fixing it on this old version. |
This pull requests updates the libbsd to a FreeBSD baseline close to the FreeBSD 12 release (2018-09-17). This requires an RSB and RTEMS update as well.
The saf1761_otg driver uses now a real interrupt handler for the saf1761_otg_filter_interrupt() function which reduces the amount of task switches to the interrupt server.
An mbuf alignment was fixed in the rtwn driver receive path to avoid unnecessary data movements.
Task stacks moved to the internal SRAM in the grisp-sd-sample. This improves TCP throughput by about 100KiB/s.
curl -o /dev/null ftp://[email protected]/dev/zero
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 104M 0 0 485k 0 --:--:-- 0:03:39 --:--:-- 542k
curl -T /dev/zero ftp://[email protected]/dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 76.2M 0 0 0 76.2M 0 593k --:--:-- 0:02:11 --:--:-- 606k
The signal quality has a huge impact on the throughput. This makes measurements quite uncertain.
The rtwn transmit path uses m_copydata() which uses bcopy() which is a memmove(). There is no specialized memmove() implementation for ARMv7-M in Newlib (unlike to memcpy()). This is a slight performance penalty.