#11  (Permalink
Alt 19.08.2019, 10:20
Benutzerbild von Chrisulin
Chrisulin Chrisulin ist offline
Mitglied
 
Registriert seit: 13.03.2015
Beiträge: 494
Provider: Telekom
Bandbreite: VDSL 100
Standard AW: Paketverlust: Sind diese Werte normal?

@Khaaaan
Frage am Rande, Netzwerkadapter, MTU, Windows 10 TCP/IP Parameter sind schon mal überprüft worden? Ähnlich wie bei dir hatte ich es mal im Netz gelesen. Dort war die Lösung einfach, das Windows 10 Auto-Tuning Level war verantwortlich und wurde deaktiviert. Danach sah der Upload nicht mehr so zackig aus wie bei dir im dslreports Ergebnis. Falls schon geprüft, einen Versuch wäre es Wert.
__________________
FRITZ!Box 7530 (7.13), Broadcom 178.17, Magenta L mit TV-Plus
Mit Zitat antworten
  #12  (Permalink
Alt 19.08.2019, 13:24
Khaaaan Khaaaan ist offline
Neues Mitglied
 
Registriert seit: 04.11.2017
Beiträge: 25
Standard AW: Paketverlust: Sind diese Werte normal?

Zitat:
Zitat von pufferueberlauf Beitrag anzeigen
Ach so, die DS und US Fehler- Zähler wären interessant, um Deine TAL zu bewerten.


Gruss
P.


P.S.: habe keine Fritzbox und deshalb auch keine Ahnung was da sonst noch in den Supportdaten steht, aber das braucht es für Dein Problem auch gar nicht....

Was genau da alles drin steht weiß ich auch nicht . Mir ist nur beim ersten durchgucken aufgefallen, dass da auch WLAN Logs enthalten sind und da viele ihr Handy "HandyVonMaxMustermann" nennen sind, stehen dort die Namen vom halben Freundes- und Bekanntenkreis drin. Und wer weiß, was da noch drin steht.


Naja, hier sind die Werte, die dich Interessieren.
Der dazugehörige Speedtest: http://www.dslreports.com/speedtest/53270239
Vorher:
Code:
DSL
---

DS Max Rate: 8192
DS Min Rate: 720
DS Attainable: 9980
DS Delay: 8
DS INP: 2.7
DS Trellis: 16
DS Bitswap: 1
DS Bitswap Cnt: 170
DS Margin (dB): 8
DS Margin per Band (0.1dB): 0
DS Attenuation (dB): 41
DS Attenuation per Band (0.1dB): 0
DS Powercutback: 0
DS SRA: 0
DS SRA Cnt: 0
DS ES: 12
DS SES: 0
DS total CRC: 14
DS total FEC: 19532
DS CRC per Minute (0.01): 0
DS FEC per Minute (0.01): 757
DS CRC 15 Minutes (0.01): 0
DS FEC 15 Minutes (0.01): 3
DS RTX active: 0
DS RTX used: RTX not in use, not supported by the XTU-R
DS RTX intra DTU ilv active: 0
DS RTX INP against REIN: 0
DS RTX expected throughput (kbit/s): 0
DS RTX error free throughput (kbit/s): 0
DS RTX uncorrected DTUs: 0
DS RTX corrected DTUs: 0
DS RTX retransmitted DTUs: 0

US Max Rate: 2800
US Min Rate: 368
US Attainable: 2384
US Delay: 6
US INP: 1.1
US Trellis: 128
US Bitswap: 1
US Bitswap Cnt: 177
US Margin (dB): 6
US Margin per Band(0.1dB): 0
US Attenuation (dB): 22
US Attenuation per Band (0.1dB): 0
US Powercutback: 0
US SRA: 0
US SRA Cnt: 0
US ES: 110
US SES: 0
US total CRC: 141
US total FEC: 1105938
US CRC per Minute: 5
US FEC per Minute: 42882
US CRC 15 Minutes: 3
US FEC 15 Minutes: 13040
US RTX active: 0
US RTX used: RTX not in use, RTX_MODE = FORBIDDEN
US RTX intra DTU ilv active: 0
US RTX INP against REIN: 0
US RTX expected throughput (kbit/s): 0
US RTX error free throughput (kbit/s): 0
US RTX uncorrected DTUs: 0
US RTX corrected DTUs: 0
 US RTX retransmitted DTUs: 0
Nachher:
Code:
DSL
---

