Core2 und modern in einem Satz? Sorry, aber die paar clients deiner Familie spielen keine Rolle [...]
Die Diskussion ging so: 1. Ich: "[...], und AES-NI bieten fast ausschließlich modernere x86-, ARMv8- oder SPARC-Recheneinheiten." 2. Sie: "aes-ni bieten nur moderne Recheneinheiten? mit Verlaub mit Verlaub sandybridge ist aus 2011, prinzipiell gab es aes instructions weit früher [...]. keine Hardware die 2019 noch Relevanz und Verbreitung besitzt fälltiin deine [...] Argumentation" 3. Ich: "Das ist eine Frage der Definition von "modern". Innerhalb meiner Verwandtschaft und Bekanntschaft läuft [...], so z.B. zwei Core2 Duos, ein Phenom II, viele nicht-Exynos-prä-ARMv8-Android-Kommunikatoren usw."
Und nun kommen Sie mir mit gequirlten Scheiße? Sagen Sie mal, sind Sie eventuell ein bisschen dämlich? Übrigens stehen "Core2" und modern nicht im einem Satz. Es war ledigleich eins von mehreren Gegenbeispielen (siehe 3.) für "modern" nach meiner Definition, um Ihr Gegenargument zu entkräften und mein Argument zu stützen, mehr nicht. Was Sie da für einen Strick draus drehen, grenzt an Wahnsinn.
Das was bei dir die Zukunft ist wurde 2018 eigentlich flächendeckend umgesetzt, Verschlüsselung bei allen Websites [...]
"... ganz Gallien?" Nein, falsche Aussage! Gegenbeispiel: http://www.ard.de/
[...] und nein es war am cluster keine höhere CPU last zu sehen
Und Sie sind wohl in diversen Rechenzentren von Google, Facebook, Amazon, Netflix, Akamai, etc. daheim, um solche Sprüche klopfen zu dürfen...
Von Verfluchtnochmal_5987108 am Mi, 16. Oktober 2019 um 14:00 #
Die paar clients die wirklich noch mehr Strom für Verschlüsselung ziehen sind komplett irrelevant weil zum einen sehr wenige und zum anderen ziehen die auch ohne Verschlüsselung mehr als halbwegs moderne mit
Die ARD Website geht auch mit https
Nein, mein cluster läuft nicht bei Google sondern steht im Büro undhhosted knapp 1000 domains die seit mehr als 12 Monaten https only sind
Die paar clients die wirklich noch mehr Strom für Verschlüsselung ziehen sind komplett irrelevant weil zum einen sehr wenige und zum anderen ziehen die auch ohne Verschlüsselung mehr als halbwegs moderne mit
Diese Aussage ist haltlos, denn erstens nennen Sie keine belastbaren Beweis oder harte Fakten (etwa wie in diesem Kommentar), und zweitens ziehen Sie einen falschen Vergleich (altes Gerät ohne Verschlüsselung vs modernes Gerät mit Verschlüsselung). Es ging allein um den für Verschlüsselung zusätzlichen Energie-/Strombedarf. Die An- oder Abwesenheit von (verpflichtender) Verschlüsselung war und ist in diesem Zusammenhang unabhängig davon, ob sie auf eine alte oder modernen Maschine stattfindet (oder nicht). Für einen sinnvollen und aussagekräftigen Vergleich müssen die Szenarien der also ein konkretes Gerät An- bzw. Abwesenheit von (verpflichtender) auf der selben Hardware stattfinden. Natürlich wäre es repräsentativer den selben Vergleich auf mehreren Geräten durchzuführen.
Außerdem entfällt der erhöhte Energie-/Strombedarf nicht nur auf die Klienten.
Die ARD Website geht auch mit https
http://www.ard.de/ war nur ein Beispiel einer Webseite, die nicht verschlüsselt oder weiterleitet, um Ihre Aussage (s.o.) zu widerlegen. Was wollen Sie?
Falls Ihnen das nicht reicht, müssen Sie nicht weit schauen, [0].
Nein, mein cluster läuft nicht bei Google sondern steht im Büro undhhosted knapp 1000 domains die seit mehr als 12 Monaten https only sind
Und Sie haben die gemessene Last sicherlich auch auf das Volumen der Requests (Anzahl und Größe) normiert, bevor Sie diese vergleicht haben, korrekt? Falls nein, so würden Ihre Messungen nichts taugen, da sie in diesem Zusammenhang nicht vergleichbar/belastbar wären. Nur die Spitzen- oder Durchschnittslast zu betrachten, reicht hier nicht.
Von Verfluchtnochmal_5987108 am Mi, 16. Oktober 2019 um 15:35 #
Natürlich reicht die durchschnittliche CPU Last am Cluster denn nur die zählt und nicht die 0.5 Prozent Ausreißer die auf einem Liniendiagramm noch nicht mal zu sehen sind weil die für den gesamten Energieverbrauch schlichtweg keine Rolle spielen
Wenn die durchschnittliche Anzahl Requests und Traffic unverändert sind und du von einem Tag auf den anderen knapp 1000 domains auf https umstellst und sich in der durchschnittlichen Last auf der darunter liegenden Hardware nichts ändert was schliesst du daraus?
Wenn die durchschnittliche Anzahl Requests und Traffic unverändert sind und du von einem Tag auf den anderen knapp 1000 domains auf https umstellst und sich in der durchschnittlichen Last auf der darunter liegenden Hardware nichts ändert was schliesst du daraus?
... in diesem Zusammenhang reichlich wenig, denn - wie ich ja bereits schrieb - muss man die Last (auch / vor Allem) bezüglich des Volumens der verschlüsselt übertragenen Daten normieren. Haben Sie das berücksichtigt?
Zudem lässt sich von einer unveränderten Durchschnittslast (Über welche Definition von "Durchschnitt" reden wir eigentlich? Pro Zeitintervall gemessene Last durch diskretisierte Zeitdifferenz/Zeitintervallänge bzw. Messdauer?) nur bedingt auf die zeitliche Verteilung jener Last, bzw. der sie verursachenden Requests (Anzahl & Volumen) schließen. Die zeitlich integrierte Lastverteilung (nennen wir sie doch Lastsumme mit der Einheit Last mal Zeit) kann für zwei verschiedene Lastverteilungen die selbe sein. Hinter Ihren Daten können sich also verschiedene Lastverteilungen verstecken. Wie haben Sie gemessen? Über welche Dauer? Mit welcher Messauflösung?
Unabhängig davon arbeitet Hardware bei einer vorgeschriebenen "Lastsumme" (Definition s.o.) für gewöhnlich weitaus effizienter, wenn diese als konstante Lastverteilung statt mit kurzzeitig stark variierender Spitzenlasten anliegt. Denn so liegt die Rechenleistung der Hardware nicht brach (Hardware braucht auch im Idle Strom), die Hardware muss nicht wild zwischen Lastszenarien wechseln (kostet Zeit in Form von Rechenzyklen und Energie), und sie muss nicht ganz so hoch takten (Energiebedarf steigt üblicherweise superlinear oder überproportional mit dem Takt). Demnach können unterschiedliche Lastverteilungen bei gleicher "Lastsumme" unterschiedlichen Energiebedarf wecken. Oder können Sie diese Effekte anderweitig ausschließen?
Also lässt sich Ihre Aussage über die Irrelevanz von Verschlüsselung bezüglich der Durchschnittslast bzw. der daraus resultierende Energiebedarf auf der Grundlage dieser Daten nicht belastbar belegen. Es ist komplizierter als Sie hier zu verstehen geben. Ihre Ausführungen sind zu einfach.
Und angenommen, Ihre Aussage wäre korrekt, ließe sich daraus schlussfolgern, dass der durch Verschlüsselung zusätzlich anfallende Rechenaufwand keinen zusätzlichen Energiebedarf wecken würde. Das wäre wissenschaftlich nicht plausibel nachvollziehbar (Perpetuum mobile lässt grüßen!).
Von Verfluchtnochmal_5987108 am Do, 17. Oktober 2019 um 01:04 #
Wenn man so gar keine Ahnung wie du hat weiss man natürlich nicht dass die Datenmenge sekundär ist denn der hauptsächliche overhead bei https liegt im Handshake während dir aes-ni zwischen 2500 und 3000 MB pro Sekunde verschlüsselt (Megabyte, nicht Mbit)
Es ist nicht komplizierter, der cluster zeichnet ein Liniendiagramm mit der durchschnittlichen CPU last aller VM's auf allen nodes in MHz
Und nein, es ist nicht sehr wahrscheinlich dass genau am selben Tag wo man alles auf https umstellt nach 5 Jahren die Zugriffe auf alle Kundeseiten zufällig gewaltig einbrechen und den von dir behaupteten Anstieg der Last durch die Verschlüsselung zufällig verstecken
Natürlich wird es ein paar Rechenzyklen brauchen aber nicht signifikant sonst hätten wir 2018 nach Spectre/Meltdown und 2 Monate nach Umstellung auf https nicht bei der neuen Hardware nichtsschlicht und ergreifend die CPUs halbiert weil nach PHP7 zweijJahre zuvor die Hardware nur Däumchen gedreht hat
Wenn du dämlich recht hättest wäre der neue Cluster physisch gleich stark geblieben und wir hätten uns darüber gefreut dass die Optimierungen der letzten beiden Jahre Ressourcen für https frei geschaufelt haben, war aber nicht der Fall und ja der Austausch war seit 2015 geplant
1. Ich: "[...], und AES-NI bieten fast ausschließlich modernere x86-, ARMv8- oder SPARC-Recheneinheiten."
2. Sie: "aes-ni bieten nur moderne Recheneinheiten? mit Verlaub mit Verlaub sandybridge ist aus 2011, prinzipiell gab es aes instructions weit früher [...]. keine Hardware die 2019 noch Relevanz und Verbreitung besitzt fälltiin deine [...] Argumentation"
3. Ich: "Das ist eine Frage der Definition von "modern". Innerhalb meiner Verwandtschaft und Bekanntschaft läuft [...], so z.B. zwei Core2 Duos, ein Phenom II, viele nicht-Exynos-prä-ARMv8-Android-Kommunikatoren usw."
Und nun kommen Sie mir mit gequirlten Scheiße? Sagen Sie mal, sind Sie eventuell ein bisschen dämlich?
"... ganz Gallien?" Nein, falsche Aussage! Gegenbeispiel: http://www.ard.de/Und Sie sind wohl in diversen Rechenzentren von Google, Facebook, Amazon, Netflix, Akamai, etc. daheim, um solche Sprüche klopfen zu dürfen...Übrigens stehen "Core2" und modern nicht im einem Satz. Es war ledigleich eins von mehreren Gegenbeispielen (siehe 3.) für "modern" nach meiner Definition, um Ihr Gegenargument zu entkräften und mein Argument zu stützen, mehr nicht.
Was Sie da für einen Strick draus drehen, grenzt an Wahnsinn.
Die paar clients die wirklich noch mehr Strom für Verschlüsselung ziehen sind komplett irrelevant weil zum einen sehr wenige und zum anderen ziehen die auch ohne Verschlüsselung mehr als halbwegs moderne mit
Die ARD Website geht auch mit https
Nein, mein cluster läuft nicht bei Google sondern steht im Büro undhhosted knapp 1000 domains die seit mehr als 12 Monaten https only sind
Außerdem entfällt der erhöhte Energie-/Strombedarf nicht nur auf die Klienten.
http://www.ard.de/ war nur ein Beispiel einer Webseite, die nicht verschlüsselt oder weiterleitet, um Ihre Aussage (s.o.) zu widerlegen. Was wollen Sie?Falls Ihnen das nicht reicht, müssen Sie nicht weit schauen, [0].
Und Sie haben die gemessene Last sicherlich auch auf das Volumen der Requests (Anzahl und Größe) normiert, bevor Sie diese vergleicht haben, korrekt?Falls nein, so würden Ihre Messungen nichts taugen, da sie in diesem Zusammenhang nicht vergleichbar/belastbar wären. Nur die Spitzen- oder Durchschnittslast zu betrachten, reicht hier nicht.
[0] - Alexa Top100 Analysis
Natürlich reicht die durchschnittliche CPU Last am Cluster denn nur die zählt und nicht die 0.5 Prozent Ausreißer die auf einem Liniendiagramm noch nicht mal zu sehen sind weil die für den gesamten Energieverbrauch schlichtweg keine Rolle spielen
Wenn die durchschnittliche Anzahl Requests und Traffic unverändert sind und du von einem Tag auf den anderen knapp 1000 domains auf https umstellst und sich in der durchschnittlichen Last auf der darunter liegenden Hardware nichts ändert was schliesst du daraus?
Zudem lässt sich von einer unveränderten Durchschnittslast (Über welche Definition von "Durchschnitt" reden wir eigentlich? Pro Zeitintervall gemessene Last durch diskretisierte Zeitdifferenz/Zeitintervallänge bzw. Messdauer?) nur bedingt auf die zeitliche Verteilung jener Last, bzw. der sie verursachenden Requests (Anzahl & Volumen) schließen. Die zeitlich integrierte Lastverteilung (nennen wir sie doch Lastsumme mit der Einheit Last mal Zeit) kann für zwei verschiedene Lastverteilungen die selbe sein. Hinter Ihren Daten können sich also verschiedene Lastverteilungen verstecken.
Wie haben Sie gemessen? Über welche Dauer? Mit welcher Messauflösung?
Unabhängig davon arbeitet Hardware bei einer vorgeschriebenen "Lastsumme" (Definition s.o.) für gewöhnlich weitaus effizienter, wenn diese als konstante Lastverteilung statt mit kurzzeitig stark variierender Spitzenlasten anliegt. Denn so liegt die Rechenleistung der Hardware nicht brach (Hardware braucht auch im Idle Strom), die Hardware muss nicht wild zwischen Lastszenarien wechseln (kostet Zeit in Form von Rechenzyklen und Energie), und sie muss nicht ganz so hoch takten (Energiebedarf steigt üblicherweise superlinear oder überproportional mit dem Takt).
Demnach können unterschiedliche Lastverteilungen bei gleicher "Lastsumme" unterschiedlichen Energiebedarf wecken.
Oder können Sie diese Effekte anderweitig ausschließen?
Also lässt sich Ihre Aussage über die Irrelevanz von Verschlüsselung bezüglich der Durchschnittslast bzw. der daraus resultierende Energiebedarf auf der Grundlage dieser Daten nicht belastbar belegen. Es ist komplizierter als Sie hier zu verstehen geben. Ihre Ausführungen sind zu einfach.
Und angenommen, Ihre Aussage wäre korrekt, ließe sich daraus schlussfolgern, dass der durch Verschlüsselung zusätzlich anfallende Rechenaufwand keinen zusätzlichen Energiebedarf wecken würde. Das wäre wissenschaftlich nicht plausibel nachvollziehbar (Perpetuum mobile lässt grüßen!).
Wenn man so gar keine Ahnung wie du hat weiss man natürlich nicht dass die Datenmenge sekundär ist denn der hauptsächliche overhead bei https liegt im Handshake während dir aes-ni zwischen 2500 und 3000 MB pro Sekunde verschlüsselt (Megabyte, nicht Mbit)
Es ist nicht komplizierter, der cluster zeichnet ein Liniendiagramm mit der durchschnittlichen CPU last aller VM's auf allen nodes in MHz
Und nein, es ist nicht sehr wahrscheinlich dass genau am selben Tag wo man alles auf https umstellt nach 5 Jahren die Zugriffe auf alle Kundeseiten zufällig gewaltig einbrechen und den von dir behaupteten Anstieg der Last durch die Verschlüsselung zufällig verstecken
Natürlich wird es ein paar Rechenzyklen brauchen aber nicht signifikant sonst hätten wir 2018 nach Spectre/Meltdown und 2 Monate nach Umstellung auf https nicht bei der neuen Hardware nichtsschlicht und ergreifend die CPUs halbiert weil nach PHP7 zweijJahre zuvor die Hardware nur Däumchen gedreht hat
Wenn du dämlich recht hättest wäre der neue Cluster physisch gleich stark geblieben und wir hätten uns darüber gefreut dass die Optimierungen der letzten beiden Jahre Ressourcen für https frei geschaufelt haben, war aber nicht der Fall und ja der Austausch war seit 2015 geplant