Linecode 6.20/e74.02.15

[Raudi]

(sowohl mit als auch ohne gleichzeitige ISDN-Aktivität)

Spielt die ISDN Aktivität da wirklich eine Rolle? Aber wo Du es schreibst, ich habe schon mal beobachtet, das genau in dem Moment wo meine Frau begonnen hat zu telefonieren, der ADSL Link verloren ging.

Beim TELEDAT würde mich interessieren, warum eigentlich fast immer spätestens das zweite Training erfolgreich ist.

Das scheint normal, ich habe nun mein TELEDAT 431 auch wieder angeschlossen, nach dem der 3. Download-Versuch einer 551 MB Datei wieder gescheitert ist, weil der DSL Link verloren ging.

Nach dem Einschalten blinkt erst die DSL LED grün, dann blitzt die ein mal kurz rot auf und dann nach einer weiteren günen Blink-Phase leuchtet sie dann permanent grün.

Mal sehen ob ich die 551 MB nun downgeloadet bekomme, bei 768K dauert das knapp 2 Stunden...

Stefan

[AndreasMarx]

Aha,

ZynOS erlaubt sogar die SNRs pro Träger auszulesen. Im US-Bereich keine Auffälligkeiten. Also doch ein AGC-Problem beim LC?

[AndreasMarx]

Hmm, das hier dürfte Auskunft geben, was das TELEDAT beim Training so anstellt und was das LC ja offensichtlich so nicht macht. Die Bedeutung der Codes ist mir allerdings (noch) nicht bekannt:

Code: Alles auswählen

P660M> wan adsl driver info
...
trainFails= 1
trainFailStates[0]~[29] =
0x00000078      0x00000000      0x00000000      0x00000000
0x00000000      0x00000000      0x00000000      0x00000000
0x00000000      0x00000000      0x00000000      0x00000000
0x00000000      0x00000000      0x00000000      0x00000000
0x00000000      0x00000000      0x00000000      0x00000000
0x00000000      0x00000000      0x00000000      0x00000000
0x00000000      0x00000000      0x00000000      0x00000000
0x00000000      0x00000000      0x02f9459f      0x02fdf161
...

[ittk]

Spielt die ISDN Aktivität da wirklich eine Rolle? Aber wo Du es schreibst, ich habe schon mal beobachtet, das genau in dem Moment wo meine Frau begonnen hat zu telefonieren, der ADSL Link verloren ging.

Das konnte ich mal einmal beobachten, als der DSLAM aufgetauscht wurde auf UR-2 Standard und das Modem auf der Gegenseite nicht UR-2-fähig war.

Aber ggf. hat dies auch Einfluss auf eure Szenarien, insb. dann wenn adaptive Entzerrung zum Einsatz kommt.

[froeschi62]

Hallöchen,

Moin,
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.
Gruß Alfred

schade nur, dass der gute Ruf Euerer Produkte sowohl in einigen Internetforen als auch in der Fachpresse inzwischen durch den eher mäßigen Modemlinecode etwas leidet. Selbst ADS1, obwohl schon lange im Angebot, ist nicht restlos sauber implementiert, geschweige denn überhaupt ADSL2+. Falls Ihr mit dem Linecode nicht weiterkommt, wäre es sicher sinnvoller, zukünftige Produktlinien ganz ohne Modem anzubieten. Hoffentlich wird mit der 6.24 wieder ein eingermaßen vernünftiger Linecode angeboten. Mittlerweile bieten alle Provider ADSL2+ an, davon die Größten (Arcor/T-COM) DSLAMS mit Infineon. Es wäre schön, wenn der neue Linecode zumindest auf ADSL2+/Infineon gut abgestimmt ist. Das könnte schon ein ordentlicher Anfang sein und Grundlage für eine gute Weiterentwicklung bieten.

Gruß
Dietmar

[Popasi]

Selbst ADS1, obwohl schon lange im Angebot, ist nicht restlos sauber implementiert[...]

Das kann ich als geplagter ADSL1 Nutzer leider bestätigen, mit dem "geraden" LCOSs mit dem ADSL2+ Linecode bekomme ich Syncs die generell 500 kBit/s *unter* den Linecodes der "ungeraden" Versionen sind. Dies finde ich ziemlich bedenklich, da die ADSL2+ fähigen Linecodes ja eigentlich die "neueren" seinen sollen und ADSL1, wie gesagt, ja bereits länger eingeführt ist, da sollte es keine Qualitätsunterschiede mehr geben. Seit ich meine neue Version des LC1821 habe. erhalte ich mit dem "ungeraden" Linecode keine sauberen Connects mehr, so das ich mit dem Penalty leben muss....
Trotzdem würde ich zu dem Thema gerne mal eine Aussage der "Linecodeprofis" hören...

[MoinMoin]

Moin Andreas!

ZynOS erlaubt sogar die SNRs pro Träger auszulesen. Im US-Bereich keine Auffälligkeiten. Also doch ein AGC-Problem beim LC?

Die Möglichkeit gab es bei LANCOM auch mal (z.B. 1621). Bis Conexant den Status bei einer neuen API-Version weggelassen hat. Der Upstream ist bei Annex-B in den Frequenzbändern (Tönen, Bin) 32 bis 63. In deinem Diagramm fehlt der Upstream offensichtlich, es wird nur der Downstream dargestellt. Du kannst dir bei LANCOM auch einen groben Überblick über die Qualität der einzelnen Frequenzen verschaffen, indem du dir die Bits-per-Bin-Tabellen ansiehst.

Ciao, Georg