Kann mir jemand von den alten Hasen vielleicht dabei helfen *auszurechnen*, wie man die effektive maximale Transferrate z.B. einer 20 MBit-Leitung ermittelt?

20 MBit muss man ja von vornherein durch 8 Teilen, um die Byte zu bekommen.
Kommen da dann noch Parietäts-Bit dazu? Ich meine, man bräuchte 10 bit, um 1 Byte zu übertragen?
Wieviel Byte rechnet man, um effektiv 1024 Byte (= 1 kb) per IP zu übertragen?

Ich bräuchte die Zahl, um mal eine Vorstellung davon zu bekommen, was wirklich in so eine Internet-Anbindung unter optimalen Umständen (0 packet loss) drinne sind.

Das wäre echt nett und sehr hilfreich!

Johannes

Antwort auf [ JWeitzel ]

[...]20 MBit muss man ja von vornherein durch 8 Teilen, um die Byte zu bekommen. Kommen da dann noch Parietäts-Bit dazu? Ich meine, man bräuchte 10 bit, um 1 Byte zu übertragen?
Wieviel Byte rechnet man, um effektiv 1024 Byte (= 1 kb) per IP zu übertragen?

Die Nettoübertragungsleistung hängt vor allem vom verwendeten Übertragungsprotokoll ab. IP ist zwar involviert aber nur eine Komponente von mehreren. Auf IP kommt noch TCP oben drauf und darauf erst kommt dann das eigentliche Übertragungsprotokoll wie zB FTP, RSYNC, AFP, SMB, SMTP etc. Ein TCP/IP basiertes Datenpaket ist (Brutto) idR 1500 Byte gross. Das Tara (um bei dieser Terminologie zu bleiben) nennt man Overhead und der setzt sich aus dem IP Header[1] (ca. 20 Byte), dem TCP Header[2] (ca. 20 Byte) zusammen. Im TCP Header ist auch die erste Checksumme enthalten, was der von dir angesprochenen Parität entspricht. Wird UDP statt TCP verwendet, entfällt die Checksumme, dieses Protokoll ist verbindungslos und wird hauptsächlich bei Streaming Übertragungen verwendet. Hilft ja nix, wenn bei einem Telefongespräch mal ein "Ha" verschluckt wird und man dieses dann später noch nach reicht ;-) Anyway, das macht bis hierhin schon mal 40 Bytes Overhead, verbleiben noch 1460 Byte Nutzlast oder Payload. Davon sind dann ggf diverse Bytes für zB PPPoE (DSL) abzuziehen (ca. 8 Byte, ein Schnäppchen ;-)

Jetzt kommen die eigentlichen Übertragungsprotokolle zum Tragen, welche wiederum, je nach Protokoll, einen eigenen Overhead mitbringen. FTP hat zB sehr wenig Overhead was uA dafür sorgt, dass FTP bis heute eines der nativ schnellsten Übertragungsprotokolle ist. SMTP dagegen ist die Verschwendung pur. Hier werden 3 Byte Binärdaten in 4 Byte ASCII Daten kodiert, was einen Zuwachs (bzw. Verlust) von ca. 33% ausmacht[3]. Wenn das die Leute mal wüsten, die täglich tonnenweise Daten per E-Mail durchs Netz schaufeln.

Bei SMB (Das Microsoft Übertragungsprotokoll) verhält es sich höchst unterschiedlich bzgl. des Overheads. Wird zB SMB-Signing verwendet, was in Active Directorys zumindest von und zu den Domänenkontrollern per Default aktiviert ist, legt da nochmal tüchtig was drauf. Hat man dann noch einen paranoiden Admin, der aus seinem Netz einen Hochsicherheitstrakt machen will (oder muss), kann es ein zäher Prozess werden. Schnelle LANs und Bücher füllende Registry Tweaks sorgen dann wieder für Abhilfe. Die genauen Zahlen bzg. SMB kenne ich nicht (und BTW auch die der anderen Protagonisten auf Layer 5 nicht) aber man kann mal so als Hausnummer von einer Nettoübertragung bei SMB von (IMHO maximal) ca. 8MB/s ausgehen (bei einem 100MBit/s LAN)

