Hi
Da man hier öfter über Probleme mit der DBox in einem 100Mbit-Netzwerk liest, kam mir folgende Idee, die man ja mal ganz naiv diskutieren könnte:
So wie es schon sehr lange die Idee mit der IDE-Schnittstelle an dem RAM-Erweiterungsport der DBox gibt, kann man dort doch wahrscheinlich auch eine Art Ethernet-Schnittstelle betreiben. Also im Prinzip eine gute Netzwerkkarte dort einbauen.
Mich wundert es ein bisschen, dass die DBox so schlecht über das Netzwerk Daten einlesen und abspielen kann. Im Prinzip geht es doch nur darum, Daten von einem Ort (Ethernet-Schnittstelle) zum anderen (MpegDecoder) zu schaufeln, da muss doch nichts umgerechnet oder verändert werden. Ist der eingebaute NIC wirklich so schlecht und belastet den Prozessor so stark? Würde ein guter Ethernet-Chip (wie zB. auf 3Com- oder Intel-Netzwerkkarten) die Box spürbar entlasten?
Ich habe nämlich das Problem, dass meine NokiaBox nicht vernünftig an meinem Netzwerk läuft. Die Kabel sind in der Wohnung fest installiert (Cat5e), Switch (Elsa 10/100 MBit 8Port) ist vorhanden und ich habe prinzipiell nur die Möglichkeit die Box am Switch anzuschliessen oder es zu lassen, ein 10 MBit Hub oder eine Direktverbindung kommt nicht in Frage.
Ich habe u.a. zwei Rechner (LinuxVDR und Windows2k) im Netzwerk hängen, auf denen sich DVB-Aufnahmen befinden und würde diese gerne ohne Umrechnug, Kompression etc. auf der Box anschauen.
Gruß
Jarny
Guten Netzwerkadapter in die Box einbauen
-
- Interessierter
- Beiträge: 45
- Registriert: Samstag 2. Oktober 2004, 10:14
-
- IDE-Frickler und Berufspessimist
- Beiträge: 464
- Registriert: Samstag 27. Juli 2002, 21:13
-
- Interessierter
- Beiträge: 45
- Registriert: Samstag 2. Oktober 2004, 10:14
Hehe, natürlich der obligatorische 'when it's '-Termin. Ist ja schon fast krankhaft bei Hard/Software-Entwicklern weil man immer drauf festgenagelt wird, geht mir genauso. Termine sollten hier auch nicht das Thema sein.Rudi Ratlos 4711 hat geschrieben:.....in sehr ferner Zukunft .....
Schaun wir mal.....
RR4711
Ist das Projekt einfacher als die IDE-Schnittstelle oder eher komplexer?
Gruß
Jarny
-
- Neugieriger
- Beiträge: 5
- Registriert: Dienstag 30. Dezember 2003, 02:26
Hallo,
also ich dachte bisher, der Ethernet-Teil des Prozessors ist eigentlich sehr effizient. In der CPU ist ein separater Kommunikations-Prozessor(CP) eingebaut. Der wickelt alle seriellen Schnittstellen (SCC's, I2C, SPI, seriell ist in dem Sinne auch Ethernet) ab, so daß die eigentliche CPU weiterarbeiten kann. Dabei benutzt er DMA um aus dem Arbeitsspeicher die Paket-Daten abzugreifen/abzuspeichern. Der Prozessor kann derweil im (leider etwas kleinen) Cache weiterarbeiten, der während der Pausen des CP aufgefrischt wird.
Um ein Paket (einen Block von Zeichen, dh. zb. ein IP-Paket) zu senden/empfangen benutzt der Chip sogenannte Buffer-Descriptoren. Das ist nichts weiter als einen kleiner Ringpuffer(im internen Ram des CP) von Zeiger auf die eigentlichen Daten (die üblicherweise im externen RAM liegen). Eigentlich muss zum letzlichen Senden der Daten nur der Header (IP) an die Daten rankopiert werden und in den nächsten freien Bufferdescriptor eingetragen werden. Leider ist der Aufbau der Datenpuffer meist so gelöst, das die Daten doch umkopiert werden müssen (kein Platz für den Header VOR den Sendedaten). Weiterhin müssen zumeist die Sendedaten entsprechend unterteilt werden.
Das eigentliche Problem des Interface der Box ist jedoch auch der festverdrahtete Halbduplexmodus. D.h. auf Rx und Tx ist jeweils das gleiche Datum zu finden (welche Verschwendung). Es gab imho hier mal den Versuch den Chip auf Fullduplex zu stellen(Hardware-Umbau), ich weis aber nicht mehr wie das ausging, es wäre aber imho leichter zu bewerkstelligen.
Ein externer Ethernet-Chip müßte die Sendepuffer beinhalten. D.h. die CPU muss weiterhin die Daten erstmal in den Ethernet-Chip umkopieren. Also darin seh ich keinen Vorteil. Der einzige Vorteil wäre für mich, das man einen Chip mit 100MBit/s Fullduplex betreiben könnte (auch wenn die CPU bei der maximalen Datenlast ziemlich überfordert wäre, aber wir sprechen hier ja vom Streamen, d.h. Datenrate bis max. 10MBit/s). Man hätte zumindest bei Übertragungsfehlern (wie sie im Kabel-Netzwerk eigentlich kaum vorkommen sollten, Funk ist da was anderes) einen Zeitvorteil (geringere Latenzzeit- Verzögerung zwischen absenden und ankommen des Packets und damit ev. Antwortpackete).
Ich hoffe ich konnte etwas von meinem bescheidenen Wissen vermitteln.
Falls dabei etwas nicht korrekt dargestellt ist, sollte sich einer der Devs vielleicht mal melden.
Gruss Panta Rhei
also ich dachte bisher, der Ethernet-Teil des Prozessors ist eigentlich sehr effizient. In der CPU ist ein separater Kommunikations-Prozessor(CP) eingebaut. Der wickelt alle seriellen Schnittstellen (SCC's, I2C, SPI, seriell ist in dem Sinne auch Ethernet) ab, so daß die eigentliche CPU weiterarbeiten kann. Dabei benutzt er DMA um aus dem Arbeitsspeicher die Paket-Daten abzugreifen/abzuspeichern. Der Prozessor kann derweil im (leider etwas kleinen) Cache weiterarbeiten, der während der Pausen des CP aufgefrischt wird.
Um ein Paket (einen Block von Zeichen, dh. zb. ein IP-Paket) zu senden/empfangen benutzt der Chip sogenannte Buffer-Descriptoren. Das ist nichts weiter als einen kleiner Ringpuffer(im internen Ram des CP) von Zeiger auf die eigentlichen Daten (die üblicherweise im externen RAM liegen). Eigentlich muss zum letzlichen Senden der Daten nur der Header (IP) an die Daten rankopiert werden und in den nächsten freien Bufferdescriptor eingetragen werden. Leider ist der Aufbau der Datenpuffer meist so gelöst, das die Daten doch umkopiert werden müssen (kein Platz für den Header VOR den Sendedaten). Weiterhin müssen zumeist die Sendedaten entsprechend unterteilt werden.
Das eigentliche Problem des Interface der Box ist jedoch auch der festverdrahtete Halbduplexmodus. D.h. auf Rx und Tx ist jeweils das gleiche Datum zu finden (welche Verschwendung). Es gab imho hier mal den Versuch den Chip auf Fullduplex zu stellen(Hardware-Umbau), ich weis aber nicht mehr wie das ausging, es wäre aber imho leichter zu bewerkstelligen.
Ein externer Ethernet-Chip müßte die Sendepuffer beinhalten. D.h. die CPU muss weiterhin die Daten erstmal in den Ethernet-Chip umkopieren. Also darin seh ich keinen Vorteil. Der einzige Vorteil wäre für mich, das man einen Chip mit 100MBit/s Fullduplex betreiben könnte (auch wenn die CPU bei der maximalen Datenlast ziemlich überfordert wäre, aber wir sprechen hier ja vom Streamen, d.h. Datenrate bis max. 10MBit/s). Man hätte zumindest bei Übertragungsfehlern (wie sie im Kabel-Netzwerk eigentlich kaum vorkommen sollten, Funk ist da was anderes) einen Zeitvorteil (geringere Latenzzeit- Verzögerung zwischen absenden und ankommen des Packets und damit ev. Antwortpackete).
Ich hoffe ich konnte etwas von meinem bescheidenen Wissen vermitteln.
Falls dabei etwas nicht korrekt dargestellt ist, sollte sich einer der Devs vielleicht mal melden.
Gruss Panta Rhei
-
- Senior Member
- Beiträge: 1278
- Registriert: Mittwoch 5. September 2001, 00:00
Thema gesplittet, weil OT
http://forum.tuxbox-cvs.sourceforge.net ... hp?t=33784
http://forum.tuxbox-cvs.sourceforge.net ... hp?t=33784