DS Max Rate: 8192
DS Min Rate: 720
DS Attainable: 9988
DS Delay: 8
DS INP: 2.7
DS Trellis: 16
DS Bitswap: 1
DS Bitswap Cnt: 170
DS Margin (dB): 8
DS Margin per Band (0.1dB): 0
DS Attenuation (dB): 41
DS Attenuation per Band (0.1dB): 0
DS Powercutback: 0
DS SRA: 0
DS SRA Cnt: 0
DS ES: 12
DS SES: 0
DS total CRC: 14
DS total FEC: 19532
DS CRC per Minute (0.01): 0
DS FEC per Minute (0.01): 757
DS CRC 15 Minutes (0.01): 0
DS FEC 15 Minutes (0.01): 3
DS RTX active: 0
DS RTX used: RTX not in use, not supported by the XTU-R
DS RTX intra DTU ilv active: 0
DS RTX INP against REIN: 0
DS RTX expected throughput (kbit/s): 0
DS RTX error free throughput (kbit/s): 0
DS RTX uncorrected DTUs: 0
DS RTX corrected DTUs: 0
DS RTX retransmitted DTUs: 0

US Max Rate: 2800
US Min Rate: 368
US Attainable: 2384
US Delay: 6
US INP: 1.1
US Trellis: 128
US Bitswap: 1
US Bitswap Cnt: 177
US Margin (dB): 6
US Margin per Band(0.1dB): 0
US Attenuation (dB): 22
US Attenuation per Band (0.1dB): 0
US Powercutback: 0
US SRA: 0
US SRA Cnt: 0
US ES: 110
US SES: 0
US total CRC: 141
US total FEC: 1107022
US CRC per Minute: 5
US FEC per Minute: 42907
US CRC 15 Minutes: 3
US FEC 15 Minutes: 13236
US RTX active: 0
US RTX used: RTX not in use, RTX_MODE = FORBIDDEN
US RTX intra DTU ilv active: 0
US RTX INP against REIN: 0
US RTX expected throughput (kbit/s): 0
US RTX error free throughput (kbit/s): 0
US RTX uncorrected DTUs: 0
US RTX corrected DTUs: 0
   US RTX retransmitted DTUs: 0
Edit:
Wenn ich die Anzahl der Streams auf 1/1 begrenze, gibt es kein Paketverlust mehr.
http://www.dslreports.com/speedtest/53270627

Geändert von Khaaaan (19.08.2019 um 13:29 Uhr)
Mit Zitat antworten
  #13  (Permalink
Alt 19.08.2019, 13:42
Khaaaan Khaaaan ist offline
Neues Mitglied
 
Registriert seit: 04.11.2017
Beiträge: 25
Standard AW: Paketverlust: Sind diese Werte normal?

Zitat:
Zitat von Chrisulin Beitrag anzeigen
@Khaaaan
Frage am Rande, Netzwerkadapter, MTU, Windows 10 TCP/IP Parameter sind schon mal überprüft worden? Ähnlich wie bei dir hatte ich es mal im Netz gelesen. Dort war die Lösung einfach, das Windows 10 Auto-Tuning Level war verantwortlich und wurde deaktiviert. Danach sah der Upload nicht mehr so zackig aus wie bei dir im dslreports Ergebnis. Falls schon geprüft, einen Versuch wäre es Wert.

Das hatte ich tatsächlich noch nicht geprüft, also vielen Dank für den Hinweis. Leider hat das Ändern des Windows 10 Auto-Tuning Level nichts gebracht. Die MTU Größe ist 1500, was standard ist, oder? Ich hab den Speedtest auch noch mal an einem Linux Rechner laufen lassen und da sah das Ergebnis auch zackig aus.
Mit Zitat antworten
  #14  (Permalink
Alt 19.08.2019, 14:14
pufferueberlauf pufferueberlauf ist offline
Senior Mitglied
 
Registriert seit: 20.06.2013
Beiträge: 3.345
Standard AW: Paketverlust: Sind diese Werte normal?

MMMh, die CRC Fehler haben sich ueber den Test nicht veraendert, weder im DS noch im US und sind mit 14 und 141 so niedrig, dass Sie Deine Paketverluste nicht erklaeren koennen. Auch der Umstand dass
"Wenn ich die Anzahl der Streams auf 1/1 begrenze, gibt es kein Paketverlust mehr."
spricht dafuer, dass die DSL-Strecke nicht Dein Problem ist.
"Ich hab den Speedtest auch noch mal an einem Linux Rechner laufen lassen und da sah das Ergebnis auch zackig aus."

