Schneller File-Sync

[LL0rd]

Hallo Leute,

ich brauche mal eben einen Tipp: Ich habe einen Arbeitsrechner und ein Notebook. Beide Rechner laufen auf OS X. Ich möchte von beiden Rechnern an einem Projekt arbeiten. Das Projekt ist zwar sehr klein, hat aber viele Dateien, die bei jedem Ausführen gelesen und kompiliert (cache) werden müssen. Ich spreche hier von ca. 10.000 Files in 1.000 Ordnern. Trotz 10GbE habe ich einen deutlichen Performance-Schub, wenn ich das Projekt auf der NVMe ausführe.

Nun möchte ich an dem Projekt nicht nur zu Hause arbeiten, sondern auch auf dem Notebook.

Ich habe den Sync bereits mit Dropbox probiert. Es klappt nur bedingt. Kompilier ich aber hintereinander das Projekt, tauchen auf einmal beim Cache Konflikte auf. Lasse ich den Cache beim Sync weg, gibt es Probleme mit der IDE. Im Worst Case kompilier ich auf dem Notebook, während der Desktop noch hochlädt. Dann geht alles schief. Die Files sind zusammen keine 10MB, nur sind es eben viele.

Bei Nextcloud habe ich übrigens ähnliche Probleme.

Kennt von euch jemand eine Möglichkeit für einen schnellen Sync?

 

[Snuskhammer]

Hi,

Hast du schon syncthing ausprobiert?

 

[ctcn]

Hast du schon mal Git ausprobiert? Löst meines Verständisses nach alle deine Konflike. Wenn du es noch in deine IDE integrierst ist der Ablauf sogar noch etwas flüssiger als über die CLI.

 

[LL0rd]

Hast du schon mal Git ausprobiert? Löst meines Verständisses nach alle deine Konflike. Wenn du es noch in deine IDE integrierst ist der Ablauf sogar noch etwas flüssiger als über die CLI.

Ich selbst nutze Git, aber eben für mehr oder weniger abgeschlossene Milestones. Git funktioniert in dem Fall nicht wirklich. Denn git muss man ja manuell committen. Damit ist schon alles hinfällig. Ich kann nicht mal eben vom Bürostuhl aufstehen, auf Klo gehen und dann ins Wohnzimmer und dann am Notebook weiter arbeiten. Ich muss erst committen und pushen. Und auf der anderen Seite einen Pull starten. Du, es mag ganz ehrlich sich nach mimimi anhören, aber mehr man etwas anderes tut, desto schneller sind die guten Ideen aus dem Kopf.

 

[sch4kal]

Resilio Sync ?

 

[hominidae]

...ist doch alles in Deinem lokalen Netz, oder? ...und der Arbeitsrechner ist Deiner? Kannst Du den nicht mit ner NVMe aufrüsten, dann vom Notebook nur remote eine Session aufmachen?

 

[Tzk]

Jop, entweder komplett auf einem Netzlaufwerk arbeiten, vom Notebook auf das Laufwerk vom PC zugreifen und so arbeiten oder Remote Session.

 

[LL0rd]

...ist doch alles in Deinem lokalen Netz, oder? ...und der Arbeitsrechner ist Deiner? Kannst Du den nicht mit ner NVMe aufrüsten, dann vom Notebook nur remote eine Session aufmachen?

Die Frage wäre dann, mit welchem Remote-Tool denn? VNC kann man komplett vergessen. Da macht das Arbeiten absolut keinen Spaß. Genauso mit Teamviewer und diesem neuen Chrome Tool. RDP habe ich jetzt für Mac nicht ausprobiert, ich habe aber 5 Jahre lang am Fraunhofer gearbeitet, wo ich einen scheiß Desktop-Rechner hatte und einen schnellen Server im lokalen RZ, auf dem ich remote gecoded habe. Trotz damals 1GbE gab es einen Lag beim Tippen (was tierisch nervt) und wenn ich große Fenster aufgerufen habe, z.B. beim Wechseln zwischen IDE und Browser, hat es lange gedauert, bis das Fenster sich aufgebaut hat. Ich habe lokal auch einen Windows Server hier stehen und da ist es mit RDP nicht viel anders. Zwar sind die Fenster sofort da, aber auf Maus und Tastatur-Eingaben reagiert das System relativ schlecht. Damit sind Funktionen wie Code-Completion (also man Tippt die ersten Zeichen ein und die IDE fügt den Rest ein) schlecht nutzbar.

 

[hominidae]

