Forum: PC Hard- und Software Transportdatenkomprimierung für maximalen Durchsatz?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Daten Endlager (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Hi,
gibt es Daten Komprimierverfahren die auf maximalen Durchsatz 
programmiert sind?

Also bei z.B. 115200 bps sehr lange nach Ähnlichkeiten suchen (z.B. gzip 
--best) und bei 10Gbps nur sehr wenige nach Ähnlichkeiten suchen (z.B. 
lz4 -fast).

von Pandur S. (jetztnicht)


Bewertung
0 lesenswert
nicht lesenswert
Ja. Sicher. Einige.
Eine Frage erst mal, ob lossless oder loss behaftet. Du meinst 
wahrscheinlich fuer Daten, also wahrscheinlich lossless.
Lossless ist zwingend fuer files. Und lossbehaftet ist eher fuer Audio 
und video. Dann kann man mit der qualitaet runter fuer hoehere 
Kompression.
Dann waere die Frage, ob man wieder aufsetzen koennen muss, also 
irgenwas wegwerfen und neu anfangen. Das waere dann zB bei Video. Da 
darf hin und wieder, resp speziell am Anfang beliebig viel fehlen.

Dann waere gefragt auf welcher Blocklaenge. Um wieviel an Daten geht es. 
ein Kompressor fuer paar kByte hat andere Moeglichkeiten wie einer fuer 
GByte.

Ein Entropy Kompressor baut sich on the fly eine Lookup Table welche der 
Enpfaenger auch so dann mitbekommt. Der Entropy Kompressor kann also in 
Echtzeit, ohne vorgaengige Arbeit loslegen.

: Bearbeitet durch User
von oszi40 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Erst steht die Frage, ob diese Daten nicht schon VORHER komprimiert 
gespeichert wurden. Eine Komprimierung gut komprimierter Daten bringt 
keinen Vorteil. Komprimiere zum Test 3 Bild.jpg mit rar und vergleiche 
das Ergebnis.

von A. K. (prx)


Bewertung
-1 lesenswert
nicht lesenswert
Es kann auch eine Rolle spielen, ob sich bei den Daten eine aufgrund 
ihres Ursprungs natürliche Redundanzreduktion anbietet, die dann 
vielleicht wesentlich einfacher ist als allgemeine 
Kompressionsalgorithmen wie in gzip.

Beispiel: Hat man es mit digitalisierten Analogwerten zu tun, dann kann 
es sein, dass man einer simplen Huffman-gestärkten Differenzcodierung 
weit besser dran ist als mit LZ Verfahren. Erst recht wenn ein wenig 
Rauschen drinsteckt.

: Bearbeitet durch User
von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
Daten Endlager schrieb:
> Also bei z.B. 115200 bps sehr lange nach Ähnlichkeiten suchen (z.B. gzip
> --best) und bei 10Gbps nur sehr wenige nach Ähnlichkeiten suchen (z.B.
> lz4 -fast).

Kein kompressionsAlgorithmus berücksichtigt die Übertragungsrate. Das 
muss der Anwender schon auf seine Bedürfnisse zuschneiden (gewichten, 
vorgeben, an typischen Szenarien ausrichten). Zumal er die 
decodierleistung der Gegenstelle meist nicht kennt.

von zstd (Gast)


Bewertung
0 lesenswert
nicht lesenswert
--adapt : dynamically adapt compression level to I/O conditions
?

von Michael D. (nospam2000)


Bewertung
-1 lesenswert
nicht lesenswert
Daten Endlager schrieb:
> Also bei z.B. 115200 bps sehr lange nach Ähnlichkeiten suchen

Damit fängst du dir eine große Latenz ein. Das war übrigens der große 
Nachteil von MNP5 gegenüber V.42bis 
(https://en.wikipedia.org/wiki/Microcom_Networking_Protocol).

Für interaktive Anwendungen und Protokolle mit Acknowledge ist große 
Latenz schlecht und bremst ggf. sogar den Durchsatz, das hängt von der 
Windowsize und der Blockgröße der Komprimierung ab.

Bei Dateitransfers ist es besser die Datei selbst von der Übertragung zu 
packen. Oft sind es sowieso mehrere Dateien die übertragen werden, dann 
macht ein komprimiertes Archiv Sinn.

Sprich es hängt von der Anwendung ab, ob die Komprimierung mehr schadet 
als sie hilft. Solange wir die nicht kennen, können wir nur orakeln.

 Michael

: Bearbeitet durch User
von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
Daten Endlager schrieb:
> Hi,
> gibt es Daten Komprimierverfahren die auf maximalen Durchsatz
> programmiert sind?
>
> Also bei z.B. 115200 bps sehr lange nach Ähnlichkeiten suchen (z.B. gzip
> --best) und bei 10Gbps nur sehr wenige nach Ähnlichkeiten suchen (z.B.
> lz4 -fast).

Also du meinst welche, die automatisch erkennen, ob der Prozessor oder 
die Datenleitung der Flaschenhals ist und sich daran anpassen? Da ist 
nicht nur die Bandbreite der Übertragung relevant, sondern auch die 
CPU-Geschwindigkeit, und das auf Sender- und Empfänger-Seite. Man 
bräuchte also noch ein Protokoll, um die Kompressionsrate auszuhandeln.

von Michael D. (nospam2000)


Bewertung
0 lesenswert
nicht lesenswert
Michael D. schrieb:
> Damit fängst du dir eine große Latenz ein. Das war übrigens der große
> Nachteil von MNP5 gegenüber V.42bis
> (https://en.wikipedia.org/wiki/Microcom_Networking_Protocol).

V42.bis könnte tatsächlich das sein was du suchst:

"V.42bis, also an adaptive data compression standard, is based on the 
Lempel Ziv dynamic dictionary approach, and may go to "transparent 
mode," in which data is transmitted uncompressed. The specific algorithm 
is "BTLZ" (British Telecom Lempel Ziv), which was developed by Alan 
Clark (then with BT)."

  Michael

von Sebastian S. (amateur)


Bewertung
0 lesenswert
nicht lesenswert
@Daten Endlager
Zu wenige Informationen!

Natürlich gibt es verschiedene Verfahren zur Datenkompression, wie auch 
bereits angedeutet von verlustbehafteten aber beim Kompressionsfaktor 
unübertroffenen Verfahren (wie z.B. MP?, JPG oder eines der vielen 
Videostandards), wie auch vielen anderen, die eine 1:1 Rekonstruktion 
zulassen.

Wie so oft gilt hier aber: Das kommt darauf an.

Der Datentransport hängt nämlich, wenn man mal so langsame Wege wie 
115200 bps außen vor lässt, grob von zwei Faktoren ab. Die sich 
dummerweise meist addieren.
1. Der Kompression und
2. Dem Transport.

Bei der Kompression, wenn Du nicht fertig komprimierte Daten bekommst, 
sollte man meinen: Standards sind oft in Hardware verfügbar und somit 
extrem schnell, während eine explizite Software vielleicht effektiver 
ist, aber oft wie ein Bremsklotz wirkt.
Der Transport ist oft fixiert und kann somit als "konstante" Verzögerung 
angesehen werden.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.