Kein Paket Verlust, dennoch lägs im TS > Debian 9

S

SirFail

New Member
Guten Tag,

nach den Problemen mit unserem letzten Server haben wir vor fünf tagen auf einen Server mit Ryzen 2700x und 64GB Ram und 2x1TB HDD gewechselt.
Hab ganz normal alles installiert: Mailserver(Über Mailcow), Teamspeak, Webserver dazu Forum, und unsere Ts3 Bots, sowie einen Minecraft Server. Uns ist dann
ganz schnell aufgefallen, das auf dem Teamspeak Server komische Lag Spikes auftreten. Paket Verlust ist meistens nicht da. Aber wenn dann bis 10%. Die Lägs sind nicht bei allen Usern zur gleichen Zeit sondern sporadisch bei allen zu Unterschiedlichen Zeiten. Habe Debian 9 schon einmal neuinstalliert, Und solange nur der TS3 Server läuft sind die lägs weniger da. Sobald auf dem Server mehr Traffic läuft wird es schlimmer. Der Hoster sagt es besteht kein Problem. Doch in WinMTR's sind teilweise Pings von bis zu 6000 zu sehen. Meine Frage ist jetzt: Machen wir tatsächlich was falsch oder ist das nur ein Zufälliges Problem das gerade bei allen Internet Anbietern besteht(Ich bin bei der Telekom, 3 andere User bei O2 und 4 bei Vodafone). Unser Hoster möchte keine weitern schritte unternehmen und ich weiß nicht mehr weiter da ich für den rest des Monats mit einem nicht funktionierenden Server fest sitze und diesen Zahlen muss. Wir haben dem Hoster ja sogar ein Video geschickt mit den Lägs da dieser sagte das wenn er auf dem Server ist keine Lägs da sind, dieses hat er einfach ignoriert.

|------------------------------------------------------------------------------------------|

| WinMTR statistics |

| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |

|------------------------------------------------|------|------|------|------|------|------|

| speedport.ip - 0 | 382 | 382 | 0 | 0 | 31 | 1 |

| p3e9bf546.dip0.t-ipconnect.de - 0 | 382 | 382 | 4 | 6 | 75 | 5 |

| 217.5.116.218 - 0 | 382 | 382 | 7 | 8 | 17 | 9 |

| 217.5.116.218 - 0 | 382 | 382 | 7 | 8 | 24 | 8 |

| 80.156.162.158 - 0 | 382 | 382 | 7 | 9 | 45 | 8 |

| ae10-2021.fra20.core-backbone.com - 0 | 382 | 382 | 7 | 8 | 21 | 8 |

| ae4-33891.edge2.ffm3 - 1 | 357 | 356 | 10 | 192 | 4752 | 169 |

| ae0-edge1.core1.ffm3 - 1 | 357 | 356 | 9 | 196 | 4795 | 115 |

| ae1-ffm31.core1.ffm2 - 0 | 381 | 381 | 12 | 58 | 1341 | 29 |

| 45.11.17.250 - 0 | 382 | 382 | 10 | 41 | 259 | 220 |

| . - 1 | 378 | 377 | 7 | 8 | 34 | 8 |

|________________________________________________|______|______|______|______|______|______|

WinMTR v1.00 GPLv2 (original by Appnor MSP - Fully Managed Hosting & Cloud Provider)
|------------------------------------------------------------------------------------------|

| WinMTR statistics |

| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |

|------------------------------------------------|------|------|------|------|------|------|

| speedport.ip - 0 | 1922 | 1922 | 0 | 0 | 50 | 0 |

| p3e9bf546.dip0.t-ipconnect.de - 0 | 1921 | 1921 | 4 | 8 | 82 | 5 |

| 217.5.116.218 - 0 | 1921 | 1921 | 7 | 10 | 183 | 8 |

| 217.5.116.218 - 0 | 1921 | 1921 | 7 | 10 | 187 | 12 |

| 80.156.162.158 - 0 | 1921 | 1921 | 7 | 11 | 76 | 8 |

| ae10-2021.fra20.core-backbone.com - 0 | 1921 | 1921 | 7 | 10 | 68 | 8 |

| ae4-33891.edge2.ffm3 - 1 | 1874 | 1864 | 9 | 61 | 4155 | 60 |

| ae0-edge1.core1.ffm3 - 1 | 1875 | 1865 | 9 | 60 | 4130 | 20 |