Koenntest Du da bitte den Link zu posten?

Entweder kommt es in Deinem Heimnetz zu den Packetverlusten oder bei Deinem ISP. Wenn es das Heimnetz ist, wuerde ich immer den Router als potentiell Verdächtigen mit ins Auge fassen; wenn Du die Chance hast den Router mal auszutauschen waere das ein guter Test. Ansonsten sind WLAN-Strecken manchmal problematisch, da lohnt es sich dann mal mit komplett deaktiviertem WLAN auf dem Router ueber ein Ethernetkabel den Test zu wiederholen...

Ach ja, wenn Du einen Linuxrechner zur Verfügung hast dann lass doch mal "mtr -4 www.heise.de" parallel zu einem Speedtest laufen und poste den Output hier (Achtung der enthaelt Deine IPv4 Adresse, die ist aber unwichtig kann also problemlos geXXX.XXX.XXX.XXXt werden). Damit kommt man manchmal Problemen auf der Strecke auf die Schliche (ist aber nicht ganz einfach zu interpretieren).

Und zuletzt waere ein Speedtest gegen breitbandmessung.de mit gleichzeitigem Wireshark-Mitschnitt interessant um zu sehen wie viele Retransmits dann auftreten (idealerweise auch das mit parallelem mtr vom Linuxhost).


Gruss
P.
Mit Zitat antworten
  #15  (Permalink
Alt 19.08.2019, 15:50
Khaaaan Khaaaan ist offline
Neues Mitglied
 
Registriert seit: 04.11.2017
Beiträge: 25
Standard AW: Paketverlust: Sind diese Werte normal?

Zitat:
Zitat von pufferueberlauf Beitrag anzeigen
wenn Du die Chance hast den Router mal auszutauschen waere das ein guter Test. Ansonsten sind WLAN-Strecken manchmal problematisch, da lohnt es sich dann mal mit komplett deaktiviertem WLAN auf dem Router ueber ein Ethernetkabel den Test zu wiederholen...

Alle bisherigen Tests waren über Ethernet. Bevor ich hier im Forum geschrieben habe, hatte ich schon eine Fritzbox 7390 angeschlossen, aber das hat nichts geändert. Allerdings ist das ja auch eine Fritzbox. Ich die aber auch noch mal anschließen und die Tests wiederholen.


Hier sind die Ergebnisse von mtr während eines Speedtests bei dslreports. Ich habe das Intervall verkürzt, damit die die Werte genauer sind und außerdem habe ich das in Download- und Uploadphase aufgeteilt. Dafür musste ich 2 Speedtests machen, aber die Ergebnisse waren bei beiden sehr ähnlich. Die Speedtests habe ich auf demselben Linux Rechner laufen lassen, auf dem auch mtr lief. Des Weiteren habe ich die ersten 2 Hops rausgenommen, da ich nicht weiß, wie viel die über meinen genauen Standort aussagen .


dslreports Ergebnis: http://www.dslreports.com/speedtest/53272073


Downloadphase:
Code:
fsda (10.0.0.33)                                       2019-08-19T14:52:12+0200
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. fritz.box                         5.9%   118   17.4  61.6   0.4 126.1  20.9
    X.X.X.X
 2. X.X.X.X                           6.8%   118   17.4  62.4  17.4 116.3  20.7
 3. X.X.X.X                           2.6%   118   25.9  69.0  25.3 101.4  19.9
 4. 62.157.251.38                     6.0%   117   25.5  69.9  25.5 104.6  20.4
 5. 82.98.102.5                       5.1%   117   25.6  67.9  25.5  92.4  19.9
 6. 82.98.102.65                      3.4%   117   25.1  69.1  24.9 192.8  23.1
 7. 212.19.61.13                      1.7%   117   25.0  68.7  25.0 103.5  19.2
 8. redirector.heise.de               2.6%   117   25.7  68.0  24.9  90.9  19.3
