Evtl. habe ich einen (weiteren) Grund für das langsame Netzwerk der 500 gefunden(zumindest habe ich den Eindruck, daß das Problem relevant sein könnte):

Egal was ich in /proc/sys/net/core/?mem_max(u.a.) ausgebe, die Window Size der Box ist und bleibt (MTU-40)*4. Ist das ein Treiberproblem oder durch die Firmware begründet? Beispiel: MTU=1500, Window-Size=5840, anstatt 104448 lt. cat /proc/sys/net/core/rmem_max (Standardeinstellung!!)

Hab das mit zwei Boxen und Wireshark für alle Verbindungen nachvollziehen können, egal ob von der oder zur Box, egal ob NFS, CIFS, Telnet oder FTP.

Firmware ist das Release 1.09 vom 20.09.2006. Kann das jemand bestätigen oder hat vllt. sogar einen Workaround dafür?

Erst mal danke für die Antwort.

DMA hab ich noch nicht betrachtet, aber schon drüber gelesen. Werde ich mir mal vornehmen, sobald das mit der TCP Window Size geregelt ist.

Ob die TCP Window Size nun groß genug für was auch immer ist, war nicht einmal Gegenstand meiner Betrachtungen. Ich könnte sie ja nicht verändern, selbst wenn ich wollte, weil die Box nicht die Window Size benutzt, die ich über die dafür gedachten Dateien festlege(proc/sys/net etc.), sondern immer den gleichen Wert wie unten beschrieben. Und da liegt der Kern des Problems: Warum macht sie das?

Re-Transmits bleiben bei nur einer Telnetverbindung aus, selbst über WLAN. Muß aber noch ein paar Tests machen, was größere Datenmengen und mehrere Verbindungen angeht. Sollten die etwas neues ergeben werde ich es hier posten.

So, hab mal ein paar Tests durchgeführt.

Kern der Tests war immer eine 4 MB-Datei in der Ramdisk(/var/tmp).
Diese wurde mittels Endloschleife in einem Shell-Script permanent in eine CIFS-Freigabe kopiert. Ein Test erfolgte kabelgebunden, der andere über 54 MBit WLAN.
Das ganze wurde mit Wireshark gesnifft, um die Zeiten festzuhalten. Über diese Zeiten und den vom SMB-Protokoll gemeldeten Dateigrößen habe ich dann die durchschnittliche Geschwindigkeit errechnet.

Ergebnisse:
[list=1]
[*]Das SMB-Protokoll regelt die Window Size nochmal neu, nach welchem Muster ist mir noch nicht klar. In jedem Fall war sie mind. 3x so groß wie die Initialgröße(nach wie vor 5840).
[*]Es gab bei keinem Medium Re-Transmits, erklärbar durch Punkt 1
[*]Durchschnittsgeschwindigkeit LAN: 12 MBit
[*]Durchschnittsgeschwindigkeit WLAN: 2,5 MBit
[/list=1]
Danach habe ich die Datei mit drei Schleifen gleichzeitig übertragen, nennenswerte Änderungen gab es nicht.

Fazit:

Streaming per LAN zu CIFS müsste störungsfrei möglich sein, wenn man den DMA mal außer acht lässt. Werde ich demnächst nochmal ausprobieren.

Streaming per WLAN ist mit diesen Ergebnissen fast schon ausgeschlossen. Die meisten Sender liegen ja über dieser Datenrate. Physik spielt eigentlich keine Rolle bei mir. Access Point und Client sind etwa 5m Luftlinie voneinander entfernt, zwei Innenwände á 20cm dazwischen. WLAN-Stärke sollte damit eigentlich locker für das drei- oder vierfache an Bandbreite reichen. Werde es aber noch mit direkter Sichtverbindung probieren(ist immer so ein Act den ganzen Kram abzubauen).

Hat noch jemand Tipps?

So hab das Thema jetzt denke ich fertig durchgekaut.

• Streaming über WLAN(entweder per Bridge oder AccessPoint und USB-Stick am PC) geht prinzipiell, stabil aber nur mit ngrab per UDP (dazu am Schluß noch etwas) und keinesfalls zu CIFS oder NFS.
• Streaming über LAN zu CIFS stabil und im Wesentlichen fehlerfrei(s.u.). Die beteiligten Parameter(soweit alle Standard):

• rsize: 8192
• wsize: 8192
• mtu: 1500
• Platte: 5400 U/min 8 MB Cache in nem normalen PC
• Last: Nicht genau gemessen, aber spürbar hoch(z.B. gabs deutliche Verzögerungen bei Aufruf der Infoleiste)

Ergebnis: Über 3:20h Aufnahmedauer nur etwa 100 video frames und 250 audio frames verlustig. Tolerabel und durchaus auch durch Bitfehler im Kabelsignal zu erklären.

Anmerkung: Box ist mit Kondensatorumbau. Ohne gäbe es wahrscheinlich die bekannten Probleme. Andere Cams hatte ich nicht getestet, was die Last angeht.

Zu ngrab:

Hier ist womöglicherweise ein Bug vorhanden, was ich selbst aber nicht weiter untersuchen werde als ich das wie unten beschrieben schon getan habe.

Es kam wiederholt und reproduzierbar vor, daß der Meta-Datenstrom von der Box(also das XML-Geraffel mit Record-Befehl, Sendernamen, PIDs usw.) leer war. Als Folge spielte jeder Grabber verrückt, da insbesondere der Record-Befehl(record=stop bzw. record=start) zur Aufnahmesteuerung wichtig ist. Eindeutig feststellen konnte ich das mit SimpleGrab im Debug-Modus und kontrolliert hatte ich es mit Wireshark.

Das Verhalten der Box passte zum Fehlen der Daten. Es wurden bpsw. bei bei angewiesenem Aufnahmestopp mit fehlenden Metadaten weiter fleißig Streamdaten gesendet. Erst mit Beenden des Grabservers hörte die Box dann auch auf Daten zu senden.

Die Metadaten wurden bei weiteren Aufnahmen nach o.g. Verhalten verkehrt gesendet, also z.B. der Aufnahmestopp für die vorherige Aufnahme, obwohl ich eine neue gestartet hatte. Vermute daher ein Timingproblem oder was in der Richtung. Kann auch durchaus sein, daß das Verhalten vom zeitlichen Abstand zwischen Aufnahmebeginn und Aufnahmestopp abhängt. Nichtsdestotrotz vermutlich ein Bug.

Kann sich jemand anders dran machen, für mich ist das Thema Streaming auf der DM500 damit abgeschlossen.

MOD: Selbiges kann mit diesem Thread gemacht werden, sofern niemand noch ne Frage hat oder was hinzufügen will. Gerne auch per PM.