| ae1-ffm31.core1.ffm2 - 0 | 1903 | 1903 | 12 | 66 | 3120 | 28 |

| 45.11.17.250 - 0 | 1921 | 1921 | 10 | 46 | 264 | 17 |

| . - 1 | 1913 | 1911 | 7 | 10 | 384 | 8 |

|________________________________________________|______|______|______|______|______|______|

WinMTR v1.00 GPLv2 (original by Appnor MSP - Fully Managed Hosting & Cloud Provider)
HOST: mail.theorderofdarkness.eu Loss% Snt Last Avg Best Wrst StDev
1.|-- 45.11.17.250 0.0% 900 6.4 27.3 2.3 261.1 45.0
2.|-- 5.1.74.1 0.0% 900 8.4 73.4 1.0 2110. 288.2
3.|-- 160.20.144.21 0.0% 900 12.7 275.9 1.6 6700. 986.9
4.|-- 160.20.144.17 0.0% 900 6.4 278.6 1.8 6609. 988.3
5.|-- 160.20.144.69 0.0% 900 0.4 0.3 0.2 0.7 0.0
6.|-- 5.56.21.130 0.0% 900 0.6 1.5 0.5 47.4 5.4
7.|-- 212.6.114.37 0.0% 900 8.7 9.0 8.1 44.7 2.9
8.|-- 212.6.114.250 0.0% 900 17.1 10.4 9.7 26.5 1.1
9.|-- 85.16.249.118 0.0% 900 9.8 10.4 9.7 23.6 1.1
10.|-- 85.16.250.253 0.0% 900 13.7 10.8 9.7 38.4 3.6
11.|-- 31.150.230.172 0.4% 900 13.9 13.5 13.4 14.8 0.0

Mit freundlichen Grüßen
Patrick Lange
 

Attachments

  • pingplotter.png
    pingplotter.png
    108.8 KB · Views: 249
  • pingplotter2.png
    pingplotter2.png
    108 KB · Views: 211
Sorry, da ist kein Packetloss zu sehen. Nicht am Server. Warum und weshalb unterwegs einzelne Router nicht antworten, habe ich in diesem Thread mal erläutert.
Ich würde eher darauf tippen, dass der Energiesparmodus deiner CPU das verursacht. Vermutlich wird diese immer wieder hin und her geschaltet, jenachdem ob auf den Kernen mehr zu tun ist oder nicht - und das verursacht dann hörbare Lags.
Stell doch mal alle CPU-Kerne auf Performance-Mode und gucke, ob die Lags bleiben.
 
Guten Tag,

ich habe leider so gar keinen Plan wie man das macht wäre es möglich das sie mir ein Tutorial verlinken dazu oder das mir kurz erklären?
Ich will jetzt nicht einfach einem x Beliebigen Tutorial aus dem Internet folgen das dann mein Server zerschießt. Ich habe gerade auch noch gesehen das der Boost Takt aus ist. Wie kann ich den Aktivieren?

Mit freundlichen Grüßen
Patrick Lange
 
Last edited:
Normalerweise lässt sich das mit handelsüblichem Linux per "cpufreq-set -g performance -r" setzen.
Das solltest du dann aber notfalls später nochmal über die Taktfrequenzen kontrollieren (ob diese alle dann stabil dauerhaft auf höherem Takt laufen), gerade bei den aktuellen Epycs funktioniert es scheinbar nicht immer, alle CPU-Kerne auf einmal umzuschalten.
 
Danke,

das umstellen habe ich geschafft auch so das es noch nach dem Boot so ist, was ich nicht hin bekomme ist den Boost Takt zu aktivieren. Der Server läuft mit einem Ryzen 2700x. Wir testen nachher mal ob das jetzt die Probleme behoben hat oder nicht.
 
Boost kann meistens ohnehin nicht dauerhaft aktiviert sein, dafür ist die Kühlung in der Regel nicht ausgelegt.
Der Boost soll wirklich nur kurzzeitige Peaks abfangen, deshalb heißt der so ;-)
Ziel der Aktion war es auch, nicht die Änderungen der Taktfrequenz an sich zu unterbinden sondern nur den Energiesparmodus abzuschalten.
Wenn die CPU auf niedrigster Frequenz läuft und dann auch eher behäbig (teilweise erst nach 2-3 Sekunden Voll-Last) auf höhere Frequenzen wechselt, hast du in den 2-3 Sekunden dann Lags, weil die CPU ausgelastet ist. Läuft die CPU auf Performance-Mode, ist der Basistakt höher und bei kleinsten Anzeichen von Auslastung wird direkt der Takt erhöht, so dass immer genug Rechenzeit da ist.
So ist zumindest meine Erfahrung mit einer Videokonferenz-Software gewesen, die exakt gleiche Symptome zeigte.
 