Uploadphase:
Code:
 fsda (10.0.0.33)                                       2019-08-19T14:57:44+0200
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. fritz.box                         0.0%   194   20.3  23.1   0.4  79.2   9.5
    X.X.X.X
 2. X.X.X.X                           0.0%   194   18.9  22.7  17.9  66.6   7.1
 3. X.X.X.X                           0.0%   193   25.1  28.8  25.1  35.2   2.0
 4. 62.157.251.38                     0.0%   193   31.8  30.2  25.8  41.4   2.4
 5. 82.98.102.5                       0.0%   193   30.0  29.2  25.9  36.1   1.9
 6. 82.98.102.65                      0.0%   193   28.2  28.7  25.5  35.5   1.8
 7. 212.19.61.13                      0.0%   193   27.8  29.4  25.3 129.2   7.5
    8. redirector.heise.de               0.0%   193   26.7  28.6  25.3  36.4   2.1
Und hier das ganze noch mal bei breitbandmessung.de.

Wireshark: https://imgur.com/a/oTxQfEs
Falls du noch mehr Informationen von Wireshark brauchst, dann sag bescheid.


Code:
My traceroute  [v0.92]
fsda (10.0.0.33)                                       2019-08-19T15:10:15+0200
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. fritz.box                         1.0%   409   20.7  34.0   0.5 111.8  21.5
    X.X.X.X
 2. X.X.X.X                           0.2%   409   19.3  33.8  17.0  99.5  21.1
 3. X.X.X.X                           1.0%   409   29.9  40.2  25.0  97.7  20.2
 4. 62.157.251.38                     1.0%   408   29.1  41.7  25.4 101.3  20.5
 5. 82.98.102.5                       0.0%   408   27.9  41.1  25.0  99.9  20.8
 6. 82.98.102.65                      0.2%   408   26.2  41.2  24.8 148.4  21.9
 7. 212.19.61.13                      0.2%   408   31.0  41.0  24.7 202.5  22.2
 8. redirector.heise.de               0.7%   408   30.0  40.3  24.7  99.3  20.4
Mit Zitat antworten
  #16  (Permalink
Alt 20.08.2019, 11:16
pufferueberlauf pufferueberlauf ist offline
Senior Mitglied
 
Registriert seit: 20.06.2013
Beiträge: 3.345
Standard AW: Paketverlust: Sind diese Werte normal?

Zitat:
Zitat von Khaaaan Beitrag anzeigen
Alle bisherigen Tests waren über Ethernet.
Gut, hatte ich wohl ueberlesen.
Zitat:
Zitat von Khaaaan Beitrag anzeigen

Bevor ich hier im Forum geschrieben habe, hatte ich schon eine Fritzbox 7390 angeschlossen, aber das hat nichts geändert. Allerdings ist das ja auch eine Fritzbox. Ich die aber auch noch mal anschließen und die Tests wiederholen.
Okay, alternatives Modem getestet selbes Verhalten, das Modem der 7390 hat keinen guten Ruf, aber ich glaube das bezieht sich auf VDSL nicht ADSL und ausserdem ist Dein Hauptmodem ja eine andere FB.
Zitat:
Zitat von Khaaaan Beitrag anzeigen

Hier sind die Ergebnisse von mtr während eines Speedtests bei dslreports. Ich habe das Intervall verkürzt,
Also, das mtr interval ("mtr -i")? Oder die Dauer des dslreport sppedtests? (Nach kostenloser Registrierung kann man da den Test konfigurieren, einschliesslich laengerer Laufzeiten, messe gerne mit 30-60 Sekunden pro Richtung).
Zitat:
Zitat von Khaaaan Beitrag anzeigen

damit die die Werte genauer sind und außerdem habe ich das in Download- und Uploadphase aufgeteilt.
Gute Idee.
Zitat:
Zitat von Khaaaan Beitrag anzeigen

Dafür musste ich 2 Speedtests machen, aber die Ergebnisse waren bei beiden sehr ähnlich. Die Speedtests habe ich auf demselben Linux Rechner laufen lassen, auf dem auch mtr lief.
Theoretisch nicht ideal, aber bei ADSL-Bandbreiten duerfte das egal sein (es sei denn Deine Linux-PC ist steinalt ).
Zitat:
Zitat von Khaaaan Beitrag anzeigen


Des Weiteren habe ich die ersten 2 Hops rausgenommen, da ich nicht weiß, wie viel die über meinen genauen Standort aussagen .
Kein Problem, wichtig sind die Zaehler, die IP Adresse ist ever weniger relevant. Tip, mit "mtr -z ..." zeigt mtr auch die AS Nummern der Hops an, damit kann man erkennen, durch welches Netz die Pakete (auf dem Hinweg) laufen, ist aber auch nicht wirklich Dein Problem
Zitat:
Zitat von Khaaaan Beitrag anzeigen

