Verteilte GPU-beschleunigte Datenkompression

[Visceroid]

Sicherlich wuerde der Grossteil der User nur den dekomprimierer nutzen. Allerdings kann mann hoffen das einige User beim komprimieren mitmachen wuerden zum Wohle aller um kleinere Downloads auf diesen Seiten zu bekommen. Bei Folding@Home machen ja auch viele mit ohne direkten Vorteil fuer sich selbst. Was auch noch eine Moeglichkeit ist, mann bietet den Downloadseiten an die Downloads auf einem dedizierten Cluster zu komprimieren, das wuerde dann allerdings Geld kosten, zumindest waere das eine Option wenn wenig User online sind zum komprimieren. Das System sollte dann aber dynamisch sein so dass der dedizierte Cluster und die User zusammen arbeiten koennten.

Folding@Home bringt nicht dem einzelnen User was aber der Menschheit als gesamtes. Wenn jemand seine Downloads etwas schneller bekommt hilft das nur dem einzelnen, da liegt meiner Meinung nach der Motivatiosunterschied zwischen einem Distributed Packer und Folding.

3.5GB Download pro Tag verteilt auf mehrere Clients sollten doch kein Problem sein. Der Zentral Rechner wird vermutlich ein VPS mit 1Gbit/s connection.

War eher gemeint das der einzelne Enduser, der den Client und dadurch den PC 24/7 laufen hat, bei ~4kb/s auf ca. 345MB/Tag kommen wird und sich der Vorteil durch kleinere Downloads erst nach ca. 3,5GB (bei 10% Optimierung gegenüber aktuell gängigen Packern) rechnet. Natürlich rein auf den Datentransfer bezogen.

Die Download Seite koennte die Downloads direkt nach Release noch als .rar, .7z oder .zip Dateien anbieten waehrend gleichzeitig auf dem Cluster die Dateien im andern Format komprimiert werden, sobald das fertig ist, werden die Downloads halt im neuen Format angeboten.

Ja so war das gedacht. Erfordert aber zusätzliche Administration bzw. Implementation. Dann aber trotzdem auch die Frage was günstiger ist: 10% mehr Bandbreite (wenn sie nur .zip anbieten) oder 90% mehr Speicherplatz (wenn .zip und .ohnegehäuse angeboten wird)?

Mann koennte die Downloads als selbst-entpackendes Archiv anbieten. Der Download duerfte dadurch nur 27KB groesser werden.

Was wieder dazu führen würde dass noch weniger User in den Versuch kommen den Client laufen zu lassen? Abgesehen davon weißt du vermutlich wie gerne .EXE Dateien heruntergeladen werden, sind diese doch direkt für Viren angreifbar. Abgesehen davon musst du sehen ob deine im Endstadium gewählte Kompressionsmethode auch SFX bei GPU Decompressing unterstützt.
Viele Programme/Seiten erlauben auch das direkte .EXE handling gar nicht ohne weiteres (Outlook als großes fällt mir da Spontan ein). Viele Firewalls unserer Kunden blocken .EXE Attachments auch einfach ohne Rückfrage.

Mann koennte ja erstmal nur die populaersten Downloads mit dem Verfahren komprimieren. Den Clients koennte zur Hilfe ein dedizierter Cluster zur Seite stehen, hier ist die Finanzierung allerdings das Problem da vermutlich viele Download Seiten nicht bereit waeren fuer kleinere Downloads zu zahlen.

Vermutlich werden sie nicht zahlen wollen, wenn wollen die Downloadseiten Geld sparen durch eine neue Technik wie diese.

Ich halte die Idee noch immer für gut, aber ich bin noch nicht überzeugt dass sich sowas auch durchsetzen wird. Ich war early adopter bei RAR, habe es benutzt, da wussten die meisten noch nicht mal davon - heute ist es quasi Standard, wer weiß was mit deinem System passiert.

 

[Sebbi]

Nein, der Zentralserver wuerde erst ueberpruefen ob sich jedes Packet entpacken laesst, wenn nicht dann muss ein anderer Client es ein zweites mal entpacken, das dies passiert sollte aber nicht zur Regel gehoeren, also in 999/1000 Faellen duerfte es nicht noetig sein ein Packet mehr als einmal zu packen.

Das wäre dämlich, um es höflich auszudrücken. Denn es kann zu jeder Zeit zu Rechenfehlern kommen, vorallem wenn die Komponenten außerhalb der Spezifikationen laufen. Und der Client hat auch nicht die Möglichkeit, das zu Prüfen, ob er richtig gerechnet hat, da er ja nur einen Teil berechnet.

Und damit haste das Problem dann, wenn du die zusammengesetzte Datei hast, nicht mehr feststellen kannst, welcher Client nun fehlerhaft arbeitet und im Zweifelfall jeden weiteren Komprimierungsversuch kaputt macht.

Da sieht mann auch schoen das es durchaus moeglich ist 7zip, Winrar etc. deutlich zu schlagen.

Aber der ZEIT und Energie aufwand ist 300x höher .... sprich ich brauch schon alleine 300 Clients um eine 11 MB datei um knapp 50 % mehr zu komprimieren.

Problem ist, GPU Packer die einen wirklich grossen Leistungsunterschied zur CPU aufweisen brauchen meines Wissens nach sehr agressive Komprimiersettings um deutlich schneller als die CPU zu sein. In den ersten Tests wird das auch mehr als deutlich.

und puff ... damit verschwindet der Traum von GPU packer (auch vom verteilten), weil sich der Mehraufwand an Energie gegenüber der CPU Komprimierung einfach nicht lohnt.

 

[Ohne Gehäuse]

