zaphfc: dropped audio & bchan rx fifo not enough bytes

Oja, das kommt mir entfernt bekannt vor.
Habe vor kurzem in http://www.ip-phone-forum.de/forum/viewtopic.php?t=12915 von ähnlichen Problemen berichtet. Ich hatte allerdings keine "bchan rx fifo" Probleme, bei mir ging es um "bchan tx fifo."

Die schlechte Nachricht ist allerdings, dass ich auch noch keine richtige Idee habe wo das Problem überhaupt liegt.

An der Größe des fifo Buffers kann man aber meines Wissens nichts machen. So wie ich das im ersten Anschein gesehen habe ist das der Pufferspeicher auf der Karte. Der dürfte wohl eine feste Größe haben.

Sag mal, 1.2 GHz hört sich nach Tualatin-CPU an (oder wie hiessen die Dinger damals noch gleich?). Das müsste so in der Anfangszeit der I/O-APICS im single CPU Mainboard gewesen sein. Was sagt denn "cat /proc/interrupts" bei Dir? Steht da etwas von IO-APIC-EDGE oder findet sich in der Liste dauernd XT-PIC?

Irgendwie hört es sich so an als hättest Du mehrere Asterisk-Systeme ("Zumindest auf einem System habe ich ..."). Taucht denn das Problem nur bei dem einen auf?

 

Ok,
ich hab gestern einen Flieger verpasst und habe mir Wartezeit damit vertrieben mal ins zaphfc hineinzusehen. Die Sache wurde zwar gegen Ende etwas uneffizient, aber das lag eher daran, dass ich mal die KLM lounge in Schiphol nach Herzenslust geplündert habe. :bier:

Aber zur Sache. Ich denke, dass ich so langsam eine Idee bekomme wie RTAI funktioniert und wo es klemmen könnte. Der Gag von RTAI liegt darin, dass es gewissermassen eine Zwischenschicht zwischen Hardware und Linux darstellt. Im Grunde übernimmt RTAI die Herrschaft über den Rechner und unter RTAI laufen verschiedene Tasks. Hierbei ist in erster Linie an real time tasks zu denken, die quasi in Echtzeit z.B. auf äußere Ereignisse reagieren. Diese laufen unter RTAI mit hoher Priorität, wodurch es auf einem Rechner mit ausreichender Verarbeitungsgeschwindigkeit zu einem quasi Echtzeitverhalten kommt. Irgendwie pfiffig ist, dass Linux selbst als eine RTAI task läuft - und zwar als eine task mit niedriger Priorität.

Im Ergebnis werden also die realtime tasks (in unserem Fall zaphfc) mit dem gewünschten Timing ausgeführt und in den Pausen kommt dann mal Linux dran. Aber wie gesagt nur dann, wenn gerade keine real time Aufgabe zur Verarbeitung ansteht. Wir werden darauf noch zurückkommen.

Klaus-Peter Junghanns hat zaphfc so konzipiert, dass RTAI eigentlich nur benutzt wird um den Treiber jede Millisekunde "aufzuwecken". Man sollte meinen, dass jetzt die Daten von der ISDN-Karte ausgelesen würden, so dass sie dann weiter verarbeitet werden können (so etwas würde in der Regel ein Treiber tun wenn er auf einen Interrupt reagiert). Aber an dieser Stelle passiert etwas anderes. Klaus-Peter hat sich dafür entschieden, den Interrupt der Karte(n) zur Bearbeitung an Linux weiterzureichen.

Warum nur macht er es so? Ich habe darüber echt lange nachgedacht (naja der Sekt war wirklich gut und so hat es wohl noch länger gedauert) und bin nun fast der Überzeugung, dass er es sich da etwas einfach macht. Verstehen kann ich es ja irgendwie. Denn jetzt kommt rein programmiertechnisch die ganz normale Interruptbehandlung in Linux - ganz so als gäbe es RTAI gar nicht. Weitere Programmänderungen sind nicht mehr erforderlich - sehr praktisch.