dslreports Ergebnis: http://www.dslreports.com/speedtest/53272073


Downloadphase:
Code:
fsda (10.0.0.33)                                       2019-08-19T14:52:12+0200
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. fritz.box                         5.9%   118   17.4  61.6   0.4 126.1  20.9
    X.X.X.X
 2. X.X.X.X                           6.8%   118   17.4  62.4  17.4 116.3  20.7
 3. X.X.X.X                           2.6%   118   25.9  69.0  25.3 101.4  19.9
 4. 62.157.251.38                     6.0%   117   25.5  69.9  25.5 104.6  20.4
 5. 82.98.102.5                       5.1%   117   25.6  67.9  25.5  92.4  19.9
 6. 82.98.102.65                      3.4%   117   25.1  69.1  24.9 192.8  23.1
 7. 212.19.61.13                      1.7%   117   25.0  68.7  25.0 103.5  19.2
 8. redirector.heise.de               2.6%   117   25.7  68.0  24.9  90.9  19.3
Oha, der Packetloss geht direkt an der FritzBox los, das ist schlecht. Aber nur beim Download...
Zitat:
Zitat von Khaaaan Beitrag anzeigen

Uploadphase:
Code:
 fsda (10.0.0.33)                                       2019-08-19T14:57:44+0200
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. fritz.box                         0.0%   194   20.3  23.1   0.4  79.2   9.5
    X.X.X.X
 2. X.X.X.X                           0.0%   194   18.9  22.7  17.9  66.6   7.1
 3. X.X.X.X                           0.0%   193   25.1  28.8  25.1  35.2   2.0
 4. 62.157.251.38                     0.0%   193   31.8  30.2  25.8  41.4   2.4
 5. 82.98.102.5                       0.0%   193   30.0  29.2  25.9  36.1   1.9
 6. 82.98.102.65                      0.0%   193   28.2  28.7  25.5  35.5   1.8
 7. 212.19.61.13                      0.0%   193   27.8  29.4  25.3 129.2   7.5
    8. redirector.heise.de               0.0%   193   26.7  28.6  25.3  36.4   2.1
Der Upload sieht hier sauber aus...
Zitat:
Zitat von Khaaaan Beitrag anzeigen


Und hier das ganze noch mal bei breitbandmessung.de.

Wireshark: https://imgur.com/a/oTxQfEs
Falls du noch mehr Informationen von Wireshark brauchst, dann sag bescheid.


Code:
My traceroute  [v0.92]
fsda (10.0.0.33)                                       2019-08-19T15:10:15+0200
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. fritz.box                         1.0%   409   20.7  34.0   0.5 111.8  21.5
    X.X.X.X
 2. X.X.X.X                           0.2%   409   19.3  33.8  17.0  99.5  21.1
 3. X.X.X.X                           1.0%   409   29.9  40.2  25.0  97.7  20.2
 4. 62.157.251.38                     1.0%   408   29.1  41.7  25.4 101.3  20.5
 5. 82.98.102.5                       0.0%   408   27.9  41.1  25.0  99.9  20.8
 6. 82.98.102.65                      0.2%   408   26.2  41.2  24.8 148.4  21.9
 7. 212.19.61.13                      0.2%   408   31.0  41.0  24.7 202.5  22.2
 8. redirector.heise.de               0.7%   408   30.0  40.3  24.7  99.3  20.4

Mmh, die Paketverluste passen in etwa zu denen aus den beiden obigen tests (bei ~400 probes gegen ~120 sollte die gleiche Anzahl verlorener Probes in etwa die beobachteten Verlustanteile erklären.)

Wegen WIreshark habe ich keine bessere Idee, ausser vieleicht im IO graph noch tcp.analysis.retransmission und tcp.analysis.duplicate_ack anzeigen zu lassen und auf "Logarithmische Skala" umzuschalten.

Letztlich, arbeitet TCP so, dass das Sendefenster staendig vergroessert wird, bis es zum Paketverlust kommt, dann wird das Fenster halbiert und langsam wieder hochgefahren. D.h. Paketverlust per se ist gar nicht so boese, aber die Anteil auf Deinem Link scheint mir deutlich zu hoch zu sein.

Gruss
P.
Mit Zitat antworten
  #17  (Permalink
Alt 20.08.2019, 13:59
Pornstar Pornstar ist offline
Senior Mitglied
 
