Hi,
auf einem sehr lahmen System (Geode 300, Debian) lese ich ständig Daten
von der seriellen Schnittstelle mit Baudrate 38400 ein, ohne
Flußkontrolle. Die Datenrate beträgt etwa 600 Byte/sec. Wenn die
Prozessorlast durch andere Prozesse für längere Zeit sehr hoch wird,
gehen Teile der seriellen Daten verloren. Ich habe das überprüft mit
"cat /dev/ttyS0 > test.dat". In test.dat sieht man dann bei hoher
Prozessorlast die Lücken.
Wenn ich die gleichen Daten über einen Ethernet Port einlese, gibts
keine Lücken.
Ich habe gelesen, dass die UART Bausteine einen Empfangspuffer von nur
16Byte besitzen. Habe aber nichts drüber gefunden, wie man diesen Puffer
irgendwie vergößern kann. In setserial oder stty gibts dafür keine
Optionen.
Hat jemand eine Idee zur Lösung des Problems?
Gruß
Malte
Linux-Systeme haben einen zusätzlichen Datenpuffer,
der aber nur dann gefüllt wird, wenn von der
seriellen Schnittstelle Interrupts durchkommen.
Festplatteninterrupts haben eine höhere Priorität
als die der seriellen Schnittstellen.
Das verhindert oft das Durchkommen der seriellen INTs.
Eine Lösung kann darin bestehen, die Platten in den
DMA-Modus zu versetzen. "man hdparm", Option -d.
Du kannst noch versuchen, deinem Leseprogramm
eine höhere Priorität zu verschaffen.
Dazu dient das Programm nice.
Aufrufbeispiel: nice -n -10 deinprog
Der Wert muss negativ sein! Gelingt aber nur als root.
malt wrote:
> Hi,>> auf einem sehr lahmen System (Geode 300, Debian) lese ich ständig Daten> von der seriellen Schnittstelle mit Baudrate 38400 ein, ohne> Flußkontrolle.
Im 'schlimmsten' Fall könnte man eine Flusskontrolle
aktivieren bzw. implementieren.
Den die gibt es genau aus dem Grund der jetzt deinen
Fehlerfall darstellt.
Hallo,
nice hat kaum Wirkung gezeigt, leider. Kann es sein, dass nice nur die
Prozessorzeit anders aufteilt, und dies keine Auswirkung auf die
Reaktion auf Interrupts hat?
Ja, eine Flusskontrolle waere gut in diesem Fall. Mir graut aber vor der
Implementierung, von den Aenderungen in der Hardware ganz zu
schweigen...
Es wundert mich, dass die eth-Ports so gaenzlich anders behandelt werden
als die seriellen. Haben die einfach mehr Speicher im Chip?
Gruss
Malte
malt wrote:
> Hallo,>> nice hat kaum Wirkung gezeigt, leider. Kann es sein, dass nice nur die> Prozessorzeit anders aufteilt, und dies keine Auswirkung auf die> Reaktion auf Interrupts hat?>> Ja, eine Flusskontrolle waere gut in diesem Fall. Mir graut aber vor der> Implementierung, von den Aenderungen in der Hardware ganz zu> schweigen...>> Es wundert mich, dass die eth-Ports so gaenzlich anders behandelt werden> als die seriellen. Haben die einfach mehr Speicher im Chip?>> Gruss> Malte
Soweit ich weiß werden die Daten von der Netzwerkschnittstelle per DMA
direkt in den Hauptspeicher kopiert, ohne dass der Prozessor was machen
muss.
Beim 16byte FIFO kann man den triggerlevel setzen. Auf 4,7,10,14, soweit
ich mich erinnere. Diese Zahl sollte man kleiner waehlen. ZB von 10 auf
7 erniedrigen. Wenn die Festplatte, alllerdings das system zu macht,
hilft das nicht viel. In dem Falle eine externe Schnittstellenkarte, zB
ISA oder PCI, die haben beliebig viel Buffer drauf.
Eine eigene Frage?
Dieser Thread ist über 19 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