Aber:
Bei der noch folgenden Verarbeitung des Interrupts muss man mit zwei Konsequenzen leben. Nummer eins ist die schon vorher erwähnte geringe Priorität, mit der Linux unter RATI läuft. Nun, da auf dem System nur der zaphfc als real-time task laufen sollte, wird das vermutlich zu verschmerzen sein. Mit ein wenig Glück kann also Linux den Interrupt gleich weiterverarbeiten. Aber jetzt kommt möglicherweise Problem Nummer zwei. Während bei der direkten Verarbeitung der Interrupts unter Linux alle anderen Interrupts bis zur Abarbeitung gesperrt sind, ist das jetzt bei dem unter RTAI laufenden Linux nicht mehr der Fall. Hier findet die Interrupt-Verarbeitung innerhalb von Linux sicher noch immer mit hoher Priorität statt, aber Linux selbst läuft ja mit niedriger Priorität unter RTAI und kann von diesem jederzeit unterbrochen werden. Ausserdem kann diese Interrupt-Verarbeitung jetzt auch noch durch jeden anderen Interrupt unterbrochen werden.

Tja, so scheint es also zu sein. Nun folgt Raum für Spekulationen.
Aus den Fehlermeldungen ist ja ganz klar ersichtlich, dass zaphfc beispielsweise das Auslesen der Karte oft nicht ohne zu stolpern schafft. Oft sind mehr Daten da als erwartet. Wie kann das sein? Ich persönlich denke es liegt daran, dass zwischen dem letzten Interrupt und dem tatsächlichen Auslesen der Karte ein völlig unbekannter Zeitraum vergangen ist. Da erst einmal Linux selbst zwecks Weiterverarbeitung des Interrupts zur Ausführung kommen muss, kann es also durchaus vorkommen, dass bis zur (oder während der) Verarbeitung einige Zeit vergeht. Ganz offensichtlich können sich bis dahin etliche neue Daten auf der HFC-Karte ansammeln. Möglicherweise wurde der Verarbeitungsvorgang selbst ja auch noch durch Interrupts oder durch tasks höherer Priorität unterbrochen. Aber ganz offensichtlich passiert hier auf der Karte vor oder während der Bearbeitung der Daten etwas womit zaphfc ganz einfach nicht rechnet.

 

Re: zaphfc: dropped audio & bchan rx fifo not enough byt

Interessanterweise bekomme ich jetzt genau diese Fehlermeldungen auch nachdem ich zaphfc mal ohne RTAI ausprobiert habe. Hattest Du Asterisk bzw. zaphfc bei Dir mit oder ohne RTAI am laufen, Fux?

 

Genau das habe ich aus genau dem selben Grund versucht: zwar habe ich RTAI installieren können und auch entsprechende zaphfc Module bauen können, aber es löste die Probleme nicht wirklich, im Gegenteil, machte das Telefonieren mit Asterisk unbrauchbar, da in eine Kommunikationsrichtung eine riesige Verzögerung (mit Echo) von über 1 Sekunde entstand.
Könnte aber durchaus sein, dass mein System für RTAI zu schwach ist und du mehr Erfolg damit hast (P2@350MHz). Probiers doch mal aus, am einfachsten geht es mit den original patches, mit etwas Umbiegen geht es dann auch mit den original unstable Debian Paketen (siehe bugreports zu zaphfc).

 

zum RTAI:
Ohne RTAI scheinen die HFC-Karten mit 8kHz Interrrupts zu erzeugen, wobei nur bei jedem 8. Daten von der Karte geholt werden (also mit 1kHz Frequenz).
Mit RTAI erzeugen die Karten jedoch keine Interrupts, sondern es wird von einem Timerbaustein auf dem Motherboard Interrupts mit 1kHz erzeugt.
Interrupts werden nach der Bearbeitung von echten RTAI-Tasks (es gibt nur einen Proxy-Task, der nichts macht) an den Kernel weitergeleitet, der mit geringer Verzögerung dann die Interrupts verarbeitet. Linux verarbeitet also immer den Interrupt weiter, das ist bei RTAI so.

Somit ist nur noch 1/8 der Interrupts notwendig, das ist der Trick!