So wir haben das ganze jetzt nochmal getest, es ist nicht weg aber es ist besser geworden. Was mir aufgefallen ist, ist folgendes. wenn der Server frisch ausm Clean Install kommt und ich nur den Energiesparmodus deaktiviere läuft der Ts3 Server spitze kommen dann weiter Dienste wie Apache2, MailServer, Terraria Server hinzu dann fängt es an zu spinnen umso mehr dazu kommt umso schlimmer wird es.

Wenn ich cpupower frequency-info eingebe kommt das raus:
analysiere CPU 0:
driver: acpi-cpufreq
Folgende CPUs laufen mit der gleichen Hardware-Taktfrequenz: 0
Die Taktfrequenz folgender CPUs werden per Software koordiniert: 0
Maximale Dauer eines Taktfrequenzwechsels: Cannot determine or is not supported.
Hardwarebedingte Grenzen der Taktfrequenz: 2.20 GHz - 3.70 GHz
available frequency steps: 3.70 GHz, 3.20 GHz, 2.20 GHz
mögliche Regler: conservative powersave userspace ondemand performance schedutil
momentane Taktik: die Frequenz soll innerhalb 2.20 GHz und 3.70 GHz.
liegen. Der Regler "performance" kann frei entscheiden,
welche Taktfrequenz innerhalb dieser Grenze verwendet wird.
current CPU frequency: 3.70 GHz (asserted by call to hardware)
boost state support:
Supported: yes
Active: no
Boost States: 0
Total States: 3
Pstate-P0: 900MHz
Pstate-P1: 400MHz
Pstate-P2: 500MHz

Habe inzwischen auch ein Festplattenfehler in betracht gezogen und habe folgendes Ergebnis weiß nur leider nicht ob das so normal ist oder nicht

fdisk -l
Disk /dev/sda: 1,8 TiB, 2000398934016 bytes, 3907029168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x98789596

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 499711 497664 243M 83 Linux
/dev/sda2 501758 3907028991 3906527234 1,8T 5 Extended
/dev/sda5 501760 3907028991 3906527232 1,8T 8e Linux LVM

Partition 2 does not start on physical sector boundary.


Disk /dev/mapper/blu4238--vg-root: 1,8 TiB, 1931472797696 bytes, 3772407808 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/mapper/blu4238--vg-swap_1: 64 GiB, 68664950784 bytes, 134111232 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
 
Last edited:
Mit fdisk kann man Festplattenfehler nicht erkennen ;-) Dafür bräuchtest du smartmontools.
Ich tippe aber auch weiterhin auf ein CPU-Problem. Als schnellen Fix würde ich Teamspeak einfach mit etwas höherer Prozesspriorität laufen lassen (sprich ein geringerer "nice"), dann können die anderen Dienste keine CPU-Zeit klauen.
 
Wenn die CPU auf niedrigster Frequenz läuft und dann auch eher behäbig (teilweise erst nach 2-3 Sekunden Voll-Last)
Click to expand...
Das unter einem Standard Linuxscheduler? Kommt mir seltsam vor. State- und Frequenzanpassungen erfolgen eher im Bereich von Nano- und Millisekunden. Sogar AMD's "parken" von CPU-Kernen ist im ms-Bereich. 2-3 Sekunden ist was ich ungefähr brauchte um physisch den "Turbo"-Knopf eines 486er zu drücken :p


was ich nicht hin bekomme ist den Boost Takt zu aktivieren
Click to expand...
Trotz der recht kurzen Taktungszeiten sollte man die CPU insbesondere für Gameserver und Teamspeak nicht dynamisch takten lassen. Dadurch verliert man aber Turboboost weil dies prinzipiell darauf basiert dass ein Core die von einem anderen (heruntergefahenen) Core ungenutzte Abwärme verwenden kann bis seine TJunction (interne Core-Temperatur) zu stark erhöht. S Ryzen 2xxx unterstützt zwar All-Core Boost, dabei hängt es aber extrem von der Umgebungstemperatur ab. Von der Hardware klingt es für mich nach potentiellem Towerhosting in sogenanntem "max-temp" (aka "eco") Rechenzentren (Umgebungstemperatur >30°). Kombiniert mit boxed-Kühlkörper wird dann kaum Kapazität für all-core-boost übrig bleiben. Hast du dir Temperaturen (CPU, Mainboard, Festplatten, ...) schon angesehen?

