Fax Versand und Fax Empfang auf FritzBox oder PC-Linux

Entweder hat die MIPS CPU diesen Befehl doch nicht, oder die Autoren von GCC kennen ihn nicht. Jedenfalls erzeugt GCC für diese Funktion auf der MIPS einen Aufruf auf eine Library-Funktion, die etwas in der Art macht, wie ich es oben beschrieben habe. Wenn Du das verwendest, hast Du Overhead für Call, Return und dafür, daß alle 32 Bit durchsucht werden.

Was den Fax-Empfang betrifft, so habe ich Deine fastfp Library im alten Thread auch gefunden und etwas damit experimentiert. Anscheined ist der Fax-Empfang an manchen Stellen etwas empfindlich, was Ungenauigkeiten in der Fließkomma Berechnung betrifft.

Konkret konnte ich eine Fax-Übertragung simulieren mit der float Emulation vom GCC. Wenn ich die Subtraktion durch eine weniger genaue Funktion ersetzt habe, gab es Fehler beim Empfang. Da scheint also etwas sehr empfindlich zu sein.

Wo erwartest Du Dir eine bessere Geschwindigkeit durch Deine neue Art der Darstellung im Vergleich zum konventionellen Format?
 
Schwer vorstellbar, daß die CPU einen Befehl hat, der von GCC nicht benutzt wird. Da ich gerade auf dem Sprung bin, habe ich keine Zeit zum Recherchieren, aber falls es diesen ominösen Befehl geben sollte, kannst Du ja immer noch eine kleine Assembler-Sektion in den C-Code einbetten.
 
Zum CLZ Befehl :
http://www.motherboardpoint.com/t94978-cross-compile-with-mips4kc-instructions.html

die fbox hat doch mips32-4kc cpu, oder? da ist genau das prob. beschrieben dass der mipsel-linux-gcc das instruction set ISA nutzt und nicht das vom 4KC

CLZ Befehl scheint die 4KC-arch. zu haben

Zur Genauigkeit und fastfp: fastfp sollte die gleiche genauigkeit haben wie die gcc float emulation, ausser es sind bugs drin, was nicht auszuschließen ist.
dann werden wohl meine 16-bit wirklich nicht ausreichen. man kann auch 32 bit verwenden, dann braucht man halt mehrere multiplikationen um 2 32-bit ints zu mult. und einen vollen 64-bit int zu bekommen (ausser mips4kc UND gcc unterstüzen das schon wieder irgendwie...)
ich denke mal, dass wenn man nicht dauernd shifts und ands braucht um an mant. bzw. exp. ranzukommen dass man dadurch mit weniger instruktionen auskommen könnte, vor allem wenn man dann noch den clz verwendet ;) wenn man nicht immer die mantissen normalisieren muss, dann würde das auch schon shifts und abfragen sparen.
 
Es gibt einen CLZ Befehl, und der Compiler verwendet ihn auch, wenn man die Option -mips32 verwendet.

Nicht nur das, auf meiner Box funktioniert aus das Programm, das heißt der verwendete Prozessor kann den Befehl auch ausführen.

Jetzt bleibt noch die Frage, wie man -mips32 als Default aktivieren kann.

florixyz war schneller.
Wenn es ein mips 4kc ist, sollten wird das auch so aktivieren. Vielleicht gibt es ja auch andere Programme, die davon profitieren.
Hier noch ein Link zum MIPS 4KC

Unabhängig davon, für welche Operationen ist Dein Format schneller? Speziell bei der Multiplikation mit normalisierten Werten ist das Normalisieren des Ergebnisses ja sehr einfach.
 
Zuletzt bearbeitet:
Bei mir meldet das Linux einen MIPS 4KEc.

FRITZ!Box SL WLAN:

# cat /proc/cpuinfo
system type : MIPS AR7
processor : 0
cpu model : MIPS 4KEc V4.8
BogoMIPS : 149.91


FRITZ!Box 7170:

/var/mod/root $ cat /proc/cpuinfo
system type : MIPS OHIO
processor : 0
cpu model : MIPS 4KEc V4.8