Zum Problem Nr. 2:
Linux sperrt mit und ohne RTAI Interrupts, d.h. es bekommt keine Interrupts, bis Linux dies wieder erlaubt! Einziger Unterschied ist, daß RTAI die Interrupts (hardwareseitig) entgegennimmt und in einer Queue zwischenspeichert, bis Linux wieder soweit ist. Linux kann zwar von Hardware-Interrupts unterbrochen werden, aber nur für eine kurze Zeit (bis alle RTAI-Tasks höherer Priorität diesen verarbeitet haben).

Ich sehe da 2 andere Probleme:
1. Der Timerbaustein auf dem Board läuft mit einer zu stark abweichenden Frequenz als der der HFC-Karten (sie laufen nie gleich, das muß aber kein Problem sein). Dann sollte es nur selten aber regelmäßig zu Problemen kommen. Mal übertrieben gesprochen: Der Treiber will mit 1,1kHz Daten abholen, die aber nur mit 1kHz erzeugt werden --> irgendwann sind nur 7 von 8 Byte da (siehe Fehlermeldung!).
2. Nach dem Timer-Interrupt vergeht eine zu lange Zeit bis der Treiber die Daten von der Karte abholt, der Puffer läuft über und erreicht irgendwann 7 Byte (würde mich jedoch wundern, wenn die Verzögerung derart groß ist!). Da würde es helfen, wenn der RTAI-Task die Daten abholen und in eine Queue speichern würde (RTAI bietet das ja an).

Das wird ja bald ein Treiber-Developer-Thread hier ;-)

Gruß

 

Liegt vermutlich eher am preemptible Kernel, da dieser früher durch den Timer-Interrupt unterbrochen werden und die HFC-Karte bedienen kann. Wenns daran liegt, wäre ein echtzeit-Treiber für den HFC eine schöne Lösung!
Zeigt der Kernel beim Booten an, daß er HPET verwendet?

 

Preemtive heißt in diesem Fall, das einem Prozess die CPU entzogen werden kann (d.h. er wird angehalten und es wird vorrübergehend etwas anderes gemacht). In Unserem Fall handelt es sich dabei um Funktionen des Kernels, die normalerweise nicht unterbrochen werden dürfen, u.U. selbst von IRQ's nicht.
Bei Servern erreicht man die höchste Geschwindigkeit, wenn nun so wenig Prozess-Wechsel wie möglich stattfinden, da jeder Wechsel selbst Zeit kostet. Dafür aber steigt dadurch die Reaktionszeit, und ohne "preemtible kernel" muß die HFC-Karte manchmal länger warten, als ihr lieb ist. Und dann kommt oben genannte Warnung, das Puffer über-/leergelaufen sind.

Ich selbst verwende einen nicht-preemtiven Kernel, da (zumindest früher) die HFC-Treiber allergisch reagiert haben, wenn man sie im Betrieb neu laden wollte (weil sie dabei unterbrochen wurden). Wenn man das 1-2 mal gemacht hat, mußte ich nicht mehr lange auf einen Kernel Panic warten

Wenn du also so zufrieden bist wie es ist, laß' es so! HPET gibts meines Wissens sowieso erst auf neuern Motherboards und hilft in dem Fall auch nicht weiter.

Gruß, Sion

 

Sion,
auch wenn ich nicht genau weiss ob Du mit ersten zitierten Satz das richtige meinst, gebe ich Dir mit der dann folgenden Ausführung recht.

Aber ich sehe das Problem so:
Die Interrupts sind zunächst in der Tat gesperrt. Wenn die HFC-Karten unter RTAI ausgelesen würden, könnte man das wohl auch ohne zu fürchtende Unterbrechung tun. Allerdings gibt Klaus-Peter Junghanns den Interrupt mit rt_pend_linux_irq an Linux weiter. Und damit ist es vorbei mit der real-time Umgebung und auch mit den gesperrten Interrupts.

Aus dem RTAI-Handbuch:

Code:

DESCRIPTION
rt_pend_linux_irq appends a Linux interrupt irq for processing in Linux IRQ mode, i.e. with hardware interrupts fully enabled.

Bevor also die HFC-Karte(n) tatsächlich ausgelesen werden (jetzt von der Routine hfc_interrupt mit "Linux-Priorität" und mit Interrupts enabled), kann alles mögliche andere passieren. Andere Interrupts können beispielsweise kommen, aber auch der timer kann nach einer Millisekunde erneut ausgelöst werden. Und dann wundert sich die routine hfc_interrupt (dort wird die HFC-Karte ausgelesen), dass viel mehr Daten zur Verfügung stehen als eigentlich erwartet werden.

