RAM begrenzen ?

[Vienna144]

Hallo,

ich hab' seit kurzem a.) die v 4.x und b.) aufgestockt auf 16 GB RAM. Am Ende einer Videobearbeitung "hängt" tsdoctor eine Weile und bemeckert "keine Rückmeldung" (v 3.2 "hängt" da genau so - nur wird die Meldung nicht angeschrieben).

Jetzt bin ich drauf gekommen, dass genau im Zeitraum des "Hängens" (= keine Rückmeldung) noch Netzwerkaktivität "Senden" stattfindet. Heißt: anscheinend arbeitet der tsdoctor den RAM voll - und im Anschluss arbeitet das Netzwerk den vollen RAM ab.

Kann man dem tsdoctor das abgewöhnen? Er müsste sich ja nicht so beeilen, wenn das Netzwerk mit der Ziel-HDD nicht nachkommt...?

Thx

[tsduser]

Rein interessehalber (weil der Doc von sich aus so etwas sicher nicht tut/tun wuerde):
Die bearbeitete Datei traegt vielleicht die Erweiterung .ts? Kannst Du dann mal probieren, ob das Verhalten auch zu beobachten ist, wenn Du die Erweiterung auf .ts4 (akzeptiert der Doc ebenfalls) aenderst?

[Vienna144]

Ich bin mittlerweile einen Schritt weiter - es scheint eher ein Netzwerkproblem zu sein: das Quell-Laufwerk (SAT-Receiver) bringt übers Netzwerk ca. 80MBit - während es zum Ziel-Laufwerk nur mit ca. 55 MBit geht. D.h. der tsdoctor arbeitet in den RAM rein, weil das Netz beim Abtransport zu langsam ist.

Ich bin dabei das Nadelöhr zu suchen ... habe seit einigen Tagen einen neuen (managed) Switch - auf den fällt Verdacht #1. Vielleicht kann ich ihn auch (noch) nicht richtig konfigurieren...

Thx

[Mam]

agen einen neuen (managed) Switch - auf den fällt Verdacht #1. Vielleicht kann ich ihn auch (noch) nicht richtig konfigurieren...

Nun ja, er wird nicht kapput sein 
Aber, überprüf mal, ob für alle Ports auch "Flow Control" aktiviert ist. Damit kann der Switch den PC auf "klientenfreundliche" Geschwindigkeit runterbremsen. So kommt es dann nicht zu dem Blutstau im RAM.
Insgesamt sieht die Übertragung danach langsamer aus, ist es aber gar nicht, wenn Du die Pause am Ende mitzählst.
(Bei den Rechnern sollte Flow Control automatisch aktiviert werden, sobald der Switch es anfordert)

[Vienna144]

Ich bin noch einen Schritt weiter ... mea culpa ... ich hatte eine andere Anwendung, die kräftigen Netzwerktraffic verursacht, nicht am Schirm. Ich konnte dort an einem Rädchen drehen, den Traffic reduzieren. Jetzt - wo der Abtransport der Daten wieder sichergestellt ist - läuft's auch mit dem tsdoctor rund.

Danke!

[Vienna144]

NACHTRAG: ich hab' jetzt weiter getestet: es kommt immer wieder mal vor, dass die Datenanlieferung schneller erfolgt als der Datenabtransport - speziell dann, wenn man SMR-Festplatten *) nutzt. Dann arbeitet der tsdoctor in den RAM - und bis der dann von der HDD "abgearbeitet" (= auf HDD geschrieben) ist, dauert's halt. Bei meinen 16 GB RAM auch mal bis zu 30 Sekunden...

... die Fehlermeldung "keine Rückmeldung" erzeugt dann halt erst mal Panik! Die Frage ist: muss das so sein?

*) SMR-Platten müssen intern "umschichten", weshalb deren Datenrate ab einem gewissen Füllgrad bei hohem Datenaufkommen beim Schreiben einbricht. D.h. lesen geht flott, schreiben u.U. nicht.

[Mam]

speziell dann, wenn man SMR-Festplatten *) nutzt

Wer kauft den SOWAS??? 

Oder ist die vom LKW gefallen und zufällig in Deinem Vorgarten gelandet?

Das sind reine Archivplatten (na ja, eigentlich sind es reine "No-Go" Platten), die kannst Du nicht als Arbeitslaufwerk verwenden.

rzeugt dann halt erst mal Panik! Die Frage ist: muss das so sein?

Was soll der Doc denn machen, wenn die doofe Platte die Daten nicht haben will? Er kann doch nur "warten", bzw, wird vom OS schlafen gelegt. Und wenn das Warten zu lange dauert, wird das OS nervös und zeigt eben "keine Rückmeldung" an, weil der Schläfer eben im Koma ist.

[Vienna144]

Ich möcht' mich jetzt nur noch mal melden, damit ich nicht ganz so blöd da stehe - ich konnte mittlerweile einen HW-Fehler diagnostizieren: es lag an einem Netzwerk-Switch! Jetzt ist ein neues Switch drin - und die Daten werden brav weiter geschaufelt. Die (neue) Message "Keine Rückmeldung" kommt - wenn überhaupt - dann nur mehr ganz kurz.

LG

[Cypheros]

Danke für die Rückmeldung.