zaphfc: dropped audio & bchan rx fifo not enough bytes

[otaku42]

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?

http://zaphfc.florz.dyndns.org duerfte wohl die beste verfuegbare Quelle sein

 

[fly-a-lot]

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!

Hallo Sion,

man müsste mal ausprobieren welche Funktion cli/sti unter RTAI überhaupt noch hat, denn (aus RTAI-Handbuch):

The Linux task can never block interrupts or prevent itself from being preempted. The mechanism that makes this possible is the software emulation of interrupt control hardware. When any code in Linux tries to disable interrupts, the real time system intercepts the request, records it, and returns it to Linux. In fact, Linux is not permitted to ever really disable hardware interrupts, and hence, regardless of the state of Linux, it cannot add latency to the interrupt response time of the real time system. When an interrupt occurs, the real time kernel intercepts the interrupt and decides what to dispatch. If there is a real time handler for the interrupt, the appropriate handler is invoked. If there is no real time interrupt handler, or if the handler indicates that it wants to share the interrupt with Linux, then the interrupt is marked as pending. If Linux has requested that interrupts be enabled, any pending interrupts are enabled, and the appropriate Linux interrupt handler invoked - with hardware interrupts re-enabled. Regardless of the state of Linux: running in kernel mode; running a user process; disabling or enabling interrupts; the real-time system is always able to respond to an interrupt.

Es wird also auch darauf ankommen wie genau cli/sti implementiert sind, d.h. wie und ob diese Funktionen unter RTAI überhaupt arbeiten.

 

[fly-a-lot]

http://zaphfc.florz.dyndns.org duerfte wohl die beste verfuegbare Quelle sein

Au Danke!
Das schaue ich mir doch gerne mal an.

 

[fly-a-lot]

Ach je, das war ja das Ding mit der Löterei...

Ehrlich gesagt würde ich mir das diesmal gerne ersparen und neige daher erst einmal einer Software-Lösung zu. Aber sicher, wenn das softwaremäßig nicht anständig zu machen ist werde ich wohl doch wieder meinen Lötkolben suchen.

aber ich werde mal das "Interrupt-Bundling" ausprobieren ohne die Karten "synchron zu löten." Mal schauen wie weit man damit schon kommen kann.

 

[otaku42]

Florz hatte mir gesagt, dass die Loeterei nicht unbedingt notwendig ist und man in der Regel auch ohne Hardware-Synchronisierung relativ gut leben kann. Soweit er weiss, werden die auseinanderlaufenden Queues fuer jeden Anruf neu angelegt, sodass die Probleme eher bei sehr langen Verbindungen auftauchen. Dazu kommt, dass sein Interrupt-Bundling die De-synchronisierung als solche ja schon gut in Grenzen haelt.

 

[lo4dro]

Löterei?
Könnt das jemand mal genauer erklären?
Ich nutz den Patch ohne das ich etwas an der Hardware geändert habe und bin mit dem Ergebniss bis jetzt sehr zufrieden.

 

[fly-a-lot]

Löterei?
Könnt das jemand mal genauer erklären?
Ich nutz den Patch ohne das ich etwas an der Hardware geändert habe und bin mit dem Ergebniss bis jetzt sehr zufrieden.

Ja, das hätte ich in der Tat anders ausdrücken sollen.
Florian Zumbiehl (Florz) hat sich mit dem Treiber richtig viel Mühe gemacht und gleich mehrere Verbesserungen eingebaut. Ein Feature besteht in der Taktsynchronisation der HFC-Karten. Dabei muss eine Verbindung zwischen den Karten hergestellt werden. Aber wie otaku42 schon sagte, man kann den Patch (d.h. die anderen Softwareänderungen) auch nutzen ohne eine Verbindung zwischen den Karten anzulöten.

Sorry!

 

[otaku42]

Löterei? Könnt das jemand mal genauer erklären?

Gucksu hier im Abschnitt "Slave Mode" ("What is it good for?" und "How does it work?"). Wie gesagt, man muss es nicht unbedingt machen, aber die Option besteht, und das ist ja manchmal ganz gut zu wissen

 