In meinen Augen ist also immer noch das Problem, dass mit rt_pend_linux_irq die geschützte realtime-Umgebung verlassen wurde. Wie gesagt, jetzt kann allerhand auf dem System passieren bis die HFC-Karte ausgelesen wird. Und da wundert sich dann die Funktion hfc_interrupt und meckert.

Immerhin muss man sich ja auch überlegen, wie es zustande kommen kann, dass der Treiber gerne 8 Datenpakete aus der Karte auslesen möchte und statt dessen 24 oder noch mehr vorfindet (woraufhin er immerhin 16 oder mehr wegschmeissen muss). Das bedeutet doch, dass hier bis zum Auslesen der Karte 3 komplette Timerzyklen von jeweils einer Millisekunde vergangen sind. Das ist nun wirklich kein Pappenstil. Hier vergeht auf dem System offenbar richtig viel Zeit.

Meines Erachtens ist das nur dadurch abzustellen, dass die HFC-Karte noch unter real-time Bedingungen und gesperrten Interrupts ausgelesen wird. Wenn da erst lange gezögert wird, steht ja auf der Karte schon wieder das nächste Datenpaket zur Verfügung und hfc_interrupt ist wieder total überrascht, dass mehr Daten da sind als vom Programmierer vorausgesehen.


Anfügen möchte ich noch einen anderen Grund, weshalb die HFC-Karte meines Erachtens zwingend ohne Unterbrechung ausgelesen werden muss. Und zwar kann sich die Datenlage auf der Karte ändern während die Karte ausgelesen wird. Der Grund ist der gleiche wie oben angeführt. Wir starten die Routine und gehen von einer Anzahl n eingetroffener Daten aus. Aber zufällig werden wir von einem Interrupt unterbrochen, der dann erst abgearbeitet wird (oder RTAI übernimmt mal kurz wieder das Steuer). Wenn wir dann wieder "dran" sind, geht das Programm zwar von den zuvor bestimmten n eingetroffenen Datenpaketen aus - aber wer sagt denn, dass nicht inzwischen 1/8000 sek vergangen ist und evtl n+1 oder noch mehr Daten da sind? Die Funktion hfc_interrupt hat keine Ahnung, dass sie unterbrochen wurde, und geht nur von n aus. Und damit haben wir bereits ein Problem für die nächste Datenabfrage geschaffen.

 

Danke für den Hinweis zur Funktion rt_pend_linux_irq, habe da nicht genau nachgeschaut. Mit cli/sti sollte es jedoch innerhalb des HFC-Treibers möglich sein, Interrupts zu sperren!

Deiner Ausführung, daß der Treiber zumindest teilweise in einen Echtzeittreiber umgebaut werden sollte, kann ich nur voll zustimmen. Vielleicht (!!) werde ich mich da in den nächsten Wochen mal hinsetzen und etwas experiementieren; allerdings kennt mein Rechner das Problem mit überlaufenden Puffern nicht (zum Glück), weshalb ich dann auch nicht testen kann, ob es besser oder schlechter wird...

Gruß

 

Aber gerne doch!

Sag mal, Sion, hast Du Dir mal überlegt wie die ganze Sache mit einem timer wie im ztdummy (für Linux 2.6) aussehen könnte? Linux selbst hat ja mit Version 2.6 auch schon ordentlich in Richtung real-time Verwendbarkeit zugelegt. Durch den veränderten Scheduler und die neuen Timer sind ja jetzt auch 1000 Hertz timings möglich. Genau das eigentlich, was hier benötigt wird.

Und wenn man dem Gejubel der embedded-Jungs folgen mag, ist die latency im reinen 2.6 kernel auch nicht mehr soo schlecht. (Naja, nicht so gut wie mit RTAI natürlich. Aber für unsere Zwecke sollte das doch locker reichen)