Als generelle Warnung auch hier; Latenzsensible Applikationen (Teamspeak, ...) soll man nicht auf dem gleichen System als lastintensive (Webserver, ...) Applikationen betreiben. Wie @Lord Gurke angegeben hat, kanne höhere Priorität (nice) helfen, ein voller LAMP(P)-Stack inklusive potentieller Adminoberfläche, Mailingstack inklusive Antispam, ... braucht sehr viel RAM und sehr viel CPU-Leistung. Ein kleines Webspace wäre hier generell die flexiblere und angenehmere Wahl.

Falls weder dein Anschluss noch der Server eine relevante Traffic-Limitierung haben und dein Anschluss einen vernünftigen Uplink hat, würde ich vorschlagen mal mit iperf3 im UDP-Modus drauf zu ballern, Howto zur Server- und Clienteinrichtung sind leicht zu finden deshalb überspringe ich das hier. In dieser Zeit sollte dein Anschluss unbenutzt sein. Iperf ist dahin sinnvoller als ping dass es quantitiv und qualitativ testet.

War euer vorheriges System (ihr habt ja erst gewechselt) beim gleichen Anbieter im gleichen Rechenzentrum und ohne Probleme? Anbindungen zu unterschiedlichen Netzen können durchaus unterschidlieche Störungen aufweisen aber die Anbindung im gleichen RZ ist generell nach aussen durchaus identisch.
Ich würde in Anbetracht dass die Probleme zu unterschiedlichen Zeiten auftreten nicht auf Hardware sondern Software oder Anbindung tippen, mit erhöhtem Verdacht auf die Anbindung (potentiell auch interne Anbindung/Switches). Von der Spezifikation klingt es als wäre es ein Server aus 2er Hand (Ryzen2 als Neubau wäre verwunderlich), der Vorbesitzer hätte Störungen der Hardware zumindest ja auch bemerken sollen.
 
Guten Tag,