Deine 20Mbit hören sich nach WAN Übertragung an (Internet) und hier käme es wiederum auf den genauen Zweck der Übertragung an. SMB und AFP ist dafür im Prinzip nicht gedacht, außer man sichert das mindestens noch mit SSL[4] ab, was aber auch wieder einen Overhead erzeugt. RSYNC zB ist so ein Kandidat, welcher mit einigen Tricks und Datenkompression die Nettoübertragung signifikant erhöhen kann, wenn die Voraussetzungen dafür günstig sind. Aber der langen Rede kurzer Sinn, du kannst je nach Art der zu übertragenen Daten (große Daten verhalten sich zB günstiger wie kleine) und des verwendeten Protokoll von ca. 50 - 75% Nettonutzlast kalkulieren. Details müsste man im Einzelfall ausarbeiten, die Ausnahmeliste reicht von hier bis nach Paris ;-)

Noch Fragen? Dann fragen!

HTH & Bye Tom

[1] http://de.wikipedia.org/wiki/IP-Paket
[2] http://de.wikipedia.org/...ion_Control_Protocol
[3] http://wiki.prontosystems.org/it:ftp_smtp
[4] http://de.wikipedia.org/...sport_Layer_Security

Herzlichen Dank!
Eine sehr ausführliche, natürlich zum guten Teil mein "intellektuelles Niveau" ;-) übersteigende Antwort. Aber so war ja auch die Frage gestellt.

Der Hintergrund ist der, dass bei uns in der Firma (Buchverlag) an den Macs im Jahr ca. 1 TB Daten anfallen - wenn wir unsere eigenen Inhalte alle sammeln täten. Nun ist "man" in die wohl "cloudcomputing" zu nennende IT eingestiegen, die Server stehen nicht mehr im Haus und die Macs sollen per smb (oder cifs?) ihre Daten in der Cloud ablegen. Seit dem geht hier quasi nichts mehr (für 550 MB 46 Minuten Kopierzeit). Und "man" versucht nun, dahinter zu kommen, warum.

Vielleicht ist/wird ja dieser thread auch für andere interessant, die sich mit ähnlichen Gedanken tragen.

Besten Dank nochmal

Johannes

Hi,

"Cloud Computing" daher weht also der Wind. Na dann wünsche ich euch viel Spaß damit. Die Clouds sind in meinen Augen eine Zukunftsvision mit ersten zarten Ansätzen in der praktischen Umsetzung. Die verfügbaren Bandbreiten für WAN Verbindungen haben sich in den letzten 10 Jahren zwar deutlich erhöht, sind aber für die Auslagerung von Fileservern immer noch zu niedrig bzw. nicht bezahlbar. Das wird sich den nächsten 10 Jahren sicherlich auch noch ändern aber derzeit ist das gerade für uns (Druckvorstufe, grafisches Gewerbe) noch kein Thema.

Ich hoffe ihr habt nicht nur einen stinknormalen (A)DSL Anschluss, welcher nur einen Bruchteil an Upload im Vergleich zur Downloadbandbreite hat. Wir zahlen hier in der Wallachei derzeit 800.- / Monat für eine 10MBit Company Standleitung und das ist ohne Clouds schon grenzwertig. Aber wir haben hier aktuell ein ähnliches Problem und recherchieren gerade fieberhaft an diesem Thema. Wir haben die Auflage eines Kunden bekommen, im Katastrophenfall (Brand etc) innerhalb von 24 Stunden dem Kunden die Daten zur Verfügung zu stellen. Das kann auch nur so funktionieren, dass wir täglich unsere Fileserver an einen anderen Standort syncen. Bei 10 MBit und täglich ca. 20 bis 30 GB anfallende Daten macht das keinen Spaß. Und die Problematik, dass alle Daten neu synchronisiert werden, wenn sich nur der Verzeichnisname ändert, macht das System hochgradig anfällig. Aber mir bleiben noch 3 Wochen bis ich ein stimmiges Konzept vorlegen muss.

550 MB in 46 Minuten ist aber wirklich nicht viel aber hier werden wohl viele kleinere Daten anfallen, was den Overhead natürlich deutlich ansteigen lässt. Dazu wird sich vermutlich noch der restliche Internetverkehr wie die E-Mails etc mischen und schon bricht das ganze ein. Fehlt nur noch, dass ihr Internettelefonie betreibt und fertig ist der Daten Super Stau. Bei meinen Recherchen bin ich über (Hardware) Datenkompressoren gestolpert, die man jeweils am Perimeter Gateway anschließt aber die kosten ein Vermögen, so ca. 25.000.- / Stück und AFAIK braucht man mindestens zwei davon. Stichwort zum googeln: WAN Accelerator.