.....wenn Du das in 4k-Auflösung über eine 2.4G WLAN Verbindung beamst, kann das leider sein....Auflösung in Full-HD stellen mit einem vernünftiges WLAN aber eigentlich kein Problem da.
Ich kann auf dem Laptop sogar über RDP Sendungen in FullHD aus dem SAT-TV gucken ;-) Eine Kommandozeile mit Code-Completion ist bei mir gar kein Problem.
Die Frage ist welche IDE Du braucht.
Für Terminals würde ich SSH mit screen auf dem Server/Arbeitsrechner nehmen...da kannst Du auch bei erneutem verbinden vom Notebook wieder auf den alten Screen zurück, der auf dem Arbeitsrechner läuft -> https://linuxwiki.de/screen ...ob es das für MacOS gibt?

 

[LL0rd]

.....wenn Du das in 4k-Auflösung über eine 2.4G WLAN Verbindung beamst, kann das leider sein....Auflösung in Full-HD stellen mit einem vernünftiges WLAN aber eigentlich kein Problem da.

Ich zeige es dir mal an dem Windows-Server, was ich meine:

Datenschutzhinweis für Youtube

An dieser Stelle möchten wir Ihnen ein Youtube-Video zeigen. Ihre Daten zu schützen, liegt uns aber am Herzen: Youtube setzt durch das Einbinden und Abspielen Cookies auf ihrem Rechner, mit welchen sie eventuell getracked werden können. Wenn Sie dies zulassen möchten, klicken Sie einfach auf den Play-Button. Das Video wird anschließend geladen und danach abgespielt.

Youtube Videos ab jetzt direkt anzeigen

Video anzeigen

Siehst du, wie lange es dauert, bis der Rechner auf die Windows-Taste reagiert? Der Windows-Server ist mit 1GbE angebunden, der Mac mit 10GbE. Und beide Rechner machen gerade nichts, also es liegt nicht an den Rechnern, sondern an RDP.

 

[Digi-Quick]

Derartige Latenzen habe ich ja noch nichtmal via DSL (30/10 Real gemessen - 50/10 Tarif) mit Site2Site-VPN (Netgear FVS336Gv2 als VPN Gateway und einem TP-Link TL-ER604W als Initiator)

 

[hostile]

Also "syncen" geht normalerweise wunderbar mit rsync.
Das Problem ist nicht RDP. So wie @hominidae sagt, arbeiten und sogar Videos gucken geht wunderbar.
Welche Netzwerklatenz hast du? Das müssen ja irgendwie 150ms sein oder mehr.

gruß
hostile

 

[sch4kal]

RDP ist für sowas Mist. Halt mal nach Exceed on Demand bzw den Nachfolger Exceed VA TurboX Ausschau. EoD dürfte mittlereile kostenlos sein, bzw TurboVNC.

 

[Ceiber3]

Klingt jetzt vielleicht komisch, aber Parsec ist auch recht performant.

 

[LL0rd]

Welche Netzwerklatenz hast du? Das müssen ja irgendwie 150ms sein oder mehr.

64 bytes from 10.2.0.161: icmp_seq=14 ttl=64 time=0.176 ms
64 bytes from 10.2.0.161: icmp_seq=15 ttl=64 time=0.190 ms
64 bytes from 10.2.0.161: icmp_seq=16 ttl=64 time=0.172 ms
64 bytes from 10.2.0.161: icmp_seq=17 ttl=64 time=0.185 ms
64 bytes from 10.2.0.161: icmp_seq=18 ttl=64 time=0.177 ms
64 bytes from 10.2.0.161: icmp_seq=19 ttl=64 time=0.161 ms

Am Netz liegt es nicht.

 

[hostile]

Dann verstehe ich wohl dein Problem noch nicht.

