HFC Interrupts

smartbyte

Neuer User
Mitglied seit
21 Dez 2004
Beiträge
35
Punkte für Reaktionen
0
Punkte
0
Hallo Leute,

nach einigen Experimenten mit meinem Linux-Asterisk-Server habe ich gemerkt, dass Asterisk grosse Probleme bekommt, wenn ich den Server ein bisschen belaste (einen Atlhon 64 2800+). Vor allen Dingen sobald man die Interrupt-Zugriffe des Servers mal für andere Dinge, z.B. Festplatten benötigt. Nach ein bisschen Forschungsarbeit war das Problem auch schnell ausfindig zu machen. Der Zaphfc-Treiber benutzt Interrupts der HFC-Karte als Timer um das ISDN-Protokoll zu syncronisieren.
Das ist anstrengend für das System. Im neusten bristuff hat sich der Programmierer auch darum gekümmert und den rtai-Treiber als Realtime-Timer eingesetzt (anstatt der vielen Interrupt-Aufrufe). Das Problem dabei ist allerdings, dass dieser Treiber einen Kernelpatch benötigt und viel zu gross dafür ist, dass er eigentlich nur als timer dienen soll (und ich ihn einfach nicht kompiliert bekomme:-( ).
Daraufhin habe ich mich wieder auf die Suche in der allwissenden Müllhalde (auch Internet genannt) gemacht und das ztdummy-Modul gefunden, dass nur dafür da ist genau diese Timing-Tätigkeit zu vollführen, wobei es den ztdummy wieder in zwei Versionen gibt. Einmal für den 2.4er Kernel (USB-Kontroller abhängig) und einmal für den 2.6er Kernel. Das Modul für den 2.6er Kernel soll nun wieder von dem USB-Port unabhängig sein, und direkt mit der RTC im 2.6er Kernel zusammenarbeiten, der dafür angeblich eine ausreichende Genauigkeit besitzt.
Und nun meine Frage: Kann mir einer erklären, warum der HFC-Treiber nicht auch einfach die RTC vom Server als Timing-Quelle benutzt?
(Bitte, mein Server macht "nebenbei" noch andere Sachen ausser Asterisk, warum muss man über diese komplizierten Weg ein Timing-Signal generieren, dass meine VoIP-Verbindung so anfällig macht?)

Hat jemand einen direkten Draht zum Programmierer, oder kann mir kurz erklären, warum das so nicht geht, was ich mir da ausgedacht habe?

Danke schoneinmal.

Ciao.
 
den direkten Draht bekommst Du auf irc.freenode.net in #asterisk-drinkers :)
 
Guter Punkt, smartbyte!

Zugegebenermassen weiss ich die Antwort auch nicht, erinnere mich aber noch aus alten Tagen, dass der RTC-Interrupt mit niedriger Priorität läuft und allen anderen Interrupts hinterher läuft. Das Problem ist, dass ich nicht mehr weiss ob das irgendwann softwareseitig einstellbar geworden ist. Kann gut sein, ich weiss es aber nicht.

Falls mich also mein Gedächtnis nicht trügt, ist man mit dem RTC-Interrupt auf einem belasteten System wesentlich schlechter dran als mit den anderen Interrupts. Deshalb hatte mir klein-Erna-mäßig immer irgendwie eingeleuchtet, dass man den Umweg über den USB-Controller, ISDN-Karte usw geht um einen anständigen Takt zu bekommen.

Übrigens, Junghanns.net ist auf der CeBit. Evtl kann man Klaus-Peter Junghanns dort treffen und über solche Dinge mal sprechen...
 
smartbyte schrieb:
(und ich ihn einfach nicht kompiliert bekomme:-( )
Ich ahne wovon Du sprichst.
Leider bin ich im Moment auf Achse und habe deshalb keine ISDN-Hardware greifbar, habe aber auch mal "schnell" RTAI zu installieren versucht. Pustekuchen von wegen schnell.

Letztlich habe ich RTAI in meiner kleinen Testinstallation am Laufen, zumindest gibt der latency Test einen sinnvollen output.

Aufgesetzt habe ich auf ein frisch installiertes Gentoo (mein Hotel hat freies Internet bei völlig unerwarteter Geschwindigkeit :D :D).

Ohne Kernel 2.6.8.1 scheint es in der Tat nicht zu gehen. Mit dem Compilieren von RTAI hatte ich dann wie gesagt auch noch meine Probleme. Letztlich habe ich mich an das README.INSTALL von RTAI gehalten. Im letzten Teil (Bootstrap in 7 Schritten - oder ähnlich) steht das nützliche Zeugs.

erst konfigurieren (oder war das nach dem Patch?)
dann manuell patchen (wie im README.INSTALL beschrieben)
dann kernel neu kompilieren
dann erst funktioniert make (ich brauchte mehrere Versuche weil ich irgendwie beim beschriebenen make -f ... aus dem readme auf Abwege geraten bin)
wenn das alles funktioniert hat den neuen Kernel booten
und dann hat es geklappt bis zum latency Test

Zusammenfassend habe ich mich entweder paddelig angestellt oder die Sache war trotz readme nicht so ganz trivial. Aber wer richtig lesen kann soll ja Vorteile im Leben haben. Nun ja...

Anyway, im Moment komme ich wohl nicht weiter, weil ich keine ISDN-Hardware greifbar habe. Ich bin erst zur CeBit wieder retour.

Vielversprechend sieht es allerdings aus. Zumindest habe ich jetzt sozusagen ein realtime-Notebook. Naja, wenigstens bis ich ich die Testpartition wieder brauche...
 
Ach ja, eine Sache habe ich noch vergessen.

Beim meiner Gentoo-Installation habe ich offenbar beim module-unload nicht richtig aufgepasst. Wenn ich den latency test wie im readme von rtai beschrieben mit ^c abbreche, bekomme ich

FATAL: Kernel does not have unload support

Also, aufgepasst bei der Kernel-Konfiguration...
 
smartbyte schrieb:
Hat jemand einen direkten Draht zum Programmierer, oder kann mir kurz erklären, warum das so nicht geht, was ich mir da ausgedacht habe?

Hast Du schon Kontakt aufnehmen können?
 
Besonders ärgerlich ist die Tatsache, dass ztdummy de RTC belegt, so dass
Code:
hwclock --debug
zu
Code:
hwclock from util-linux-2.12r
hwclock: Open of /dev/rtc failed, errno=16: Das Gerät oder die Ressource ist belegt.
No usable clock interface found.
Cannot access the Hardware Clock via any known method.
führt.
Nach
Code:
modprobe -r ztdummy
ist die RTC wieder nutzbar:
Code:
hwclock --debug
hwclock from util-linux-2.12r
Using /dev/rtc interface to clock.
Last drift adjustment done at 1185864360 seconds after 1969
Last calibration done at 1185864360 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
/dev/rtc does not have interrupt functions. Waiting in loop for time from /dev/rtc to change
...got clock tick
Time read from Hardware Clock: 2007/08/01 06:29:58
Hw clock time : 2007/08/01 06:29:58 = 1185949798 seconds since 1969
Mi 01 Aug 2007 08:29:58 CEST  -0.994482 seconds
Kennt jemand eine Lösung, wie die RTC trotz ztdummy zugreifbar bleibt?
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.