Was fallen denn bei euch so täglich an Daten an, die so an einem repräsentativen Durchschnittstag über diese Leitung gehen? Wie viele Benutzer ? Wie viele arbeiten in der Bildbearbeitung? Wie viele in der Verwaltung? Wird über Internet telefoniert? habt ihr einen FTP Server? Wie viele Daten bekommt ihr täglich rein (nicht aus der Cloud) oder wie viele gehen raus (nicht in die Cloud)? Und was erhofft man sich bei euch durch Cloud Computing zu erreichen?

Bye Tom

Da ich in erster Linie Anwender (DTP) und dann noch Systembetreuer/Supporter bin (11 Macs, abe rnur bis zur Wandsteckdose) bin, kann ich die meisten Deiner Fragen leider nicht beantworten :-( Die 550 MB waren ca. 25 PDF-Dateien eines voll bebilderten Buches, also nicht viele Einzeldateien.
Ich selber habe die Sichtweise, dass in Arbeitsgruppen die Beteiligten ihre Gestaltungen auf einem Server liegen haben (bisher Helios Ethershare), damit kurzfristig eine Nebentätigkeit (z.B. Freisteller in PSD) durch andere wahrgenommen bzw. eine Tätigkeit an jemand dritten übergeben werden können. Dies scheint mir mit einem Server "in der cloud" derzeit nicht praktikabel. Ich bin gewohnt, ca. alle 5-10 Minuten "Apfel-S" (speichern) reflexartig zu drücken. Na dann prost...

Der normale in- out-traffic größerer Datenmengen geht über ftp. Leider ist nicht allseits bekannt, dass dabei die Type-1 PS Schriften futsch gehen. Also jeweils zippen...

Ansonsten kein/kaum Internettelefonie.

Soviel dazu.


Grüßle!

Wer hat euch denn die Cloud Computing Geschichte aufgeschwatzt? So was macht man doch nicht einfach so. Das sollte doch jemand mal theoretisch mit euch durchgesprochen haben, die Anforderungen sollten analysiert worden sein und praktisch sollte das ganze doch mindestens eine Zeit lang in eine Testphase gehen. Die Umstellung auf ausgelagerte Server ist schon eine signifikante Änderung in der Infrastruktur und ohne es jetzt im Detail zu wissen, gehe ich schon davon aus, dass das ganze auch nicht gerade billig sein wird. Da hat sich ein Tuareg in der Sahara mal einen tiefer gelegten Sportwagen andrehen lassen, weil der weniger Benzin verbraucht, wie sein Geländewagen. Lange war er nicht glücklich damit, dann ist das Ding in einer Staubwolke verschwunden ;-)

Nein Spaß beiseite, ich kann von hier aus nicht an einer konstruktiven Lösung für euer Problem mit helfen (so gerne ich das täte) aber diese Angelegenheit hat offensichtlich nicht nur technische Probleme sondern auch politische. Irgendwer hat sich das ja eingebildet oder aufdrehen lassen aber ich wäre zumindest am weiteren Fortschritt in dieser Sache interessiert. Vielleicht finden sich ja interessante Ansätze die das Problem technisch lösen oder zumindest eingrenzen können. Das wäre natürlich schön, dass zu erfahren.

Ansonsten wünsche ich euch viel Erfolg mit eurer Wolke.

Bye Tom

Hallo

zur Abschätzung:

20 MBit pro Sekunde ist für Internetseite viel, aber für verteiltes Arbeiten traurig wenig. 20 / 8 ist ergibt die theoretische möglichen Megabyte pro Sekunde (also 2,5) - die theoretischen, wenn:
- nur einer im Haus die Leitung nutzt
- keine sonstigen Störungen auftreten
- und ihr vor allem tatsächlich eine symmetrische 20 MBit-Leitung habt und nicht irgendeine der billigen asynchronen. (Die 46 Minuten für den Upload von 550 MB deuten auf eine asynchrone Anbindung hin, mit einem Upload von 1-2 Mbit ...)
- und selbst wenn alles stimmt, erreicht ihr die nicht. Realistisch würde ich sagen, etwa 2 MB. Also Rechner A sichert 500 MB und belegt die Leitung für 250 Sekunden. Derweil sichert Rechner B und beide teilen sich die Leitung, also mindestens 500 Sekunden für beide ... viel Spaß ... soviel Kaffee kann man gar nicht trinken.

