search

grisp / grisp-software

Toolchain and Examples for GRISP
28 stars 5 forks source link

WiFi optimizations and libbsd to FreeBSD 12 update #46

Open sebhub opened 6 years ago

sebhub commented 6 years ago

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://anonymous@192.168.178.27/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://anonymous@192.168.178.27/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.

eproxus commented 4 years ago

@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)?

c-mauderer commented 4 years ago

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.