BRI_STUFF - neue (vorab)Version

[thorsten.gehrig]

Hallo
nachdem schon einige auf die BRI_STUFF 0.0.3 warten hab ich heute in der Mailingliste einen Hinweiß bekommen - und siehe da:
http://www.junghanns.net/asterisk/downloads/
gibt es
http://www.junghanns.net/asterisk/downloads/bri-stuff-0.1.0-RC1.tar.gz
mit datum vom 15.7.2004

Es baut auf folgenden Versionen auf:
cvs co -D 05/27/04 zaptel
cvs co -D 07/14/04 libpri
cvs co -D 07/14/04 asterisk

dazu gibt es noch die
http://www.junghanns.net/asterisk/downloads/chan_capi.0.3.4a.tar.gz

ich schau mir mal beide an - vielleicht sollten wir hier (in diesem Thread) unsere erfahrungen sammeln....

Gruß
Thorsten

 

[Hupe]

dazu gibt es noch die
http://www.junghanns.net/asterisk/downloads/chan_capi.0.3.4a.tar.gz

Die ist n alter Hut. Funzt bei mir seid n paar Wochen ohne Probleme.

 

[thorsten.gehrig]

Yo,
bei chan_capi habe ich jun und jul verwechselt - ich dachte das währe beides vom selben datum...
gruß
thorsten

 

[dg8lav]

bri-stuff-0.1.0-RC1.tar.gz
mit datum vom 15.7.2004

cvs co -D 05/27/04 zaptel
cvs co -D 07/14/04 libpri
cvs co -D 07/14/04 asterisk

das obige habe ich gerade compiliert und installiert. CAPI brauche ich nicht, weil ich eine QuadBri von Junghanns mit qozap/zaptel Treiber benutze.

Als Addon habe ich noch Brian's: app_dbodbc.c hinzugefügt. Ich konfiguriere alle extensions aus einer mysql datenbank via odbc.

Die gesamte Aktion hat 10 Minuten gedauert und Asterisk läuft tadellos.

 

[otaku42]

Laesst sich bei mir einwandfrei installieren.

Meine konkreten Erfahrungen im Zusammenhang mit der neuen zaphfc-Version:

Positiv:
Meine HFC-Karte (Typhoon) wird jetzt ohne, dass ich die PCI-ID einpatchen muesste, erkannt.

Negativ:
Das Problem " bchan rx fifo not enough bytes" ist noch immer vorhanden. Die Haeufigkeit der Meldungen ist identisch zu zaphfc aus bristuff-0.0.2, dafuer scheint er jetzt die fraglichen Pakete zu verwerfen. Entsprechend bescheiden ist die Audioqualitaet beim telefonieren: es knackt dauernd, die Sprache wird "zerloechert".

Ich schaue mir mal an, ob das Problem mit bristuff-0.0.2a-pp behoben ist (in den Changes wird es jedenfalls angedeutet) und versuche ggf., den noetigen Patch zu "portieren".

Ciao, Mike

 

[Blackvel]

Nein, ist es nicht.
Mit bristuff-0.0.2a-pp kriegst Du dann auch keine eingehenden Calls mehr z.B Sipgate da insecure=very einen Bug hat, der 3-5 Versionen später durch verschiedene Patches behoben wurde.

 

[otaku42]

Nein, ist es nicht.

Das habe ich auch bemerkt

Das Problem blieb bestehen, und zwar in aehnlicher Form wie bei 0.1.0RC1. Als ich wieder auf den Build zurueckgegangen bin, der von bristuff-0.0.2 erzeugt wurde, ist die Meldung zwar immer noch da gewesen, jedoch waren die Audio-Aussetzer nicht mehr vorhanden.

Aufgefallen ist mir allerdings, dass die Meldungen immer dann aufzutauchen scheinen, wenn Netzwerkkarten-Aktivitaet vorliegt. Das Netzwerkinterface ist fest auf dem Motherboard integriert, und der einzige vorhandene PCI-Slot scheint den selben IRQ-Pin zu verwenden, der auch fuer die Netzwerkkarte verwendet wird. Zwar unterscheiden sich die IRQs (11 fuers LAN, 15 fuer die HFC-Karte - nein, IRQ15 ist nicht fuer den zweiten IDE-Kanal belegt, es ist nur einer vorhanden), aber das scheint trotzdem Probleme zu machen.

Ich werde Asterisk spaeter mal testweise auf einer alten P90-Kiste installieren und sehen, ob das Problem dort auch auftritt.

Ciao, Mike

 

[Blackvel]

Also ich telefoniere mit 0.1.0RC1 und es ist nicht schlechter geworden (mein subjektiver Eindruck).
Allerdings möchte ich lieber keinen Vergleich mit chan_capi machen.

Ich hatte bis dato niemals bristuff 0.0.2 + CVS Stable ausprobiert.

 

[otaku42]

Die aktuellen Erkenntnisse zum "rx fifo not enough bytes"-Problem:

• Die oben erwaehnten Tests mit einem P90 verliefen nicht wirklich gut. Die besagte Meldung war dort kaum zu sehen, dafuer war die Audiowiedergabe verlangsamt (etwa so, als wuerde man eine Schallplatte zu langsam abspielen). In einem P2-233 war die langsame Audio-Ausgabe weniger dramatisch, dafuer war die Meldung aber ebenso haeufig zu sehen wie auf dem Ursprungssystem.
  
• Meine Diagnose, dass die Meldung immer dann auftaucht, wenn ein Netzwerkzugriff erfolgt, war verkehrt. Richtig ist, dass sie immer dann auftaucht, wenn die Festplatte aktiv wird.
  
• Laut einem User bei #asterisk scheint die Haeufigkeit des Auftretens dieser Meldung auch mit der Karte selbst zusammenzuhaengen. Die Typhoon TAS106H (das ist die gleiche Karte, die ich auch verwende) brachte bei ihm die Meldungen deutlich haeufiger als eine HFC-Karte von Billion.
  
• Die Meldung selbst ist harmlos. Mich irritierte die Prioritaet KERN_CRIT in der printk-Anweisung, mit der die Meldung vom zaphfc-Treiber ausgegeben wird. Scheinbar verwendet kapejod diese Prioritaet aber standardmaessig fuer alle Ausgaben, auch solche, die eigentlich nur Hilfestellung beim Debugging geben sollen.
  
• Die Meldung bedeutet, soweit ich verstanden habe, "lediglich", dass ein Paket ueber den B-Kanal haette empfangen werden sollen, im FIFO aber kein Platz mehr vorhanden ist. Es geht dabei um Audiodaten, die vom ISDN-Telefon in Richtung Asterisk geschickt werden, betrifft also "meine Sprache", die mein Gespraechspartner hoeren wuerde.
  Die Ursache ist wahrscheinlich, dass durch die oben genannten Festplattenzugriffe die Latenz bei der Verarbeitung von IRQs zu hoch ist und deswegen die FIFOs der Karte volllaufen. Ich werde daher mal mein Glueck mit den verschiedenen Patches ausprobieren, die die IRQ-Latenz verringern sollen.
  
• Die verworfenen Audiopakete, die ich beim Test der 0.1.0RC1 festgestellt habe, scheinen durch eine Aenderung beim FIFO-Management zu kommen. Ich bin mir noch nicht sicher, welchen Sinn diese Aenderung ueberhaupt hat - sie ist auch bei 0.0.2a-pp zu finden, und dort wird auf einen Patch von Tim Robinson verwiesen, den ich aber im Mailinglistenarchiv nicht finden konnte...

Mehr demnaechst an dieser Stelle

Ciao, Mike

 

[otaku42]

*grummel*
Ich habe einen Kernel mit Low-Latency, Preemption und HZ=512 compiliert, was das Problem schonmal nicht beseitigt hat. Bleiben folgende Ideen:

• Der Code, der letztlich zu der Meldung fuehrt, ist falsch, und es liegt eigentlich kein Engpass vor. Das glaube ich allerdings weniger.
  
• Meine Interpretation des betreffenden Codeabschnittes ist verkehrt. Das ist schon wahrscheinlicher als der erste Punkt, insgesamt aber auch nicht uebermaessig wahrscheinlich.
  
• Die Zeit, die der Treiber in der Interrupt Service Routine verbringt, ist zu gross. Das duerfte eines der Hauptprobleme sein. Insgesamt wird dort zu viel Kram erledigt. Es waere vielleicht sinnvoller, die im RX-Fifo haengenden Daten erst einmal aus dem Fifo rauszuholen und dann erst weiter zu verarbeiten. Die Wahrscheinlichkeit fuer einen Ueberlauf des Fifo wuerde dadurch verringert. Allerdings bezweifle ich, dass ich das so ohne weiteres hinbekomme...

We'll see... das wird mich wohl noch einige Zeit kosten. Aber immerhin funktioniert die 0.0.2 mit brauchbarer Audioqualitaet, trotz der Meldungen. Das ist schonmal etwas.

Ciao, Mike

 

[otaku42]

Die beschriebenen Probleme sind seit bri-stuff 0.1.0 RC2i nicht mehr vorhanden. Es war wohl ein Problem mit zaphfc, bei dem die Laenge der im FIFO wartenden Audiodaten falsch berechnet wurde.

Ciao, Mike

 

[Blackvel]

HAR HAR HAR.
Wohl endlich meine Knackser-Probleme behoben ?
Otaku Du bist der Grösste

Ich probier's gleich mal aus!

 

[otaku42]

Ich habe eigentlich nicht viel mehr dazu beigetragen als kapejod lange genug zu nerven. Er hatte sich wohl auf meine letzte Mail hin den Source von hfc_brecv() nochmal naeher angesehen und dabei auch die Ursache gefunden...

Interessant finde ich aber, dass der alte Buffer-Wrap-Code das jetzt behobene Problem zumindest so weit kaschiert, dass die Audio-Beeintraechtigungen nicht mehr so deutlich zu bemerken sind.

Aber egal... hauptsache, es funktioniert jetzt endlich (tut es zumindest bei mir)

Ciao, Mike