Keine Ahnung wie relevant die Unterschiede zu einem 4Kc sind. Der 4KEc scheint zumindest ein paar Features mehr zu haben.

http://www.mips.com/products/cores/hard_ip_cores/4Kc_Hard_IP_core.php#features
http://www.mips.com/products/cores/hard_ip_cores/4KEc_Hard_IP_cores.php#features
 
Anscheined gibt es einige interesante Unterschiede, zum Beispiel "Special PC-relative instructions for efficient loading of addresses and constants".

Leider hat GCC keien Option für 4kec, so daß dies vorerst nicht von Bedeutung ist.
 
Ich hab irgendwann mal von march=4kc auf march=mips32 umgestellt, weil mir keiner einen Nachteil nennen konnte. Und weil openssl mit "march=4kc" nicht läuft.

MfG Oliver
 
UTFSF -> Link

MfG Oliver
 
RalfFriedl schrieb:
Unabhängig davon, für welche Operationen ist Dein Format schneller? Speziell bei der Multiplikation mit normalisierten Werten ist das Normalisieren des Ergebnisses ja sehr einfach.

Da muss ich dir recht geben. Ich weiss auch noch nicht ob mein Format wirklich schneller ist, ich hab es ja noch nicht vollständig implementiert und getestet. Sobald das der Fall ist, poste ich hier die Ergebnisse. Ich dachte halt vor allem an das packen und entpacken des float formats. wenn mantisse und exponent schon getrennt sind, dann entfällt das ja. evtl. könnte man auch immer normalisieren und die 1 allerdings mit drinnenlassen, vllt. wäre es dann auch schneller, weil wie du sagst, es bei der mult. sehr einfach ist.
ich werd mal die mult. implementieren und dann die performance mit fastfp softfloat vergleichen, wenn das nicht wesentlich schneller ist, dann bringts nichts, sonst könnte man ja mal weiter machen in der richtung.
 
Nach meinen letzten Versuchen auf der Box sehe ich im Moment das Problem eher in der Datenübertragung der CAPI. Wenn solche Störungen kommen, insbesondere wenn dabei auch noch die Daten verschoben sind, ist es kein Wunder, wenn der Empfänger aus dem Takt kommt.

Beim Fax-Empfang ist bei mir die CPU Auslastung hoch, aber meiner Meinung nach nicht so extrem, daß das der Auslöser für die Probleme ist.

Das Packen und Entpacken der Floats ist sicherlich auch von Bedeutung, aber vermutlich nicht übermäßig schlimm. Und wie bereits gesagt, scheinen Teile von spandsp empfindlich auf Ungenauigkeiten zu sein, und die Ungenauigkeiten in Deiner fastfp sind wirklich nicht groß.

Ein weiterer Nachteil ist, daß für die Verwendung des von Dir vorgeschlagenen Formats das komplette spandsp umgestellt werden muß, und bei jeder neuen Version immer wieder.
 
ja, sicherlich müsste man dazu tief in spandsp eingreifen. doch falls meine neue fastfp lib, einigermaßen brauchbar ist, wäre es vllt. möglich diese in spandsp einzubinden (die unterstützt dann auch diverse festkomma operationen usw.) wenn man den entwickler kontaktiert. denke mal es sollte möglich sein, so dass man eben eine compileroption hat use fastfp oder so

aber das würde alles nur was bringen, wenn das wirklich was hilft und die einzige lösung ist. ich sehe hier schon einmal -mips32 als vielversprechend was die performance betrifft.

allerdings in der Tat das größte Problem sind die eingefügten Blöcke vom CAPI. Vllt. liegt es an der Capi.cpp die du verwendest? Hast du den gleichen Test mal mit meinem alten ivcall und dem capi zeugs davon gemacht? oder mit dem capi von der dtmfbox? wenn theoretisch auch in einem tel. gespräch solche aussetzer drin wären, dann wären die doch deutlich hörbar als knackser und das problem müsste bekannter sein.... vor allem bei dtmfbox usern.
was mich noch wundert. die daten sind eingefügt. d.h. es ist nichts verlorengegangen aufgrund schlechter performance, timings etc... sonst würden an der stelle daten fehlen und ergänzt werden um den grundsätzlichen sync, oder datenstrom nicht zu unterbrechen.
ich tippe hier mal drauf, dass vom capi undefinierte "inline" messages kommen, die von deiner capi lib als daten interpretiert werden. (EDIT: natürlich nicht ausgeschlossen, dass meine, bzw. andere capi libs das auch machen würden....)
 