[fly-a-lot]

Ich habe den Florz-Patch heute übrigens mal mit einem Kernel 2.6 und bristuff-0.2.0-RC8 getestet. Kann über die Qualität bisher nicht viel sagen. Ich hatte gegenüber vorher (d.h. 0.2.0-RC8 ohne Florz-Patch) sowohl bessere als auch schlechtere Verbindungen.

Allerdings ist die hohe Fehlerrate in dmesg bzw. /var/log/messages anschließend noch auffälliger geworden.

Nun arbeitet zaphfc mit Florz-Patch ja wieder mit den vollen 8000 Interrupts pro Sekunde. Und mit den anfallenden Arbeiten in zaphfc (im Florz-Patch passiert ja auch noch etwas mehr als im Original-zaphfc) scheint mein Rechner in der Zeitvorgabe von 125 Mikrosekunden überfordert zu sein, was zu entsprechend vielen "buffer overflows" und "underruns" führt.


Also wenn ich mir das alles so anschaue, komme ich doch immer mehr zu der Überzeugung, dass der Kernel 2.6 alleine nicht in der Lage zu sein scheint die 8000 Interrupts/sek fehlerfrei zu bearbeiten. Damit meine ich in erster Linie, dass es ganz offenbar ziemlich häufig Situationen auf der Maschine zu geben scheint, in denen 125 Mikrosekunden "Bearbeitungszeit" ganz offenbar nicht ausreichen. (Damit ist übrigens auch meine vorherige Idee erledigt, dass man es mal mit einem Timer ala ztdummy unter Kernel 2.6 ohne RTAI probieren könnte)

In der Tat scheint es mir nur zwei Wege zu geben, das Problem in den Griff zu bekommen. Einmal kann man versuchen, die Schreib- und Lese-Puffer weniger hektisch zu bearbeiten (ich habe noch nicht gesehen ob Florz so etwas in der Richtung tut - d.h. man genehmigt einige Takte Vorlauf und rechnet damit, dass man beim nächsten Mal aufgehalten werden könnte nicht rechtzeitig zurück sein kann). Andererseits kann man die Reaktionszeit des Systems verbessern und den real-time Weg mit RTAI oder einem anderen real-time System gehen. Aber langsam dämmert mir, dass für eine fehlerfreie Bearbeitung zunächst wohl kein Weg an RTAI oder etwas ähnlichem vorbeiführt. Anschliessend wird man wohl noch einmal checken müssen, ob man dann nicht auch noch die Fehleranfälligkeit ala Florz in Angriff nehmen muss.

 

[lo4dro]

zum Kernel 2.6.x gibt es eine Aussage von Alan Cox. Das der Hz Wert von 1000 für älter CPUs nicht gut/geeignet ist.
Deswegen hab ich den 2.6.10-AC12 Kernel genommen.
Dort kann man den Hz Wert wider auf 100 umstellen so wie das bei den 2.4.x Kernel ist.

Ich habe zwar immer noch gelegendlich so ein buffer "overflows" und "underruns" aber man hört nichts. Ich kann sogar FAXe verschicken.


http://www.kernel.org/pub/linux/kernel/people/alan/linux-2.6/2.6.10/patch-2.6.10-ac12.bz2

 

[sion]

Hallo fly-a-lot,

zum ztdummy-Treiber kann ich leider nicht viel sagen, es scheint jedoch eine mögliche Timer-Quelle zu sein. Aber es bleibt das folgende Problem: Du weißt nicht wie viel Zeit vom Interrupt vergeht bis der HFC-Treiber tatsächlich aufgerufen wird, und er kann sogar u.U. in seiner Bearbeitung unterbrochen werden.

Meine Anmerkungen dazu, man könne ihn ja mit cli/sti davor schützen, haben sich nicht auf RTAI bezogen! Dieses interessiert sich in erster Linie überhaupt nicht für sti/cli, sondern das wird von dem darunterliegenden Adeos abgefangen und in Software simuliert (erfolgt zur Compilier-Zeit). RTAI-Tasks sollten das jedoch niemals verwenden, weil das dem Prinzip des prioritätsgesteuerten Echtzeitsystems widerspricht.

