CRC Fehler auf LAN Schnittstelle

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Hallo zusammen,

      ich wollte mich auch nochmal zu Wort melden.
      Wie auch in anderen Threads im Internet zu lesen ist, hat die Solo2 ein Problem mit vielen Switchen.
      Man erkennt es auch als Laie daran, dass die grüne LED vom Netzwerkport nicht durchgehend leuchtet, sondern im Zweisekunden-Takt blinkt.

      Meine Tests haben gezeigt, dass ich nur gedroppte Pakete und schlechte Übertragungsgeschwindigkeiten habe, wenn die LED blinkt anstatt durchgehend zu leuchten.

      Folgende Netzwerkgeräte konnte ich mittlerweile testen. Die Verbindung kommt immer über ein Cat.6 Kabel zustande.

      • TP-LINK TL-SG1008D Ver:5.1, 1000 MBit: blinkt im Zweisekunden-Takt
      • TP-LINK TL-WR1043ND Ver:1.4, 1000 MBit: leuchtet durchgehend (Router)
      • D-Link DGS-108/E HW Ver.: B1, 1000 MBit: blinkt im Zweisekunden-Takt
      • TP-LINK TL-SG1008D Ver:4.20, 1000 MBit: leuchtet durchgehend
      • AVM FRITZ!Box WLAN 3370, 1000 MBit: leuchtet durchgehend (Router)
      • Netgear ProSafe GS108 v3, 1000MBit: blinkt im Zweisekunden-Takt
      • Netgear ProSafe GS108E v2, 1000MBit: blinkt im Zweisekunden-Takt
      Vielleicht könnt ihr die Liste noch ergänzen. Somit hat man bei Anschaffung eines Switches/Routers eine Auswahl, bei der es keine Probleme gibt.

      Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von Sizco ()

    • Hallo zusammen,

      ich krame diesen Thread nochmal aus.
      Also Eine lange Zeit hatte ich Ruhe in meiner Konstellation - Nutze einen Netgear Prosafe - wollte dann komforthalber auf den Netgear prosafe plus (managed) umsteigen und seitdem hatte ich massive Problee mit der Solo2!
      Massenhaft CRC Fehle ganz gleich bei welcher Einstellung des Switch waren da - Solo2 hatte Ruckler/Klötzchenbildung bei den Aufnahmen aufs NAs und gleichzeitiger ansehen einer Sendung usw.
      Daraufhin dachte ich mir : Solo2 und der Switch = Nogo - also wieder zurück zu meinem "normalen" Prosafe - und : Weiterhin die Probleme ! Seltsam

      alles ausprobiert hin und her Kabel gewechselt, Ports getauscht wirlich ALLES - keine Lösung

      Dann mal kurzerhand ein altes 5e Kabel aus dem Keller gekramt angeschlossen an den Switch und siehe da alles läuft soweit...
      Ich habe Keine Ahnung woran es liegt...bei ifcomfig sehe ich weder droppes noch errors

      Werde jetzt nocmalk mein reguläres Kabel anschließen und den gleichen Test mit den gleichen Aufnahmen starten - danach gibts noch einen test mit dem Prosafe Plus...
      ich werde berichten - aber die CRC´s etc. sind schon ein seltsames Thema - evtl. hat die Solo2 ja eher/auch Probleme mit en angeschlossenen Kabeln ?

      Bin etwas ratlos - noch - mal sehen...

    • Hi,

      geblubber schrieb:

      Was is'n ne UDF Verbindung?

      ich hatte das Gefühl das es sich blöd anhört bekam aber nicht die 3 richtigen Buchstaben zusammen. Ich meinte natürlich UDP.. Bei TCP müssen gesendete Pakete bestätigt werden und wenn nach einer gewissen Zeit nichts angekommen ist wird es erneut gesendet und vermutlich dropped geht hoch. Bei UDP schert sich niemand drum ob die Pakete ankommen, d.h. nach mir die Sintflut.

      ciao

    • Ich konnte mir schon denken, was Du meinst. Bei TCP ist es ein bischen anderes. Der Empfänger (Client) der Daten bestätigt jedes Packet, welches er bekommen hat, damit der Sender (Server) den Speicherbereich auf dem System wieder freigeben kann. Dieses wird vom Client sequentiell abgearbeitet. Wenn zu dem Empfänger also 5 Datenpackete gesendet werden, davon aber nur 4 ankommen, bestätigt dieser nur die Kette bis zum fehlenden Packet. Wenn also das 3. fehlt, bestätigt der Empfänger nur das 1te und 2te, das 4te und 5te nicht. Dies erfolgt erst, nachdem ein erfolgreiches Retransmit des 3ten Packetes geglückt ist. Natürlich kommt noch der Overhead für den Verbindungsaufbau (SYN-ACK-Handshake) und Abbau (FIN-ACK) dazu.

      Packet drops ist nicht direkt ein Timeout, sondern kommt vor, wenn das System den IP Cache aufräumen muss, um neue Packages senden zu können.Der Grund dafür kann vielfältig sein. Verlorengegangene ACK Packete, Laufzeitprobleme im LAN, Defekte am Kabel usw. usf.

    • geblubber schrieb:

      Wenn also das 3. fehlt, bestätigt der Empfänger nur das 1te und 2te, das 4te und 5te nicht.




      So ist das eben nicht !!
      Der Vorteil des IP Protokolls ist, dass die einzelnen Pakete auch über unterschiedliche Wege ans Ziel kommen können (unter Wege meine ich Routen - im I-net dann die einzelnen Router).
      D.h. es kann sein dass folgende Reihenfolge passiert:
      Paket 5
      Paket 1
      Paket 3
      usw.

      Der Empfänger puffert die Pakete, sortiert diese und fordert nicht zugestellte oder "defekte" Pakete nochmals an.
      Das benötigt zwar Zeit, aber funktioniert.

      Umsonst sagt man nicht dass das Internet noch laufen wird, auch wenn keine Menschen mehr da sind ;_(

      Grüße
      Chris

    • Ja, er puffert sie, das stimmt. Aber die Bestätigung wird erst gesendet, wenn er das fehlende Packet hat.Und nichts anderes habe ich geschrieben. Dass die Packete über unterschiedliche Routen (und damit auch zeitlich durcheinandergewürfelt) ankommen, hat nichts mit dem Verfahren der Bestätigung zu tun.

    • Also es ist und bleibt ein Problem - denke User die Ihre Aufnahmen auf die interne HDD packen werden das nicht bemerken....aber da ich alles auf NAS aufnehme, sehe ich die Problematik --> immer mal kleine Ruckler - vor allem wenn die Aufnahme die läuft gleichzeitig gestreamt wird.
      Bei Aufnahmen die ich auf die inter hdd laufen lasse gibt es das Problem nicht.

      Nur zur Info : LAN ist optimal eingestellt - andere Geräte (Laptop/Uno etc. p.p.) erzeugen keine CRC fehler....
      Speed im Lan vom Gigabit Laptop zum NAS rd. 90 Mb/s
      also daran kanns nicht liegen ;)

      Werde jetzt mal zum Test die Solo2 auf 100mbit laufen lassen - sollte ja
      auch locker reichen um HD aufzunehmen und gleichzeitig zu streamen....
      Ich berichte...

    • Per NFS Auto.network....die wohl beste Lösung...alles perfekt eingerichtet und kann mich nur wiederholen :
      Solo2 Bei Aufnahmen auf NAS und gleichzeitig ansehen der Aufnahme (Nicht TS) --> Fehler...

      Mache ich das Ganze auf eine Interne HDD --> kein Problem...

      Bin es mittlerweile leid und verliere auch ein wenig das Vertrauen in das Produkt !
      Selbst meine Uno mit 100Mbit leistet da bessere Ergebnisse...

      Habe nun ALLES durchgespielt : Die Fehler entstehen und sind sogar reproduzierbar...das ist sowas von nervig !

      doe0201 schrieb:

      Wie hast du dein NAS denn eingebunden? Bei mir gibts per NFS keinerlei Probleme.

    • Wird an dem Problem mit der Solo2 eigentlich noch gearbeitet? Mir ist letztens ein älterer GB Switch ausgefallen an dem es alles sehr gut lief. Mit dem "aktuellen/neueren" den ich damals bei der Solo2 Beschafung ebenfalls hatte (das Problem bestand dort damals schon und ist ja nicht der einzige Switch) habe ich nach wie vor CRC Fehler. Ich muss die Solo2 auf 100mbit drosseln damit ruckelfreies Streaming funktioniert... Arbeitet da jemand dran? Ist die Solo2 nicht IEEE konform oder woran liegt's?

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von blueray ()

    • Mit Erschrecken musste ich feststellen, dass der Thread schon 3 Jahre alt ist.
      Ich krame ihn wieder her, da das Problem in dieser Zeit nicht gelöst wurde.

      Ich nutze momentan wie damals auch den Switch: TP-LINK TL-SG1008D Ver:4.20 (weißes Modell)
      Damit gibt es keine Probleme.

      Da wir gerade ein Haus bauen, habe ich mir für die Netzwerkverkabelung einen 24 Port Switch angeschafft: Netgear JGS524Ev2
      Und was soll ich sagen? VU+ Solo2 dran gehängt (Verbindung über CAT.6 Kabel) und wieder das alte Problem: CRC Fehler.
      Über ein CAT.5 UDP Kabel, welches nicht voll belegt ist, gibt es keine Probleme. Der Switch schaltet auf 100MBit.

      Mich wundert, dass es nur wenige Menschen gibt, die dieses Problem haben bzw. die es bemerken.
      Hat denn jemand zufällig in den letzten Jahren den Grund für das Problem ermitteln können?

      Gruß,
      Sizco

    • Wie immer, es kommt darauf an ...
      Gerade durch die Spezifikation von Cat.6 und die draus resultierende Eigenschaft des Kabels muss dies nicht pauschal besser sein als das augenscheinlich schlechtere Cat.5. Besonders wenn die Qualität des Kabels (z.B. wegen eines schlechten Leiters (CCA)) mangelhaft ist, kann es bei längeren Verbindungen zu massiven Problem kommen.

      In einem Neubau Cat.6 Kabel zu verlegen halte ich für eine Fehlentscheidung.

      Wie lang ist das Kabel zum Receiver?
      Wie ist das Cat.6 Kabel aufgebaut? Welcher Leiter?
      Wie sieht die Verbindung aus mit einem gleichlangen, testweise verlegten Cat.5a Kabel?