Es ist nicht so, daß nur Daten eingefügt werden, es werden auch Daten verändert. Das Einfügen ist aber nach dem, was ich von spandsp gelesen habe schlimmer. Ein kurzes Knacken in der Leitung sollte es verkraften, ein Verschieben anscheinend nicht.

Hier ist ein Beispiel. Die Datei enthält aufsteigende Intergers im Little-Endian Format. Die Blockgröße ist 512 Bytes
Code:
27a70 9c 00 00 f0 9c 00 00 f1 9c 00 00 f2 9c 00 00 f3   ................
27a80 9c 00 00 f4 9c 00 00 f5 9c 00 00 f6 9c 00 00 f7   ................
27a90 9c 00 00 f8 9c 00 00 f9 9c 00 00 fa 9c 00 00 fb   ................
27aa0 9c 00 00 fc [B]3c f0 00 ad 6c 2c 00 f8 00 cc 00 a0[/B]   ....<...l,......
27ab0 d0 7c 00 00 [B]f1 9c 00 00 f2 9c 00 00 f3 9c 00 00[/B]   .|..............
27ac0 f4 9c 00 00 f5 9c 00 00 f6 9c 00 00 f7 9c 00 00   ................
27ad0 f8 9c 00 00 f9 9c 00 00 fa 9c 00 00 fb 9c 00 00   ................
27ae0 fc 3c f0 00 ad 6c 2c 00 f8 00 cc 00 a0 d0 7c 00   .<...l,.......|.
27af0 00 f1 9c 00 00 f2 9c 00 00 f3 9c 00 00 f4 9c 00   ................
27b00 00 f5 9c 40 00 68 8c ac 00 36 d0 8c 00 e0 5e 3c   [email protected]....^<
27b10 80 80 ea 7c 80 80 eb 7c 80 80 2c fc 80 80 2d fc   ...|...|..,...-.
27b20 60 60 2e fc 60 60 af 3c 60 60 40 3c 60 60 41 3c   ``..``.<``@<``A<
27b30 60 60 42 bc 58 e0 ba 0c 28 60 64 6c 6e 60 dd 2c   ``B.X...(`dln`.,
27b40 a7 60 08 dc 09 60 46 b9 21 60 a0 b0 41 60 a8 98   .`...`F.!`..A`..
27b50 d1 80 18 80 2d 00 20 1b 4d c0 c0 de 3d c0 80 4a   ....-. .M...=..J
27b60 [B]7d[/B] 00 00 0c 9d 00 00 0d 9d 00 00 0e 9d 00 00 0f   }...............
27b70 9d 00 00 10 9d 00 00 11 9d 00 00 12 9d 00 00 13   ................
27b80 9d 00 00 14 9d 00 00 15 9d 00 00 16 9d 00 00 17   ................
Bei der ersten Markierung beginnt die Störung. Bei der zweiten Markierung werden Daten wiederholt, die vorher schon dran waren (f1 9c 00 00, bei 27a70). Bei 27b61 geht es dann wieder normal weiter. Allerdings sollte dort schon "00 00 2c" sein und nicht "00 00 0c". Es sind insgesamt 190 Bytes fehlerhaft. Davon sind 62 Bytes falsch angekommen und 128 Bytes eingefügt.

Es kann natürlich sein, daß meine CAPI Funktion etwas falsch macht. Auf einem PC wird allerdings die ganze Datei, auch 4 MB, ohne solche Aussetzer Empfangen.

