Quote from: mimugmail on August 31, 2018, 03:54:39 PM
Als Queuing Mechanismus FQ_CoDel
Und den stellt man wo ein?
Habe leider wirklich keine Ahnung vom Traffic Shaper :D
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Show posts MenuQuote from: mimugmail on August 31, 2018, 03:54:39 PM
Als Queuing Mechanismus FQ_CoDel
Quote from: Roger2k on August 31, 2018, 03:38:46 PM
Traffic Shaping einrichten, eine Pipe für den Upstream und eine Pipe für den Downstream. Dazu jeweils eine passende Regel:
Schnittstelle "WAN" -> Quelle "any" -> Ziel z.B "192.168.1.0" -> "Download Pipe"
Schnittstelle "WAN" -> Quelle z.B "192.168.1.0" -> Ziel "any" -> "Upload Pipe"
Damit sollte das Problem gelöst sein.
Quote from: Philipp on April 04, 2018, 11:23:18 PM
Zeitzonen-Unterschied beachtet?
Wenn die Firewall mit UTC läuft, ist dort jetzt nicht 23:21, sondern 21:21.
Und natürlich auch darauf achten, dass die Reihenfolge der Rules stimmt.
Eine "allow any to any" sollte, falls vorhanden, nach der Scheduler-Rule kommen, sonst wird diese niemals matchen. :)
Quote from: NicholasRush on March 28, 2018, 11:06:18 PM
Es geht eher weniger um deine Downstreambandbreite sondern mehr um deinen begrenzten Upstream. Wenn mehrere PCs gleichzeitig TCP Verbindungen offen halten. Und dort viel Traffic fließt, dauert es nicht lange und du bekommst Probleme mit Echtzeitanwendungen wie VOIP.
Die Pakte müssen von dir aus gesehen Priorisiert werden, weil du den begrenzten Upload hast.
Ob sie im Providernetz priorisiert werden oder nicht spielt keine Rolle für dich, weil du den kleinsten Flaschenhals in der Kette hast. Dein Provider wird ohnehin VOIP auf allen seinen Links und Switchen Priorisieren, sonst könnte er nämlich die Dienstgüte und Verfügbarkeit seines Telefondienstes nicht gewährleisten.
Quote from: Alphakilo on March 28, 2018, 10:30:37 PM
Mehr. Threads. :P
Du betreibst mehr oder weniger einen Server. Kein single-purpose device. Es passieren Dinge im Hintergrund. Und diese Dinge brauchen Zeit von der CPU.
Je mehr Dinge du parallel ausführen kannst, desto geringer die Wahrscheinlichkeit das etwas auf freie CPU-Zeit warten muss.
Quote from: Alphakilo on March 28, 2018, 10:30:37 PM
Bitflips im RAM passieren. Je länger die Maschine läuft desto Wahrscheinlicher ist es irgendwo im Speicher ein paar "falsche" Bits zu haben. Ohne ECC gibt es wenig Möglichkeiten zu prüfen, ob der ausgelesene Speicherbereich von Bitflips betroffen ist oder nicht.
Die Auswirkungen kommen immer drauf an wo der / die Bit(s) gekippt sind. Von Logikfehlern in Applikationen, Abstürzen (Segfault, "Oops"), Kernelpaniks ("BSOD") über Dateien die korrupt auf den Blockspeicher geschrieben werden ist eigentlich alles drin.
Das ist mit einer der Gründe warum bei Consumer-Hardware so vieles durch einen Neustart gelöst werden kann.
Ich persönlich würd's für daheim drauf ankommen lassen und mehr Speicher statt ECC nehmen. Aber das ist Geschmackssache.
Quote from: Alphakilo on March 28, 2018, 10:30:37 PM
Da schließe ich mich fabian an. SD-Karten und Sticks sind nicht für den Einsatzzweck geeignet. Oder zumindest nicht konzipiert.
Außerdem sind USB-Controller nicht für ihre Stabilität bekannt.
Und nimm lieber die 120GB, für 'nen Zehner mehr bekommst du fast das vierfache der Kapazität, wenn die Geizhals-Links stimmen ;)