*, bristuff-0.3.0-PRE-1k, florz 1f

ulus

Neuer User
Mitglied seit
22 Mai 2005
Beiträge
10
Punkte für Reaktionen
0
Punkte
0
Hallo,

ich versuche folgende Kombination zum Laufen zu bringen:
Debian 3.1 mit Kernel 2.6.15.3 sowie bristuff 0.3.0-PRE-1k und zaphfc_0.3.0-PRE-1f_florz-11.
Zunächst habe ich es ohne den Patch probiert. Bei Karten generieren je 8k Interrupts. Dann die Quellen gepacht. Jetzt macht nur noch eine Karte 8000 Interrupts. Mit timer_card=0 bzw. 1 kann ich "zwsichen den Karten hin- und herschalten". Die Konfigs in zaptel.conf und zapata.conf habe ich schon x-mal geprüft. Bei Karten befinden sich im TE-Modus. Ist auch so gewollt. Eine Karte ist mit dem S0-Bus einer Hicom 3000 verbunden.
Wenn ich die Anmerkung auf Florians Seite richtig interpretiere, dann gibt es nicht zwangsläufig einen neuen Patch bei neuer bristuff.
Damit überhaupt was läuft habe ich den Aufruf des Kernel-Loggers in zaphfc.c auskommentiert.
Probleme traten im ungepatchten Zustand bei eingehenden Anrufen auf dem S0-Bus auf. Ein Anruf wird sowohl durch die HICOM/Anlagentelefon als auch durch asterisk/SIP-Telefon signalisiert (Telefone klingeln gleichzeitig). Allerdings bekamm der Anrufer kein Freizeichen. Die Signaliserung der HICOM war total gestört. Nach Auflegen des Anrufers erfolgte erst ein Klingeln des Anlagentelefons. Aufgefallen ist dies erst nach einem Tag. Da das SIP-Telefon bei mir im Büro steht, schien alles in Ordnung zu sein. Tatsächlich nehme ich die Gespräche nicht an. Anrufe auf "meiner" Extension haben problemlos funktioniert.
Gespräche per sipgate/ISDN waren möglich. Aktuell fahre ich wieder gepacht, allerdings habe ich die HICOM Extensions auskommentiert.
Achja, mit der 1.0.9 respektive der damaligen bristuff hatte ich die Probleme nicht. weder die Interrupts noch die Probleme mit den Anrufen.
Hat jemand einen Tip für mich bzw. wird es einen neuen florz-Patch geben?
Auf der Seite von kombjuter scheint es fast so. Allerdings geht der Link ins Leere.

Gruß
Gerd
 
ulus schrieb:
Hat jemand einen Tip für mich bzw. wird es einen neuen florz-Patch geben?
Auf der Seite von kombjuter scheint es fast so. Allerdings geht der Link ins
Der Quellcode für den zaphfc Treiber hat sich schon eine ganze Weile nicht mehr geändert, deswegen kann mann auch die alten Versionen weiter benutzen, mann muss höchstens die Zaptelpfade anpassen.
Steht alles hier
http://www.ip-phone-forum.de/showthread.php?t=73787
kombjuter hat dies soweit ich weiß auch so gemacht.

PS: Editier mal deinen Beitrag etwas (Absätze, etc) damit er für alle etwas leichter zu lesen wird.

Damit überhaupt was läuft habe ich den Aufruf des Kernel-Loggers in zaphfc.c auskommentiert.
Hatte ich vorkurzem schon einziges mal hier gelesen, aber eigentlich nicht nötig. Was passiert denn genau wenn die Logaufrufe in zaphfc sind?
 
Die Pfade hatte ich angepasst. Meiner Meinung nach sieht man es auch daran, dass der Patch "zur Hälfte" wirkt. Interrupts nur noch auf einer Karte, aber immer noch 8000/s. Erwartet hättet ich so um die 500.

Mit aktiviertem Kernel-Logger bekomme ich die bekannten overflow/underrun Probleme, die schon in etlichen Beiträgen bahandelt wurden. Hohe Last, große Logfiles....
Alles wie aus anderen Beiträgen bekannt.
Mit der bristuff-0.2.0-RC8j hatte ich die Probleme nicht. Vielleicht ist das die Ursache für den etwas verwirrt wirkenden Artikel :-)

Gruß
Gerd
 
ulus schrieb:
Interrupts nur noch auf einer Karte, aber immer noch 8000/s. Erwartet hättet ich so um die 500.

Das ist ok so! Der Florz-Patch kann die Zahl der IO's nicht runtersetzen, aber sie auf eine Karte beschränken. Damit habe ich hier einmal 8000 statt 3 mal 8000.