Es kann auch sein, daß es ein Problem mit wem W900V ist. Die Telekom Firmware ist ja nicht mehr die neueste, und das Zusammenspiel mit den neueren Kernel-Sourcen ist etwas problematisch.
Andererseits ist es ja nicht so, daß die CAPI dort nicht gehen wurde. Die Störungen betreffen ja nur einen kleinen Teil der Datei, aber es ist trotzdem zu viel.

@olistudent
openssl mit -march=4kc scheint bei mir zu gehen. Zumindest kann ich mit openssl s_client eine Verbindung zu einem Server aufbauen, ohne daß es zu einem Fehler kommt.
 
Zuletzt bearbeitet:
das sieht ja alles andere als schön aus............

auf dem pc läuft es mit demselben code?
ich könnte mir evtl. noch vorstellen, dass die fbox capi eben nicht genauso wie die pc capi implementiert ist, da dort ja auch vieles vereinfacht wurde, und deswegen nicht voll kompatibel. hast du mal fbox remote capi probiert? treten da die gleichen fehler auf? hast du die capi.cpp aus einem pc-linux programm? oder hast du sie an die avm capi header angelehnt, die avm im opensource teil zur box mitliefert?

@bodega: falls du hier mitliest, ist dir von der dtmfbox sowas bekannt, dass es veränderte und eingefügte dabei bei der isdn/capi übertragung gibt??
 
@RalfFriedl
Wenn das funktioniert und die "bessere" Wahl wäre, dann können wir das auch wieder rückgängig machen.

MfG Oliver
 
Ob es die bessere Wahl ist, weiß ich nicht, ich vermute es aber.
Laut source/toolchain/gcc-4.2.1/gcc/config/mips/mips.c ist mips32 und 4kc (fast) das Gleiche. In source/toolchain/gcc-4.2.1/gcc/config/mips/4k.md sind aber einige zusätzliche Definitionen für 4kc. Ich gehe mal davon aus, wenn der Prozessor genauer beschrieben ist, kann der Compiler eher den geeigneten Code dafür erzeugen.

Vielleicht war es damals ein Compiler-Fehler, der inzwischen behoben ist, oder der Fehler ist nicht in openssl, sondern anderswo.

Generell würde ich es aber als Compiler-Fehler betrachten, wenn die Box einen 4kc hat und der dafür generierte Code auf der Box nicht läuft.

Daher bin ich dafür, daß wir den Default auf -march=4kc ändern und evtl. auftretenden Fehlern nachgehen.

@florixyz
Mit Remote-CAPI tritt das Problem auch auf, wenn ich auch den Eindruck habe, daß es nicht ganz so häufig ist. Das kann aber auch Zufall sein.

Die Capi-Funktionen sind nach der CAPI-Dokumentation und Programmen, die CAPI verwenden, erstellt. Auf einem PC-Linux funktioniert es auch. Das muß aber nicht heißen, daß nicht irgendwo ein Fehler enthalten ist, der sich nur sonst nicht bemerkbar macht.

Nachtrag:
Für eine Audio-Verbindung ist das ein Knacken von ca. 24ms. Wenn das etwas einmal pro Minute vorkommt, bemerkt das wahrscheinlich kaum jemand.
 
Zuletzt bearbeitet:
Warum jetzt auf einmal 4kp und nicht 4kc?

MfG Oliver
 
Tut mir leid, war ein Tippfehler. Ich habe es oben auch geändert, bevor es noch mehr Verwirrung gibt. 4kc ist richtig.
Code:
  { "mips32", PROCESSOR_4KC, 32 },
 
Aus
Code:
default "-Os -W -Wall -pipe -march=mips32 -mips32 -Wa,--trap -msoft-float"
wird dann
Code:
default "-Os -W -Wall -pipe -march=4kc -Wa,--trap -msoft-float"
Oder ist noch was wichtig?

MfG Oliver

edit:
Free WRT:
Code:
-march=mips32 -Wa,-32 -Wa,-march=mips32 -Wa,-mips32 -Wa,--trap
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
246,080
Beiträge
2,245,707
Mitglieder
373,529
Neuestes Mitglied
der_wolle
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.