Zum Vergleich:
USB 2.0 hat 600 Mbit und das wird beim Arbeiten auf einem Server als langsam empfunden. Firewire 800 hat 800 und Ethernet 1000 Mbit.

Wenn ihr arbeiten wollt, dann schafft das ab.
Gruß

Hallo Tom und Peter,
herzlichen Dank für Eure Informationen und Einschätzungen!

Da ich selbstverständlich mich meinem Arbeitgeber gegenüber loyal zeigen sollte, scheint es mir besser zu sein, an dieser Stelle allerhöchstens sich mit PM weiter auszutauschen.

Anyway, ich muss erstmal die genaueren technischen Fakten unserer "cloud IT" recherchieren, denn mit den 20 MBit kommt mir das für einen Servereinsatz tatsächlich aussichtslos vor.

In die cloud umzuziehen ist ja zur Zeit hip. Warum man das tut, entzieht sich meiner Einsicht. Habe aber selber von einschlägigen Groß-IT-Firmen Prospekte bekommen, die anbieten, gleich auch noch die Mitarbeiter abzulösen ;-)

Die Interpretation/Würdigung des Szenarios gehört dann nicht mehr hier her.

Bis denne
Johannes

Antwort auf [ JWeitzel ]

[...]In die cloud umzuziehen ist ja zur Zeit hip. Warum man das tut, entzieht sich meiner Einsicht. Habe aber selber von einschlägigen Groß-IT-Firmen Prospekte bekommen, die anbieten, gleich auch noch die Mitarbeiter abzulösen[...]

Hip ist das nur in Hochglanzprospekten, bei der Kaltakquise und bei Steve Jobs. Wenn es nach dem geht, haben wir in 10 Jahren gar keine Rechner mehr, sondern laufen alle mit iPads und Smartphones rum. Und Apple macht sich bei seiner iTunes Store Politik im Moment auch nicht gerade beliebt. Was glauben die wer sie sind, zu bestimmen welche Inhalte ich mir auf meinem iPad anschaue und welche nicht? Wär ja grad so, als ob Samsung oder Löwe bestimmen würde, welche Programme ich auf deren Fernsehern anschauen kann und welche nicht...

Schau dir Wikileaks an, weil es gerade so ein Topthema ist. Da macht Amazon mal eben die Server dicht, weil sich ein paar politische Schwergewichte in den USA auf den Schlips getreten fühlen. Die sind dann quasi aus allen Wolken gefallen, wobei Julian Assange gerade ein anderes Problem an der Backe hat, die wollen seinen Kopf rollen sehen. Aber es zeigt, in welche Abhängigkeit man sich begeben kann. Und Wikileaks ist beileibe nicht der erste Server der auf Nachdruck dicht gemacht wurde.

Die ganze Cloud-IT Geschichte könnte ich mir vorstellen, bei einem kleinen Betrieb, eine Schlosserei oder ein Autohaus vielleicht. Aus den Augen aus den Sinn, da will man sich mit dem IT Krempel nicht besonders auseinander setzen, ist hoch standardisiert und wird eh schon zT zentral verwaltet. Aber eine Druckvorstufe? Wo täglich Gigabyte an Daten im zwei- bei großen sogar im dreistelligen Bereich verarbeitet werden? Für die stehen die Wolken imho noch recht hoch am Himmel. Cirrius zB... ;-)

Bye Tom

Hi,

auch mich hat vor einem Jahr so ein "Dienstleister" zu
so einer Geschichte versucht zu überreden.
Ich habe vorher kurz kalkuliert was ich an Daten täglich
habe und wie dick oder dünn meine Leitung ins Netz ist.

Fazit: So eine Dienstleistung ist für unsere Branche
schlichtweg totaler Blödsinn, aber die versuchen es
halt überall und denken nur Provisionorientiert...

Vergesst sowas....