wir sind immer noch beim gleichen Anbieter und wir sitzen immer noch im gleichem Rechenzentrum. Bei unserem alten Server lief auch alles auf dem gleichen Server also Webserver,Apache2 und Mailserver mit Teamspeak und anderen Gameservern. Da gab es auch keine Probleme. Der Cpu hat 16 Threads und ist kaum ausgelastet, und wir haben jetzt wieder alles installiert was auch auf dem letzten Server war. Traffic Limit haben wir nur in dem sinn das wir nicht mehr als 8TB pro Monat verbrauchen dürfen aber das erreichen wir nie im Leben. Wir haben ein 1Gbit/s Uplink und 64GB Ram deswegen vermute ich daran wird es nicht liegen. Ich bin leider inzwischen ganz schön plan los was ich machen soll. Ich hab bis jetzt noch keinen anderen Hoster gefunden der uns Desktop Prozessoren zu einem guten Preis liefert(Wir bevorzugen Desktop Prozessoren da wir bei Server CPU's es noch nie geschafft haben einen Minecraft Modpack Server ohne lägs zu betreiben). Der Server Hoster möchte auch nicht wirklich Helfen und sagt nur das ist was mit der Software und antwortet nicht mehr. Selbst wenn MariaDB, Apache2 und der Mailserver aus sind kommen die Probleme immer noch.

lm-sensors gibt mir leider nur das hier aus, und das sehe ich nicht als Hilfreich(Weil ich es auch nicht ganz verstehe)
sensors
acpitz-virtual-0
Adapter: Virtual device
temp1: +16.8°C (crit = +20.8°C)

nouveau-pci-0600
Adapter: PCI adapter
GPU core: +0.90 V (min = +0.85 V, max = +1.00 V)
temp1: +53.0°C (high = +95.0°C, hyst = +3.0°C)
(crit = +105.0°C, hyst = +5.0°C)
(emerg = +135.0°C, hyst = +5.0°C)
 
d4f said:
Das unter einem Standard Linuxscheduler? Kommt mir seltsam vor. State- und Frequenzanpassungen erfolgen eher im Bereich von Nano- und Millisekunden. Sogar AMD's "parken" von CPU-Kernen ist im ms-Bereich. 2-3 Sekunden ist was ich ungefähr brauchte um physisch den "Turbo"-Knopf eines 486er zu drücken :p
Click to expand...

Das kommt auf den Governor an.
Ich habe noch nicht das genaue Muster herausgefunden, aber einige Distributionen setzen (scheinbar CPU-Abhängig) als Standard-Governor "Powersave". Der verhält sich wie von mir beschrieben so, dass die CPU so 2-3 Sekunden lang ausgelastet sein muss, damit sie hochgetaktet wird.
Bei allen anderen Governors wird sofort hochgetaktet.
 
Hallo,

ich komme nochmal mit neuen Infos rein. Ich habe dem Ts3 Server jetzt die höchste Priorität geben, selbe Probleme immer noch. Dann auch wieder getest wie es aussieht wenn Apache2 etc aus sind immer noch das selbe Problem. Ich werde einfach nicht Herr der lage und der Hoster verweigert immer noch seine Hilfe.
 
Da bin ich noch einmal ich habe mal Htop durchgeschaut und habe was gefunden was ich davor noch auf keinem anderen Server gefunden habe den ich bis jetzt benutzt habe.

sleep.png

Von diesen hab ich noch ungefähr 10 andere gefunden. Sind die Schlimm oder so gewollt?
 
So habe die Sleeps kommen vom Mailserver also Mailcow(Hab den mal runtergefahren Ts3 Problem bleibt)
Wir haben jetzt was anderes gefunden das darauf schließen lässt das der Ethernet Controller wahrscheinlich kaputt ist. Bevor ich das an den Hoster weiterleite wolle ich mal hier fragen ob wir falsch liegen oder nicht.

806b7bcb-1d42-4aa8-8ef7-64a45e6f02a5.png


Man kann hier sehen das der Ethernet Controller sehr viele CPU interrupts macht. enp4so konnten wir ermitteln ist der Ethernet Treiber oder die Karte dazu selbst. Kann das schon das Problem bei anderen Diensten verursachen die wir haben?

Hier auch noch mal zu sehen das sehr viele Interrupts pro sekunde geschehen

e86f4165-bae9-4d60-ba61-b30de9746a0f.png
 
Es ist sehr normal dass Ethernet Controller viele Interrupts machen. Die billigen Controller (Realtek, ...) einen pro Paket und die CPU darf alles berechnen. Bei "besseren" Controller im Stil von Intel e1000 (auf Gaming-Boards, Workstations oft integriert und für knapp 10-15€ als PCIe-Steckkarte zu haben) kann nicht nur die Berechnung an den Controller offloaded werden (rx-offload, tx-offload) sondern auch Pakete gesammelt werden (Interrupt delay / Interrupt throttling) oder die RX-Interrupts (einkommender Verkehr) mittels mehrerer Queues auf mehrere Prozessoren aufgeteilt werden. Teure Controller können sogar in Kombination mit kompatibler Software die Interrupts übrigens ganz umgehen indem direkt in den jeweiligen Ram-Bereich geschrieben wird - kommt zB bei Cloudflare-Systemen in der DDoS-Bekämpfung zum Einsatz.

Interrupt-Provokation führt bei billigen Controller faktisch zu Denial-of-service. Ein Ist-Zustand der Zahlen bringt übrigens nichts, du braucht Interrupts pro Zeiteinheit als Messlatte. Bis dreistellig pro Sekunde schafft auch jeder nicht optimisierter Netzwerz-Stack mit untauglichem Chip problemlos wenn ich es richtig im Kopf habe. e1000 waren definitiv mindestens 4stellig.

Ein guter Ist-Zustand des Servers als Anzeige finde ich übrigens entweder "atop -af 1" oder nmon mit "n m c t" wobei atop den Vorteil hat sowohl rote Farbe zu verwenden als auch deutlich mehr Details an zu zeigen, insbesondere was Interrupts angeht. Bei Netzwerk-Problemen siehst du generell eher in "dmesg" Warnungen / Neu-Synchronisierungen sowie eine steigende Fehlerzahl in den Paketinformationen ("ifconfig" oder "nstat" oder "ip -s link")
 
Atop -af 1 gibt das hier aus

Screenshot

Ein bandbreiten test gibt das hier aus

iperf -c speedtest.serverius.net -P 10
------------------------------------------------------------
Client connecting to speedtest.serverius.net, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 5] local 45.155.173.136 port 46576 connected with 178.21.16.76 port 5001
[ 3] local 45.155.173.136 port 46568 connected with 178.21.16.76 port 5001
[ 9] local 45.155.173.136 port 46574 connected with 178.21.16.76 port 5001
[ 7] local 45.155.173.136 port 46580 connected with 178.21.16.76 port 5001
[ 12] local 45.155.173.136 port 46578 connected with 178.21.16.76 port 5001
[ 10] local 45.155.173.136 port 46572 connected with 178.21.16.76 port 5001
[ 6] local 45.155.173.136 port 46586 connected with 178.21.16.76 port 5001
[ 11] local 45.155.173.136 port 46584 connected with 178.21.16.76 port 5001
[ 8] local 45.155.173.136 port 46582 connected with 178.21.16.76 port 5001
[ 4] local 45.155.173.136 port 46570 connected with 178.21.16.76 port 5001
[ ID] Interval Transfer Bandwidth
[ 5] 0.0-10.2 sec 26.9 KBytes 21.5 Kbits/sec
[ 3] 0.0-10.2 sec 26.9 KBytes 21.5 Kbits/sec
[ 9] 0.0-10.2 sec 26.9 KBytes 21.5 Kbits/sec
[ 7] 0.0-10.2 sec 26.9 KBytes 21.5 Kbits/sec
[ 12] 0.0-10.2 sec 26.9 KBytes 21.5 Kbits/sec
[ 10] 0.0-10.2 sec 26.9 KBytes 21.5 Kbits/sec
[ 6] 0.0-10.2 sec 26.9 KBytes 21.5 Kbits/sec
[ 11] 0.0-10.2 sec 26.9 KBytes 21.5 Kbits/sec
[ 8] 0.0-10.2 sec 26.9 KBytes 21.5 Kbits/sec
[ 4] 0.0-10.2 sec 26.9 KBytes 21.5 Kbits/sec
[SUM] 0.0-10.2 sec 269 KBytes 215 Kbits/sec
 
