hans12459 hat geschrieben:Hier wird schon über einen instabilen DSL-3000 connect gejubelt ("Gratulation") - ich glaub ich bin im Heimwerkerforum.
Hallo Hans,
ich hätte da noch einen Ironie-Smiley dazusetzen sollen, ich weiß ...
Ich finde auch, daß ein Premium-Hersteller, der zu großen Teilen den deutschsprachigen Raum bedient (korrekt ?) ein Modem ausliefern sollte, das es mit den Modems der hiesigen Provider aufnehmen kann.
Leider hat LANCOM da mit den Conexant-Chips offensichtlich keine so gute Wahl getroffen.
Aber einen kleinen Fortschritt kann ich mit diesem Linecode vermelden, und das wollte ich nicht versäumen.
ich will auch nicht klagen hab mit dme neuen code nur noch alle paar stunden einen syncverlust ... es hab aber auch versionen wo ich garkeine probleme hatte.
Es gruesst Lars
--
Zwischen einen NAT-Router hinter einen Nat-Router und vor einen NAT-Router passt immer noch ein NAT-Router
Linecode Version 2.73/a27.4.11
Rauschabstand Lokal (dB) 23.5
Rauschabstand Remote (dB) 19
Dämpfung Lokal (dB) 49.0
Dämpfung Remote (dB) 31.5
Linecode Version 6.20/e74.02.15
Rauschabstand Lokal (dB) 20.5
Rauschabstand Remote (dB) 9.5
Dämpfung Lokal (dB) 49.5
Dämpfung Remote (dB) 31.5
Ich würde mal behaupten, die 2.73er Version ist hier besser geeignet. Denn wenn ich das korrekt verstanden habe ist bei Dämpfung ein kleinerer Wert besser und beim Rauschabstand ein größerer...
nach dem nun die LCOS 6.14/6.15 erschienen ist, habe ich erstmal wieder die 6.14 mit dem neuen Linecode installiert.
Mit dem Linecode 2.73 hatte ich verdammt oft einen Syncverlust, nun mit der 6.20 scheint es doch besser zu funktionieren, ob wohl der Rauschabstand Remote 10 dB weniger ist.
Am 01.08. um 22:06 habe ich die neue FW installiert und seit dem ist der Link stabil. Um 5:00 Uhr mache ich einen Reset des Routers.
Daher noch mal die Frage, was hat der Rauschabstand Remote zu bedeuten, warum ist da je nach Linecode so ein Unterschied? Ist da ein Bug in der Software und das wird in einer Version nur falsch angezeigt?
Raudi hat geschrieben:Daher noch mal die Frage, was hat der Rauschabstand Remote zu bedeuten, warum ist da je nach Linecode so ein Unterschied? Ist da ein Bug in der Software und das wird in einer Version nur falsch angezeigt?
Die Werte der neuen Firmware entsprechen dem, was auch der DSLAM ausgibt. Die (höheren) Werte der alten Firmware sind falsch.
Raudi hat geschrieben:... nun mit der 6.20 scheint es doch besser zu funktionieren ...
Hallo zusammen,
kann ich leider nicht bestätigen. Ich hab's heute mal wieder mit 6.14 versucht (obwohl der Linecode ja der gleiche geblieben ist). Der DSLAM ist heute wohl wieder schlecht auf LANCOMs zu sprechen: Endlose Abfolge von Handshake und Training.
Mein TELEDAT-431 hat's danach auch nicht beim ersten Anlauf geschafft --- beim zweiten dann aber wohl, und der Link ist stabil, also kein Ansatzpunkt für Störmeldungen bei T-COM.
P660M> wan adsl linedata near
relative capacity occupation: 0%
noise margin downstream: 21 db
output power upstream: 11 db
attenuation downstream: 30 db
P660M> wan adsl linedata far
relative capacity occupation: 0%
noise margin upstream: 18 db
output power downstream: 15 db
attenuation upstream: 19 db
P660M>
mit dem internen Modem des 821 habe ich bei mir auch keinen Link hinbekommen. Bei dem konnte ich auch nur das Teledat DSL Modem nutzen. Jetzt mit dem 1722 habe ich das interne Modem mal wieder getestet und es funktioniert wunderbar...
Das Modem des 821/1821 scheint somit nicht so gut zu sein, wie das eines 1722....
Raudi hat geschrieben:Hi,
Das Modem des 821/1821 scheint somit nicht so gut zu sein, wie das eines 1722....
Du täuschst Dich gewaltig. Zumindest das LC1821 Hardwarerevision E setzt den gleichen Modemchipsatz ein wie Dein LC1722. Der Modemteil ist absolut identisch.
Naja, ich habe meinen 821 im April 2003 gekauft und nun 3 Jahre später durch einen 1722 ersetzt.... Die Hardwareversion dürfte schon etwas älter gewesen sein. Und AndreasMarx hat die Version C...
ich habe --- wie schon öfter mal hier berichtet --- einen etwas problematischen ADSL1-Zugang der T-COM mit 3MBit-Downstream und 448KBit upstream zu einem Texas-Instruments DSLAM. Mein TELEDAT-431 kommt mit der Leitung allerdings recht gut zurecht (wochenlange Connects, nur unterbrochen durch Software-Hänger, die nur mit einem Reset zu beheben sind).
Mein 1821/C (6.22.0007 // 6.20/e74.02.15) kommt leider nicht so gut mit dem Anschluß klar.
Ich weiß, daß der Chip (CX85300?) von Conexant kommt und daß LC beim Linecode auf den Hersteller angewiesen ist.
Da das Ärgernis mit dem ADSL-Modem nun schon recht lange besteht wollte ich mal wieder nachfragen, wo hier der Hund begraben liegt. Ist eigentlich klar, wo der Fehler liegt und liegen die zögerlichen Verbesserungen nur an der niedrigen Prio, die Conexant für Annex B ansetzt? Oder ist gar nicht so recht klar, woran es liegt?
Die Trace-Möglichkeiten von LCOS sind vergleichweise gut (mit anderen Herstellern verglichen), aber für eine Eigendiagnose natürlich trotzdem nicht ausreichend, zumal wenn man wie ich eigentlich keine fundierte Ahnung von der Materie hat.
Hier meine Beobachtungen aus dem heutigen (regelmäßig durchgeführten) Retest:
Der 1821 pendelt scheinbar endlos zwischen Handshake und Training, manchmal unterbrochen durch eine kurze Idle-Phase. Zuweilen kommt dann doch ein Showtime zustande (einmal sogar 20 Minuten lang) der mit Link-Failure abbricht, nachdem Local/LCD-I rapide bis 300 hochzählt. Umittelbar vor dem Abbruch sind alle LCD/NCD/LOS/SEF-Werte noch null, dann geht einzig Local/LCD-I innerhalb weniger Sekunden auf 298 und dann ist der Link-Failure da.
Auffällig ist, daß LC und TELEDAT vergleichbare Werte für Dämpfung und SNR liefern, die SNR/remote aber beim LC regelmäßig 9db unter dem TELEDAT-Wert liegt (sowohl mit als auch ohne gleichzeitige ISDN-Aktivität). Der Wert liegt dennoch bei 9-10db, sollte also sich er sein.
Das läßt m.E. auf Near-End-Interference schließen. Leider kann ich nicht herausfinden, welche Träger das TELEDAT aushandelt (weiß jemand, wo man das rausfindet?). Evtl. ist es ja in der Lage einen US-Träger auszublenden der gestört ist. Oder der LC ist zurückhaltender beim Aufdrehen der Upstream-AGC...
Und noch eine Auffälligkeit: Mit /set/inter/adsl/adsl=Auto komme ich scheinbar häufiger zu einem Connect als mit /set/inter/adsl/adsl=G.Dmt, obwohl in beiden Fällen bei Erfolg der G.Dmt-Mode zu Anwendung kommt (die Testreihe war allerdings nicht lange genug für eine fundierte Aussage). Augenfälliger Unterschied: Bei Einschränkung auf G.Dmt ist der Handshake/Trainging-Zyklus ca. 10sec, bei Auto geht das langsamer. Ich habe so das Gefühl, daß der TI-DSLAM das gar nicht mag, wenn man alle 10 Sekunden ein Training beginnt.
Kommen eigentlich bei wiederholten Handshakes immer die gleichen Einstellung zum Zuge oder merkt sich der LC Ergebnisse des/der vorausgegangenen Trainings?
Beim TELEDAT würde mich interessieren, warum eigentlich fast immer spätestens das zweite Training erfolgreich ist. Automatische Testreihen sind leider wegen der beschränkten Trace-Möglichkeiten unmöglich. Interessant wäre eine Statistik, wie oft ein Connect nach einem Reset beim ersten, beim zweiten, beim dritten Training zustande kommt. Sich ändernde Leitungsbedingungen könnte man durch eine längere Testreihe (etwa jede Nacht 4 Stunden zur selben Zeit) herausmitteln. Aus der Verteilung könnte man schließen, ob das TELEDAT beim Training mit der gleichen Wahrscheinlichkeit versagt wie beim ersten und damit, ob Status aus dem ersten Traininig in das zweite eingeht.
Gefühlsmäßig würde ich sagen, daß das der Fall sein muß (erstes Training geschätzte 60% Erfolg, zweites >95%), aber man kann sich da ja leicht täuschen oder selbst belügen.
nach der Technik nochmal was produktpolitisches: Mir ist schon klar, warum in den LCs keine TI AR7 oder ein Broadcom BCM63xx steckt --- die Dinger bringen gleich einen CPU-Kern nebst weiteren integrierten Komponenten mit und sind damit schlicht teurer.
Wer sich als Hersteller auf diese Dinger einläßt produziert früher oder später nur noch customizte Varianten der jeweiligen Referenzdesigns und das ist sicher das letzte, was wir von LANCOM sehen wollen.
Andererseits betreibt eine nicht zu vernachlässigende Zahl von LC-Nutzern ein externes Modem und da steckt dann ja doch wieder so ein Ding samt CPU-Kern drin. Warum also nicht gleich einbauen, die Nutzer sparen dann wenigstens eine Box, ein Netzteil und können das Ding mit LC-Software managen. Die CPU kann dann ja nebenbei Sudokus lösen
Ich hab da nicht wirklich einen Überblick, aber daß die Hersteller künftig niedrig integrierte ADSL-Tranceiver auf den Markt werfen halte ich für wenig wahrscheinlich. Die hoch integrierten sichern ihnen schließlich einen höheren Anteil an der Produktionskette und damit mehr Umsatz.
Den gleichen Effekt kann man z.B. bei GPS-Chipsätzen beobachten --- der Zarlink GP2021 wird wohl der letzte simple Korrelator bleiben, alles was neuer ist bringt CPU samt Firmware gleich mit.
Schlechte Karten also für Hersteller individueller Lösungen?
Vielleicht sollte LANCOM zusammen mit dem Volumenproduzenten devolo mal ein eigenes Design angehen. Das wäre auch im Hinblick auf den Technologiestandort Deutschland wünschenswert nachdem die Kompetenz im Bereich GSM ja gerade verschenkt wird (Siemens/BenQ).
machtst Du Dir nur auch eine ungefähre Vorstellung, was für einen Aufwand die Umstellung der
halben Produktpalette (nämlich alle Geräte mit ADSL-Modem) für LANCOM Systems bedeuten
würde? Dan kann man Conexant noch einige Versuche mit der Firmware geben. Es
ist ja nicht so, daß daran nicht bei Conexant gearbeitet werden würde.
Andererseits betreibt eine nicht zu vernachlässigende Zahl von LC-Nutzern ein externes Modem und da steckt dann ja doch wieder so ein Ding samt CPU-Kern drin. Warum also nicht gleich einbauen, die Nutzer sparen dann wenigstens eine Box, ein Netzteil und können das Ding mit LC-Software managen. Die CPU kann dann ja nebenbei Sudokus lösen
- Platzprobleme, Leistungsaufnahme...
Schlechte Karten also für Hersteller individueller Lösungen?
Möglicherweise. Ist in anderen Bereichen aber auch nicht anders.
Vielleicht sollte LANCOM zusammen mit dem Volumenproduzenten devolo mal ein eigenes Design angehen. Das wäre auch im Hinblick auf den Technologiestandort Deutschland wünschenswert nachdem die Kompetenz im Bereich GSM ja gerade verschenkt wird (Siemens/BenQ).
Devolo macht aus Prinzip keine eigenen Designs, die definieren höchstens, wie etwas
aussehen sollte, und lassen es sich dann von einem Taiwanesen machen.
Und einen eigenen Chipsatz zu machen - das hat man mal bei ELSA versucht (zu Zeiten,
als da 500 Leute gearbeitet haben...), und das ist fürchterlich in die Hose gegangen.
Von den Stückzahlen sind sowohl Devolo als auch LANCOM um Größenordnungen
entfernt.
Ziemlich beunruhigend, daß meine Leitung vielleicht nur mithilfe adaptiver Entzerrung funktioniert, sozusagen auf der letzten Rille. Und für sowas zahlt man dann €25/Monat. Grummel
