Deutsche Übersetzung weiter unten
Wi-Fi 7 at Selfnet
In line with the purpose of Selfnet e.V. to promote knowledge transfer in the field of information and communication technology, we have intensively studied Wi-Fi 7 (IEEE 802.11be). Selfnet has been an early adopter of Wi-Fi 6 (802.11ax) and Wi-Fi 6E in dormitories. The early evaluation of new standards in the WLAN environment now continues for 802.11be. This standard is currently still in the development phase, however, as it was the case for Wi-Fi 6, Wi-Fi 7 is already being offered by the first manufacturers. Possible changes during development are to be followed up with updates on the devices.
Transparency note: Selfnet received the AirEngine 8771-X1T access point (AP) and a Xiaomi 13 Pro from Huawei for the Wi-Fi 7 test. We used the AC6805 WLAN controller already available from Selfnet for the rest of the test.
The test took place using Huawei hardware because Selfnet currently relies exclusively on products from this manufacturer in the area of WLAN.
The good cooperation enabled Selfnet to gain access to the corresponding hardware at an early stage.
Given existing infrastructure in the association and the know-how facilitate the testing of these devices. The tests presented here are intended to show what is possible with the new Wi-Fi 7 technology and do not intend to test the performance of devices from specific manufacturers. However, Selfnet is open to continue testing with devices from other manufacturers of this technology. These are welcome to contact us at support@selfnet.de to provide us with appropriate loan hardware.
Software Version
The AirEngine 8771-X1T is not yet usable as a standalone access point (FAT AP). For this reason, we relied on our associations active controller solution for the test implementation. In order to integrate the new AP model, it was necessary to upgrade our AC6805 access controller to software version V200R023C00SPC100. At the beginning of the test phase, test results were very inconsistent, which was caused by the beta version of the AP firmware. Therefore, for the final tests, the software version AirEngineX771-V200R023C00SPC100 was used.
Excursion Selfnet L3 WLAN
The processing of traffic in the Selfnet WLAN is more extensive than what is typical for home networks. From the regular LAN network, the APs route all traffic via a tunnel to the access controller. This enables us to provide each user with an individual IP network in the WLAN within an extensive Layer-3 network. Two specially configured servers located behind the redundant access controllers assume the role of gateway and client isolation in the WLAN network. These servers are automatically supplied with the relevant information for operation.
In winter 2022, the number of simultaneous WLAN clients of Selfnet e.V. exceeded the 3,000 mark for the first time. The servers, configured with over 10,000 interfaces and traffic of approximately 2 gigabits, exhibited performance gaps and recorded CPU utilization of 100%. The outdated hardware, equipped with an Intel(R) Atom(TM) CPU C2750 and 16 GB of RAM and dating back to 2014, could no longer keep up with the efficiency of modern devices.
For Selfnet the year 2023 was marked by the renewal of hardware. In parallel with the replacement of our entire access platform, we also took care of the WLAN gateways. They are now powered by an AMD EPYC 7313P processor, which features twice the number of cores, supports hyper-threading, and has higher single-core performance. Due to the low RAM usage of under 1 GB, they are equipped with just 16 GB of RAM, split into two 8 GB modules to ensure fault tolerance and bandwidth optimization. With additional SFP+ ports, the new servers can now be redundantly connected to the ACs, providing increased redundancy. Just in time for the start of the winter semester, the first of the new servers was put into operation. The integration of the new backup server on the new hardware is expected to follow in the coming weeks.
Wiring of the test setup
The existing Layer-3 network infrastructure is capable of providing high WLAN bandwidth to our members in the Selfnet network. However, it proves to be unsuitable for test scenarios aimed at evaluating the maximum speed and performance of Wi-Fi 7. Therefore, in the test scenario, we have chosen to use the controller infrastructure solely for management purposes. The traffic is directly routed as a local breakout from the access points.
The access point of the model 8771-X1T was connected to a Huawei Switch S5732-H48UM4Y2CZ-V2 for both power and management. This switch supports Power over Ethernet (PoE) according to the 802.3bt standard, which is required to operate the 8771-X1T at full capacity. However, in our access network, this type of switch is operated with a license for solely 2.5 gigabit.
In the context of this test setup, the additional ports on the AP proved to be advantageous. The 8771-X1T has three ports that support data transfer rates of up to 10 gigabits - two of them via RJ45 and one via SFP+. Since one RJ45 port is connected for power and management with the switch, one SFP+ and one RJ45 port with 10 gigabit capacity remain available for other applications. This port is intended to be used to connect a speed test server directly to the AP. The connection looks as follows:
Speedtestserver
|
| (Ethernet)
V
AP 8771-X1T - - - - (WiFi 7) - - - - - > Xiaomi 13 Pro
|
| (Ethernet)
V
Switch S5732-H48UM4Y2CZ-V2
|
| (Ethernet)
V
Core Netzwerk
|
| (Ethernet)
V
AC6805
Speedtestserver
For conducting speed tests with high bandwidths, Selfnet has already opted for a Mac Mini with a 10 gigabit onboard network card in other test scenarios. Previous tests with various RJ45 adapters and cards that support more than 1 gigabit yielded varying results in tests. The Mac Mini offers the advantage of being available in an "out of the box" version with 10-gigabit RJ45 interfaces and is delivered with the appropriate software, thus avoiding driver problems.
To assess the performance of the setup, two Mac Minis with similar specifications were connected, and speed tests were conducted. Test tools used included iPerf3 and a browser-based speed test, for which the Librespeed software was used. The latter was run as a Docker container on one of the Mac Minis, using the Docker image linuxserver/librespeed, which is optimized for ARM processors. The Mac Mini used by Selfnet has the following specifications: M2 8C CPU, 10C GPU, 16 GB RAM, 512 GB SSD, and a 10 Gbit Ethernet interface.
During tests, where two Mac Minis with similar configurations communicated with each other, the HTTP test achieved 9963 Mbps in download and 2442 Mbps in upload. These results demonstrate that the setup fundamentally supports 10 gigabit.
Speedtest Mac mini - Mac mini
It was observed that the generation of upload files in the browser on a Mac Mini on the client side reaches its limit at around 2.5 Gbit/s. However, additional iPerf3 tests between both Mac Minis confirmed transmission speeds of approximately 9.4 Gbit/s in both directions.
iperf3 test
selfnet@mac-mini ~ % iperf3 -c 10.0.0.1
Connecting to host 10.0.0.1, port 5201
[ 5] local 10.0.0.2 port 49907 connected to 10.0.0.1 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 1.09 GBytes 9.38 Gbits/sec
[ 5] 1.00-2.00 sec 1.10 GBytes 9.41 Gbits/sec
[ 5] 2.00-3.00 sec 1.10 GBytes 9.41 Gbits/sec
[ 5] 3.00-4.00 sec 1.10 GBytes 9.41 Gbits/sec
[ 5] 4.00-5.00 sec 1.10 GBytes 9.41 Gbits/sec
[ 5] 5.00-6.00 sec 1.10 GBytes 9.41 Gbits/sec
[ 5] 6.00-7.00 sec 1.10 GBytes 9.41 Gbits/sec
[ 5] 7.00-8.00 sec 1.10 GBytes 9.41 Gbits/sec
[ 5] 8.00-9.00 sec 1.10 GBytes 9.41 Gbits/sec
[ 5] 9.00-10.00 sec 1.10 GBytes 9.41 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 11.0 GBytes 9.41 Gbits/sec sender
[ 5] 0.00-10.00 sec 11.0 GBytes 9.41 Gbits/sec receiver
iperf Done
iperf3 reverse test
selfnet@mac-mini ~ % iperf3 -c 10.0.0.1 -R
Connecting to host 10.0.0.1, port 5201
Reverse mode, remote host 10.0.0.1 is sending
[ 5] local 10.0.0.2 port 49909 connected to 10.0.0.1 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 1.09 GBytes 9.34 Gbits/sec
[ 5] 1.00-2.00 sec 1.10 GBytes 9.41 Gbits/sec
[ 5] 2.00-3.00 sec 1.10 GBytes 9.41 Gbits/sec
[ 5] 3.00-4.00 sec 1.10 GBytes 9.41 Gbits/sec
[ 5] 4.00-5.00 sec 1.10 GBytes 9.41 Gbits/sec
[ 5] 5.00-6.00 sec 1.10 GBytes 9.41 Gbits/sec
[ 5] 6.00-7.00 sec 1.10 GBytes 9.41 Gbits/sec
^C[ 5] 7.00-7.27 sec 303 MBytes 9.41 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-7.27 sec 0.00 Bytes 0.00 bits/sec sender
[ 5] 0.00-7.27 sec 7.96 GBytes 9.40 Gbits/sec receiver
iperf3: interrupt - the client has terminated
For the subsequent tests, the Mac Mini was directly connected to the available RJ45 port on the AP and served as the speed test server. A full 10 gigabit speed was achieved and successfully negotiated, as indicated by both the Mac Mini and the AP.
AP Configuration
The configuration of the Wi-Fi 7 AP was based on the experiences and insights provided to us by Huawei from their own tests. They provided us with documents that included detailed instructions on how to configure the WLAN for optimal speed performance. The basic configuration is as follows:
[ac-wlan-view]disp ap ap-group wifi7-test
Total AP information:
nor : normal [1]
ExtraInfo : Extra information
----------------------------------------------------------------------------------------------------------------------
ID MAC Name Group IP Type State STA Uptime ExtraInfo Scene
----------------------------------------------------------------------------------------------------------------------
1 XXXX-XXXX-XXXX wifi7-test wifi7-test XXX.XXXX.XXX.XXXX AirEngine8771-X1T nor 0 3H:2M:38S - -
----------------------------------------------------------------------------------------------------------------------
Total: 1
# Configuration for ap-group wifi7-test
#
radio 1
radio-5g-profile wifi7-test
vap-profile wifi7-test wlan 1
#
# Configuration for ap-id 1
#
ap-name wifi7-test
ap-group wifi7-test
regulatory-domain-profile wifi7-test
radio 1
channel 160mhz 100
eirp 15
calibrate auto-channel-select disable
calibrate auto-txpower-select disable
radio 2
radio-5g-profile wifi7-test
vap-profile wifi7-test wlan 1
channel 320mhz 5
eirp 18
calibrate auto-channel-select disable
calibrate auto-txpower-select disable
#
# Configuration of radio-5g-profile wifi7-test
#
rrm-profile wifi7-test
rts-cts-mode disable
a-msdu enable
air-scan-profile wifi7-test
#
# Configuration of rrm-profile wifi7-test
#
multimedia-air-optimize disable
bss-color disable
spatial-reuse disable
#
# Configuration of air-scan-profil wifi7-test
#
scan-disable
#
# Configuration of vap-profile wifi7-test
#
ssid-profile wifi7-test
security-profile wifi7-test
traffic-profile wifi7-test
band-steer disable
dynamic flow inspection disable
#
# Configuration of ssid-profile wifi7-test
#
ssid "WiFi7 @ Selfnet"
wmm edca-client ac-be aifsn 3 ecw ecwmin 0 ecwmax 0 txoplimit 0
ofdma downlink disable
ofdma uplink disable
mu-mimo disable
#
# Configuration of security-profile wifi7-test
#
security wpa3 sae pass-phrase REDACTED aes
#
# Configuration of traffic-profile wifi7-test
#
rate-limit client dynamic disable
#
Additional test parameters
To achieve an optimal speed test result, various factors need to be taken into account. In the initial phases of the tests, the results were highly variable, ranging from 500 mbit/s to 3 gigabit/s. This inconsistency in test results was primarily attributed to a beta firmware with which the devices were initially provided. A few weeks later, we received an updated software from the development team, which resulted in a significant improvement in the test results.
In addition to the mentioned firmware, physical conditions also played a crucial role in optimizing the test results. The positioning of the test device is of paramount importance; ideally, it should be placed directly on the 6 GHz antenna of the AP, which is located on the lower front of the device. We are aware that this setup is not practical for real-world use. In this part of the test, the goal was to determine the theoretical maximum possible data throughput.
One challenge during the tests was heat generation. The AP generates more heat during operation compared to typical entry-level models, a characteristic of APs with advanced features and higher speeds. The smartphone used as a test client also warmed up quickly due to intensive CPU usage and its proximity to the AP.
This required special attention, as excessive heating can negatively impact the test results. For longer test durations, it is advisable to take measures to cool the device. Additionally, the smartphones power management is an important aspect: to ensure that no power-saving modes are activated that could affect performance, the smartphone should have a full battery. At the same time, it's recommended to avoid charging during the test to prevent additional heat generation and hence potential result distortions.
Wi-Fi 7 Test under optimal conditions
After implementing all the mentioned requirements and updating to the latest firmware, consistent speeds were achieved that surpass the expected performance of Wi-Fi 6.
The tests were conducted under the best possible conditions and executed both via HTTP and iPerf3. The app Magic iPerf was installed on the test smartphone to perform the iPerf3 tests, with the smartphone serving as the server. The Mac mini used as the speed test client connected to this iPerf3 server on the smartphone.
During the tests using the iPerf3 protocol, speeds of approximately 3 gigabits were achieved. Below is an excerpt from the iPerf3 output with the obtained results:
selfnet@mac-mini Documents % iperf3 -c 10.0.0.1 -i 1 -R -t 60 -P 30 -p 5201
Connecting to host 10.0.0.1, port 5201
Reverse mode, remote host 10.0.0.1 is sending
.
.
.
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.01 sec 12.8 MBytes 106 Mbits/sec
[ 7] 0.00-1.01 sec 12.8 MBytes 106 Mbits/sec
[ 9] 0.00-1.01 sec 12.8 MBytes 106 Mbits/sec
[ 11] 0.00-1.01 sec 12.8 MBytes 106 Mbits/sec
.
.
.
[SUM] 0.00-1.01 sec 382 MBytes 3.19 Gbits/sec
.
.
[SUM] 1.01-2.01 sec 424 MBytes 3.54 Gbits/sec
.
.
[SUM] 2.01-3.00 sec 379 MBytes 3.21 Gbits
.
.
[SUM] 3.00-4.01 sec 300 MBytes 2.50 Gbits/sec
.
.
[SUM] 4.01-5.06 sec 345 MBytes 2.76 Gbits/sec
.
.
[SUM] 5.06-6.00 sec 360 MBytes 3.20 Gbits/sec
.
.
[SUM] 6.00-7.01 sec 360 MBytes 3.00 Gbits/sec
.
.
[SUM] 7.01-8.01 sec 364 MBytes 3.06 Gbits/sec
.
.
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-60.01 sec 732 MBytes 102 Mbits/sec
sender
[ 5] 0.00-60.01 sec 719 MBytes 101 Mbits/sec
receiver
.
.
.
[ 63] 0.00-60.01 sec 719 MBytes 101 Mbits/sec
receiver
[SUM] 0.00-60.01 sec 21.4 GBytes 3.07 Gbits/sec
sender
[SUM] 0.00-60.01 sec 21.1 GBytes 3.02 Gbits/sec
receiver
iperf Done.
The results from iPerf3 show some variation in the values, which, from our perspective, fall within an acceptable range for a wireless connection and offer significant advantages over older Wi-Fi standards. Speeds of at least 2.5 gigabits were achieved, with an average of over 3 gigabits. Despite the use of a not yet fully matured GA-firmware, these results hold promise for future WLAN data rates. Tests were also conducted over HTTP using LibreSpeed in the test setup. Download speeds varied but consistently remained just below or just above 3 gigabits. The results are therefore very comparable to what iPerf3 has shown.
HTTP Test Wi-Fi 7 under optimal conditions
What's interesting about the HTTP test result is that the upload, at 2613 Mbps, is almost 200 Mbps better than in the direct connection between two Mac Minis.
To include the performance of the Mac mini in addition to the direct Mac-to-Mac test in a speed test with the smartphone, the utilization was monitored during an HTTP speed test from the smartphone to Libre Speed.
Speed test server CPU utilization
Test setup closer to reality
After conducting tests under nearly ideal conditions, we focused on repeating the tests under more realistic conditions. In this case, only HTTP tests were performed, and the configuration of the Wi-Fi 7 AP remained unchanged. To directly compare performance, a Wi-Fi 6 AP was included in the test series.
Selfnet employs the AirEngine 8760-X1-PRO in many of its office spaces, which is expected to provide sufficient bandwidth for many present members. The AP 8771-X1T is its direct successor and represents Huawei's first device in the highest AP class that supports the 6 GHz band. With its features, including two RJ45 ports with 10 gigabit interface speed and an SFP+ port, this model serves as a suitable basis for a direct performance comparison between Wi-Fi 6 and Wi-Fi 7 devices, as it has very comparable parameters.
We made an effort to configure the Wi-Fi 6 AP as similar as possible to the Wi-Fi 7 device. This is to allow for the most precise and direct comparison of performance data between the two Wi-Fi standards in our usage scenario.
The following configuration was applied to the device for this purpose:
[ac-wlan-view]disp ap ap-group wifi6-test
Total AP information:
nor : normal [1]
ExtraInfo : Extra information
------------------------------------------------------------------------------------------------------------------------------
ID MAC Name Group IP Type State STA Uptime ExtraInfo Scene
------------------------------------------------------------------------------------------------------------------------------
2 XXXX-XXXX-XXXX wifi6-test wifi6-test XXX.XXX.XXX.XXX AirEngine8760-X1-PRO nor 0 3D:4H:23M:33S - -
------------------------------------------------------------------------------------------------------------------------------
Total: 1
# Configuration for ap-group wifi6-test
#
radio 1
radio-5g-profile wifi7-test
vap-profile wifi6-test wlan 1
#
# Configuration for ap-id 2
#
ap-name wifi6-test
ap-group wifi6-test
regulatory-domain-profile wifi7-test
radio 1
channel 160mhz 100
eirp 15
calibrate auto-channel-select disable
calibrate auto-txpower-select disable
radio 2
radio-5g-profile wifi7-test
vap-profile wifi6-test wlan 1
channel 320mhz 5
eirp 18
calibrate auto-channel-select disable
calibrate auto-txpower-select disable
#
# Configuration of vap-profile wifi6-test
#
ssid-profile wifi6-test
security-profile wifi6-test
traffic-profile wifi7-test
band-steer disable
dynamic flow inspection disable
#
# Configuration of ssid-profile wifi6-test
#
ssid "WiFi6 @ Selfnet"
wmm edca-client ac-be aifsn 3 ecw ecwmin 0 ecwmax 0 txoplimit 0
ofdma downlink disable
ofdma uplink disable
mu-mimo disable
#
# Configuration of security-profile wifi7-test
#
security wpa2 psk pass-phrase REDACTED aes
#
Tests closer to reality
Three measurements were conducted with similar distances between the smartphone and AP. Due to the identical 5 GHz frequency configuration of the Wi-Fi 7 and Wi-Fi 6 APs, the measurements were carried out sequentially to avoid interference within the test setup. After the measurements on the Wi-Fi 7 AP were completed, it was turned off to conduct measurements on the Wi-Fi 6 AP.
The tests took place in our server room in Vaihingen, which is located in a residential hall without central Selfnet WLAN. As a result, many residents use their own routers or access points, which could potentially lead to interference with the measurement results. We do not expect a significant impact on the 6 GHz range, but there were several other networks active in the 5 GHz range. Despite the thick concrete walls in the basement and unfortunately still a high usage of the 2.4 GHz range by our members, these conditions and the potential distortions in the tests should be mentioned. Although the measurements for Wi-Fi6 and Wi-Fi 7 were performed sequentially, we present the corresponding data side by side to enable a direct and clear comparison.
Right from the initial connection setup, significant differences between the two standards become apparent. While Wi-Fi 6 establishes a connection rate of 2401 Mbps between the smartphone and AP, Wi-Fi 7 surpasses this with a more than doubled rate of 5764 Mbps.
Wi-Fi 7 connection speed
Wi-Fi 6 connection speed
In the first test scenario, the AP and smartphone were positioned at a distance of approximately 2 meters from each other. Under these conditions, Wi-Fi 7 achieved a download speed of 2042 Mbps. In contrast, the Wi-Fi 6 standard, at a similar distance, achieved a download speed of 1155 Mbps.
Wi-Fi 7 Speed test at 2 m distance
Wi-Fi 6 Speed test at 2 m distance
In the second scenario, the distance between the AP and the smartphone was approximately 10 meters in a direct line of sight. Under these conditions, Wi-Fi 7 achieved a download speed of 1238 Mbps. In comparison, the Wi-Fi 6 standard achieved a download speed of 524 Mbps at a similar distance. Interestingly, Wi-Fi 6 had a slightly better upload speed at 662 Mbps. This suggests that there may have been potential interference in the 5 GHz band in this environment, and in a less congested environment, even higher speeds might have been possible.
Wi-Fi 7 speed test at 10 m distance
Wi-Fi 6 speedtest at 10 m distance
In the final extreme test, a metal door was closed between the AP and the smartphone, while their distance was approximately 3 meters. As expected, the connection was severely impaired by the metal door and concrete. With Wi-Fi 6 in this environment, download bandwidths of 288 Mbps were possible. Surprisingly, Wi-Fi 6 achieved strong performance in the upload with 701 Mbps. This suggests that even in this scenario, there may have been interference in the 5 GHz band, and with an improved configuration, higher speeds might be achievable. In comparison, Wi-Fi 7 consistently achieved download speeds of 517 Mbps and upload speeds of 418 Mbps in this scenario. Therefore, we do not expect significant improvements here.
Wi-Fi 7 speed test through metal door
Wi-Fi 6 speed test through metal door
Classification of the test results
In conclusion, we can state that Wi-Fi 7 offers impressive capabilities in terms of bandwidth and performance, surpassing Wi-Fi 6 significantly. In most of our tested scenarios, we observed at least a doubling of speeds. Particularly impressive was the fact that at distances of over 10 meters, download speeds of over 1 gigabit were achieved.
These findings open up exciting prospects for offices, libraries, and universities, as Wi-Fi 7 offers the possibility to provide more bandwidth than is achievable through traditional RJ45 connections (most laptops are limited to 1 Gigabit RJ45 ports). However, it's important to note that the access points must be positioned in direct line of sight to the users to achieve such bandwidth. In scenarios with larger obstacles between devices, the differences between Wi-Fi 6 and Wi-Fi 7 are not as pronounced, indicating that the benefits of Wi-Fi 7 are particularly prominent in large spaces with a direct line of sight to the access points.
Selfnet is considering replacing the existing Wi-Fi 6 devices in the Vaihingen office with Wi-Fi 7 devices in the coming weeks. This change would not only improve performance but also provide the opportunity to utilize the 6 GHz band (Wi-Fi 6E). Some Selfnet laptops and devices of members already support this standard.
For dormitory rooms, the current device class does not seem economically or ecologically practical in terms of power consumption. For this reason, Selfnet plans to continue expanding with Wi-Fi 6 for the time being. However, it is expected that smaller and more cost-effective Wi-Fi 7 access points will enter the market in the next 1 - 2 years. This could be particularly interesting for dormitories with communal living areas, as they could benefit from the higher bandwidth in these areas.
In rooms where a weaker reception in the 6 GHz band is expected, the 5 GHz band is likely to remain important in the future. Even though, the Wi-Fi 7 standard promises higher bandwidth there as well. Additionally, all rooms have a LAN connection available, which in most cases provides a speed of 2.5 gigabits. Therefore, Wi-Fi 7 could primarily offer the opportunity to provide this high speed outside the rooms in the common areas.
Deutsche Übersetzung
Wi-Fi 7 Feldversuche
Wi-Fi 7 bei Selfnet
Im Einklang mit dem Vereinszweck des Selfnet e.V., den Wissenstransfer im Bereich der Informations- und Kommunikationstechnik zu fördern, haben wir uns intensiv mit Wi-Fi 7 (IEEE 802.11be) auseinandergesetzt. Selfnet hat sich in der Vergangenheit bereits frühzeitig Wi-Fi 6 (802.11ax) und Wi-Fi 6E in Wohnheimen eingesetzt. Die frühzeitige Evaluation neuer Standards im WLAN-Umfeld wurde nun auch bei 802.11be fortgesetzt. Aktuell befindet sich dieser Standard noch in der Entwicklungsphase. Wie bereit bei Wi-Fi 6 wird Wi-Fi 7 bereits von den ersten Herstellern angeboten und mögliche Änderungen in der Entwicklungsphase sollen mit Updates auf den Geräten nachgepflegt werden.
Transparenzhinweis: Für den Test von Wi-Fi 7 hat Selfnet von Huawei den Accesspoint AirEngine 8771-X1T und ein Xiaomi 13 Pro zur Verfügung gestellt bekommen.
Für den weiteren Test haben wir den bereits bei Selfnet vorhandenen WLAN-Controller AC6805 verwendet.
Der Test fand unter Verwendung von Huawei-Hardware statt, weil Selfnet aktuell im Bereich WLAN ausschließlich auf Produkte dieses Herstellers setzt.
Die gute Zusammenarbeit ermöglichte es Selfnet, bereits in einem frühen Stadium Zugang zu der entsprechenden Hardware zu erhalten.
Die bestehende Infrastruktur im Verein und das Know-how erleichtern den Test dieser Geräte. Die hier dargestellten Tests sollen darstellen, was mit der neuen Technologie Wi-Fi 7 möglich ist und dabei nicht die Leistung der Geräte bestimmter Hersteller testen. Der Verein ist jedoch offen auch auf Geräten von anderen Herstellern dieser Technologie zu testen. Diese können sich gerne bei uns unter support@selfnet.de melden, um uns entsprechende Leihhardware zur Verfügung zu stellen.
Softwareversionen
Der AirEngine 8771-X1T ist derzeit noch nicht als Standalone Access Point (FAT AP) einsetzbar. Aus diesem Grund haben wir für die Testdurchführung auf die aktive Controller-Lösung unseres Vereins zurückgegriffen. Um das neue AP-Modell zu integrieren, war ein Upgrade unseres AC6805 Access Controllers auf die Softwareversion V200R023C00SPC100 erforderlich. Zu Beginn der Testphase traten sehr inkonsistente Ergebnisse auf, die auf eine Beta-Version der AP-Firmware zurückzuführen waren.
Für die abschließenden Tests wurde daher die Softwareversion AirEngineX771-V200R023C00SPC100 auf dem AP installiert, um stabilere und zuverlässigere Testergebnisse zu gewährleisten.
Exkurs Selfnet L3 WLAN
Die Verarbeitung des Traffics im Selfnet WLAN erfolgt umfangreicher, als es aus klassischen Heimnetzen bekannt ist. Aus dem regulären LAN Netzwerk leiten die APs (Access Points) den gesamten Traffic über einen Tunnel zu dem Access Controller. Dies ermöglicht es, innerhalb eines umfangreichen Layer-3-Netzwerks jedem Nutzer ein individuelles IP-Netz im WLAN zur Verfügung zu stellen. Zwei speziell konfigurierte Server, die sich hinter den redundanten Access Controllern befinden, übernehmen die Rolle des Gateways und der Client Isolierung im WLAN-Netzwerk. Diese Server werden automatisch mit den relavanten Informationen zum Betrieb versorgt.
Im Winter 2022 überstieg die Anzahl der gleichzetigen WLAN-Clients des Selfnet e.V. erstmals die Marke von 3.000. Die Server, konfiguriert mit über 10.000 Interfaces und einem Traffic von etwa 2 Gigabit, zeigten Leistungslücken und verzeichneten CPU-Auslastungen von 100 %. Die veraltete Hardware, die ihren Ursprung im Jahr 2014 hat und mit einem Intel(R) Atom(TM) CPU C2750 sowie 16 GB RAM ausgestattet ist, konnte nicht mehr mit der Effizienz moderner Geräte mithalten.
2023 stand im Zeichen der Erneuerung der Hardware. Parallel zu dem Tausch unserer gesamten Access-Plattform haben wir uns auch um die WLAN Gateways gekümmert. Rechtzeitig zum Beginn des Wintersemesters wurde der erste der neuen Server in Betrieb genommen. Angetrieben wird er von einem AMD EPYC 7313P Prozessor, der über die doppelte Anzahl an Kernen verfügt, Hyperthreading unterstützt und eine höhere Single-Core-Performance aufweist. Aufgrund der geringen RAM-Auslastung von unter 1 GB blieb es bei einer Ausstattung von 16 GB RAM, aufgeteilt auf zwei 8GB-Riegel, um Ausfallsicherheit und Bandbreitenoptimierung zu gewährleisten. Mit zusätzlichen SFP+ Ports können die neuen Server nun redundant an die ACs angeschlossen werden, wodurch eine erhöhte Redundanz bereitgestellt werden soll. Die Integration des neuen Backupserver auf der neuen Hardware soll in den nächsten Wochen folgen.
Verkabelung Testaufbau
Der bestehende Layer-3-Netzwerkaufbau ist in der Lage, unseren Mitgliedern im Selfnet-Netzwerk hohe WLAN-Bandbreiten zu bieten. Allerdings erweist er sich als ungeeignet für Testsszenarien, die darauf abzielen, die maximale Geschwindigkeit und Performance von Wi-Fi 7 zu evaluieren. Daher haben wir uns im Testszenario dafür entschieden, die Controller-Infrastruktur lediglich für Managementzwecke zu nutzen. Der Traffic wird direkt als Local Breakout von den APs (Access Points) ausgeleitet.
Der Access Point des Modells 8771-X1T wurde an einen Huawei Switch S5732-H48UM4Y2CZ-V2 angeschlossen, um sowohl mit Strom versorgt als auch gemanagt zu werden. Dieser Switch unterstützt Power over Ethernet (PoE) gemäß dem 802.3bt Standard, der erforderlich ist, um den 8771-X1T mit voller Leistung betreiben zu können. In unserem Accessnetzwerk wird dieser Switchtyp von Selfnet allerdings nur mit einer Lizenz für 2,5 Gigabit betrieben.
Im Kontext dieses Testaufbaus erwies sich die Mehrzahl an Ports am AP als vorteilhaft. Der 8771-X1T verfügt über drei Ports, die Datenübertragungsraten von bis zu 10 Gigabit unterstützen - zwei davon über RJ45 und einer über SFP+. Da ein RJ45-Port für Stromversorgung und Management mit dem Switch verbunden ist, bleiben ein SFP+ und ein RJ45-Port mit 10 Gigabit Kapazität für weitere Anwendungen verfügbar. Dieser Port soll verwendet werden um einen Speedtestserver direkt mit dem AP zu verbinden. Die Verbindung sieht dadurch folgendermaßen aus:
Speedtestserver
|
| (Ethernet)
V
AP 8771-X1T - - - - (WiFi 7) - - - - - > Xiaomi 13 Pro
|
| (Ethernet)
V
Switch S5732-H48UM4Y2CZ-V2
|
| (Ethernet)
V
Core Netzwerk
|
| (Ethernet)
V
AC6805
Speedtestserver
Für die Durchführung von Speedtests mit hohen Bandbreiten entschied sich Selfnet bereits für andere Testszenarien für einen einen Mac Mini mit einer 10 Gigabit Netzwerkkarte Onboard. Frühere Tests mit verschiedenen RJ45-Adaptern und Karten, die mehr als 1 Gigabit unterstützen, lieferten in Tests teilweise schwankende Ergebnisse. Der Mac Mini bietet den Vorteil, dass er in einer „Out of the Box“-Version mit 10-Gigabit-RJ45-Interfaces erhältlich ist und direkt mit der passenden Software geliefert wird, wodurch Treiberprobleme vermieden werden.
Zur Überprüfung der Leistungsfähigkeit des Setups wurden zwei Mac Minis mit vergleichbarer Ausstattung miteinander verbunden und Speedtests durchgeführt. Als Testtools kamen iperf3 und ein Browser-basierter Geschwindigkeitstest zum Einsatz, für den die Librespeed-Software verwendet wurde. Letztere wurde als Docker-Container auf einem der Mac Minis ausgeführt, wobei das Docker Image linuxserver/librespeed zum Einsatz kam, das für ARM-Prozessoren optimiert ist. Der von Selfnet eingesetzte Mac Mini verfügt über folgende Spezifikationen: M2 8C CPU, 10C GPU, 16 GB RAM, 512 GB SSD und ein 10 Gbit Ethernet-Interface.
In Tests, bei denen zwei Mac Minis mit vergleichbarer Ausstattung miteinander kommunizierten, wurden über den HTTP Test 9963 Mbps im Download und 2442 Mbps im Upload erreicht. Diese Ergebnisse belegen, dass das Setup grundsätzlich 10 Gigabit unterstützt.
Speedtest Mac mini - Mac mini
Es wurde festgestellt, dass die Generierung von Upload-Dateien im Browser bei einem Mac mini auf der Clientseite bei etwa 2,5 Gbit/s ihre Grenze erreicht. Jedoch bestätigten zusätzliche iperf3-Tests zwischen beiden Mac Minis eine Übertragungsgeschwindigkeiten von etwa 9,4 Gbit/s in beide Richtungen.
iperf3 Test
selfnet@mac-mini ~ % iperf3 -c 10.0.0.1
Connecting to host 10.0.0.1, port 5201
[ 5] local 10.0.0.2 port 49907 connected to 10.0.0.1 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 1.09 GBytes 9.38 Gbits/sec
[ 5] 1.00-2.00 sec 1.10 GBytes 9.41 Gbits/sec
[ 5] 2.00-3.00 sec 1.10 GBytes 9.41 Gbits/sec
[ 5] 3.00-4.00 sec 1.10 GBytes 9.41 Gbits/sec
[ 5] 4.00-5.00 sec 1.10 GBytes 9.41 Gbits/sec
[ 5] 5.00-6.00 sec 1.10 GBytes 9.41 Gbits/sec
[ 5] 6.00-7.00 sec 1.10 GBytes 9.41 Gbits/sec
[ 5] 7.00-8.00 sec 1.10 GBytes 9.41 Gbits/sec
[ 5] 8.00-9.00 sec 1.10 GBytes 9.41 Gbits/sec
[ 5] 9.00-10.00 sec 1.10 GBytes 9.41 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 11.0 GBytes 9.41 Gbits/sec sender
[ 5] 0.00-10.00 sec 11.0 GBytes 9.41 Gbits/sec receiver
iperf Done
iperf3 reverse Test
selfnet@mac-mini ~ % iperf3 -c 10.0.0.1 -R
Connecting to host 10.0.0.1, port 5201
Reverse mode, remote host 10.0.0.1 is sending
[ 5] local 10.0.0.2 port 49909 connected to 10.0.0.1 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 1.09 GBytes 9.34 Gbits/sec
[ 5] 1.00-2.00 sec 1.10 GBytes 9.41 Gbits/sec
[ 5] 2.00-3.00 sec 1.10 GBytes 9.41 Gbits/sec
[ 5] 3.00-4.00 sec 1.10 GBytes 9.41 Gbits/sec
[ 5] 4.00-5.00 sec 1.10 GBytes 9.41 Gbits/sec
[ 5] 5.00-6.00 sec 1.10 GBytes 9.41 Gbits/sec
[ 5] 6.00-7.00 sec 1.10 GBytes 9.41 Gbits/sec
^C[ 5] 7.00-7.27 sec 303 MBytes 9.41 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-7.27 sec 0.00 Bytes 0.00 bits/sec sender
[ 5] 0.00-7.27 sec 7.96 GBytes 9.40 Gbits/sec receiver
iperf3: interrupt - the client has terminated
Für die weiterführenden Tests wurde der Mac Mini direkt über den freien RJ45-Port mit dem AP verbunden und diente als Speedtest-Server. Es wurde eine volle 10 Gigabit Geschwindigkeit erreicht und erfolgreich ausgehandelt, was sowohl vom Mac Mini als auch vom AP entsprechend dargestellt wurde.
AP Konfiguration
Die Konfiguration des Wi-Fi 7 AP basierte auf den Erfahrungen und Erkenntnissen, die Huawei uns aus Ihren eigenen Tests bereitgestellt hat. Uns wurden Unterlagen zur Verfügung, die detaillierte Anleitungen enthielten, wie das WLAN für optimale Geschwindigkeitsleistungen konfiguriert werden sollte. Die grundlegende Konfiguration ist wie folgt gestaltet:
[ac-wlan-view]disp ap ap-group wifi7-test
Total AP information:
nor : normal [1]
ExtraInfo : Extra information
----------------------------------------------------------------------------------------------------------------------
ID MAC Name Group IP Type State STA Uptime ExtraInfo Scene
----------------------------------------------------------------------------------------------------------------------
1 XXXX-XXXX-XXXX wifi7-test wifi7-test XXX.XXXX.XXX.XXXX AirEngine8771-X1T nor 0 3H:2M:38S - -
----------------------------------------------------------------------------------------------------------------------
Total: 1
# Configuration for ap-group wifi7-test
#
radio 1
radio-5g-profile wifi7-test
vap-profile wifi7-test wlan 1
#
# Configuration for ap-id 1
#
ap-name wifi7-test
ap-group wifi7-test
regulatory-domain-profile wifi7-test
radio 1
channel 160mhz 100
eirp 15
calibrate auto-channel-select disable
calibrate auto-txpower-select disable
radio 2
radio-5g-profile wifi7-test
vap-profile wifi7-test wlan 1
channel 320mhz 5
eirp 18
calibrate auto-channel-select disable
calibrate auto-txpower-select disable
#
# Configuration of radio-5g-profile wifi7-test
#
rrm-profile wifi7-test
rts-cts-mode disable
a-msdu enable
air-scan-profile wifi7-test
#
# Configuration of rrm-profile wifi7-test
#
multimedia-air-optimize disable
bss-color disable
spatial-reuse disable
#
# Configuration of air-scan-profil wifi7-test
#
scan-disable
#
# Configuration of vap-profile wifi7-test
#
ssid-profile wifi7-test
security-profile wifi7-test
traffic-profile wifi7-test
band-steer disable
dynamic flow inspection disable
#
# Configuration of ssid-profile wifi7-test
#
ssid "WiFi7 @ Selfnet"
wmm edca-client ac-be aifsn 3 ecw ecwmin 0 ecwmax 0 txoplimit 0
ofdma downlink disable
ofdma uplink disable
mu-mimo disable
#
# Configuration of security-profile wifi7-test
#
security wpa3 sae pass-phrase REDACTED aes
#
# Configuration of traffic-profile wifi7-test
#
rate-limit client dynamic disable
#
Zusätzliche Testparameter
Für ein optimales Speedtest-Ergebnis sind diverse Faktoren zu berücksichtigen. In den anfänglichen Phasen der Tests waren die Ergebnisse stark variabel, sie schwankten zwischen 500 Mbit und 3 Gigabit. Diese Inkonsistenz der Testergebnisse war primär auf eine Beta-Firmware zurückzuführen, mit der die Geräte an uns geliefert wurden. Einige Wochen später erhielten wir eine aktualisierte Software aus dem Entwicklungs-Bereich, die eine signifikante Verbesserung der Testergebnisse zur Folge hatte.
Neben der bereits erwähnten Firmware spielten auch physikalische Bedingungen eine entscheidende Rolle bei der Optimierung der Testergebnisse. Die Positionierung des Testgeräts ist von zentraler Bedeutung; optimalerweise sollte es direkt auf der 6-GHz-Antenne des AP platziert werden, die sich auf der unteren Vorderseite des Geräts befindet. Uns ist bewusst, dass dies kein Setup ist, wie es in der Praxis Anwedung findet, in diesem Teil des Tests war das Ziel, herauszufinden, welcher Datendurchsatz theoretisch möglich ist.
Eine Herausforderung während der Tests war die Wärmeentwicklung. Der AP erwärmt sich im Betrieb stärker als gewöhnliche Einsteigermodelle – ein Umstand, der für APs mit erweiterten Features und höheren Geschwindigkeiten charakteristisch ist. Auch das Smartphone, das als Testclient diente, wurde aufgrund der intensiven CPU-Nutzung und der direkten Nähe zum AP schnell warm.
Dies erforderte besondere Aufmerksamkeit, da eine übermäßige Erwärmung die Testergebnisse negativ beeinflussen kann. Bei längerer Testdauer empfiehlt es sich daher, Maßnahmen zur Abkühlung des Geräts zu ergreifen. Auch das Energiemanagement des Smartphones ist ein wichtiger Aspekt: Um sicherzustellen, dass keine Energiesparmodi aktiviert werden, die die Leistung beeinträchtigen könnten, sollte das Smartphone einen vollen Akku haben. Gleichzeitig ist es ratsam, das Laden während des Tests zu vermeiden, um zusätzliche Wärmeentwicklung und damit potenzielle Verzerrungen der Ergebnisse auszuschließen.
Wi-Fi 7 Test unter Optimalbedingungen
Nach der Umsetzung aller genannten Vorgaben und dem Update auf die neueste Firmware wurden konstante Geschwindigkeiten erzielt, die die erwarteten Leistungen von Wi-Fi 6 übertreffen.
Die Tests wurden unter den bestmöglichsten Bedingungen durchgeführt und sowohl über HTTP als auch über iPerf3 ausgeführt. Für die iPerf3-Tests wurde die App Magic iPerf auf dem Test Smartphone installiert, dieses hat als Server fungiert. Der als Speedtest Client genutzte Mac mini hat sich dann mit diesem iPerf3 Server auf dem Smartphone verbunden.
Während der Tests mit dem iPerf3-Protokoll wurden Geschwindigkeiten von etwa 3 Gigabit erzielt. Im folgenden ist ein Auszug aus dem iPerf3-Output mit den erzielten Ergebnissen:
selfnet@mac-mini Documents % iperf3 -c 10.0.0.1 -i 1 -R -t 60 -P 30 -p 5201
Connecting to host 10.0.0.1, port 5201
Reverse mode, remote host 10.0.0.1 is sending
.
.
.
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.01 sec 12.8 MBytes 106 Mbits/sec
[ 7] 0.00-1.01 sec 12.8 MBytes 106 Mbits/sec
[ 9] 0.00-1.01 sec 12.8 MBytes 106 Mbits/sec
[ 11] 0.00-1.01 sec 12.8 MBytes 106 Mbits/sec
.
.
.
[SUM] 0.00-1.01 sec 382 MBytes 3.19 Gbits/sec
.
.
[SUM] 1.01-2.01 sec 424 MBytes 3.54 Gbits/sec
.
.
[SUM] 2.01-3.00 sec 379 MBytes 3.21 Gbits
.
.
[SUM] 3.00-4.01 sec 300 MBytes 2.50 Gbits/sec
.
.
[SUM] 4.01-5.06 sec 345 MBytes 2.76 Gbits/sec
.
.
[SUM] 5.06-6.00 sec 360 MBytes 3.20 Gbits/sec
.
.
[SUM] 6.00-7.01 sec 360 MBytes 3.00 Gbits/sec
.
.
[SUM] 7.01-8.01 sec 364 MBytes 3.06 Gbits/sec
.
.
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-60.01 sec 732 MBytes 102 Mbits/sec
sender
[ 5] 0.00-60.01 sec 719 MBytes 101 Mbits/sec
receiver
.
.
.
[ 63] 0.00-60.01 sec 719 MBytes 101 Mbits/sec
receiver
[SUM] 0.00-60.01 sec 21.4 GBytes 3.07 Gbits/sec
sender
[SUM] 0.00-60.01 sec 21.1 GBytes 3.02 Gbits/sec
receiver
iperf Done.
Die Ergebnisse von iPerf3 zeigen eine gewisse Schwankung der Werte, die jedoch aus unserer Perspektive in einem akzeptablen Rahmen für eine Funkverbindung liegen und einen signifikanten Mehrwert gegenüber älteren WLAN-Standards darstellen. Es wurde eine Geschwindigkeit von mindestens 2,5 Gigabit erreicht, im Durchschnitt sogar von über 3 Gigabit. Trotz der Verwendung einer noch nicht vollständig ausgereiften GA-Firmware zeigen diese Ergebnisse vielversprechendes für die Datenraten von WLAN in der Zukunft. Im Testaufbau wurden ebenfalls Tests über HTTP mittels LibreSpeed dabei. Dabei varierten die Download-Geschwindigkeiten, befanden sich jedoch stetig knapp unter oder knapp über 3 Gigabit. Die Ergebnisse sind daher sehr vergleichbar mit dem was iperf3 gezeigt hat.
HTTP Test Wi-Fi 7 unter Optimalbedingungen
Interessant an dem HTTP Testergebnis ist, dass der Upload mit 2613 Mbps fast 200 Mbps besser ist als bei der direkten Verbindung zwischen zwei Mac Minis.
Damit auch die Leistung von dem Mac mini zusätzlich zu dem direkten Mac zu Mac Test bei einem Speedtest mit dem Smartphone mit einbezogen werden kann, wurde während einem HTTP Speedtest von dem Smartphone zum Libre Speed die Auslastung beobachtet.
Speedtestserver CPU Auslastung
Testaufbau näher an der Realität
Nachdem wir Tests unter nahezu idealen Bedingungen durchgeführt haben, haben wir uns darauf konzentriert, die Tests unter realistischeren Bedingungen zu wiederholen. In diesem Fall wurden ausschließlich HTTP-Tests durchgeführt, die Konfiguration des Wi-Fi 7 AP blieb dabei unverändert. Für einen direkten Vergleich der Leistung wurde ein Wi-Fi 6 AP in die Testreihe hinzugezogen.
Selfnet setzt in vielen seiner Büroräume auf den AirEngine 8760-X1-PRO, der auch bei vielen anwesenden Mitgliedern ausreichend Bandbreite liefern soll. Der AP 8771-X1T ist der direkte Nachfolger und repräsentiert Huaweis erstes Geräte in der höchsten AP-Klasse, welches das 6-GHz-Band unterstützt. Mit seiner Ausstattung, einschließlich zwei RJ45-Ports mit 10 Gigabit Schnittstellengeschwindigkeit und einem SFP+ Port, dient das Modell als adäquate Basis für einen direkten Leistungsvergleich zwischen den Wi-Fi 6- und Wi-Fi 7-Geräten, da es sehr vergleichbare Parameter aufweist.
Wir haben uns bemüht, eine Konfiguration auf dem Wi-Fi 6 AP zu erstellen, die der des Wi-Fi 7 Geräts so ähnlich wie möglich ist. Dies soll einen möglichst präzisen und direkten Vergleich der Leistungsdaten beider WiFi Standards in unserem Einsatzszenario ermöglichen.
Auf dem Gerät wurde dafür folgende Konfiguration angewendet:
[ac-wlan-view]disp ap ap-group wifi6-test
Total AP information:
nor : normal [1]
ExtraInfo : Extra information
------------------------------------------------------------------------------------------------------------------------------
ID MAC Name Group IP Type State STA Uptime ExtraInfo Scene
------------------------------------------------------------------------------------------------------------------------------
2 XXXX-XXXX-XXXX wifi6-test wifi6-test XXX.XXX.XXX.XXX AirEngine8760-X1-PRO nor 0 3D:4H:23M:33S - -
------------------------------------------------------------------------------------------------------------------------------
Total: 1
# Configuration for ap-group wifi6-test
#
radio 1
radio-5g-profile wifi7-test
vap-profile wifi6-test wlan 1
#
# Configuration for ap-id 2
#
ap-name wifi6-test
ap-group wifi6-test
regulatory-domain-profile wifi7-test
radio 1
channel 160mhz 100
eirp 15
calibrate auto-channel-select disable
calibrate auto-txpower-select disable
radio 2
radio-5g-profile wifi7-test
vap-profile wifi6-test wlan 1
channel 320mhz 5
eirp 18
calibrate auto-channel-select disable
calibrate auto-txpower-select disable
#
# Configuration of vap-profile wifi6-test
#
ssid-profile wifi6-test
security-profile wifi6-test
traffic-profile wifi7-test
band-steer disable
dynamic flow inspection disable
#
# Configuration of ssid-profile wifi6-test
#
ssid "WiFi6 @ Selfnet"
wmm edca-client ac-be aifsn 3 ecw ecwmin 0 ecwmax 0 txoplimit 0
ofdma downlink disable
ofdma uplink disable
mu-mimo disable
#
# Configuration of security-profile wifi7-test
#
security wpa2 psk pass-phrase REDACTED aes
#
Tests näher an der Realität
Drei Messungen wurden mit ähnlichen Abständen zwischen Smartphone und AP durchgeführt. Aufgrund der gleichen 5 GHz Frequenzkonfiguration des Wi-Fi 7 und Wi-Fi 6 APs wurden die Messungen sequenziell durchgeführt. So sollten Störungen innerhalb vom Testaufbau vermieden werden. Nachdem die Messungen an dem Wi-Fi 7 AP abgeschlossen waren, wurde dieser abgeschaltet, um die Messungen am Wi-Fi 6 AP vorzunehmen.
Die Tests fanden in unserem Serverraum in Vaihingen statt, der sich in einem Wohnheim ohne zentrales Selfnet WLAN befindet. Infolgedessen nutzen viele Bewohner ihre eigenen Router oder Access Points, was potenziell zu Störungen von den Messergebnissen führen kann. Wir gehen nicht davon aus, dass der 6GHz Bereich merklich beeinträchtigt wird, allerdings waren im 5GHz Bereich mehrere andere Netzwerke aktiv. Trotz der dicken Betonwände im Keller und leider noch einer hohen Nutzung des 2,4 GHz Bereichs durch unsere Mitglieder sollten diese Umstände und die damit möglichen Verzerrungen in den Tests erwähnt werden. Obwohl die Messungen für Wi-Fi 6 und Wi-Fi 7 sequenziell durchgeführt wurden, präsentieren wir die entsprechenden Datenpaare nebeneinander, um einen direkten und übersichtlichen Vergleich zu ermöglichen.
Bereits beim initialen Verbindungsaufbau werden deutliche Unterschiede zwischen den beiden Standards sichtbar. Während Wi-Fi 6 eine Verbindungsrate von 2401 Mbps zwischen Smartphone und AP aufbaut, übertrifft Wi-Fi 7 dies mit einer mehr als doppelt so hohen Rate von 5764 Mbps.
Wi-Fi 7 Verbindungsgeschwindigkeit
Wi-Fi 6 Verbindungsgeschwindigkeit
Im ersten Testszenario befanden sich AP und Smartphone in einem Abstand von ungefähr 2 Metern zueinander. Unter diesen Bedingungen erreichte Wi-Fi 7 2042 Mbps im Download. Im Gegensatz dazu konnte mit dem Wi-Fi 6-Standard bei ähnlichem Abstand eine Downloadgeschwindigkeit von 1155 Mbps erzielt werden.
Wi-Fi 7 Speedtest 2 m Abstand
Wi-Fi 6 Speedtest 2 m Abstand
Im zweiten Szenario betrug die Entfernung zwischen AP und Smartphone ungefähr 10 Meter direkte Luftlinie, wobei die Geräte in Sichtweite zueinander positioniert waren. Unter diesen Bedingungen erreichte Wi-Fi 7 1238 Mbps im Download. Im Vergleich dazu erzielte der Wi-Fi 6-Standard in einer vergleichbaren Entfernung einen Downloadwert von 524 Mbps. Interessanterweise war der Upload mit 662 Mbps bei Wi-Fi 6 etwas besser. Dies lässt vermuten, dass in dieser Umgebung möglicherweise eine Belastung des 5-GHz-Bands vorlag, und in einer weniger gestörten Umgebung sogar höhere Geschwindigkeit möglich gewesen wäre.
Wi-Fi 7 Speedtest 10 m Abstand
Wi-Fi 6 Speedtest 10 m Abstand
Im letzten Extremtest wurde eine Metalltür zwischen dem AP und dem Smartphone geschlossen, die Entfernung zwischen AP und Smartphone betrug hierbei etwas 3 Meter. Wie erwartet war die Verbindung durch die Metalltür und Beton stark beeinträchtigt. Mit Wi-Fi 6 waren in dieser Umgebung Download-Bandbreiten von 288 Mbps möglich. Überraschenderweise konnte Wi-Fi 6 hier im Upload mit 701 Mbps eine starke Leistung erzielen. Dies legt nahe, dass auch in diesem Szenario möglicherweise Störungen im 5-GHz-Band vorhanden waren und mit einer verbesserten Konfiguration höhere Geschwindigkeiten möglich wären. Im Vergleich dazu erreichte Wi-Fi 7 in diesem Szenario konstante Download-Geschwindigkeiten von 517 Mbps und Upload-Geschwindigkeiten von 418 Mbps. Hier erwarten wir daher keine wesentlichen Verbesserungen.
Wi-Fi 7 Speedtest durch Metalltür
Wi-Fi 6 Speedtest durch Metalltür
Einordnung der Testergebnisse
Abschließend können wir festhalten, dass Wi-Fi 7 beeindruckende Möglichkeiten in Bezug auf Bandbreite und Leistung bietet, die Wi-Fi 6 deutlich übersteigen. In den meisten unserer getesteten Szenarien konnten wir von mindestens einer Verdoppelung der Geschwindigkeiten sprechen. Besonders beeindruckend war die Tatsache, dass bei Entfernungen von über 10 Metern Download-Geschwindigkeiten von über 1 Gigabit erreicht wurden.
Diese Erkenntnisse eröffnen spannende Perspektiven für Büros, Bibliotheken und Hochschulen, da Wi-Fi 7 die Möglichkeit bietet, mehr Bandbreite bereitzustellen, als es über herkömmliche RJ45-Anschlüsse (die meisten Laptops sind bisher auf 1 Gigabit RJ45-Anschlüsse beschränkt) möglich ist. Allerdings ist zu beachten, dass die Access Points in direkter Sichtweite der Nutzer positioniert sein müssen, um solche Bandbreiten zu erreichen.
In Szenarien mit größeren Hindernissen zwischen den Geräten fallen die Unterschiede zwischen Wi-Fi 6 und Wi-Fi 7 nicht mehr so drastisch auf, was darauf hinweist, dass die Vorteile von Wi-Fi 7 insbesondere in großen Räumen mit direkter Sichtlinie zu den Access Points zur Geltung kommen.
Selfnet erwägt die bestehenden Wi-Fi 6 Geräte im Büro in Vaihingen in den nächsten Wochen mit Wi-Fi 7 Geräten zu ersetzen. Dies würde nicht nur die Leistung verbessern, sondern auch die Möglichkeit bieten, das 6GHz-Band (Wi-Fi 6E) zu nutzen. Einige Selfnet Laptops und Geräte von Mitgliedern unterstützen diesen Standard bereits.
Für Wohnheimszimmer scheint die aktuelle Geräteklasse aus wirtschaftlichen und ökologischen Gründen in Bezug auf den Stromverbrauch noch nicht sinnvoll zu sein. Aus diesem Grund plant Selfnet vorerst weiterhin den Ausbau mit Wi-Fi 6. Es wird jedoch erwartet, dass in den nächsten 1 - 2 Jahren kleinere und kostengünstigere Wi-Fi 7 Access Points auf den Markt kommen werden. Dies könnte insbesondere für Wohnheime mit gemeinschaftlichen Wohnbereichen interessant sein, da sie von den höheren Bandbreiten in diesen Bereichen profitieren könnten.
In den Zimmern, in denen möglicherweise ein schlechterer Empfang im 6GHz-Band zu erwarten ist, wird das 5 GHz Band voraussichtlich auch in Zukunft von großer Bedeutung sein. Wobei auch hier der Wi-Fi 7 Standard auf dem Band höhere Bandbreiten verspricht. Zusätzlich steht jedoch in allen Zimmern ein LAN-Anschluss zur Verfügung, der in den meisten Fällen eine Geschwindigkeit von 2,5 Gigabit bietet. Daher könnte Wi-Fi 7 vor allem die Möglichkeit bieten, diese hohe Geschwindigkeit außerhalb der Zimmer in den Gemeinschaftsbereichen bereitzustellen.
Deutsche Übersetzung weiter unten
A DHCP Server automatically allocates IP addresses to clients in a network using the Dynamic Host Configuration Protocol. If our DHCP Server fails, the clients in our LAN will not be able to get an IP address and can't connect to the internet. Therefore our DHCP Server is a crucial part of our infrastructure. While the Selfnet WLAN uses a FreeRADIUS Server to allocate IPs via DHCP, all WiFi Access Points get their IPs from the DHCP Server. So in case of a failure the WiFi is also affected.
In the past months we had quite a few problems with our old DHCP server. Until recently we used the ISC DHCP Server which is considered the industry standard. Since end of this year however ISC DHCP is end of life which means we won't get any updates or support, unless we pay the developers. Due to this we decided to migrate to a new DHCP server. The Kea DHCP Server is also developed by the Internet Systems Consortium and promises to be a drop-in replacement for ISC DHCP.
Since we don't want to manually edit the DHCP configuration every time a new member gets access to the network there is a Python script in place which generates the configuration automatically every 15 minutes by querying our PostgreSQL database. The old configuration was then generated using Jinja Templates. Our new scipt stores the configuration in Python data structures which get serialized to JSON which is required by Kea. A single subnet in the new configuration looks like this:
{
"subnet": "100.72.0.16/28",
"option-data": [
{
"name": "routers",
"data": "100.72.0.30"
},
{
"name": "domain-name",
"data": "user.selfnet.de"
}
],
"pools": [
{
"pool": "100.72.0.17 - 100.72.0.29"
}
],
"reservations": []
}
Every user gets a /28 subnet which consists of 16 IP addresses. Since the first IP (in this case 100.72.0.16
) is the network address, the last IP (100.72.31
) is the broadcast IP and the second to last(see option routers
) is the Gateway IP to the switch we end up with 13 available IPs per user (this range is specified in the pool
field). Additionally users have the option to get a public IPv4 address and forward ports to a device in the local network using MySelfnet. To ensure the device receives external traffic the local IP has to stay the same. This is done through the reservations
field by specifying the MAC address of the device.
Additionally a few global options are specified for all subnets:
"valid-lifetime": 43200,
"max-valid-lifetime": 86400,
...
"option-data": [
{
"name": "domain-name-servers",
"data": "141.70.124.5"
},
{
"name": "ntp-servers",
"data": "141.70.124.2"
}
],
"next-server": "141.70.126.60",
"server-hostname": "netboot-1.server.selfnet.de",
"boot-file-name": "/pxelinux.0",
The IP address allocated to a client is always valid for 24 hours (max-valid-lifetime
) and clients are supposed to renew the allocation after 12 hours (valid-lifetime
). Besides the IP itself the response from the DHCP server also contains some additional information such as the IPs of our DNS and NTP-Servers. The last three lines advertise our netboot server which can be used to install a new operating system directly from the network.
This configuration is generated for around 6800 subnets and contains 700000 lines of text. To ensure high availability our DHCP Servers run redundantly as a pair, so if one server fails the other one takes over. After implementing and testing the new DHCP server over the last few months we migrated on December 8th. Since our old DHCP server ran redundantly as well, we were able to migrate one by one which kept downtime to a minimum.
Besides the DHCP migration there are a lot of other projects we're currently working on. We're always happy about new volunteers joining us to help with existing projects or to realize new ideas. You're welcome to join us in our Vaihingen office on Monays and Thursdays during support hours.
The Selfnet-Team
Deutsche Übersetzung
Migration unseres DHCP Servers auf Kea
Ein DHCP Server ist für die automatische Allokation von IP Adressen an die Clients zuständig. Wie der Name sagt, geschieht das über das Dynamic Host Configuration Protocol. Wenn unser DHCP Server nicht funktioniert, bekommen die Clients im LAN keine IP Adresse und kommen nicht ins Internet. Daher ist die dauerhafte Verfügbarkeit des DHCP Servers essenziell für uns. Das Selfnet WLAN hat einen separaten FreeRADIUS Server, der die Allokation der IPs über DHCP übernimmt. Da jedoch die Access Points ihre IP Adressen über den DHCP Server bekommen ist das WLAN von einem Ausfall des DHCP Servers auch betroffen.
In letzter Zeit hatten wir häufiger mal Probleme mit unserem alten DHCP Server. Bisher haben wir den ISC DHCP Server verwendet, der allgemein hin als Industriestandard gilt. Seit Ende diesen Jahres ist der ISC DHCP Server jedoch End of Life, bekommt also keine Updates oder Support mehr. Firmenkunden können sich verlängerten Support erkaufen, wir als Studentennetzwerk wollen das aber nicht und da der DHCP Server aktuell sowieso in regelmäßigen Abständen ausgefallen ist und neu gestartet werden musste, haben wir die Gelegenheit ergriffen und auf einen neuen DHCP Server migriert. Der Kea DHCP Server wird ebenfalls vom Internet Systems Consortium entwickelt und soll ein vollwertiger Ersatz für den alten DHCP Server sein.
Da wir die Konfiguration des DHCP Servers nicht manuell anpassen möchten, sobald wir ein neues Mitglied an das Netzwerk angeschlossen haben, wird die Konfigurationsdatei alle 15 Minuten automatisch generiert und bei Veränderungen auf den DHCP Server kopiert. Grundlage dafür ist unsere PostgresSQL Datenbank, auf der die Subnetze aller Mitglieder hinterlegt sind. Um die Konfiguration zu generieren, werden in einem Python Skript die betreffenden Daten mit einer SQL Abfrage aus der Datenbank abgerufen und in Python Dictionaries gespeichert. Die alte Konfiguration wurde daraus mithilfe von Jinja-Templates generiert. Da der neue DHCP Server die Konfiguration im JSON Format erwartet, wird die Datenstruktur direkt serialisiert. Ein Subnetz der Kea Konfiguration sieht so aus:
{
"subnet": "100.72.0.16/28",
"option-data": [
{
"name": "routers",
"data": "100.72.0.30"
},
{
"name": "domain-name",
"data": "user.selfnet.de"
}
],
"pools": [
{
"pool": "100.72.0.17 - 100.72.0.29"
}
],
"reservations": []
}
Wir stellen jedem User ein /28 Subnetz zur Verfügung, das Subnetz ist also 16 IP Adressen groß. Dabei ist die erste IP Adresse (hier 100.72.0.16
) die Netzwerk Adresse, die letzte ist die Broadcast Adresse (100.72.0.31
) und die vorletzte ist die Gateway Adresse zum Switch (hier als Option routers
mit 100.72.0.30
angegeben). Es bleiben also 13 Adressen für den User übrig (das ist hier im pool
angegeben). Über das MySelfnet Portal hat man die Möglichkeit, Geräten eine öffentliche IPv4 Adresse zuzuweisen und Ports freizuschalten. Dafür muss die IP Adresse des betreffenden Gerätes im lokalen Netz gleich bleiben. Daher können unter reservations
MAC-Adressen angegeben werde, die immer die selbe IP bekommen sollen.
Zusätzlich gibt der DHCP Server noch ein paar Informationen an alle Subnetze weiter:
"valid-lifetime": 43200,
"max-valid-lifetime": 86400,
...
"option-data": [
{
"name": "domain-name-servers",
"data": "141.70.124.5"
},
{
"name": "ntp-servers",
"data": "141.70.124.2"
}
],
"next-server": "141.70.126.60",
"server-hostname": "netboot-1.server.selfnet.de",
"boot-file-name": "/pxelinux.0",
Die IP Adresse die ein Client erhält ist immer für 24 Stunden gültig max-valid-lifetime
, wobei die Clients üblicherweise bereits nach 12 Stunden mit dem DHCP Server kommunizieren (valid-lifetime
) um die Laufzeit der Zuweisung zu verlängern. In der Antwort des DHCP Servers wird neben der IP Adresse auch unser DNS und NTP-Server angegeben. Zudem wird mit den letzten drei Optionen ein Netboot Server angegeben, über das jedes Gerät im LAN ein neues Betriebssystem über das Netzwerk installieren kann.
Diese Konfiguration wird für ca. 6800 Subnetze generiert und umfasst ca. 700000 Zeilen. Um hohe Verfügbarkeit sicherzustellen laufen die DHCP Server als High-Availability Paar, sodass ein zweiter Server übernimmt falls der erste ausfällt. Nachdem wir die neue Konfiguration in den letzten Monaten implementiert und in ein paar Wohnheimen getestet haben wurde der DHCP Server am 8.12. in den laufenden Betrieb migriert. Da wir den alten DHCP Server auch redundant betrieben haben, konnten wir erst einen und dann den anderen DHCP Server migrieren, ohne dass es zu größeren Ausfällen kam.
Neben dem DHCP Server stehen aktuell noch zahlreiche weitere Projekte an, für die wir uns über Unterstützung freuen würden: Den Switch-Tausch im Laufe des nächsten Jahres, das Upgrade der WLAN-Gateway, der Ausbau unseres Monitorings, etc. Wenn du Interesse hast, an den Projekten mitzuwirken oder eigene Ideen umzusetzen, komme gerne Montags oder Donnerstags zu unseren Support-Stunden nach Vaihingen in unser Büro. Wir freuen uns immer über Freiwillige, egal ob technisch versiert oder nicht.
Das Selfnet-Team