Atop -af 1 gibt das hier aus
Click to expand...
Das Problem wird wohl sein dass der Server gerade sein verlängertes Wochenende geniesst. Das Ding langweilt sich vollständig.
Du hast zwar eine (verträgliche) IRQ-Last durch das Netzwerk, das macht aber 1% eines (logischen) Prozessors aus. Grob über den Daumen sind dabei die einzelnen Pakete knapp 80Byte gross, was einer ca üblichen Payload-Grösse für VoIP entsprechen würde.

Du könntest mit Netzwerk-Vermutung potentiell eine Spur haben, "tcpie" (Input error) und "tcpor" (Outgoing retransmit) sind nicht-null, hier bräuchte man mehr Daten (zB atop über ein 15min Fenster). Positive Werte sind aber sogar in Heimnetzen möglich und in Internet-Verbindungen ständiger Teil, retransmit sind fester Bestandteil des regulären TCP Congestion-Algorithmus. Ob dies aber, wenn es zutreffen sollte, die Netzwerkkarte ist, halte ich wenn es keine sonstigen Anomalien gibt für fraglich, eher eine temporär übersättigte (Aussen)anbindung oder ein Switch/Router mit Störung. Echte Störungen auf der Netzwerkkarte gab es zumindest in der Momentaufnahme nicht.
Du hast sehr viele Multicast-Pakete einkommend was eigentlich unschön ist, aber oft bei entsprechender "Gaming"-Nachbarschaft ohne entsprechende Konfiguration und mit geteiltem (VLAN) Netzwerk generell immer der Fall ist.

Allerdings sieht man gut dass die CPU hier auf Basis-Takt (2.2Ghz) heruntergetaktet hat, testweise würde ich sie auf Volldampf festsetzen, was hier 3.7Ghz wäre. Die Systemtemperatur (lm-sensors für CPU/Mainboard sowie smartmontools für Speicherauslesung) wäre übrigens noch immer interessant, sowohl vor als auch nach der Änderung ;)

iperf -c speedtest.serverius.net -P 10
Click to expand...
ich meinte eigentlich dass du einen iperf zwischen deinem Rechner und dem Server durchführen solltest :)
 
Danke für den ganzen Support. Wir haben es jetzt einfach gemacht. Wir haben den Hoster gewechselt. Wir haben genau zu dem server den wir jetzt haben(Als sonderposten gekauft) schlecht bewertungen gelesen mit dem genau gleichen Problem wo nichts passiert ist, Ist fast das gleiche ding wie bei uns. Trotzdem danke für die ganze hilfe
 
You must log in or register to reply here.
Back
Top