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).
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
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.
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
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.
1 | --adapt : dynamically adapt compression level to I/O conditions |
?
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
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.