Die Idee, die sich im Moment bei mir festgesetzt hat, ist folgende:
Wenn man anstelle von RTAI einen timer ala ztdummy nehmen würde, hätte man doch eigentlich das gleiche erreicht, wie jetzt mit RTAI. Anstelle von RTAI lässt man sich halt vom Linux timer aufwecken und dann geht man der Reihe nach die HFC-Karten durch. Wie gesagt, mit der neu gewonnenen Auflösung der Timer könnte das klappen.

[edit]Achtung, das folgende muss ich korrigieren: (nächster Beitrag)[/edit]
Letztlich hätte man doch gerne, dass die channels der HFC-Karten alle 1000 Mikrosekunden (1000 Hertz) bedient werden. Das ganze darf dann höchstens 125 Mikrsekunden dauern, da ja auf der Karte neue Daten mit 8000 Hertz zu Verfügung stehen. Also muss man sich bei einer Verzögerung entsprechend darum kümmern oder die Karten innerhalb der 125 Mikrosekunden "verarztet" haben.

Für den 2.4 Kernel habe ich immer noch Schreckenszahlen im Kopf, was die latency nach einem Interrupt anbelangt. Beim normalen 2.6 Kernel werden die Interrupts sehr viel schneller bedient als im 2.4er Kernel. Man kann wohl davon ausgehen, dass ein Treiber in Kernel 2.6 nach 12-15 Mikrosekunden definitiv in der Verarbeitung des Interrupts ist und die Sache nicht noch irgendwo hängen geblieben ist. Müsste also für unsere Zwecke passen, oder?

Ich persönlich meine, dass das insofern seinen Reiz hat, als man bei RTAI eigentlich nicht so genau weiss, welchen Teil der Gesamtapplikation man eigentlich noch real-time laufen lassen muss und welchen nicht mehr. Und dann hat man mit ein wenig Pech schnell ein Fass ohne Boden.

 

Ich wollte das sicherheitshalber noch einmal verifizieren und tat offenbar gut daran. So einfach wie ich das noch im Kopf hatte ist es nämlich auch wieder nicht.

Zum Thema habe ich glücklicherweise einen Artikel auf linuxdevices.com gefunden, in dem verschiedene latency Messungen beschrieben werden. Zum Vergleich kommen dort unter anderem Systeme mit RTAI/Kernel2.4 und Kernel 2.6 solo (Kernel 2.4 solo ist auch mit dabei).

Den vollständigen Artikel findet man unter dem obigen Link, hier nur einige wenige Abschnitte mit einigem, was für uns interessant ist:

Das Bild zeigt die Zeit, die von der Auslösung des Interrupts bis zur Ausführung der Internet Service Routine (ISR) vergeht. Mit 2.4 und 2.6 sind dabei die Kernel Versionen gemaint, RTAI ist Kernel 2.4 mit RTAI und LXRT ist eine andere real-time Umgebung. Die Autoren beschreiben "loaded" als "lightly loaded system and on a system under relatively heavy communications loading". Heavy communications ist für unsere Zwecke zwar vielleicht etwas übertrieben, aber ein wenig IAX, SIP, CAPI und weiss ich nicht noch für traffic kann auf dem Asterisk-System ja in der Tat noch vorkommen.

Für wen "cumulative percentage" fremd ist, gemessen werden hier sehr viele Reaktionszeiten auf einem Interrupt (d.h. bis die ISR aufgerufen wurde). Der kumulierte Prozentsatz gibt dann an, wieviele Reaktionszeiten kleiner oder gleich sind wie der auf der x-Achse angegebene Wert. Die Kurve geht demnach von 0 bis 100%, zu sehen ist der obere Ausschnitt ab 98%.

Man sieht schon, dass der Kernel 2.6 nicht ganz so schnell ist wie die anderen Systeme. Leider sind in dem gezeigten Zeitfenster auch noch nicht alle Interrupts bedient worden. Der Wert für 99.999% liegt übrigens erst bei 39.5 Mikrosekunden (RTAI: 15.5).

Man behalte im Hinterkopf, dass wir insgesamt 125 Mikrosekunden Zeit haben bis neue Daten auf der HFC-Karte ankommen und der zaphfc-Treiber deshalb möglicherweise in Verwirrung gerät und zu meckern beginnt.

Zusammenfassend ist sicherlich zu sagen, dass RTAI ohne Zweifel die beste Reaktionszeit bietet, aber mit dem Kernel 2.6 solo sollte es auch gehen - meine ich.