Folding@Home bringt nicht dem einzelnen User was aber der Menschheit als gesamtes. Wenn jemand seine Downloads etwas schneller bekommt hilft das nur dem einzelnen, da liegt meiner Meinung nach der Motivatiosunterschied zwischen einem Distributed Packer und Folding.

Es bekommt ja nicht nur einer seine Downloads schneller, alle die auf der Download Seite herunterladen (wie z.b. computerbase.de) die das neue Format nutzt laden die Dateien schneller runter.

Ja so war das gedacht. Erfordert aber zusätzliche Administration bzw. Implementation. Dann aber trotzdem auch die Frage was günstiger ist: 10% mehr Bandbreite (wenn sie nur .zip anbieten) oder 90% mehr Speicherplatz (wenn .zip und .ohnegehäuse angeboten wird)?

Da hast du recht, das koennte ein Problem sein.

Was wieder dazu führen würde dass noch weniger User in den Versuch kommen den Client laufen zu lassen? Abgesehen davon weißt du vermutlich wie gerne .EXE Dateien heruntergeladen werden, sind diese doch direkt für Viren angreifbar. Abgesehen davon musst du sehen ob deine im Endstadium gewählte Kompressionsmethode auch SFX bei GPU Decompressing unterstützt.
Viele Programme/Seiten erlauben auch das direkte .EXE handling gar nicht ohne weiteres (Outlook als großes fällt mir da Spontan ein). Viele Firewalls unserer Kunden blocken .EXE Attachments auch einfach ohne Rückfrage.

Dekomprimiert wird nicht auf der GPU, das ist auch gar nicht noetig weil die Speed selbst auf lahmen CPUs sehr schnell sein sollte. Deine argumentation das ein selbst-entpackendes Archiv User abschrecken koennte stimmt natuerlich. Da muss mann wohl die Datei im neuen Format anbieten, wo dann vermutlich viele User auch eher zur .zip oder.rar greifen wuerden weil sie nicht noch einen dekomprimierer runterladen wollen.

Vermutlich werden sie nicht zahlen wollen, wenn wollen die Downloadseiten Geld sparen durch eine neue Technik wie diese.

Da muesste mann dann die Performance der Software optimieren, was aber sehr schwierig sein duerfte weil alle bisherigen Performance Optimierungen die in Frage kommen wuerden, wuerden den Speicher Verbrauch massiv steigern.

Ich halte die Idee noch immer für gut, aber ich bin noch nicht überzeugt dass sich sowas auch durchsetzen wird. Ich war early adopter bei RAR, habe es benutzt, da wussten die meisten noch nicht mal davon - heute ist es quasi Standard, wer weiß was mit deinem System passiert.

Die Chance das mein System klaeglich scheitert ist sehr hoch, aber mann kanns ja wenigstens versuchen.

Das wäre dämlich, um es höflich auszudrücken. Denn es kann zu jeder Zeit zu Rechenfehlern kommen, vorallem wenn die Komponenten außerhalb der Spezifikationen laufen. Und der Client hat auch nicht die Möglichkeit, das zu Prüfen, ob er richtig gerechnet hat, da er ja nur einen Teil berechnet.

Und damit haste das Problem dann, wenn du die zusammengesetzte Datei hast, nicht mehr feststellen kannst, welcher Client nun fehlerhaft arbeitet und im Zweifelfall jeden weiteren Komprimierungsversuch kaputt macht.

Der Zentral Server ist in der Lage festzustellen ob ein einzelnes Packet vom einem Client sich dekomprimieren laesst. Der Zentral Server muss nicht warten bis alle Clients fertig sind um zu verifizieren ob sich einzelne Pakete entpacken lassen.

Aber der ZEIT und Energie aufwand ist 300x höher .... sprich ich brauch schon alleine 300 Clients um eine 11 MB datei um knapp 50 % mehr zu komprimieren.

Mit einer 11MB Datei lohnt sich das System noch nicht wirklich. Erst ab 100MB Dateien da winrar/7z/winZip vermutlich die 11MB Datei kleiner kriegen wuerden in einem Bruchteil der Zeit.

und puff ... damit verschwindet der Traum von GPU packer (auch vom verteilten), weil sich der Mehraufwand an Energie gegenüber der CPU Komprimierung einfach nicht lohnt.

Wenn eine Datei hunterdtausend mal runtergeladen wird koennte mann vielleicht den Aufwand rechtfertigen.

 

[Sebbi]

Der Zentral Server ist in der Lage festzustellen ob ein einzelnes Packet vom einem Client sich dekomprimieren laesst. Der Zentral Server muss nicht warten bis alle Clients fertig sind um zu verifizieren ob sich einzelne Pakete entpacken lassen.

Dann müsste aber jeder Teil ein eignes kleines Archiv mit Header etc (wegen Infos wie so was gemacht ist) sein (was extra platz braucht), damit der Server das überhaupt auswerten kannt. Außerdem braucht der Server auch leistungsfähige Komponenten, die dadurch auch viel mehr Strom verbrauchen usw.

Wenn eine Datei hunterdtausend mal runtergeladen wird koennte mann vielleicht den Aufwand rechtfertigen.

Schon mal überlegt, das die Patches jeder so schnell wie möglich haben will? Wenn der Hersteller einer Software den Patch (z.B. 1 GB groß) rausbringt, wolllen die meisten keine 8 Wochen warten, bis der Patch als DL zu Verfügung steht, weil eventuell sogar Sicherheitslücken dadurch geschlossen werden. Die meisten DL finden in den ersten 4 Wochen nach erscheinen das Patches statt. Danach kommen die restlichen 10 % der Downloads zusammen.

sprich wenn du glück hast. wird deine extrem komprimierte datei noch 20000 mal runtergeladen bei 1000000 Downloads ... und da is Aufwand / Leistung mangelhaft wenn nicht sogar ungenügend