Wenn du die Zahl der IO's runter haben willst, brauchst du ein Kernel das mit weniger als 1000 Hz läuft. Anleitungen dazu findest du im Internet.
 
Ich habe eben den Patch http://www.asterisk.li/download/zaphfc_0.3.0-PRE-1k_florz-11.diff.gz
von kombjuders Seite gezogen, zaphfc geleert, bristuff neu entpackt, gepatcht, kompiliert, installiert, gebootet und die Module geladen.
Anschließend sofort procinfo -d -n1 gestartet.
Nach ca. 5s fielen die Interrupts von 8000 auf ca. 490. (schwankt etwas)
Liegt das an der gestiegenen load durch die Log-Prozesse.
Am Kernel habe ich nix geändert, außer das ich einige Module raus geschmiessen habe, die ich garantiert nie benötige.
Es gibt keine gesharten Interrupts. An HW ist alles unnötige im BIOS deaktiviert. Kein APCI im Kernel.

@kombjuder: der Link auf der Download-Seite ist nicht richtig. typo: - _

Gruß
Gerd
 
ulus schrieb:
@kombjuder: der Link auf der Download-Seite ist nicht richtig. typo: - _

Danke Gerd, ist berichtigt.

Gruß

Karl-Heinz
 
Habe nun die Aufrufe des Kernel-Loggers auskommentiert.
Im Ergebnis habe ich fast keine Last mehr auf dem System und eine Karte macht 8000 Interrupts.
Nun macht mir nur noch die Tatsache Sorgen, dass das eigentlich nicht notwendig sein sollte.

Gibt's irgend eine Empfehlung?

Gruß

Gerd
 
ulus schrieb:
Habe nun die Aufrufe des Kernel-Loggers auskommentiert.
Im Ergebnis habe ich fast keine Last mehr auf dem System und eine Karte macht 8000 Interrupts.
Nun macht mir nur noch die Tatsache Sorgen, dass das eigentlich nicht notwendig sein sollte.
Ich hatte noch nie weniger mit bristuff+zaphfc.
Allerdings habe ich so gut wie keine Meldung von zaphfc, vielleicht mal eine am Tag.
Aber dafür das Problem:
http://www.ip-phone-forum.de/showthread.php?t=92940
also läuft auch nicht so rund, aber sonst habe ich keine Probleme, also keine Aussetzer oder hohe allgemeine Systemlast.
(PIII 550 MHZ, 384 MB , BX Chipsatz, ACPI aber kein APIC: Systemlast immer unter 10% bei Asterisk)
 
>>Habe nun die Aufrufe des Kernel-Loggers auskommentiert.<<

Wie kann man den den Kernel-Logger auskommentieren? Ich habe auch 8000 Interrupts / Sekunde und vor allem eine Last von 1.0 bis 1.5 bei einem Epia-System. Wenn das Auskommentieren des Kernel-Loggers hier die Last nach unten drück wäre das meine Lösung.

Danke,
Wimpf
 
Alles ohne Gewähr:
In der zaphfc.c nach den Begriffen overflow bzw underrun suchen. Dann die Aufrufe kommentieren:

if(chtmp->initialized)
/*
printk(KERN_CRIT "zaphfc[%d]: b channel buffer overflow: %d, %d\n",hfctmp->cardno,chtmp->rx.c[0].filled,chtmp->rx.c[1].fil
led);
*/

und

/*
if(chtmp->initialized)
printk(KERN_CRIT "zaphfc[%d]: b channel buffer underrun: %d, %d\n",hfctmp->cardno,chtmp->tx.c[0].filled,chtmp->tx.c[1].filled)
;
*/

Bitte die if-Abfrage beachten!!!
Irgendwo im Forum ist das schon mal beschreiben. Leider weiss ich immer noch nicht, warum das nötig ist. Schließlich wird Florian die Meldungen nicht nur aus Spass ausgeben lassen.
Ich betrachte dieses Vorgehen ausdrücklich als experimentell bis zur Klärung der Frage!


Gruß
Gerd
 
ulus schrieb:
#
Anschließend sofort procinfo -d -n1 gestartet.
Nach ca. 5s fielen die Interrupts von 8000 auf ca. 490. (schwankt etwas)
Liegt das an der gestiegenen load durch die Log-Prozesse.

Gerd

Ich hab das gerade auch getestet, meine IRQs sind konstant auf: 79990 nidrige Werte sind mit bristuff + flortz nicht möglich.
Ich hab aber gehört, das der visdn-Treiber um einiges besser sein soll.
 
Kostenlos!

Neueste Beiträge

Statistik des Forums

Themen
248,857
Beiträge
2,302,988
Mitglieder
378,504
Neuestes Mitglied
Hallo61Hallo