Transportdatenkomprimierung für maximalen Durchsatz?

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.

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.

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

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.

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

@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.