Übrigens hat Kernel 2.6 gegenüber 2.4 seine Vorteile, wenn man sich mal anschaut wann das die Daten übernehmende Programm zur Ausführung kommt. Aber das ist bei unserem 1000 Hertz-Timing (glaube ich) nicht mehr ganz so interessant und geht vermutlich eher in die Echo-Problematik ein (es sei denn man würde das halbe Asterisk als RTAI-Applikation umbasteln). Aber möglicherweise ist die bessere Reaktionszeit im verarbeitenden Programm es ja das, was die embedded-Leute am Kernel 2.6 schätzen?

 

Also mal langsam: Unter Echtzeitfähigkeit versteht man, daß ein System innerhalb festgeleter Zeiten auf Ereignisse Reagiert. Es wird unter weicher und harter Echtzeit (EZ)unterschieden: Bei weicher EZ ist ein Verstoß gegen die Vorgaben zwar erlaubt, aber die Nützlichkeit des Ergebnisses nimmt mit der Zeit ab; bei harter EZ darf es keinen Verstoß geben.

Die HFC-Karte ist, genauso wie z.B. Soundkarten, ein hartes EZ-System, da es sofort hörbar wird, wenn die Daten nicht rechtzeitig abgeholt/gesendet wurden (in unserem Fall besagte 125 µs).
Linux ist im allgemeinen dagegen (bestenfalls) ein weiches EZ-System, da es auf guten durchschnittlichen Durchsatz ausgelegt ist, und eben nicht auf garantierte Reaktionszeiten (=Latenz). Der 2.6er Linuxkernel ist dahingehend besser geworden, als daß er (entsprechend konfiguriert) nicht mehr so lange Interrupts blockiert, wodurch er eine kürzere Latenz haben kann. Aber es wird nichts garantiert, auch keine maximalen Reaktionszeiten! (Warum auf der von dir angesprochenen Seite der 2.6er immer langsamer als der 2.4er ist, weiß ich auch nicht...)

ztdummy hilft uns da leider auch nicht weiter, da auch er nichts garantieren kann, wenngleich er vielleicht die Zuverlässigkeit verbessern würde.

Bei RTAI werden Interrupts zuerst von den RTAI-Tasks bearbeitet, und zwar exklusiv (d.h. sie können nur von höherprioren RTAI-Tasks unterbrochen werden, falls vorhanden), erst danach bekommt Linux etwas von dem Interrupt mit. Dadurch kann eine maximale Latenz garantiert werden, es wird 100% "cumulative percentage" erreicht, und zwar bei realistischen Zeiten wie z.B. die 15,5µs; bei Linux werden die 100% niemals erreicht (zumindest theoretisch)!

Fazit: Um den Echtzeitanforderungen unter Linux zu genügen, müßte man entweder erreichen, daß Linux bei einem Timer-Interrupt zuerst den HFC-Treiber anspricht und keine Taskwechsel zuläßt (Änderungen am Kernel, schlecht!), oder man verwendet einen Treiber unter RTAI. Vermutlich würde es bei letzterem reichen, Daten von der Karte zu holen und in einen FIFO zu stecken (und umgekehrt für die Gegenrichtung); den Rest kann dann der normale Treiber übernehmen (sprich alle 8 Bytes die Daten an den Zaptel-Treiber weiterleiten).

Ich sehe keinen anderen Weg, die harten EZ-Anforderungen der Hardware zu erfüllen (ohne groß am Linux-Kernel herumzuschrauben, was doch etwas unsauber wäre).

Zum Schluß noch eine Ergänzung zu LXRT: Es handelt sich hierbei um einen Aufsatz auf RTAI, welcher "normale" Linux-Tasks echtzeitfähig macht - selbst, wenn diese nicht als root gestartet wurden! Dadurch erhöht sich die Latenz, aber man hat dafür so nette Dinge wie Speicherschutz und eine bessere Debug-Fähigkeit. Der Asterisk-Task sollte als solcher laufen, mit einer geringeren Priorität als der RTAI-HFC-Treiber. Dann gäbs wohl keine Timing-Probleme mehr (auch wenn er dann nur noch mit weicher EZ laufen würde, da er Systemaufrufe ausführt)...

