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.
Danke für den Tip. DMA-Modus ist bereits aktiviert. Hast du noch eine andere Idee? Gruß Malte
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.