Das hat mich gestern auf eine andere Idee gebracht: Man könnte den Treiber in eine Adeos-Domain packen, der jeden Timer-Interrupt (mit 1kHz) vor dem Linux-Kernel bekommt. Das wäre genau die Anwendung für Adeos! Dann muß man nur noch irgendwie die Daten an den Kernel weitergeben (sollte nicht so schwer sein), und das wars.
Somit hast du eine minimale Latenz (kein/minimalen Jitter), und kannst nicht durch weitere Interrupts unterbrochen werden

Und man muß "nur" Adeos in den Kernel einpatchen, und nicht noch RTAI laden. Ist quasi ein "Echtzeitsystem für Arme" ;-)

 

[sion]

Noch eine kleine Anmerkung zum Original-HFC-Treiber: Dieser bekommt mit 8kHz Interrupts, holt sich jedoch nur jedes 8. mal Daten von der Karte. Wenn dann zu viele / zu wenige Daten vorhanden sind, bricht er in Panik aus.
Wäre es nicht klüger, jedes mal Daten zu holen (falls vorhanden) und diese zu sammeln, und diese in 8er-Päckchen weiterzureichen?! (Schätze, ZAPTEL will es so....)
Damit hätte man auch das Problem gelöst, daß manchmal Interrupts verlohren gehen und dadurch der effektive FIFO kleiner wird (ist auf der FLORZ-Seite schön beschrieben).

Ich rede von folgenden Zeilen:

#ifndef RTAITIMING
if (hfctmp->ticks > 7) {
// welcome to zaptel timing
#endif

 

[fly-a-lot]

Das wäre genau die Anwendung für Adeos! Dann muß man nur noch irgendwie die Daten an den Kernel weitergeben (sollte nicht so schwer sein), und das wars.

Allerdings fürchte ich, dass genau hier die Probleme anfangen werden...

 

[fly-a-lot]

Moment mal,

ich sehe gerade, dass Klaus-Peter Junghanns in bristuff 0.2.0-RC8a bezüglich RTAI etwas wesentliches geändert hat!

Das von RTAI gerufene rtai_loop() ruft jetzt direkt das ehemalige hfc_interrupt (heisst jetzt hfc_service) auf, d.h. der Umweg über den Linux-Kernel scheint weg zu sein. Nach erstem Anschein sollte damit also zumindest mal der Fehler aus der Welt sein, dass hfc_interrupt mit allen interrupts enabled läuft.

Na jetzt bin ich ja mal gespannt!
Jetzt weiss ich zumindest was ich mache, wenn ich wieder zuhause bin. RTAI wieder installieren und mal mit RC8a testen :ziggi:

 

[sion]

Ach naja muß nicht sein... da beide Anwendungen im gleichen Adressraum sind kann man ja beim Starten einen gemeinsamen Speicher mit kalloc einrichten (=shared memory) und muß dann halbwegs geschickt mit int's signalisieren, was davon geschrieben/gelesen wurde (damit man sich semaphore sparen kann, da int's immer als ganzes schrieben und gelesen werden).

 

[fly-a-lot]

Na jetzt bin ich ja mal gespannt!
Jetzt weiss ich zumindest was ich mache, wenn ich wieder zuhause bin. RTAI wieder installieren und mal mit RC8a testen :ziggi:

OK, die Sache mit den buffer overflows und underruns scheint jetzt erledigt zu sein. Ich habe zumindest auf auf meinem betagten 700 MHz Pentium 3 keine einzige Fehlermeldung dieser Art mehr - und das in einem Zeitraum, in dem ich früher reichlich Gemecker vom zaphfc zu lesen bekommen habe (/var/log/messages oder dmesg). Die Änderung bei der Abarbeitung der HFC-Karten, die Klaus-Peter Junghanns in bristuff-0.2.0-RC8a gemacht hat, scheint also geklappt zu haben. zaphfc unter RTAI scheint jetzt tatsächlich keine oder sehr viel weniger timing-Probleme zu haben als ohne RTAI.