Registriert seit: 21.04.2017
Ort: 192.26
Beiträge: 1.913
Standard AW: Paketverlust: Sind diese Werte normal?

Je nach Fritz OS Version werden ICMP requests geblockt, kommen also nach ner Zeit fast gar nicht mehr durch.
Man kann so also keine vernünftige Analyse über icmp requests starten, insofern die fritte das nicht vernünftig zulässt.
Mit Zitat antworten
  #18  (Permalink
Alt 20.08.2019, 15:15
pufferueberlauf pufferueberlauf ist offline
Senior Mitglied
 
Registriert seit: 20.06.2013
Beiträge: 3.345
Standard AW: Paketverlust: Sind diese Werte normal?

Zitat:
Zitat von Pornstar Beitrag anzeigen
Je nach Fritz OS Version werden ICMP requests geblockt, kommen also nach ner Zeit fast gar nicht mehr durch.
Man kann so also keine vernünftige Analyse über icmp requests starten, insofern die fritte das nicht vernünftig zulässt.
Guter Punkt. "mtr -u ..." erlaubt die Verwendung von UDP probes, "mtr -T ..." die Verwendung von TCP probes, muss man ausprobieren was geht. Ansonsten ist http://gfblip.appspot.com ein passables Mittel um die instantane Latenz des eigenen Anschlusses anschaulich zu machen (mehr Information unter https://github.com/apenwarr/blip)

Gruss
P.
Mit Zitat antworten
  #19  (Permalink
Alt 20.08.2019, 15:38
Khaaaan Khaaaan ist offline
Neues Mitglied
 
Registriert seit: 04.11.2017
Beiträge: 25
Standard AW: Paketverlust: Sind diese Werte normal?

Zitat:
Zitat von pufferueberlauf Beitrag anzeigen
Gut, hatte ich wohl ueberlesen.
Hatte ich bisher noch nicht erwähnt, also nicht dein Fehler.


Zitat:
Zitat von pufferueberlauf Beitrag anzeigen
Also, das mtr interval ("mtr -i")? Oder die Dauer des dslreport sppedtests?

Mit "mtr -i 0.1".

Zitat:
Zitat von pufferueberlauf Beitrag anzeigen
Wegen WIreshark habe ich keine bessere Idee, ausser vieleicht im IO graph noch tcp.analysis.retransmission und tcp.analysis.duplicate_ack anzeigen zu lassen und auf "Logarithmische Skala" umzuschalten.

Hier :
https://imgur.com/a/kv7mQTN
Mit Zitat antworten
  #20  (Permalink
Alt 20.08.2019, 15:46
Khaaaan Khaaaan ist offline
Neues Mitglied
 
Registriert seit: 04.11.2017
Beiträge: 25
Standard AW: Paketverlust: Sind diese Werte normal?

Zitat:
Zitat von Pornstar Beitrag anzeigen
Je nach Fritz OS Version werden ICMP requests geblockt, kommen also nach ner Zeit fast gar nicht mehr durch.
Man kann so also keine vernünftige Analyse über icmp requests starten, insofern die fritte das nicht vernünftig zulässt.

Ich glaube, dass das hier der Fall war, da die bei der Fritzbox die gleiche IP wie beim 2. Hop angezeigt wurde. Das hätte ich noch dazuschreiben sollen, da ihr das ja nicht sehen konntet. Auch der Ping ist ziemlich hoch für Ethernet. Ich werde das ganze, wie von pufferueberlauf vorgeschlagen, gleich noch mal mit "mtr -u ..." wiederholen, da das zu funktionieren scheint.
Mit Zitat antworten
 
Anzeige
Antwort


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
 
Themen-Optionen

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.

Gehe zu

Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
Paketverlust bei RTTC normal ? QWERTZ3 ADSL und ADSL2+ 13 12.08.2017 12:18
Sind diese Werte plausibel ? Anotono ADSL und ADSL2+ 33 21.03.2006 15:37
ACHTUNG: Sind diese Werte gut (Rauschwerte)??? williwuff Arcor [Archiv] 12 01.08.2005 15:29
Sind diese Werte auch für dsl 3000 und höher ok ?? alex66 Arcor [Archiv] 3 03.07.2005 13:41
Sind diese Werte in Ordnung? derGunnar ADSL und ADSL2+ 10 11.10.2003 18:03


Alle Zeitangaben in WEZ +2. Es ist jetzt 03:19 Uhr.


Basiert auf vBulletin®
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.