Dann kann man gemütlich den Rechner PI auf beliebig viele Nachkommastellen berechnen lassen oder die E-Mails des Nachbarn entschlüsseln lassen, und das Telefon klingt trotzdem noch gut ;-)
(SPASS!!!)

Gruß, Sion


[edit] Man könnte natürlich den Treiber auch anders gestalten, um der ganzen Problematik etwas zu entgehen. Andere Treiber laufen ja auch wunderbar...ohne RTAI! Siehe Florz-Versionen![/edit]

 

Ich wollte gerade auf den florz-Patch hinweisen - selbiger erfuellt hier seinen Dienst einwandfrei, und das auch auf vergleichsweise langsamer Hardware (K6-266) mit zwei HFC-Karten. Probleme, die ich frueher mit bristuff-0.0.2RCirgendwas bezueglich ueberlaufender RX/TX-Puffer hatte, sind jetzt verschwunden - wobei das zugegebenermassen auch durch Aenderungen an der Hardware (vorher: Cyrix MediaGX 300 MHz mit einer HFC-S) oder die allgemein aktualisierte bristuff-Version kommen koennte.

 

Ui, das ist schön geschrieben, Sion!

Ich denke, dass ich weitgehend Deiner Meinung bin.

Lass mich kurz die Sache mit ztdummy aufgreifen und klarstellen was ich da meinte. Die Grundfrage, ich ich mir stellte, war im wesentlichen, ob RTAI soviel Nutzen schafft, dass man es unbedingt installieren muss. Letztlich wird RTAI im Moment ja de facto nur wie ein Timer verwendet und die HFC-Karten dann der Reihe nach abgefragt. Dass da meiner Meinung nach in der Implementierung zu kurz gesprungen wurde, haben wir ja zuvor schon diskutiert und soll im Moment mal keine Rolle spielen.

Ich stelle mir jetzt die Frage, ob so etwas auch mit einem ztdummy-artigen timer zu bewerkstelligen ist. Die Timer-Auflösung ist ja in Kernel 2.6 wesentlich verbessert worden und ein 1000 Hertz-Takt ist jetzt möglich (und im neuen ztdummy auch implementiert worden). Wenn man nun in zaphfc anstelle von RTAI einen timer ala ztdummy verwenden würde, hätte man eine ähnliche Struktur im zaphfc (d.h. man sollte einen überschaubar großen patch hinbekommen).

Nach Studium des vorher angegebenen Schaubildes meine ich doch irgendwie, dass man es auch unter 2.6 innerhalb von 125 Mikrosekunden hinbekommen sollte, dass der Treiber auf dem timer-Interrupt reagiert (wie gesagt, Zeiten siehe Schaubild oben) und im direkten Anschluss daran alle HFC-Karten abarbeiten, fertig. Damit liegt die Interrupt-Last auch nur noch bei 1000 timer-Interrupts und sollte den PC nicht überlasten.

So in etwa stelle ich mir eine "Billig-Lösung" für die HFC-Karten vor. Der Vorteil läge aber eher in solchen Faktoren wie vereinfachter Installation (da auf RTAI verzichtet würde). Technisch hochwertiger wäre es natürlich, Asterisk wirklich ganz unter RTAI laufen zu lassen. Aber da müsste man wohl einiges mehr an Arbeit investieren.

Übrigens habe ich Klaus-Peter Junghanns auf der CeBit ganz kurz auf ztdummy angesprochen. In dem allerdings sehr kurzen Gespräch hatte ich schwer den Eindruck, dass er die veränderten Timer in Kernel 2.6 gar nicht kannte. Er ging aus, dass noch immer die Abhängigkeit vom USB-Chip besteht. Ich hatte ihm dann noch eine Email mit einer Quellenangabe geschickt aber irgendwie hält er eine kurze Antwort wohl für überflüssig.


Was den Florz-Patch anbelangt muss ich ehrlich zugeben, dass ich mich damit noch nicht auseinander gesetzt habe - obwohl ich ihn auf meinem Produktions-Asterisk benutze . Hat jemand zufällig eine Quelle für eine kurze Erläuterung parat?