DSL verliert die Synchronisierung mehrmals pro Woche für längere Zeit
1021
Scott Simpson
Ich habe einen 12/2-DSL-Dienst von Frontier, der die Synchronisation im Durchschnitt 3-4 Mal pro Woche für 1-3 Stunden verliert. Ich habe mit den lokalen Technikern zusammengearbeitet, die sagen, dass sie alles überprüft haben und dass sie "alles getan haben, was sie wissen". Sie haben einmal das Gateway ersetzt. Ich habe den Draht von der NID zur inneren Buchse ersetzt. Momentan arbeite ich mit Level-2-Support. Sie haben den Verlust des Synchronisierungsproblems bestätigt - aber der einzige Test, der fehlschlägt, ist der Synchronisierungstest (und er kann mein Gateway nicht mehr per Ping ansprechen). Bei der Unterstützung der Stufe 2 wird empfohlen, das Modem zu ersetzen (dies ist das dritte), und die Innenverkabelung zu testen. Die Unterstützung der Stufe 2 deutet auch darauf hin, dass das Signal-Rausch-Verhältnis möglicherweise zu hoch ist, um eine 12/2 zu drücken (was an diesem Punkt wirklich 3 ist) und dass ich möglicherweise auf 6/1 umschalten muss.
Einzelheiten
Das Ersetzen des Kabels an der NID schien meine Gesamtgeschwindigkeit etwas zu verbessern. Im Allgemeinen bekomme ich fast 12 und 3 einen.
Support der Ebene 2 zeigte 1 Synchronisationsproblem um 1 Uhr morgens, als niemand die Verbindung aktiv verwendete. Mein Computer wurde jedoch möglicherweise aktualisiert.
Im Allgemeinen verliert das Gateway die Synchronisierung und versucht dann fortlaufend, 2-4 Stunden auf einer oder beiden Seiten erneut zu synchronisieren.
Vor kurzem wurde das Modem von selbst neu gestartet, als ich ein Video von meinem Computer zu AppleTV strahlte und jemand anderes ein Video auf Anforderung strahlte. Eine Seite hat die Synchronisierung für mehrere Stunden verloren. Wir konnten diesen Absturz nicht replizieren
Vor kurzem verlor es die Synchronisierung für 3 Stunden, als ich ungefähr 15 Registerkarten für eindeutige Webseiten öffnete.
Der Großteil der Synchronisierungsprobleme findet später am Nachmittag statt - zwischen 16 und 18 Uhr
Ich verwende das Actiontec F2250 Gateway.
Bereitgestellte Verbindungsgeschwindigkeit: 13923/2282 kb.
Ein Neustart des Gateways hat keine Auswirkung auf die Behebung der Synchronisierungsprobleme.
Es scheint ein Problem mit Pufferblasen zu geben
2,8% Paketverlust beim Ping beim Herunterladen von Software-Updates oder Uploads
Hohe Latenz beim Download oder Upload
7400 Fuß zu DSLAM
Die Seite mit besserem SNR wird sinken, und die Seite mit schlechterem SRN bleibt oben. (Siehe Screenshot)
UPDATE 12-14-2016
Neuer Router am 14. Dezember - Nach der Installation eines neuen Routers gab es weniger Bitfehler in Zeile 1 und ein verbessertes SNR in Zeile 2.
2 Stunden nach der Installation des neuen Routers wurden beide Leitungen "still" heruntergefahren und sofort erneut synchronisiert. Für Zeile 1: Nach 14 Minuten Betriebszeit treten 239.738 Bitfehler, 2984 HEC-Fehler, 8121 Super-Frame-Fehler auf (SNR-Marge beträgt 11,8). . Zeile 2, die seit 10 Minuten aktiv ist, hat 1225 Bit-Fehler, 21 HEC-Fehler, 4097 Super-Framers-Fehler (SNR-Margin ist 10,3).
Fehler: xt_TCPMSS: falsche Länge (589 Bytes), zwei Minuten vor dem letzten Synchronisierungsproblem
UPDATE 12-17-2016
Bei dem 12-14-Tech-Besuch fragte ich den Techniker, ob er die DSLAM-Karte für Leitung 1 austauschen könnte und ob eine andere Leitung verfügbar wäre. (Es gab ein offensichtliches Problem mit Zeile 1.
Am 12-15 verlor der Router die Synchronisierung gegen 19 Uhr.
Nach diesem Synchronisationsverlust hat sich für das Positive etwas geändert - das Gateway ist nun seit 1 Tag und 15 Stunden in Betrieb. Ich hoffe, dass es gelöst wurde.
UPDATE 18.12.2016
Die Synchronisation heute für 1,5 Stunden verloren.
Hohe Fehlersekunden (bis zu 521) um dieses Problem in BEIDEN Zeilen
Screenshot unten
Unterbrechungen, die ich seit Beginn des Trackings bemerkt habe
Sept 26, 2016 — 2:55pm — Confirmed modem offline. Rebooted modem via admin. Back up at 3:06 with 5.44 down and .52 up. 1 line is down. Intermittent lines at 3:52. Both lines back before 4:19. Running at 7.5 down, 2.0 up Sept 28 — 9:20 AM — Low bandwidth. 3.5 Mbps down. Resolved by 9:30 Sept 30 — 4:35PM: — Low bandwidth 1.5 Mbps down, .81 up. One line down. Back up by 5:00pm October 1 6:00pm Low bandwidth. 1 line down. 2.55 down, 1.07 up October 4, 5:55 pm — Both lines down. 6:00pm, 1 line down. October 11, noon — very low bandwidth. — back up before 12:30 October 11, 3:30pm down. October 11, 5:52pm down — back by 6:45 October 12, 4:54pm — 1 side down. 2.96Mbps/.89Mbps October 13, 5:20pm — very low bandwidth. Unusable. One/both sides down. 1.64Mbps up, 1.76down October 18, 5:55pm — very low bandwidth. Unusable. .77 Mbps down, 2.88up. Unable to login to modem October 19, 6:30 — low bandwidth, 4.33 down, .72 up. High latency -- 408ms, high Jitter 836ms October 23, 6:17 – low bandwidth, 3.37 down, 1.22 up. 1 side down October 24, 3:37 – no bandwidth, one/both sides down. October 25, 5:25 – no bandwidth down - up works fine, one/both sides down, able to ping. Back by 6:30 Nov 1, 8:15 — no bandwidth. Both sides down. Nov 2, 3:50 — low bandwidth, 3.57 down, 1.31 up One side down. Nov 4 — Frontier tech replaced wall jack Nov 7, 10:00 — one side down, both sides down. No bandwidth down. No bandwidth up. Cannot connect to modem. 1 side still down at 5:30p. Nov 11, 1:40 — both sides down. No bandwidth — back at 1:43 Nov 11, 5:40 — both sides down. No bandwidth — back by 6:20 Nov 15, 4:30 — both sides down. Nov 18 3:50 — both sides down, one side back by 4:00 Nov 23 10:00p — very low bandwidth Nov 24, 8:56a — both sides down. Nov 24, 4:50p — both sides down. Nov 25, Noon — 1 side down. Low bandwidth, then both sides down. Nov 27, 2:40 both sides down Dec 2, 5:55 One side down Dec 4 — Replaced wire from NID to gateway (1 wire now). Dec 6 6:30 - Router went offline, rebooted automatically (Crashed, this has happened before, but rarely). Dec 6 6:55 - One side down Dec 8 — two short drops possible. (Lost connectivity with GotoMeeting) Dec 9 — 2:40 — Down — appeared to happen by sending multiple HTTP requests. Still down at 5:45. Keeps trying to sync.
Ich habe schlechte Nachrichten für dich. Dies ist nur etwas, das Ihr ISP identifizieren und beheben kann.
Ramhound vor 7 Jahren
2
* "die lokalen Techniker, die sagen, sie hätten alles überprüft" * - Holen Sie sich die Details. Haben sie die Leitungen "konditioniert", dh einen (TDR) Scan durchgeführt, um überbrückte Abgriffe (und Lastspulen) zu lokalisieren und zu entfernen? Lesen Sie http://www.exfo.com/corporate/blog/2010/bridged-tap-detection-made-simple
sawdust vor 7 Jahren
2
Dies ist kein PC- oder interner Netzwerkfehler, überhaupt nicht, es handelt sich um reine Außen- oder DSL-Geräte ... Es gibt ein Leitungsproblem außerhalb, die L1 vs. L2-Side-by-Side beweist es, sie sollten aber fast identisch sein L2 hat einen viel höheren SNR, was wahrscheinlich auf einen Abgriff des Paares im Feld hinweist. Und @sawdust ist absolut korrekt. Ein einfacher Lauf mit einer TDR-SLA in jeder Zeile sollte etwas anzeigen. Wenn nicht, sollten sie bei der MDF beginnen und die Paare vom CO zum Prämisse eines AP / CP, Pedals oder Terminals verfolgen eine zeit und vergewissern sie sich, dass die linie ordnungsgemäß gespleißt und sauber ist. Wenn ich ein $ für jedes Mal hätte ...
acejavelin vor 7 Jahren
3
Beeindruckende Details. (Vor allem die Protokolle. Zumindest beeindrucken sie durch die Standards typischer Fragen.) Gute Arbeit.
TOOGAM vor 7 Jahren
1
Ich bin zu der Erkenntnis gelangt, dass die hauptsächliche Störquelle vom Amateurfunk eines Nachbarn stammt. Und - es stellte sich heraus, dass sie den Abfall von der NID auf das Podest nicht als den alten "C-Stil" identifiziert hatten, der Interferenzen nicht abschirmt.
Scott Simpson vor 7 Jahren
0
1 Antwort auf die Frage
1
Dave
Scott - ich bin Mitbegründer von Firebind . Unsere neue Cloud-Lösung konzentriert sich auf das kontinuierliche Testen von Last-Mile-ISP-Schaltungen. Wir führen alle 5 Minuten eine Serie von 11 Tests durch und sammeln 3.168 Datenpunkte pro Tag. Ich stimme zu, dass dies wie ein Problem klingt, das nur der ISP beheben kann. Wenn Sie jedoch mehr Daten sammeln und die Muster über einige Tage oder sogar einige Wochen sehen möchten, nutzen Sie unsere kostenlose Testversion. Unser Flaggschiff-Test simuliert alle fünf Minuten einen G.711-VoIP-Anruf für 25 Sekunden in jede Richtung und sendet insgesamt 360.000 Pakete pro Tag in den Intervallen. Da der Test mit UDP-Payloads (im Gegensatz zu ICMP-Payloads) 50 Pakete pro Sekunde ist, bietet er eine wesentlich zuverlässigere Ansicht des tatsächlichen Datenverlusts der Benutzer.
Wenn Sie einige Tage alle 5 Minuten testen, werden Sie möglicherweise bestimmte Tageszeitmuster erkennen, die möglicherweise mit einem Ereignis im ISP-Netzwerk verknüpft sind.
Der Link unten zeigt einen Screenshot der Ergebnisse unseres simulierten G.711-VoIP-Anrufs. Der linke Teil des Charts vor dem 4. Dezember war eine Wave Broadband-Verbindung in Kalifornien. Die blauen Spitzen zeigen einen Downloadverlust aufgrund des "Netflix-Effekts".
Am 4. Dezember wechselte die Seite dann zu Comcast und das Verlustproblem ist fast vollständig verschwunden.