Die einzige Fehlermeldung, die ich noch ab und zu sehe ist die "empty HDLC frame or bad CRC received" (2 in einer Stunde). Mal abwarten wie sich das entwickelt...


Allerdings habe ich jetzt wieder das Problem, dass das Echo sehr viel stärker geworden ist. Zumindest mit den Einstellungen, die ich zuvor mit bristuff-0.2.0-RC8 ohne RTAI und mit Florz-Patch verwendet hatte, komme ich jetzt nicht mehr zurecht (echocancel=yes, echotraining=yes, echocancelwhenbridged=no). Schade eigentlich. Möglicherweise "klemmt" es jetzt in einem späteren Glied der Kette?

 

[fly-a-lot]

Allerdings habe ich jetzt wieder das Problem, dass das Echo sehr viel stärker geworden ist. Zumindest mit den Einstellungen, die ich zuvor mit bristuff-0.2.0-RC8 ohne RTAI und mit Florz-Patch verwendet hatte, komme ich jetzt nicht mehr zurecht (echocancel=yes, echotraining=yes, echocancelwhenbridged=no).

Oje,
jetzt habe ich es mal mit echotraining=800 probiert und bekomme trotzdem ein so großes Echo, dass das System in dieser Form unbrauchbar ist.

Aber ich glaube, die Echo-Geschichte bereden wir besser in einem separaten Thread.

 

[sion]

Hey du Doppelposter (sorry die Stichelei konnte ich mir jetzt nicht verkneifen),

schön daß Herr Junghanns jetzt den Treiber richtig benutzt und die RX-Fehler weg sind
Ist natürlich ziemlich blöde, daß du jetzt viele Echos bekommst. Vielleicht hilft dir ja der Echo-Patch weiter, siehe http://www.ip-phone-forum.de/forum/viewtopic.php?t=4572
Denke außerdem, daß echocancelwhenbridged an sein sollte!

Gruß & viel Erfolg,
Sion

 

[fly-a-lot]

Hey du Doppelposter (sorry die Stichelei konnte ich mir jetzt nicht verkneifen)

Ok, da hätte ich editieren sollen. Sorry!

schön daß Herr Junghanns jetzt den Treiber richtig benutzt und die RX-Fehler weg sind

Die RX-Fehler sind in der Tat komplett weg.
Dafür habe ich jetzt auf einmal alle paar Minuten mal ein "bchan tx fifo full". Wenn ich mich nicht täusche, tauchte das aber erst auf nachdem ich mal testweise telefoniert hatte.

Ist natürlich ziemlich blöde, daß du jetzt viele Echos bekommst. Vielleicht hilft dir ja der Echo-Patch weiter, siehe http://www.ip-phone-forum.de/forum/viewtopic.php?t=4572

Aha, ich dachte irgendwo aufgeschnappt zu haben, dass der Patch nicht mehr erforderlich sei weil der Bug behoben wurde oder so ähnlich. Aber ich werde dem mal nachgehen. Danke für den Hinweis.

Übrigens bin ich mir fast sicher, dass das Echo von der zaptel/zaphfc-Kombination herrührt. Wenn ich nämlich intern von einem IP-Phone zu einem internen ISDN-Anschluss telefoniere (d.h. beide am gleichen Asterisk angeschlossen), höre ich am IP-Phone ein Echo, während am ISDN-Telefon alles in Ordnung ist. Wenn ich hingegen über eine ganz separate Leitung von außen über das öffentliche Telefonnetz anrufe, d.h. über eine HFC-Karte im TE-Modus in das Asterisk-System hineinkomme und den Anruf mit einem internen ISDN-Phone annehme (welches an einer anderen HFC-Karte im NT-Modus im gleichen Asterisk-System hängt), haben beide Seiten ein ordentliches Echo.

Obwohl noch einige andere Tests ausstehen (insbesondere Einwahl über SIP und Gesprächsannahme am internen ISDN und Einwahl über PSTN und Gesprächsannahme am internen IP-Phone) ist meines Erachtens davon auszugehen, dass das Echo irgendwo im zaptel/zaphfc-Bereich erzeugt wird. Aber sicherheitshalber werde ich das noch testen...