Allgemeine Fragen zu Bandbreite und Performance bei mehreren Geräten am Heimrouter
- Ersteller cabriofahrer
- Erstellt am
Zieht der Berry irgendwelche daten von dem PC? Also videos oder so?
(upnp dlna minidlna oder sowas?)
(upnp dlna minidlna oder sowas?)
cabriofahrer
Well-Known Member
Das ist richtig. Hier haben sich aber, auch wegen dem Kabel, andere Baustellen aufgetan. Bezüglich des WLAN bin ich mir jetzt nicht sicher, ob "g" oder "n" verwendet wird, der Screenshot aus dem Konfigurationsmenü des Routers lässt aber aufgrund der auswählbaren Option von "Bandwidth" (20 oder 40 Mhz) und dem vorigen Punkt "802.11n/EWC" vermuten, dass hier "n" verwendet wird.
Daraus ergibt sich aber ein Problem: Das Erhöhen der Bandbreite von 20 auf 40 Mhz könnte die Geschwindigkeit zwar erhöhen, laut meinen Nachforschungen hat der RPI 3 aber einen 20 Mhz Limit:
Gleich auf Seite 1:
BCM43438 PDF
Part #: BCM43438. Description: Single-Chip IEEE 802.11ac b/g/n MAC/Baseband/Radio with Integrated Bluetooth 4.1 and FM Receiver. File Size: 1121.19 Kbytes. Manufacturer: Cypress Semiconductor.
pdf1.alldatasheet.com
Und auf meinem RaspiOS 12 scheint es gar keine Datei hostapd.conf zu geben, ist aber egal, da 40 Mhz wohl nicht funktionieren werden, also werden die 37 MBitps wohl der Limit für mich sein.
Hier noch Ausgaben vom RPI, bezüglich Qualität der Verbindung und Vorhandensein anderer Router:
Code:
werner@raspberrypi:/etc $ iwconfig
lo no wireless extensions.
eth0 no wireless extensions.
wlan0 IEEE 802.11 ESSID:"Shitstorm"
Mode:Managed Frequency:2.462 GHz Access Point: 1C:B0:44:43:F2:27
Bit Rate=52 Mb/s Tx-Power=31 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Power Management:on
Link Quality=70/70 Signal level=-19 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:350 Invalid misc:0 Missed beacon:0
werner@raspberrypi:/etc $ iwlist wlan0 scan
wlan0 Scan completed :
Cell 01 - Address: 1C:B0:44:43:F2:27
Channel:11
Frequency:2.462 GHz (Channel 11)
Quality=70/70 Signal level=-19 dBm
Encryption key:on
ESSID:"Shitstorm"
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
24 Mb/s; 36 Mb/s; 54 Mb/s
Bit Rates:6 Mb/s; 9 Mb/s; 12 Mb/s; 48 Mb/s
Mode:Master
Extra:tsf=0000000000000000
Extra: Last beacon: 87554880ms ago
IE: Unknown: 00095368697473746F726D
IE: Unknown: 010882848B962430486C
IE: Unknown: 03010B
IE: Unknown: 050402030000
IE: Unknown: 2A0104
IE: Unknown: 2F0104
IE: IEEE 802.11i/WPA2 Version 1
Group Cipher : CCMP
Pairwise Ciphers (1) : CCMP
Authentication Suites (1) : PSK
IE: Unknown: 32040C121860
IE: Unknown: 0B0503002E0000
IE: Unknown: 2D1ABC181BFFFF000000000000000000000000000000000000000000
IE: Unknown: 3D160B001700000000000000000000000000000000000000
IE: Unknown: 7F080400080000000040
IE: Unknown: DD310050F204104A00011010440001021047001088C4230447DC759F0782DD9131D06FD6103C0001011049000600372A000120
IE: Unknown: DD090010180203000C0000
IE: Unknown: DD180050F2020101840003A4000027A4000042435E0062322F00
IE: Unknown: 46057200010000
IE: Unknown: DD800050F204104A0001101044000102103B0001031047001088C4230447DC759F0782DD9131D06FD61021000842726F6164636F6D1023000842726F6164636F6D1024000631323334353610420004313233341054000800060050F20400011011000A42726F6164636F6D415010080002200C103C0001011049000600372A000120
werner@raspberrypi:/etc $Und
Code:
werner@raspberrypi:/etc $ apt policy iw
iw:
Installed: 5.19-1
Candidate: 5.19-1
Version table:
*** 5.19-1 500
500 http://deb.debian.org/debian bookworm/main arm64 Packages
100 /var/lib/dpkg/status
werner@raspberrypi:/etc $ iw dev wlan0 info
Interface wlan0
ifindex 3
wdev 0x1
addr b8:27:eb:fa:b7:5d
ssid Shitstorm
type managed
wiphy 0
channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz
txpower 31.00 dBm
werner@raspberrypi:/etc $ iw dev wlan0 link
Connected to 1c:b0:44:43:f2:27 (on wlan0)
SSID: Shitstorm
freq: 2462
RX: 1954485568 bytes (7195590 packets)
TX: 426447198 bytes (1367936 packets)
signal: -19 dBm
rx bitrate: 65.0 MBit/s
tx bitrate: 65.0 MBit/s
bss flags: short-slot-time
dtim period: 3
beacon int: 100
werner@raspberrypi:/etc $ iw list
Wiphy phy0
wiphy index: 0
max # scan SSIDs: 10
max scan IEs length: 2048 bytes
max # sched scan SSIDs: 16
max # match sets: 16
Retry short limit: 7
Retry long limit: 4
Coverage class: 0 (up to 0m)
Device supports roaming.
Supported Ciphers:
* WEP40 (00-0f-ac:1)
* WEP104 (00-0f-ac:5)
* TKIP (00-0f-ac:2)
* CCMP-128 (00-0f-ac:4)
Available Antennas: TX 0 RX 0
Supported interface modes:
* IBSS
* managed
* AP
* P2P-client
* P2P-GO
* P2P-device
Band 1:
Capabilities: 0x1020
HT20
Static SM Power Save
RX HT20 SGI
No RX STBC
Max AMSDU length: 3839 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 16 usec (0x07)
HT TX/RX MCS rate indexes supported: 0-7
Bitrates (non-HT):
* 1.0 Mbps
* 2.0 Mbps (short preamble supported)
* 5.5 Mbps (short preamble supported)
* 11.0 Mbps (short preamble supported)
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
Frequencies:
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (20.0 dBm)
* 2472 MHz [13] (20.0 dBm)
* 2484 MHz [14] (disabled)
Supported commands:
* new_interface
* set_interface
* new_key
* start_ap
* join_ibss
* set_pmksa
* del_pmksa
* flush_pmksa
* remain_on_channel
* frame
* set_wiphy_netns
* set_channel
* start_sched_scan
* start_p2p_device
* connect
* disconnect
* crit_protocol_start
* crit_protocol_stop
* update_connect_params
software interface modes (can always be added):
valid interface combinations:
* #{ managed } <= 2, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,
total <= 3, #channels <= 2
* #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,
total <= 4, #channels <= 1
Device supports scan flush.
Device supports randomizing MAC-addr in sched scans.
max # scan plans: 1
max scan plan interval: 508
max scan plan iterations: 0
Supported TX frame types:
* managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
Supported RX frame types:
* managed: 0x40 0xb0 0xd0
* AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* P2P-client: 0x40 0xd0
* P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* P2P-device: 0x40 0xd0
Supported extended features:
* [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
* [ 4WAY_HANDSHAKE_STA_PSK ]: 4-way handshake with PSK in station mode
* [ 4WAY_HANDSHAKE_STA_1X ]: 4-way handshake with 802.1X in station mode
werner@raspberrypi:/etc $ sudo iw dev wlan0 scan | grep -iE 'ssid|freq:'
freq: 2462
SSID: Shitstorm
freq: 2412
SSID: Livebox6-F14F
freq: 2452
SSID: DIGIFIBRA-Pc36
werner@raspberrypi:/etc $Die Ausführungen zum Thema Kabel geben mir natürlich zu denken, möglicherweise ist dadurch meine Verbindung vom PC zum Router nicht optimal und ich sollte mir dann doch ein neues besorgen. Hier habe ich mal stichprobenartig einige Tests mit iperf3 gemacht. Diese fallen sehr unterschiedlich aus, einer (Server in Madrid) sieht jedoch wesentlich besser aus als die anderen:
Code:
$ iperf3 -c 207.211.214.65
Connecting to host 207.211.214.65, port 5201
[ 5] local 192.168.1.131 port 11931 connected to 207.211.214.65 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 4.50 MBytes 37.7 Mbits/sec 2 2.31 MBytes
[ 5] 1.00-2.00 sec 2.50 MBytes 21.0 Mbits/sec 1307 73.7 KBytes
[ 5] 2.00-3.00 sec 1.75 MBytes 14.7 Mbits/sec 0 108 KBytes
[ 5] 3.00-4.00 sec 2.88 MBytes 24.1 Mbits/sec 0 143 KBytes
[ 5] 4.00-5.00 sec 4.25 MBytes 35.7 Mbits/sec 0 177 KBytes
[ 5] 5.00-6.00 sec 4.38 MBytes 36.7 Mbits/sec 0 213 KBytes
[ 5] 6.00-7.00 sec 6.00 MBytes 50.3 Mbits/sec 0 248 KBytes
[ 5] 7.00-8.00 sec 6.38 MBytes 53.5 Mbits/sec 0 284 KBytes
[ 5] 8.00-9.00 sec 7.25 MBytes 60.9 Mbits/sec 0 318 KBytes
[ 5] 9.00-10.00 sec 7.75 MBytes 64.9 Mbits/sec 0 353 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 47.6 MBytes 39.9 Mbits/sec 1309 sender
[ 5] 0.00-10.04 sec 46.7 MBytes 39.0 Mbits/sec receiver
iperf Done.
$ iperf3 -c speedtest.ip-projects.de
Connecting to host speedtest.ip-projects.de, port 5201
[ 5] local 192.168.1.131 port 35310 connected to 185.245.99.75 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.01 sec 24.1 MBytes 200 Mbits/sec 0 3.00 MBytes
[ 5] 1.01-2.00 sec 39.5 MBytes 335 Mbits/sec 0 3.00 MBytes
[ 5] 2.00-3.00 sec 40.1 MBytes 335 Mbits/sec 0 3.00 MBytes
[ 5] 3.00-4.00 sec 40.5 MBytes 341 Mbits/sec 0 3.00 MBytes
[ 5] 4.00-5.00 sec 40.0 MBytes 335 Mbits/sec 0 3.00 MBytes
[ 5] 5.00-6.00 sec 40.1 MBytes 337 Mbits/sec 0 3.00 MBytes
[ 5] 6.00-7.00 sec 40.0 MBytes 335 Mbits/sec 0 3.00 MBytes
[ 5] 7.00-8.00 sec 38.5 MBytes 323 Mbits/sec 0 3.00 MBytes
[ 5] 8.00-9.00 sec 40.1 MBytes 336 Mbits/sec 0 3.00 MBytes
[ 5] 9.00-10.00 sec 40.0 MBytes 336 Mbits/sec 0 3.00 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 383 MBytes 321 Mbits/sec 0 sender
[ 5] 0.00-10.04 sec 383 MBytes 320 Mbits/sec receiver
iperf Done.
$ iperf3 -c 185.93.3.50
Connecting to host 185.93.3.50, port 5201
[ 5] local 192.168.1.131 port 55152 connected to 185.93.3.50 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.01 sec 3.50 MBytes 29.0 Mbits/sec 1463 1.30 MBytes
[ 5] 1.01-2.01 sec 384 KBytes 3.14 Mbits/sec 111 1.05 MBytes
[ 5] 2.01-3.01 sec 1.62 MBytes 13.7 Mbits/sec 344 36.8 KBytes
[ 5] 3.01-4.00 sec 11.1 MBytes 93.9 Mbits/sec 0 187 KBytes
[ 5] 4.00-5.00 sec 28.0 MBytes 235 Mbits/sec 0 340 KBytes
[ 5] 5.00-6.00 sec 45.0 MBytes 377 Mbits/sec 0 495 KBytes
[ 5] 6.00-7.00 sec 60.8 MBytes 511 Mbits/sec 0 651 KBytes
[ 5] 7.00-8.00 sec 73.5 MBytes 616 Mbits/sec 0 797 KBytes
[ 5] 8.00-9.00 sec 73.8 MBytes 619 Mbits/sec 0 922 KBytes
[ 5] 9.00-10.00 sec 74.1 MBytes 622 Mbits/sec 0 1.01 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 372 MBytes 312 Mbits/sec 1918 sender
[ 5] 0.00-10.04 sec 371 MBytes 310 Mbits/sec receiver
iperf Done.
$ iperf3 -c 95.95.252.87 -p 5201-5209
Connecting to host 95.95.252.87, port 5201
[ 5] local 192.168.1.131 port 65136 connected to 95.95.252.87 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 8.88 MBytes 74.3 Mbits/sec 0 513 KBytes
[ 5] 1.00-2.00 sec 6.50 MBytes 54.6 Mbits/sec 2 262 KBytes
[ 5] 2.00-3.00 sec 6.00 MBytes 50.3 Mbits/sec 0 293 KBytes
[ 5] 3.00-4.00 sec 6.62 MBytes 55.6 Mbits/sec 0 324 KBytes
[ 5] 4.00-5.00 sec 7.38 MBytes 61.6 Mbits/sec 0 356 KBytes
[ 5] 5.00-6.00 sec 7.88 MBytes 66.3 Mbits/sec 0 387 KBytes
[ 5] 6.00-7.00 sec 8.75 MBytes 73.4 Mbits/sec 0 418 KBytes
[ 5] 7.00-8.01 sec 9.38 MBytes 78.0 Mbits/sec 0 449 KBytes
[ 5] 8.01-9.00 sec 10.0 MBytes 84.6 Mbits/sec 0 480 KBytes
[ 5] 9.00-10.00 sec 10.6 MBytes 89.1 Mbits/sec 0 512 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 82.0 MBytes 68.8 Mbits/sec 2 sender
[ 5] 0.00-10.05 sec 82.0 MBytes 68.4 Mbits/sec receiver
iperf Done.
$Ich bin mit jetzt aber auch nicht ganz sicher, ob diese Tests irgtendwelche Rückschlüsse auf das Cat 5 Kabel zulassen?
Und ob das irgendetwas mit der Ausgangsfrage zu tun haben kann, dass das Internet auf dem PC gefühlt langsamer reagiert, wenn der RPI per WLAN verbunden ist?
Nein, der RPI zieht keine Daten vom PC. Beide haben aber den Service minidlna am laufen, der nur mp3's zur Verfügung stellt, damit ich vom Internetradio aus auf beide zugreifen kann, wenn ich das will, mache ich aber relativ selten.
Mach halt 10 mal hintereinander fast.com - von deinem PC aus. Wenn da immer ~490 rauskommt, ist dein Kabel nicht das Problem. Innerhalb deines Netzes hast du ja sowieso keine 2 GBit fähigen Geräte wie ich das verstanden habe.
Bei der Channelwahl steht halt auch "acceptable" - kA was das heißt, aber ich nehme an, wärst du alleine auf dem Kanal würde da sowas wie excellent oder good stehen. Also hast du da schonmal Bandbreitenabfall. Dennoch sehen die am Pi gemässenen Bitraten für mich verdächtig nach g - Standard aus. Ich nutze meine Pis aber A) nicht über WLAN und B) nicht mit Raspbian, von daher kann ich leider wenig dazu beitragen, wo du da am besten nachsiehst.
Was die Bandbreitenmessung betrifft: Ich weiß jetzt nicht was du da gemessen hast. Wie gesagt, du musst messen: PC - Internet. Einmal wärend Pi am wlan hängt, einmal wärend pi am LAN hängt. Diese beiden Messungen sind interessant.
Bei der Channelwahl steht halt auch "acceptable" - kA was das heißt, aber ich nehme an, wärst du alleine auf dem Kanal würde da sowas wie excellent oder good stehen. Also hast du da schonmal Bandbreitenabfall. Dennoch sehen die am Pi gemässenen Bitraten für mich verdächtig nach g - Standard aus. Ich nutze meine Pis aber A) nicht über WLAN und B) nicht mit Raspbian, von daher kann ich leider wenig dazu beitragen, wo du da am besten nachsiehst.
Was die Bandbreitenmessung betrifft: Ich weiß jetzt nicht was du da gemessen hast. Wie gesagt, du musst messen: PC - Internet. Einmal wärend Pi am wlan hängt, einmal wärend pi am LAN hängt. Diese beiden Messungen sind interessant.
Du hast nur upload von dir zu den Servern hin gemessen. Was dein ISP dir an upload erlaubt, ist wieder was anderes (selbst wenn synchron im Tarif steht).
Du musst für den download von den Servern zu dir mit -R messen.
Ich spinne jetzt mal rum und stelle die nicht ganz so abwegige These in den Raum: Was ist, wenn das WLAN von exakt diesem nicht abgeschirmten Kabel gestört wird oder ist es sogar exakt andersrum und die WLAN-Signale stören den Flow auf dem Kabel? Ich wiederhole mit Zaunpfahl: UTP heißt nicht abgeschirmt.
Das sind dann zwei potentielle Fehlerquellen.
Du musst für den download von den Servern zu dir mit -R messen.
Kabel außerhalb der Spezifikation zu betreiben ist nie eine gute Idee. Bei Stromkabeln mit zu niedrigem Querschnitt wären Kurzschluss und Brandgefahr auch nicht deine Freunde.
Ich spinne jetzt mal rum und stelle die nicht ganz so abwegige These in den Raum: Was ist, wenn das WLAN von exakt diesem nicht abgeschirmten Kabel gestört wird oder ist es sogar exakt andersrum und die WLAN-Signale stören den Flow auf dem Kabel? Ich wiederhole mit Zaunpfahl: UTP heißt nicht abgeschirmt.
Das sind dann zwei potentielle Fehlerquellen.
pit234a
Well-Known Member
Manchmal sind Kabel aber tatsächlich besser, als außen drauf steht. Deshalb ist es schon sinnvoll, erst mal zu messen, bevor man größere Baumaßnahmen durchführt. Ich meine, dass meine Hausinstallation schon deutlich älter als zehn Jahre ist und damals gab schon keine Kabel mehr < 5e zu kaufen, zumindest nicht als Neuware. In diesem Fall wird dann auch ein Patch Kabel verwendet, es ist also kein Installationskabel, das dann richtig verlegt und angeschlossen sein muss. Es gilt teilweise für Patch Kabel ebenfalls: das beste Kabel kann durch falsche Verlegung (Knicke in der Leitung) oder falschen Anschluss (Erdung missachtet), deutlich in seiner Leistung gebremst werden.
Das einzig Wahre hier ist (soweit ich sehe und verstehe), so zu messen, wie oben erklärt und dann ein neues, super duper 5m Patch Kabel aus dem nächsten PC-markt oder so für etwa 15€ kaufen, wenn es die überhaupt kosten wird. Ich schildere und meine nicht wertend oder gar diskriminierend, aber in nicht so weiter Entfernung von mir gibt es einen "Iran-Market" und der verkauft einem super duper Patch Kabel "was du immer willst" für nur 5€. Nur als Beispiel, nicht als Empfehlung, wie es in etwa wenigstens aussehen sollte (ich nahm einfach den ersten Treffer der Suche, mir gefällt dieses Kabel persönlich nicht so gut): https://www.amazon.de/CSL-Computer-Netzwerkkabel-Ethernet-Patchkabel-Schirmung/dp/B011984DZ4?th=1
Also, dann einfach ohne Baumaßnahmen die gleichen Messungen nochmal mit diesem Kabel, außen vorbei gelegt. Das bringt Einsichten, ohne raten zu müssen.
Des weiteren sehe ich deine Installation noch nicht richtig vor Augen.
Ist es so, dass
Internet ------- Router (mit eingebautem Switch und WLan-Access-Point) ------- LAN ------- PC
------- WLan ----- RasPi
Oder irgendwie anders?
Edit:
meine "Skizze" oben wird dann nicht so dargestellt, wie ich das wollte. Also PC über LAN am Router und Pi über Wlan am gleichen Router? und sonst nix?
turrican
Well-Known Member
naja, ich kann mich noch erinnern, es war früher (tm) schon mal ne Zeitlang üblich -UTP zu verlegen (hab ich damals auch im Haus, ich glaub sogar nur cat5 oder -5e), das war gut für Gig-E
Es sind ja symmetrische Adernpaare, d.h. im Idealfall heben sind die Felder um die Leiter auf und es wird nichts abgestrahlt, Einstrahlungen sind symmetrisch, d.h. auch kein Problem.
Bei dem Problem vom @cabriofahrer würd ich eher auf die interne Bridge vom Router bzw deren Implementation tippen - es wird lahm sobald eine Maschine am Wlan hängt und schnell wenn diese (mit dem davon betroffenen PC) am Kabel ist??
cabriofahrer
Well-Known Member
Bei fast.con kommt jedes Mal ein anderer Wert raus, es schwankt sogar zwischen 390 und einmal sogar 650(!). Letzteres war, nachdem ich den Stream auf dem Internetradio beendet habe. Aber nach weiteren Messungen auf fast.com war der Wert doch wieder geringer / unterhalb von 500.
Doch jetzt wird es interessanter. Nachdem die Messung auf dem Raspi auf fast.com mit dem Kabel so schlecht ausgefallen war, wollte ich es jetzt doch mal mit iperf3 wissen.
Messung Raspi mit WLAN:
Code:
werner@raspberrypi:~ $ iperf3 -R -c 185.93.3.50
Connecting to host 185.93.3.50, port 5201
Reverse mode, remote host 185.93.3.50 is sending
[ 5] local 192.168.1.95 port 47124 connected to 185.93.3.50 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 3.90 MBytes 32.7 Mbits/sec
[ 5] 1.00-2.00 sec 3.92 MBytes 32.9 Mbits/sec
[ 5] 2.00-3.00 sec 3.74 MBytes 31.4 Mbits/sec
[ 5] 3.00-4.00 sec 3.91 MBytes 32.8 Mbits/sec
[ 5] 4.00-5.00 sec 3.72 MBytes 31.2 Mbits/sec
[ 5] 5.00-6.00 sec 3.85 MBytes 32.3 Mbits/sec
[ 5] 6.00-7.00 sec 3.80 MBytes 31.9 Mbits/sec
[ 5] 7.00-8.00 sec 3.75 MBytes 31.5 Mbits/sec
[ 5] 8.00-9.00 sec 3.67 MBytes 30.8 Mbits/sec
[ 5] 9.00-10.00 sec 3.96 MBytes 33.2 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.06 sec 38.3 MBytes 32.0 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 38.2 MBytes 32.1 Mbits/sec receiver
iperf Done.
werner@raspberrypi:~ $ iperf3 -R -c speedtest.ip-projects.de
iperf3: error - the server is busy running a test. try again later
werner@raspberrypi:~ $ iperf3 -R -c speedtest.ip-projects.de
Connecting to host speedtest.ip-projects.de, port 5201
Reverse mode, remote host speedtest.ip-projects.de is sending
[ 5] local 192.168.1.95 port 51612 connected to 185.245.99.75 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 1.68 MBytes 14.1 Mbits/sec
[ 5] 1.00-2.00 sec 2.02 MBytes 17.0 Mbits/sec
[ 5] 2.00-3.00 sec 1.98 MBytes 16.6 Mbits/sec
[ 5] 3.00-4.00 sec 1.87 MBytes 15.7 Mbits/sec
[ 5] 4.00-5.00 sec 1.91 MBytes 16.0 Mbits/sec
[ 5] 5.00-6.00 sec 1.99 MBytes 16.7 Mbits/sec
[ 5] 6.00-7.00 sec 1.93 MBytes 16.2 Mbits/sec
[ 5] 7.00-8.00 sec 2.02 MBytes 17.0 Mbits/sec
[ 5] 8.00-9.00 sec 2.04 MBytes 17.1 Mbits/sec
[ 5] 9.00-10.00 sec 2.03 MBytes 17.0 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.05 sec 22.3 MBytes 18.6 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 19.5 MBytes 16.3 Mbits/sec receiver
iperf Done.Raspi mit Kabel:
Code:
werner@raspberrypi:~ $ iperf3 -R -c 185.93.3.50
Connecting to host 185.93.3.50, port 5201
Reverse mode, remote host 185.93.3.50 is sending
[ 5] local 192.168.1.71 port 46312 connected to 185.93.3.50 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 10.9 MBytes 91.3 Mbits/sec
[ 5] 1.00-2.00 sec 11.1 MBytes 93.1 Mbits/sec
[ 5] 2.00-3.00 sec 10.9 MBytes 91.8 Mbits/sec
[ 5] 3.00-4.00 sec 11.2 MBytes 93.6 Mbits/sec
[ 5] 4.00-5.00 sec 10.9 MBytes 91.8 Mbits/sec
[ 5] 5.00-6.00 sec 11.0 MBytes 92.1 Mbits/sec
[ 5] 6.00-7.00 sec 10.9 MBytes 91.7 Mbits/sec
[ 5] 7.00-8.00 sec 11.1 MBytes 93.4 Mbits/sec
[ 5] 8.00-9.00 sec 11.0 MBytes 92.7 Mbits/sec
[ 5] 9.00-10.00 sec 11.0 MBytes 91.9 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.05 sec 110 MBytes 92.0 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 110 MBytes 92.3 Mbits/sec receiver
iperf Done.
werner@raspberrypi:~ $ iperf3 -R -c speedtest.ip-projects.de
Connecting to host speedtest.ip-projects.de, port 5201
Reverse mode, remote host speedtest.ip-projects.de is sending
[ 5] local 192.168.1.71 port 39544 connected to 185.245.99.75 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 7.78 MBytes 65.2 Mbits/sec
[ 5] 1.00-2.00 sec 12.4 MBytes 104 Mbits/sec
[ 5] 2.00-3.00 sec 11.2 MBytes 94.1 Mbits/sec
[ 5] 3.00-4.00 sec 11.2 MBytes 94.1 Mbits/sec
[ 5] 4.00-5.00 sec 11.2 MBytes 94.1 Mbits/sec
[ 5] 5.00-6.00 sec 11.2 MBytes 94.1 Mbits/sec
[ 5] 6.00-7.00 sec 11.2 MBytes 94.1 Mbits/sec
[ 5] 7.00-8.00 sec 11.2 MBytes 94.1 Mbits/sec
[ 5] 8.00-9.00 sec 11.2 MBytes 94.1 Mbits/sec
[ 5] 9.00-10.00 sec 11.2 MBytes 94.1 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.04 sec 113 MBytes 94.7 Mbits/sec 46 sender
[ 5] 0.00-10.00 sec 110 MBytes 92.2 Mbits/sec receiver
iperf Done.Man kann also ganz klar sagen, dass die Verbindung auf dem Raspi mit Kabel deutlich besser ist. Warum das Ergebnis mit fast.com / Kabel auf dem Raspi so schlecht war, verstehe ich also nicht.
Weiteres Ergebnis PC:
PC, während Raspi mit WLAN verbunden ist:
Code:
$ iperf3 -R -c speedtest.ip-projects.de
Connecting to host speedtest.ip-projects.de, port 5201
Reverse mode, remote host speedtest.ip-projects.de is sending
[ 5] local 192.168.1.131 port 25436 connected to 185.245.99.75 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 24.1 MBytes 202 Mbits/sec
[ 5] 1.00-2.01 sec 37.6 MBytes 315 Mbits/sec
[ 5] 2.01-3.00 sec 37.6 MBytes 317 Mbits/sec
[ 5] 3.00-4.00 sec 37.9 MBytes 317 Mbits/sec
[ 5] 4.00-5.00 sec 37.9 MBytes 318 Mbits/sec
[ 5] 5.00-6.00 sec 37.9 MBytes 318 Mbits/sec
[ 5] 6.00-7.00 sec 37.9 MBytes 317 Mbits/sec
[ 5] 7.00-8.00 sec 37.9 MBytes 318 Mbits/sec
[ 5] 8.00-9.00 sec 37.9 MBytes 317 Mbits/sec
[ 5] 9.00-10.00 sec 37.9 MBytes 318 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.04 sec 368 MBytes 308 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 364 MBytes 306 Mbits/sec receiver
iperf Done.
$ iperf3 -R -c 185.93.3.50
Connecting to host 185.93.3.50, port 5201
Reverse mode, remote host 185.93.3.50 is sending
[ 5] local 192.168.1.131 port 26475 connected to 185.93.3.50 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 69.8 MBytes 585 Mbits/sec
[ 5] 1.00-2.00 sec 74.1 MBytes 621 Mbits/sec
[ 5] 2.00-3.00 sec 74.2 MBytes 623 Mbits/sec
[ 5] 3.00-4.00 sec 73.9 MBytes 620 Mbits/sec
[ 5] 4.00-5.03 sec 76.4 MBytes 623 Mbits/sec
[ 5] 5.03-6.00 sec 71.8 MBytes 619 Mbits/sec
[ 5] 6.00-7.01 sec 74.9 MBytes 621 Mbits/sec
[ 5] 7.01-8.00 sec 73.2 MBytes 622 Mbits/sec
[ 5] 8.00-9.00 sec 74.2 MBytes 622 Mbits/sec
[ 5] 9.00-10.00 sec 74.0 MBytes 619 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.04 sec 737 MBytes 616 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 736 MBytes 618 Mbits/sec receiver
iperf Done.PC, während Raspi mit Kabel verbunden ist:
Code:
$ iperf3 -R -c 185.93.3.50
Connecting to host 185.93.3.50, port 5201
Reverse mode, remote host 185.93.3.50 is sending
[ 5] local 192.168.1.131 port 17353 connected to 185.93.3.50 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.01 sec 71.9 MBytes 598 Mbits/sec
[ 5] 1.01-2.00 sec 74.0 MBytes 624 Mbits/sec
[ 5] 2.00-3.01 sec 75.2 MBytes 624 Mbits/sec
[ 5] 3.01-4.00 sec 73.5 MBytes 625 Mbits/sec
[ 5] 4.00-5.00 sec 74.5 MBytes 624 Mbits/sec
[ 5] 5.00-6.00 sec 74.5 MBytes 624 Mbits/sec
[ 5] 6.00-7.00 sec 74.4 MBytes 625 Mbits/sec
[ 5] 7.00-8.00 sec 74.5 MBytes 624 Mbits/sec
[ 5] 8.00-9.00 sec 74.2 MBytes 623 Mbits/sec
[ 5] 9.00-10.00 sec 74.1 MBytes 622 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.04 sec 741 MBytes 619 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 741 MBytes 621 Mbits/sec receiver
iperf Done.
$ iperf3 -R -c speedtest.ip-projects.de
Connecting to host speedtest.ip-projects.de, port 5201
Reverse mode, remote host speedtest.ip-projects.de is sending
[ 5] local 192.168.1.131 port 50646 connected to 185.245.99.75 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.01 sec 24.0 MBytes 200 Mbits/sec
[ 5] 1.01-2.00 sec 37.6 MBytes 318 Mbits/sec
[ 5] 2.00-3.00 sec 38.0 MBytes 318 Mbits/sec
[ 5] 3.00-4.01 sec 37.9 MBytes 317 Mbits/sec
[ 5] 4.01-5.00 sec 37.8 MBytes 318 Mbits/sec
[ 5] 5.00-6.00 sec 37.8 MBytes 317 Mbits/sec
[ 5] 6.00-7.00 sec 38.0 MBytes 319 Mbits/sec
[ 5] 7.00-8.00 sec 37.9 MBytes 317 Mbits/sec
[ 5] 8.00-9.00 sec 37.9 MBytes 317 Mbits/sec
[ 5] 9.00-10.00 sec 37.8 MBytes 318 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.04 sec 368 MBytes 308 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 364 MBytes 306 Mbits/sec receiver
iperf Done.Eigentlich kein großer Unterschied. Doch nach Umstellen des Raspi auf Kabel ist das Surfen auf dem PC wieder gefühlt schneller. Dabei meine ich, die Zeit, die verstreicht, wenn man eine URL eingibt / einen Link klickt, bis endlich was kommt.
Von daher denke ich, dass @turrican mit seiner Vermutung
richtig tippt.
Ein Problem der Abschirmung des Kabels scheint es nicht zu sein. Das Kabel liegt sogar direkt mit dem Stromkabel für den Verteilerstecker zusammen:
Wenn man trotzdem der Meinung ist, dass ein moderneres Kabel (Cat 6 oder 7 und abgeschirmt) meine Verbindung vom PC ins Internet noch verbessern könnte, würde ich mir dann auch ein neues zulegen.
Ja, aber nicht "sonst nix". Es sind noch ein Internetradio und zwei Mobiltelefone über WLAN mit dem Router verbunden. Und jetzt habe ich doch den Raspi wieder über Kabel verbunden.
Wir sind mittlerweile im Thread bei Seite 2 und nicht ein Problem ist gelöst. Irgendwie willst du auch möglichst optimal alles konfiguriert haben, aber die beharrliche Weigerung erstmal für mindestens eine Basis "alles innerhalb der specs" zu sorgen finde ich interessant.
Wenn das Netz ansonsten irgendwie läuft und der raspi das Netz runterzieht, kickst du dann das Netz oder den raspi?
Wenn das Netz ansonsten irgendwie läuft und der raspi das Netz runterzieht, kickst du dann das Netz oder den raspi?
pit234a
Well-Known Member
ich bleibe mal nur dabei hängen, obwohl es auch zu anderen Punkten was zu sagen gäbe. Dabei halte ich mich zurück, weil hier bereits Leute mitdenken, die viel besser in der Materie Bescheid wissen und zu helfen versuchen.
Für dich ist aber wichtig zu erkennen, dass auch die klügsten Helfer nicht alles erraten können und wenn plötzlich auch ein Internet-Radio in die Gleichung kommt, von dem bis dahin nicht die Rede war.
Du hast ja (vermutlich) nur einen einzigen Internetzugang, bekommst von deinem Provider auch nur eine IP zugewiesen und alles, was von und zum Internet läuft, muss über diese Leitung fließen. Wenn da nun ein Internetradio und vielleicht ein Telefon (mit Internet-Telefonie) mal 100k belegen, mal 300k oder auch mal nichts, dann werden die Messungen mit deinem PC zum Internet dadurch natürlich beeinflusst. Hier ist aber nicht nur die reine Bandbreite ein Faktor, sondern auch die Priorität der Pakete (wenn der Router so etwas macht). Es kann zB sein, dass der Router die Telefone bevorzugt, damit die Telefonie nicht durch einen Bildaufbau in deinem Browser gestört wird. Wie auch immer: du musst versuchen, so wenige Variablen als nur möglich in der Gleichung stehen zu lassen, um möglichst verlässliche Messungen zu erhalten, aus denen du dann auch Schlüsse ziehen kannst.
Und um das auch verstehen zu können, was du machst, ist es gut und hilfreich, wenn du gleich einen kompletten Plan deines Netzwerkes vorstellst. Dann sehen die klugen Helfer sofort, was womöglich zur Fehlersuche erst mal eliminiert werden sollte. Ansonsten verschießen sie ihr Pulver womöglich in einem Scheingefecht.
Naja du solltest die Tests schon machen, wärend du sonst keine Downloads machst?.. Also kein Internetradio, Handyupdate oder sonstwas..
Aber auch Schwankungen von ~20% sind bei manchen ISPs leider normal..
Soweit ich das in Erinnerung habe, wurde ja ein Fehler angezeigt. Müsste man gucken, aber immer nur ein Problem auf einmal. Auch kann sein, dass der PI3 schlicht nicht mehr über https kann (Verschlüsselung und Mistchip, siehe Post von Yamagi).
Wenn es wirklich nur am Aufbau nach dem ersten Klick liegt, bin ich immer noch der Meinung, das hört sich stark nach DNS an. Welche DNS Server hast du auf dem PC eingestellt?
Ich nehme an, du Surfst mit Firefox, stell doch mal, bei "Privacy & Secruity" DNS over HTTPS auf "Max Protection" und den verwendeten DoH Server auf Cloudflare (sollte voreingestellt sein). Egal was du von Cloudflare hältst, es ist nur zum testen, und Cloudflare ist am schnellsten.
Und dann Probiere nochmal, ob du Unterschiede erkennst.
Immer nur ein Problem zu einer Zeit, und wenn das Kabel seine 500+ MBIT liefert, soll es auch egal sein. Andererseits kostet ein neues 5m Kabel für Cat 6 auch keine 10 Euro.
Das ist ja nicht nix, Internetradio ist nunmal ein Download, Handys veranstallten auch alles möglich wenn ihnen danach ist.
pit234a
Well-Known Member
Ich habe mir diesen Thread nochmal angesehen und gefunden, dass Internet-Radio und Wlan-Telefone im Eingangs-Beitrag schon erwähnt wurden.
Allerdings wird der Zusammenhang zu einem "gefühlten Problem" nicht ganz klar.
Ich versuche mal, wie das @medV2 ja vorher schon gemacht hat, zusammen zu fassen:
1.) Alles ist gut
2.) RasPi über Wlan im Netzwerk -> Internet auf PC wird lahm
3.) RasPi über Lan im Netzwerk -> Internet auf PC nicht mehr lahm
Deshalb fragst du nach Methoden, wie man einem solchen Problem auf die Spur kommen kann, welche Tools einem da helfen können.
Wir alle sind natürlich getriggert, eine Lösung für ein bestehendes Problem zu finden, aber darum geht es dir vorerst ja nicht, sondern du fragst nur nach Tools und Möglichkeiten, die dir Aufschluss geben können.
"Die Lösung" hast du im Eingangsthread ja schon benannt: RasPi über Lan ins Netz, wieso auch immer, löst das Problem.
Die vorgestellten Tools ergeben Messungen, wie sich nicht anders zu erwarten sind. Meine ich nun mal.
Also, wenn ich nicht irgendwie falsch hin-geguckt habe, bekommst du die volle Bandbreite, die dir dein ISP mit 500M versprochen hat. Dass dies manchmal ein wenig schwankt, ist vollkommen normal und du hast ja auch noch andere Nutzer während des Tests aktiv, was vorher schon mal behandelt wurde. Du bekommst diese Bandbreite voll auf deinen PC, das verwendete Kabel macht das mit und ist hier also keine bemerkenswerte Bremse.
Auf dem PasPi hast du immer relativ schlechte Performance. Nun, ich habe in meinem Netz auch noch Rechner, die nur eine 10M Netzwerk-Karte haben und andere, die nur 100M haben und mein WLan benutzt meist noch 54M AccessPoints und die meisten Clienten sind damit zufrieden. Es ist vollkommen klar, dass ich auf einem Endgerät mit einer 100M oder 10M Karte, keine 500M oder 1000M messen kann und scheinbar gilt dies eben auch für deinen RasPi, der offenbar schwächer ist, als man auf Grund der Spezifikationen meinen sollte.
Hier ist guter Rat teuer. Um einen Fehler der Verkabelung/des Wlans auszuschließen, müsstest du ein anderes Gerät mit bekannter Qualität ersatzweise anschließen und dann die Strecke damit nochmals austesten. Also, vielleicht deinen PC am gleichen Lan-Kabel anschließen, wo der RasPi nur schlechte Werte bringt oder einen Ipad oder ein Handy über den gleichen Wlan-Zugang anschließen und damit den Speed-Test wiederholen.
Nebenbei: in allen meinen Versuchen weichen die üblichen Tests über Browser (fast.com oder speedtest.net) maximal marginal von den Ergebnissen mit iperf3 ab.
Solche Tests können dir dann zeigen, ob dein Netzwerk in Ordnung ist und ob dein Internet-Anschluss in Ordnung ist.
Sie geben keine Auskunft darüber, was denn der RasPi in deinem Netzwerk oder mit Blick ins Internet veranstaltet, womit er also dann einmal über Wlan dein Netz langsam macht und mit Lan doch noch verträglich bleibt.
Um so etwas zu finden, müsste entweder auf dem Pi ein Dienst laufen, der Internet- (oder allgemeiner Netzwerk-) Aktivitäten zeigt, oder, du müsstest ein zusätzliches Gerät installieren, einen zweiten Router, dem du diese Informationen dann entlocken könntest und den Netzwerkverkehr des Pi darüber leiten.
Wahrscheinlich kann der Pi so etwas wie tcpdump? oder iftop? Keine Ahnung.
Man kann aber auch einfach mal davon ausgehen, dass der einzige Dienst (?), der da läuft, nämlich kodi, möglicherweise den zusätzlichen Traffic verursacht und das Netzwerk blockiert, desto mehr, desto langsamer er bedient wird.
Und genau das will ich noch etwas weiter auf-dröseln, obwohl mir vollkommen klar ist, dass ich wieder viel zu viel und zu lange schreibe.
1.) kein VPN:
2.) über VPN in Frankfurt
Nun könnte ich natürlich noch einige andere Standorte testen und zeigen, aber, was ich damit zeigen will: wenn dein RasPi ein solches System benutzt, wie ich das früher mal erfahren habe und du deshalb Filme aus Geo-blockierten Seiten ansehen kannst, weil alle Daten über irgendeinen Tunnel gehen und wenn dann auch noch "im Leerlauf" dauernd Daten zum und vom Internet gesendet werden, um irgendwelche Datenbanken abzugleichen und Covers zu Filmen und Musik zu laden, dann ist das unter Umständen ein echter Engpass und kann dein gesamtes Netz lahm legen und besonders gut, wenn die Internet-Anbindung dann auch noch über ein lahmes Wlan erfolgt.
Also, zusammengefasst glaube ich nicht, dass dein Netzwerk wirklich problematisch ist und Korrekturen erfolgen müssen.
Wieso deine Lösung funktioniert, den RasPi am Lan zu betreiben, statt am Wlan, dazu habe ich oben spekuliert, aber letztlich auch keine Antwort und nur unzureichende Vorschläge zur Fehlersuche.
Allerdings wird der Zusammenhang zu einem "gefühlten Problem" nicht ganz klar.
Ich versuche mal, wie das @medV2 ja vorher schon gemacht hat, zusammen zu fassen:
1.) Alles ist gut
2.) RasPi über Wlan im Netzwerk -> Internet auf PC wird lahm
3.) RasPi über Lan im Netzwerk -> Internet auf PC nicht mehr lahm
Deshalb fragst du nach Methoden, wie man einem solchen Problem auf die Spur kommen kann, welche Tools einem da helfen können.
Wir alle sind natürlich getriggert, eine Lösung für ein bestehendes Problem zu finden, aber darum geht es dir vorerst ja nicht, sondern du fragst nur nach Tools und Möglichkeiten, die dir Aufschluss geben können.
"Die Lösung" hast du im Eingangsthread ja schon benannt: RasPi über Lan ins Netz, wieso auch immer, löst das Problem.
Die vorgestellten Tools ergeben Messungen, wie sich nicht anders zu erwarten sind. Meine ich nun mal.
Also, wenn ich nicht irgendwie falsch hin-geguckt habe, bekommst du die volle Bandbreite, die dir dein ISP mit 500M versprochen hat. Dass dies manchmal ein wenig schwankt, ist vollkommen normal und du hast ja auch noch andere Nutzer während des Tests aktiv, was vorher schon mal behandelt wurde. Du bekommst diese Bandbreite voll auf deinen PC, das verwendete Kabel macht das mit und ist hier also keine bemerkenswerte Bremse.
Auf dem PasPi hast du immer relativ schlechte Performance. Nun, ich habe in meinem Netz auch noch Rechner, die nur eine 10M Netzwerk-Karte haben und andere, die nur 100M haben und mein WLan benutzt meist noch 54M AccessPoints und die meisten Clienten sind damit zufrieden. Es ist vollkommen klar, dass ich auf einem Endgerät mit einer 100M oder 10M Karte, keine 500M oder 1000M messen kann und scheinbar gilt dies eben auch für deinen RasPi, der offenbar schwächer ist, als man auf Grund der Spezifikationen meinen sollte.
Hier ist guter Rat teuer. Um einen Fehler der Verkabelung/des Wlans auszuschließen, müsstest du ein anderes Gerät mit bekannter Qualität ersatzweise anschließen und dann die Strecke damit nochmals austesten. Also, vielleicht deinen PC am gleichen Lan-Kabel anschließen, wo der RasPi nur schlechte Werte bringt oder einen Ipad oder ein Handy über den gleichen Wlan-Zugang anschließen und damit den Speed-Test wiederholen.
Nebenbei: in allen meinen Versuchen weichen die üblichen Tests über Browser (fast.com oder speedtest.net) maximal marginal von den Ergebnissen mit iperf3 ab.
Solche Tests können dir dann zeigen, ob dein Netzwerk in Ordnung ist und ob dein Internet-Anschluss in Ordnung ist.
Sie geben keine Auskunft darüber, was denn der RasPi in deinem Netzwerk oder mit Blick ins Internet veranstaltet, womit er also dann einmal über Wlan dein Netz langsam macht und mit Lan doch noch verträglich bleibt.
Um so etwas zu finden, müsste entweder auf dem Pi ein Dienst laufen, der Internet- (oder allgemeiner Netzwerk-) Aktivitäten zeigt, oder, du müsstest ein zusätzliches Gerät installieren, einen zweiten Router, dem du diese Informationen dann entlocken könntest und den Netzwerkverkehr des Pi darüber leiten.
Wahrscheinlich kann der Pi so etwas wie tcpdump? oder iftop? Keine Ahnung.
Man kann aber auch einfach mal davon ausgehen, dass der einzige Dienst (?), der da läuft, nämlich kodi, möglicherweise den zusätzlichen Traffic verursacht und das Netzwerk blockiert, desto mehr, desto langsamer er bedient wird.
Und genau das will ich noch etwas weiter auf-dröseln, obwohl mir vollkommen klar ist, dass ich wieder viel zu viel und zu lange schreibe.
Also, ich nutze MPV, um deutsches Fernsehen zu gucken und zwar aus Frankreich, nicht aus Spanien, wie das bei dir der Fall zu sein scheint. Das entscheidende: MPV kann das nicht und Kodi kann das afaik auch nicht! Also, wenn ich nun auf meinem FreeBSD ein Kodi installiere und damit Geo-blockierte Inhalte aus Deutschland ansehen will, dann geht das damit nicht, so wenig, wie mit VLC oder irgendeinem anderen Player. Zumindest früher war es so, dass Kodi und seine Vorläufer auf fertig konfigurierten Systemen angeboten wurde, die dann auch diverse Plugins direkt mitgeliefert hatten und darunter war dann auch (eigentlich kein Plugin), ein VPN-Client oder "etwas ähnliches". Wenn du so etwas auf dem Pi benutzt, dann werden da alle deine Daten womöglich durch diesen Tunnel gelenkt und einen solchen Effekt will ich mal zeigen, wenn ich meinen VPN einschalte:
1.) kein VPN:
Code:
> iperf3 -R -c speedtest.ip-projects.de
Connecting to host speedtest.ip-projects.de, port 5201
Reverse mode, remote host speedtest.ip-projects.de is sending
...
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.08 sec 1.06 GBytes 905 Mbits/sec 504 sender
[ 5] 0.00-10.06 sec 1.06 GBytes 904 Mbits/sec receiver2.) über VPN in Frankfurt
Code:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.03 sec 673 MBytes 563 Mbits/sec 447 sender
[ 5] 0.00-10.01 sec 670 MBytes 561 Mbits/sec receiverNun könnte ich natürlich noch einige andere Standorte testen und zeigen, aber, was ich damit zeigen will: wenn dein RasPi ein solches System benutzt, wie ich das früher mal erfahren habe und du deshalb Filme aus Geo-blockierten Seiten ansehen kannst, weil alle Daten über irgendeinen Tunnel gehen und wenn dann auch noch "im Leerlauf" dauernd Daten zum und vom Internet gesendet werden, um irgendwelche Datenbanken abzugleichen und Covers zu Filmen und Musik zu laden, dann ist das unter Umständen ein echter Engpass und kann dein gesamtes Netz lahm legen und besonders gut, wenn die Internet-Anbindung dann auch noch über ein lahmes Wlan erfolgt.
Also, zusammengefasst glaube ich nicht, dass dein Netzwerk wirklich problematisch ist und Korrekturen erfolgen müssen.
Wieso deine Lösung funktioniert, den RasPi am Lan zu betreiben, statt am Wlan, dazu habe ich oben spekuliert, aber letztlich auch keine Antwort und nur unzureichende Vorschläge zur Fehlersuche.
cabriofahrer
Well-Known Member
Welche beharrliche Weigerung? Ich habe doch alle Tests durchgeführt und Ausgaben geliefert, die hier verlangt wurden? Die ganze Testerei hat zumindest interessante Ergebnisse über die unterschiedlichen möglichen Netzwerkgeschwindigkeiten des Raspi jeweils mit Kabel und mit WLAN gebracht.
Die Erkenntnis, dass das Internet vom PC aus besser funktioniert, wenn der Raspi über Kabel läuft und nicht über WLAN, lässt sich offenbar nicht mit iperf3-Tests belegen. Es scheint auch kein Problem der maximal erreichbaren Geschwindigkeit vom PC aus zu sein, sondern gefühlt eher, wie schnell es reagiert. Nochmal: Ich finde, dass die Erklärung von @turrican bezüglich des Routers das Problem sehr wahrscheinlich trifft. An dem Router lässt sich aber nichts ändern, der wurde vom ISP geliefert "as is", man kann natürlich das WLAN ganz ausschalten.
In der Tat, die Heimnetztwerkkonstellation hatte ich gleich in den ersten Sätzen beschrieben:
Habe ich auch. Ich hatte den Stream vom Internetradio abgestellt und es liefen garantiert auch keine Updates auf den Handys.
Der Preis ist natürlich kein Problem. Das Problem ist das mit der Kabelleiste am Boden. Da müsste ich mir schon sicher sein, dass sich das lohnt.
Kann denn ein Kabel auch Einfluss darauf haben, wie schnell die Übertragungsgeschwindigkeit bis auf Ihr Maximum ansteigt? Das könnte z.B. bei einem
pkg upgradeinteressant sein? Da fällt auf, dass jedes einzelne Paket ein gesonderter Herunterladevorgang zu sein scheint, der von neuem beginnt und bei kleinen Paketen manchmal im Kilobyte/ses-Bereich beginnt und bei größeren Paketen dann langsam aber sicher auf über 20 MB/sec ansteigt.Und warum ergibt eine Messung sogar mehr als 600 Mbit/sec, wenn ich laut Provider nur 500 habe?
8.8.8.8. Und das scheint schneller zu sein, als das, was im Router ursprünglich vom ISP eingestellt war.
Danke für den Hinweis, werde ich mal ausprobieren.
Überlegung noch zum Raspi allgemein: Könnte man die LAN Geschwindigkeit durch einen externen USB-LAN Adapter beträchtlich erhöhen? Die maximale Geschwindigkeit würde dann der maximalen Geschwindigkeit des USB entsprechen, also 480 MBit/sec, weil der externe Adapter dann nicht den Prozessor des Raspi beansprucht?
Anmerkung noch für @pit234a : Du bist offensichtlich kein Kodi-Fan. Aber ich glaube nicht, dass Kodi, wenn nicht gerade gestreamt wird, irgendwelchen Traffic veranstaltet. Was denn oder warum denn, wenn man sich im Hauptmenü befindet oder wieder in der Liste der Sendungen, auf denen man war? Zum Thema Geoblocking: Das scheint nur Sportsendungen und internationale Filme zu betreffen. Deutsche Filme (z.B. Tatort und andere Krimis) und Sendungen sind aber kein Problem.
Wenn Du die PlutoTV-App installierst, bekommst Du die Streams sogar in "Deiner" Sprache. Leider funktioniert in der PlutoTV-App das "On demand" nicht mehr.
Wird schwierig wegen der Länge. Wäre aber interessant, um zusehen, ob Cat. 5 - 5e am PC einen Unterschied macht.
Nein, das ist genau das Problem, wieso es so langsam ist. Der LAN Port am RPI3 ist in wirklichkeit ein USB Adapter - nur eben fest verlötet. Und USB braucht immer die CPU. USB ist ein dummes Protkoll.
pit234a
Well-Known Member
das spielt für meine Aussagen gar keine Rolle.
Ich bin kein Fan von irgendeiner SW, es geht mir nur um die möglichen Einflüsse im Rahmen deiner Schilderung und im Hinblick auf meine alten Erfahrungen mit Kodi. Daraus leite ich einen möglichen Zusammenhang ab. Mir erscheint das plausibel, aber ich kann es natürlich aus der Ferne nicht beurteilen und werde mir nicht eigens einen Pi anschaffen, um Kodi darauf zu starten.
naja, dann kauf dir gleich eines mit zehn oder fünfzehn Meter, was immer du brauchst, aber eben mit wenigstens cat6, besser cat7 und leg es zum testen/messen einfach über den Boden zwischen den jeweiligen Endpunkten.
Oder, viel einfacher: vergessen wir das Ganze und leben damit, dass du mit Pi am Lan ja glücklich bist.
cabriofahrer
Well-Known Member
Nee, vergessen nicht. Wenn ein neues Kabel meine Verbindung vom PC ins Internet merklich verbessern kann, bin ich natürlich auch daran interessiert.
Musst Du ja auch nicht. Aber früher hatte ich extra für Kodi am Fernseher immer mein altes Acer Notebook per VGA- und Audio-Kabel dran, bis es offensichtlich einen Schaden davon trug (siehe alte Threads von mir). Danach einen alten PC, der war laut, nahm viel Platz weg und musste natürlich auch immer hoch und runtergefahren werden, nur weil ich mal was gucken wollte.
Der Raspi ist nun seit mehr als einem Jahren ein Segen: lautlos, immer bereit, per HDMI verbunden und verbraucht obendrein nur 2W. Ein P4 wäre natürlich besser gewesen...
Jedenfalls habe ich durch diesen Thread wieder einige neue Dinge in Erfahrung gebracht und bin für alle Eure Beiträge sehr dankbar. Gute Nacht!
Die Weigerung für wenige € Cat5e zu verlegen, damit WENIGSTENS der Mindeststandard für Gigabit vorliegt und man dann nicht rumraten muss, ob das nicht doch irgendwas murkst. Wir werden es nie erfahren.
Ja, höchstwahrscheinlich möglicherweise ändert es für jetzt nichts (vielleicht aber doch) und ja, die Messung hat ergeben, dass dein ISP das im Tarif vereinbarte reinliefert und die beiden verbundenen Geräte entschieden haben, dass sie bei dem Kabel GigE schalten. Das kann doch aber nicht der Grund sein, es nicht zu tauschen.
Bevor ich irgendwo was optimiere und zuverlässige Messergebnisse erwarte, sorge ich doch zuerst dafür, dass der Mindeststandard erfüllt ist? Wie kann ich einen sauberen Betrieb ohne diffuse Probleme ohne Mindeststandard erwarten? Ist potentielle Fehlerquellenvermeidung keine Verbesserung? Ein passendes Kabel wäre in keinster Weise Verschwendung und wir reden nicht von Ausgaben, wo man überhaupt darüber sprechen müsste.
Ich kann dich nicht zu deinem Glück zwingen, mich irritiert sowas nur hart in einem Techforum.
Beim nächsten Router geht dann vielleicht gar nichts mehr und es gibt wieder nen Thread mit Fragezeichen...weil "mit dem alten hats doch funktioniert". Ka, weiß nicht...
Andy_m4
Well-Known Member
Sieh' solche Threads doch einfach als regelmäßiges "ping", ob das Forum noch lebt. ;-)
cabriofahrer
Well-Known Member
Sorry, aber man kann nicht von Weigerung sprechen, wenn ich mir nicht sofort von einem Tag auf den anderen ein neues Kabel besorge, nur weil man etwas vermuten kann. Ich habe in unmittelbarer Nähe keinen Laden, in dem es sowas gibt, ich müsste es mir bei Amazon bestellen. Es hat sich auch eher zufällig erst in diesem Thread, in dem es eigentlich um eine andere Frage ging, ergeben, dass das Kabel zu alt ist.
Wenn ich mich also jetzt dazu entscheide, ein neues Kabel zu bestellen, dann wird es noch ein paar Tage dauern. Ihr werdet es dann also doch irgendwann erfahren, keine Sorge.
Unabhängig von dem Kabel bleibt jedoch meine Frage, warum ich in einer Messung über 600 Mbitps bekomme, wenn ich angeblich nur 500 habe? Ist die vertraglich genannte Leistung nur geschätzt und kann sie in der Praxis drunter oder drüber liegen?
Na das ist doch auch schön...^^
pit234a
Well-Known Member
sowohl, als auch.
Meist sind die Leitungen ja besser, als der abgeschlossene Tarif. In meinem Fall habe ich eine 2G Glasfaser und einen 2G Tarif, aber innerhalb des Hauses ja nur 1G verlegt. Wäre der 1G Tarif billiger gewesen, hätte ich den genommen, aber der Zugang wäre ja immer noch (wenigstens) für 2G ausgelegt gewesen. Das bedeutet, dass häufig dein tarif über die Leistung entscheidet und nicht die verwendete HW.
Die meisten Provider "sichern" einem dann eine Leistung "bis zu" dem bezahlten Tarif, das heißt, es darf auch durchaus deutlich weniger sein.
Sodann sind die Messungen ja nicht zu vergleichen, wie wenn man während der Autofahrt aufs Tacho schaut, eher schon mit der Messung eines Blitzers, der ja von außen hinschaut und eine Strecke und Zeit messen muss, um daraus die Geschwindigkeit zu ermitteln. Hier werden Datenpakete generiert und von einem Rechner übers Internet zu einem anderen Rechner geschickt und dann die Zeiten gemessen. Zwischen den beiden Ziel-Rechnern können unterschiedlich viele Stationen liegen und alleine daher die Ergebnisse schon mal schwanken. Deshalb haben Test-Tools wie iperf3 auch diverse Einstellungen, mit denen man die Mess-Variablen beeinflussen kann, etwa die Zeit einer Messung (wenn ich richtig erinnere). Und deshalb sollte man auch immer mehrere Messungen durchführen, um sich ein Bild zu machen. Abweichungen von 20% rauf und runter sind nicht ungewöhnlich und es kann je nach Test sogar deine Festplatte mit eingebunden werden und unter Umständen dann auch wieder was bremsen.
Nunja, im "richtigen Leben", also beim alltäglichen Gebrauch des PCs ist das dann ja auch so, dass die Performance des Rechners in das Geschehen eingeht und nicht nur die Geschwindigkeit des Datenflusses aus dem Internet, gar nicht zu reden von der Performance der Anbieter im Netz, die auch stark unterschiedlich sein kann.
Deshalb sagen solche Tests nicht besonders viel über die "Surf-Geschwindigkeit", sie zeigen nur, ob grundsätzlich bis zu dieser Stelle alles im grünen Bereich liegt, oder hier bereits ein Problem vorliegt.
wo auch immer, eine Lieferung ist innerhalb weniger Tage möglich.
Da will ich dich nun nicht beeinflussen, aber ich könnte nicht wirklich ohne eine Kiste voller Ersatzkabel leben. Ich brauche immer wenigstens einen Ersatz-PC, Ersatz Access-Points, Switches, Netzteile und so weiter, damit ich überhaupt Fehler suchen kann und im Falle eines Ausfalles auch mal schnell reagieren. Lan-Patch-Kabel hatte ich früher immer in der Werkzeugtasche, zu eigenem Gebrauch, aber auch als schneller Ersatz. Patch-Kabel sind quasi Verbrauchsteile, weil schnell mal jemand sich darin verheddert und sie aus der Fassung reißt, womit dann die Arretierung oft schadhaft ist und eine meist schwierig zu findende Fehlerquelle darstellt. Sehr schnell werden die Kabel auch mal gequetscht oder zu scharf gebogen. Kurzum, man will ein ordentliches Kabel zur Hand haben, um mal schnell zu wechseln und testen zu können.
Also, mir fehlt hier die Geduld, bei einem Vorkommnis, erst noch Tage bis zur Lieferung einer Bestellung zu warten.
Das ist halt mein Blickwinkel und es ist menschlich, das auf Andere zu übertragen, aber durchaus nicht in Ordnung. Nur bin ich halt so und nur ein armer, sündiger Mensch. Mir würde es helfen, wenn ich gleich zu Recht gewiesen würde, indem ein kleiner Satz einfließt, der Art: "ist angekommen, wird in naher Zukunft probiert". Oder nächstes Jahr oder wenn wieder Zahltag war, was auch immer. Du verstehst? Kein solcher Hinweis kann auch Ignoranz des Vorschlages bedeuten. Ablehnung eines Vorschlages aus irgendwelchen Gründen ist nicht so schlimm, wie totale Ignoranz. Aber das ist nun ganz allgemein gesprochen.
cabriofahrer
Well-Known Member
Ja @pit234a , ist angekommen. Ich werde mir ein neues Kabel bestellen. Was hälst Du von diesem hier?
Wenn du dir ein neues Kabel kaufst, bitte kauf dir ein S/FTP Kabel. S für shielded (also Drahtmantel rum, hat das was du verlinkt hast nicht), F für foiled (Die Adernpaare sind einzeln in Folie verpackt).
Das hier zB: https://www.amazon.es/Cat7-Cable-Re...=ethernet+cable+5m+cat7&qid=1722329039&sr=8-7
Bitte nochmal kontrollieren, ich spreche kein Spanisch.
Das hier zB: https://www.amazon.es/Cat7-Cable-Re...=ethernet+cable+5m+cat7&qid=1722329039&sr=8-7
Bitte nochmal kontrollieren, ich spreche kein Spanisch.
midnight
OpenBSD & FreeBSD
Geschirmt ist jedenfalls sehr wichtig, wie medV2 bereits schrieb. Vor allem, da Du das Kabel zusammen mit Stomleitungen verlegst. Normalerweise muss alles ueber 48V getrennt von Niederspannung verlegt werden und zu Niederspannung zaehlt auch das Netzwerkkabel und Telefonleitungen. Wenn das nicht moeglich ist, sollte es wenigstens ausreichend gut geschirmt sein. Sonst kann es sein, dass die 50 Hz Netzfrequenz ins Netzwerkkabel induziert, was zu Fehlfunktionen und Uebertragungsstoerungen fuehren kann.