Also du hast doch das Problem, dass deine Tastatureingaben so verzögert sind - dazu hast du ja das Video gepostet (Post #10).
Dadurch bedingt ist wohl irgendwo eine Latenz drin, die auch das Synchronisieren der Dateien so extrem verschlechtert, so dass es bei 10000 Dateien eben extrem lange dauert.

Ist das korrekt?

gruß
hostile

 

[LL0rd]

Also du hast doch das Problem, dass deine Tastatureingaben so verzögert sind - dazu hast du ja das Video gepostet (Post #10).
Dadurch bedingt ist wohl irgendwo eine Latenz drin, die auch das Synchronisieren der Dateien so extrem verschlechtert, so dass es bei 10000 Dateien eben extrem lange dauert.

Ist das korrekt?

Okay, dann versuche ich es noch ein Mal zu erklären mit genauen Zahlen:
Ich habe ein Projekt, dass 60.000 kleine Dateien hat. 30.000 davon sind statisch, 30.000 werden bei jedem Kompilieren aus den statischen 30.000 neu gebaut. Nehme ich einfach nur rsync um Projektdaten von einem Ordner der NVMe in einen zweiten Ordner der NVMe zu kopieren, dauert es schon 21 Sekunden. Mit File-Sync Anbietern wie Dropbox dauert es Minuten, bis solche Ordner gesynct wurden. Mit irgendeiner Latenz hat das ganze wenig zutun, da die CPU die ganze Zeit ausgelastet ist. Das ist in etwa die Ausgangslage.

Dann gab es eben den Vorschlag, remote zu arbeiten. Und mein Einwand ist, dass auch das schlecht geht, weil Latenz zwischen Eingabe und Ausführung. Und die Latenz liegt ganz sicher nicht am Netzwerk, denn auf beiden Seiten ist noch ne ganze Menge an Software dazwischen.

 

[hostile]

Okay, dass 60.000 Dateien "lange" dauern ist nicht verwunderlich. Dass es über ein anderes Protokoll noch länger dauert wundert mich auch nicht. Ich weiß nicht wie viel Dateien der Linux-Kernel hat, aber das dauert ja schon ordentlich, den zu entpacken.

Mein Vorschlag bleibt auch weiterhin, "remote" zu arbeiten.
Die Frage, die sich mir stellt, was für Software dazwischen ist, die so eine Latenz auslöst, da du ja angeblich vom Client oder Endgerät zum RDP-Server eine total geringe technische Latenz hast (Post #15). Das ist einfach nicht normal.

gruß
hostile

 

[Ceiber3]

Ich zeige es dir mal an dem Windows-Server, was ich meine:

Datenschutzhinweis für Youtube

An dieser Stelle möchten wir Ihnen ein Youtube-Video zeigen. Ihre Daten zu schützen, liegt uns aber am Herzen: Youtube setzt durch das Einbinden und Abspielen Cookies auf ihrem Rechner, mit welchen sie eventuell getracked werden können. Wenn Sie dies zulassen möchten, klicken Sie einfach auf den Play-Button. Das Video wird anschließend geladen und danach abgespielt.

Youtube Videos ab jetzt direkt anzeigen

Video anzeigen

Siehst du, wie lange es dauert, bis der Rechner auf die Windows-Taste reagiert? Der Windows-Server ist mit 1GbE angebunden, der Mac mit 10GbE. Und beide Rechner machen gerade nichts, also es liegt nicht an den Rechnern, sondern an RDP.

Das könnte an MacOS liegen, laut Google gibt es wohl einige wo es nen großen Input Lag gibt. RDP ist allgemein nicht das schnellste. Das schnellste ist Moonlight, hat gefühlt kein Inputlag und wie geschrieben Parsec macht das auch wirklich sehr gut. Ich würde einfach mal testen, wenn es nicht gefällt kann man es ja schnell wieder runterhauen. Parsec wirbt für beides, also Gaming wie auch produktiven Einsatz. Vorteil: geringe Latenzen. Ich nutze es allerdings auch als RDP Software zum Arbeiten.

 

[hostile]

Evtl. wäre es noch etwas, die Dateien zu packen, dann zu transferieren und auf dem Endgerät zu entpacken.
Das könnte schneller sein als jede Datei einzeln zu transferieren (wegen Protokoll-Overhead).

gruß
hostile

 

[hominidae]

...die Ideee war, Dir das rsync zu sparen, indem Du ne NVMe (für die lokale Performance, was ja die initiale Anforderung ist, um das Projekt zu beschleunigen) in den Server steckst und das Projekt dort ausführst / bauen lässt.
Um den "Build" zu starten - auf dem Weg vom Bürozimmer auf WC - über das Notebook, brauchst Du ja ne remote-Verbindung zwischen beiden.

Dein "Problem" war aber, dass Deine UI-/IDE-Performance Dir über die Verbindung zu langsam ist.
Wenn es nicht am direkten Netzwerk liegt, dann eben doch am Protokoll...Alternativen wurden ja schon genannt.
Du hast immer noch nicht gesagt, welche IDE Du nutzt,
Beim arbeiten via remote kann ein Verbindungsabruch und reconnect auch den Zugang in den laufenden Build stören. Daher meine Anmerkung zum Thema "screen".

 

[LL0rd]

...die Ideee war, Dir das rsync zu sparen, indem Du ne NVMe (für die lokale Performance, was ja die initiale Anforderung ist, um das Projekt zu beschleunigen) in den Server steckst und das Projekt dort ausführst / bauen lässt.

Der Server ist schnell genug, da brauche ich keine NVMe (bzw. da sind NVMe und SSDs als Cache im Einsatz).

Ich verstehe deinen Vorschlag, nur funktioniert er nicht zu 100%. Denn Sobald ich die IDE (WebStorm) über ein Netzwerk-Share auf die Daten zugreifen lasse, geht es meistens schief, wenn zwei Rechner gleichzeitig auf die Daten zugreifen.

In 90% merkt die IDE, dass die Datei außerhalb der IDE geändert wurde und lädt die neu. In 10% der Fälle klappt es allerdings nicht. Ich ändere etwas auf dem Notebook, der Desktop merkt die Änderung nicht. Ich gehe an den Desktop, merke nicht, dass da noch ein alter stand ist, ändere wieder etwas an der Datei und beim Speichern sind die Änderungen vom Notebook weg.

Um den "Build" zu starten - auf dem Weg vom Bürozimmer auf WC - über das Notebook, brauchst Du ja ne remote-Verbindung zwischen beiden.

Dein "Problem" war aber, dass Deine UI-/IDE-Performance Dir über die Verbindung zu langsam ist.
Wenn es nicht am direkten Netzwerk liegt, dann eben doch am Protokoll...Alternativen wurden ja schon genannt.

Naja, als Alternative wurde Exceed VA TurboX und Moonlight genannt. Exceed VA TurboX ist Kommerziell, muss ich mir mal anschauen. Moonlight habe ich noch nie was von gehört, muss ich auch mal schauen.

 

[hominidae]

Der Server ist schnell genug, da brauche ich keine NVMe (bzw. da sind NVMe und SSDs als Cache im Einsatz).

Na dann ist der Teil ja schon gut. Bisher war die Annahme, dass Du nicht parallel auf Server und Notebook arbeitest, im Projekt.
Dein Video zeigt auf jeden Fall einen Lag, aber normal ist das nicht.
Da würde ich auch nochmal ansetzen....

 

[p4n0]

Besteht das laggy Problem auch, wenn du von ner Windows-Maschine aus auf deine Moehre per RDP huepfst?

 

[Digi-Quick]

Okay, dann versuche ich es noch ein Mal zu erklären mit genauen Zahlen:
Ich habe ein Projekt, dass 60.000 kleine Dateien hat. 30.000 davon sind statisch, 30.000 werden bei jedem Kompilieren aus den statischen 30.000 neu gebaut. Nehme ich einfach nur rsync um Projektdaten von einem Ordner der NVMe in einen zweiten Ordner der NVMe zu kopieren, dauert es schon 21 Sekunden. Mit File-Sync Anbietern wie Dropbox dauert es Minuten, bis solche Ordner gesynct wurden. Mit irgendeiner Latenz hat das ganze wenig zutun, da die CPU die ganze Zeit ausgelastet ist. Das ist in etwa die Ausgangslage.

Dann gab es eben den Vorschlag, remote zu arbeiten. Und mein Einwand ist, dass auch das schlecht geht, weil Latenz zwischen Eingabe und Ausführung. Und die Latenz liegt ganz sicher nicht am Netzwerk, denn auf beiden Seiten ist noch ne ganze Menge an Software dazwischen.

Dein Projekt hat also 30.000 Dateien mit Quellcode, die 30.000 Dateien mit dem kompilierten/ausführbaren Code sind eigentlich ersteinmal zu vernachlässigen, denn diese kommen erst beim Testen zu tragen...

Ich empfinde 30.000 Dateien sehr viel, selbst ein Libre Office hat nur 12.000 Dateien im Installationsordner (zzgl. dem was veteilt wird). Davon dürfte der größte Teil aus bereits fertigen DLLs bestehen.
Das muß also folglich ein extrem komplexes Produkt sein - oder schlichtweg schlecht geplant! Möglichgerweise ist auch die IDE "Kernschrott"!
Bei derartig vielen "Codeschnipseln wäre vermutlich eine Datenbankähnliche Struktur besser geeignet als das ganze in einzelnen "Mini-Dateien" zu verwursten.

Die Sync-Zeit zwischen 2 Ordnern kannst du nicht mehr stark beeinflussen, daß liegt einfach an der "Unzahl" kleiner Dateien.

Test: den Odner von einer NWME SSD auf eine andere NVME SSD kopieren, dann erfährst du was nach derzeitigem Stand der "bezahlbaren" Technik maximal möglich wäre - ich vermute das Ergebnis wird dich "schockieren".
(Die schnellste Technologie wäre RAMDisk, mit dem Nachteil, daß diese bei jedem Reboot befüllt und mit einem nicht flüchtigem Speicher in Sync gehalten werden muß - spätestens vor dem Herunterfahren!)