Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden.
Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
News ARM-Server-Prozessor: 40 Modelle des ThunderX2 mit bis zu 32 Kernen verfügbar
Piktogramm
Admiral
- Registriert
- Okt. 2008
- Beiträge
- 9.166
@eremit007:
Was für Cryptokram? Wenn du dir OpenSSL anschauen magst sind die gängigen Cryptoalgorithmen da für mehrere Architekturen in Assembler umgesetzt.
https://github.com/openssl/openssl/tree/master/crypto/aes/asm
Wobei da die Optimierungen der EVP-Bibliotheken glaub noch garnicht vorkommt (die sollten in openssl/crypto/evp liegen?!) und auch da ist allerhand von Hand optimiert worden.
Die Differenzen in der Performance von Binaries die aus C-Code statt Assembler erzeugt wurden recht groß sind. HTTPS auf einem Produktivsystem kann man sich eigentlich komplett vergessen. Dazu will man schon die handgeklopften Funktionen nutzen oder noch besser die EVP Implementierung.
https://wiki.openssl.org/index.php/EVP
Was für Cryptokram? Wenn du dir OpenSSL anschauen magst sind die gängigen Cryptoalgorithmen da für mehrere Architekturen in Assembler umgesetzt.
https://github.com/openssl/openssl/tree/master/crypto/aes/asm
Wobei da die Optimierungen der EVP-Bibliotheken glaub noch garnicht vorkommt (die sollten in openssl/crypto/evp liegen?!) und auch da ist allerhand von Hand optimiert worden.
Die Differenzen in der Performance von Binaries die aus C-Code statt Assembler erzeugt wurden recht groß sind. HTTPS auf einem Produktivsystem kann man sich eigentlich komplett vergessen. Dazu will man schon die handgeklopften Funktionen nutzen oder noch besser die EVP Implementierung.
https://wiki.openssl.org/index.php/EVP
mensch183
Captain
- Registriert
- Jan. 2008
- Beiträge
- 3.666
Bibliotheken mit Krypto-Algorithmen ... Openssl, NSS, ./{arch/*/}crypto/* in Linux usw.eremit007 schrieb:@Piktrogramm
Was für Cryptokram?
Deine Felder, denen angeblich die Architektur egal ist, nutzen dann solche Bibliotheken und damit auch deren Optimierungen. Kryprokram steckt heute fast überall drin.
Piktogramm
Admiral
- Registriert
- Okt. 2008
- Beiträge
- 9.166
eremit007 schrieb:@Piktogramm
Aber die openssl-libs gibt's ja für ARM?
Es gibt Assembler für AES unter ARM, das ist aber eher eine Notlösung für ARM CPUs ohne Cryptoerweiterungen (z.B. AES-Ni für X86 CPUs). Es ist halt die Frage ob Cavium Crypto in Hardware umsetzt und wie gut da dann u.a. die Bibliotheken von OpenSSL gepflegt werden. Da müsste man dann aber wirklich mal einen intensiveren Blick drauf werfen.
S
smalM
Gast
Einen ThunderX2 baut man nicht in einen Rechenknecht, ist die CPU doch eher auf Content-Delivery ausgerichtet.
Für großartig Anderes fehlt es den Cores an Resourcen.
@Piktogramm
Eine Crypto-Unit, die sich den Execution-Port mit ALU, FP/NEON und Int Mul/Div teilen muß.
Für großartig Anderes fehlt es den Cores an Resourcen.
@Piktogramm
Eine Crypto-Unit, die sich den Execution-Port mit ALU, FP/NEON und Int Mul/Div teilen muß.
Zuletzt bearbeitet von einem Moderator:
Piktogramm
Admiral
- Registriert
- Okt. 2008
- Beiträge
- 9.166
@smalM
Hast du ne Quelle die da gescheit ins Detail geht?
Bzw kannst du Ähnlichkeiten Differenzen bei der Implementierung bei Beispielsweise x86er CPUs beschreiben? Wäre spannend
An sich sollte es ja in Ordnung sein bereits vorhandene Ressourcen auf der CPU zu nutzen.
Hast du ne Quelle die da gescheit ins Detail geht?
Bzw kannst du Ähnlichkeiten Differenzen bei der Implementierung bei Beispielsweise x86er CPUs beschreiben? Wäre spannend
An sich sollte es ja in Ordnung sein bereits vorhandene Ressourcen auf der CPU zu nutzen.
Zuletzt bearbeitet:
Haldi
Admiral
- Registriert
- Feb. 2009
- Beiträge
- 9.731
Das ist doch mal eine sehr interessante aussage.Particle010 schrieb:Bei Cloudflare überlegt man wohl, langfristig ganz auf ARM umzusatteln: https://www.golem.de/news/cpu-architektur-cloudflare-koennte-komplett-auf-arm-cpus-wechseln-1803-133478.htmlDas wird natürlich aber auch von den Workloads abhängen
Gibts davon mehr? Nimmt mich wunder wer alles auf ARM umsatteln möchte.
- Registriert
- Juni 2001
- Beiträge
- 18.729
Artikel-Update: Gegenüber The Next Platform hat Cavium zumindest 35 Modelle der neuen Chips im Detail erklärt, die weiteren sollen für gewisse Aufgaben und Hersteller separat spezifizierte SKUs sein. Die Topmodelle sollen dabei in einer TDP-Liga der Xeon SP spielen und bei bis zu 200 Watt arbeiten.
[Bilder: Zum Betrachten bitte den Artikel aufrufen.]
Artikel schrieb:Beworben wird die neue Prozessorfamilie mit einem 256 KByte großen L2-Cache pro Kern, der gesamte SoC wird dabei flankiert von einem gemeinsam genutzten 32 MByte großen L2-Cache und acht Speicherkanälen, die mit schnellem DDR4 umgehen können.
Müsste es beim Zweiten L2 nicht L3 heissen?
KurzGedacht
Lt. Commander
- Registriert
- Mai 2013
- Beiträge
- 1.755
Auf dem Großteil aller relevanten Server der Zielgruppe läuft open-source Software die problemlos auch auf Arm genutzt werden kann.leipziger1979 schrieb:Wie soll das gehen ?
Wenn ich eine x86-x64 Umgebung habe wird das nichts.
Es macht nur Sinn wenn ich schon ARM nutze oder entsprechend umsteigen kann.
KurzGedacht schrieb:Auf dem Großteil aller relevanten Server der Zielgruppe läuft open-source Software die problemlos auch auf Arm genutzt werden kann.
ARM server ist ein Witz! ARM hat in den letzten 10 Jahren praktisch alle Marktanteile an X86 verloren.
X86 ist die Technologie auf dem Vormarsch und nicht anders herum!
Qualcomm hat gerade eben seinen Ausstieg bekannt gegeben:
https://www.bloomberg.com/news/arti...to-plan-exit-from-server-chips-amid-cost-cuts
Hier verschenken sie ein paar 32 kerner, der Große wurden gestrichen weil ihre chips nicht Konkurenzfähig sind wenn man mehr als 1000€ dafür verlangt!
Seit AMD´s rückkehr in den Server markt gibt es keine existenzgrundlage mehr für ARM server (abgesehen von ein paar neischenanwendungen).
T
Teralios
Gast
Hatte ARM jemals einen signifikanten Marktanteil im Bereich Server? Ich mag mich täuschen, aber sogar bis Anfang der 10er Jahre hatte ARM meist nur In-Order-Designs und hat im Bereich der Server überhaupt keine Rolle gespielt. x86 konnte da sicher keine Marktanteile von ARM "erobern" oder sonst wie akquirieren.simons700 schrieb:
Die wirklich ersten ARM-Server-Meldungen kamen mit ARMv8 und der entsprechenden 64Bit-Archichtektur auf. Und x86 spielt im Bereich Server auch eher dank AMD eine Rolle durch die x86_64-Erweiterung und ja, da konnte die Architektur mit der Zeit Marktanteile von IA64 (Intel selbst) und PowerPC sowie Sparc erobern. IA64 ist de facto verschwunden und PowerPC ist in der Regel nur noch bei SuperComputern aktuell interessant, aber sonst auch Bedeutungslos.
Und ja, Qualcom mag nun auch wieder aussteigen, andere bemühen sich jedoch weiter. Gerade für "Webserver" und "Datenbankserver" könnte ARM interessant sein. Nur irgendwer muss es sich nun langsam trauen.
Hier liegt auch das bekannte Henne-Ei-Problem vor. Ohne Angebot keine Nachfrage, ohne Nachfrage kein Angebot.
textract
Lt. Commander
- Registriert
- Aug. 2011
- Beiträge
- 1.744
@Teralios
Ich gebe die bezüglich ARM vollkommen Recht, die hatten nie Makrtanteile, aber was POWER muss ich dich korrigieren.
Quasi jede Bank in Deutschland setzt noch auf z oder p Systeme und auch in Großunternehmen spielt POWER eine große Rolle.
Intel ist für Standardsoftware nicht skalierbar genug. Eine Oracle Datenbank mit 80 TB aus 1000 LUNs +- arbeitet AIX zum Beispiel spielend leicht weg, solange die Hardware unten drunter stimmt. Systeme mit 100 CPUs und 10 TB RAM sind da keine Seltenheit.
Beispiele für deutsche Firmen, die immernoch POWER-Kunden sind, sind Bosch, Daimler, BASF, Siemens, Deutsche Bank, kfw, Lotto, DM und viele mehr.
Ich sehe den Trend sogar eher entgegengesetzt: IBM verliert im HPC Umfeld massiv an Kunden, während im Rechenzentrum wieder einige zurück auf POWER gehen.
Ich gebe die bezüglich ARM vollkommen Recht, die hatten nie Makrtanteile, aber was POWER muss ich dich korrigieren.
Quasi jede Bank in Deutschland setzt noch auf z oder p Systeme und auch in Großunternehmen spielt POWER eine große Rolle.
Intel ist für Standardsoftware nicht skalierbar genug. Eine Oracle Datenbank mit 80 TB aus 1000 LUNs +- arbeitet AIX zum Beispiel spielend leicht weg, solange die Hardware unten drunter stimmt. Systeme mit 100 CPUs und 10 TB RAM sind da keine Seltenheit.
Beispiele für deutsche Firmen, die immernoch POWER-Kunden sind, sind Bosch, Daimler, BASF, Siemens, Deutsche Bank, kfw, Lotto, DM und viele mehr.
Ich sehe den Trend sogar eher entgegengesetzt: IBM verliert im HPC Umfeld massiv an Kunden, während im Rechenzentrum wieder einige zurück auf POWER gehen.
Jesterfox schrieb:Selbst Microsoft .NET Core läuft auf ARM... habs sogar schon live auf einem RaspberryPi mit Linux gesehen ;-)
Diverse große Webportale und Onlineshops nutzen längst .Net Core auf Linuxbasis (zugegeben viele wohl trotzdem auf x86). Vor allem bei modernen Architekturmodellen wie React oder Views mit einer Microservice-Architektur hintendran, ist es ja recht leicht, nach und nach umzuziehen auf .net Core und Linux.
Wir haben jedenfalls bisher quasi keine probleme damit feststellen können und ein paar der der Server in der Lastverteilung der Testsysteme wohl auch schon mit ARM am laufen (frag mich nicht was genau, so tief war ich da nicht drin).
Im Gegensatz dazu zeigen sich seltsame Verhaltensweisen bei manchen Portalen seit diese auf die aktuelle Windows-Server und IIS-Version umgezogen wurden. Seither gibts immer wieder mal 100% loads auf den CPUs. Die APIs auf Linux laufen dagegen butterweich - obwohl dort sehr viel mehr Traffic zusammenkommt.
Zuletzt bearbeitet:
SoDaTierchen schrieb:ARM-CPUs kann man nur ganz oberflächlich mit x86-CPUs vergleichen, also die Leistung im Vergleich zu Skylake-EP / Epic ist ein unsinniger Vergleich. ARM-Software läuft nicht auf x86-Architektur und umgekehrt.
Ich habe aber mal gelesen, dass die Leistung der ARM-Modelle den x86-Modellen gleichen Preises leicht überlegen ist. Nimmt man Modelle gleicher Spezifikationen, dann verlieren die ARM-Modelle ausnahmslos. Der Wert Watt/Leistung war bei ARM minimal besser, aber kaum der Rede wert. Selbst für den 24/7-Betrieb kaum der Rede wert.
Was für ein Blödsinn.
Die Leistung einer CPU-Architektur lässt sich sehr wohl auch über ISAs hinweg vergleichen, zumindest die theoretische Leistung.
Aber ein Leistungs-vergleich einer ISA allein, also ohne konkrete Produkte zu nehmen, ist Sinn befreit. Da wirst du auch keine Quellen für finden, denn wenn dann ging es immer um den vergleich konkreter Prozessoren.
Das ist so als wenn ich behaupte: Elektroautos sind stärker als Benziner. Solche Technologievergleiche sind auch nicht machbar, da es um die konkreten Automodelle geht, die man vergleicht. S-Klasse vs Tesla Model S, Renault Twizzy vs Smart, etc.
Man kann die konkretren Chip-Architekturen aber mit dem was wir jetzt wissen schonmal auf dem Papier vergleichen: Dabei findet man heraus dass der ThunderX2 im idealen Fall einen sehr ähnlichen Throughput pro Core hat wie AMDs Zen oder Intels Haswell/Broadwell Generation, bei optimaler SMT Ausnutzung etwas mehr. Wenn man sich also beim Cache, Speichercontroller, Branch Prediction etc. keine groben Schnitzer geleistet hat, dann kann die Architektur durchaus konkurrenzfähig sein.
btw, der Thunder X2 hat wirklich nichts mehr gemein mit dem originalen Cavium Thunder, sondern basiert auf dem eingekauften Vulcan Projekt von Broadcom. Ursprünglich sollte der Thunder 2 aus 64 Stück Atom-like Thunder 1 Cores bestehen. Stattdessen ist man den Xeon-like Pfad mit 32 beefigeren Cores und 4fach SMT eingeschlagen.
Frontend
Cavium spricht von "quad issue pipelines", das deutet auf einen Decoder hin der bis zu vier Instruktionen weiter gibt. Das ist vergleichbar mit der aktuellen Zen Konfiguration. Skylake hat einen 5-fach decoder, der aber auch Floating Point verarbeiten muss und damit bei reiner Integer Last einen Vorteil beim Decoder, aber bei gleichzeitiger FP Last ein Defizit.
Ob es einen micro Op cache gibt, bzw. wie effizient der branch predictor arbeitet wissen wir noch nicht. Beides ist wichtig für die Effizienz und threaded Leistung.
Scheduling & Register files
Der Thunder X2 bietet 4fach SMT, Intel und AMD nur 2fach. Dadurch sollten sich die vorhandenen Einheiten wesentlich besser auslasten lassen. Den Vorteilen bei multithreaded workloads stehen aber auch Nachteile bei Latenzen, höhere Cache Anforderungen und geringe Energieefizienz bei lightly threaded workloads gegenüber.
Mit 2048 Einträgen hat man einen riesigen TLB verbaut (doppelt so groß wie Intel)
Die Größe des Schedulers (Zen 84Int+96FP, Intel 97 total)) ist überraschender weise gering (60 ENtry total). und Register Files ist wahrscheinlich höher als bei AMD (168INT) und Intel (180INT).
INT Pipelines & ALUs
Die "quad issue pipelines" kann man auch in Richtung ALU Anzahl deuten, also das ebenfalls vier ALU vorhanden sind, wie auch bei der Zen Architektur. Wahrscheinlich sind wie etwa bei Zen und Skylake auch noch zwei AGUs für Load and Store vorhanden.
16nm TSMC mit Taktraten unter 3Ghz deutet wohl auf relativ kurze Pipelines hin, was gut für die IPC ist.
Floating Point
2x 128bit FP entspricht der FP-Breite von AMDs Zen und Intels Haswell/Broadwell Generation. Skylake-SP hat mit 2x256 plus 1x512b deutlich die Nase vorn, noch ist die Softwareunterstützung aber schlecht und der Energieverbrauch hoch. Im Normalfall nutzt Software nichtmal die 256bit FP funktionalitäten, sondern nur 128bit "quad precision". In diesen Fällen gibt es keinen Unterschied des FP-Durchsatz zwischen Zen, Skylake-SP und dem ThynderX2. Im Gegenteil, durch das geteilte Frontend schneidet SkylakeSP in FP-lastigen Benchmarks wie Raytracing (C-Ray, PovRay, NAMD) häufig schlechter ab als Epyc.
Cache und Memory Subsystem
Der 32kb L1$ in der 256kb L2$ pro Core ist genau so groß wie bei Intels Sandy, Ivy, Haswell, Skylake und damit kleiner als der L2 von Epyc, der darüber hinaus noch über 64kb dedizierten L1D$ verfügt. Da der L3 $ mit "distributed" 32mb auf 32 Cores exakt der Größe wie bei AMDs 32Core EPYC SKUs entspricht, wäre es interessant zu wissen ob es sich auch um einen reinen Victim-$ wie bei AMD handelt, oder einen Write-back-$ wie bei Intel.
Mit einem reinen Victim $ hängt man noch sehr an der DDR4 Speicherbandbreite, andererseits ist ein solcher $ auch einfacher zu konstruieren und verbraucht weniger Energie.
Den DDR4 PHY wird man sich ebenso wie bei AMD als IP eingekauft haben. Je nachdem ob es ein Cadence, Synopsys oder Rambus PHY handelt, entsteht hier ein interessanter Vergleich. AMDs Rambus PHY in der ZEN Architektur hat gegenüber Intel eine klare Latenz-Schwäche, taktet anscheinend mit demselben Ram auch noch weniger gut, aber bringt bei gleicher Kanal-Anzahl eine überlegene Bandbreite auf die Straße. Also eigentlich ideal für Multicore Serverprozessoren.
Fazit
Der Thunder X2 ist damit zufälligerweise viel näher an AMDs Epyc als an Intels Xeon, dem ursprünglichen Projektgegner. Wenn Cavium sich keine groben Schnitzer leistet, kann der Integer und Floating Point Durchsatz AMDs Top SKUs erreichen, mit der Chance dass die Performance bei mehr als 64 Threads noch besser skaliert. In Speicherlastigen Benchmarks werden beide CPUs alleine kiteinander konkurrieren, weit vor Intels Xeon Skylake-SP.
Das beide Hersteller pro CPU bis zu 4TB RAM, aber nur maximal 2 Sockel pro System unterstützen ist ebenfalls ein verblüffend Identisches Merkmal. Auch Cavium hat sich mit ICI="Inter -Chip Coherent Interface" ein "Infinity Fabric"-like Interconnect gebastelt, nur schlägt das durch die single-chip Lösung hoffentlich weniger auf die Core zu Core Latenzen aus.
Dafür muss Cavium aber erstmal delivern. Und die Software muss bereit stehen.
Dann steht aber auch schon AMDs Epyc Refresh bereit und die x86 Software ist perfekt optimiert. Es wird nicht einfach für Cavium, ohne einen klaren Vorteil in der Rohleistung wird es schwierig die Serverkunden davon zu überzeugen in eine relativ unerfahrene Infrastruktur zu investieren.
Zuletzt bearbeitet:
T
Teralios
Gast
Na ja, nur weil du ein paar Großkunden nennst, korrigiert es meine Aussage nicht wirklich.textract schrieb:Ich sehe den Trend sogar eher entgegengesetzt: IBM verliert im HPC Umfeld massiv an Kunden, während im Rechenzentrum wieder einige zurück auf POWER gehen.
Wenn man sich mal ein paar Zahlen holt, stehen in der Regel bei verkauften Server-CPUs ca. 96% Marktanteil (+/- wohl ein paar Prozent, je nach Quelle) gegenüber ca. 4% die sich unter ARM, PowerPC und Sparc und andere Architekturen aufteilen und ca. 1% soll ARM aus machen, also bleiben für PowerPC und Sprac ca. 3%.
Früher hatte Sparc als auch PowerPC deutlich höhere Marktanteile und x86 war bedeutungslos. Heute hat sich das Bild eigentlich vollständig gedreht. Man kann jetzt natürlich darüber streiten, ob Bedeutungslos hier die richtige Vorwahl ist, aber mit maximal 3% Marktanteil (+ ein paar Prozent je nach Statistik) spielt man wohl wirklich nur noch eine untergeordnete Rolle.
Piktogramm
Admiral
- Registriert
- Okt. 2008
- Beiträge
- 9.166
davidzo schrieb:Was für ein Blödsinn.
Floating Point
2x 128bit FP entspricht der FP-Breite von AMDs Zen und Intels Haswell/Broadwell Generation. Skylake-SP hat mit 2x256 plus 1x512b deutlich die Nase vorn, noch ist die Softwareunterstützung aber schlecht und der Energieverbrauch hoch. Im Normalfall nutzt Software nichtmal die 256bit FP funktionalitäten, sondern nur 128bit "quad precision". In diesen Fällen gibt es keinen Unterschied des FP-Durchsatz zwischen Zen, Skylake-SP und dem ThynderX2. Im Gegenteil, durch das geteilte Frontend schneidet SkylakeSP in FP-lastigen Benchmarks wie Raytracing (C-Ray, PovRay, NAMD) häufig schlechter ab als Epyc.
Du haust da gerade etwas durcheinander- Typischerweise werden die heutzutage sehr breiten Register nicht genutzt um einzelne Floats mit 128bit, 256bit oder 512bit zu rechnen. Typischerweise nutzt man die breiten Register um damit mehrere Werte gleichzeitig zu berechnen. In ein 512bit breites Register passen gleichzeitig 16 32bit Floats hinein, mit denen man gleichzeitig rechnen kann. (Stichwort Vektorisierung -> AVX).
Wobei sich dies nicht nur auf Floats bezieht, analog verfährt man auch mit Ganzzahlen.
T
Teralios
Gast
Stichwort: SIMD.Piktogramm schrieb:
Ist ja ganz nett, was Cavium da auf die Beine gestellt hat, kommt aber recht spät und ist weit von den angekündigten 54 Kernen entfernt. Unter der Berücksichtigung, dass selbst die 32 Kern Variante in der Liga um 200 Watt TDP mitspielt, will ich lieber gar nicht wissen, wie viel ein vergleichbar getaktetes 54-Kern-Äquivalent aus dem Sockel nuckeln würde. Womöglich ginge da ohne Wasserkühlung rein gar nichts oder man dreht die Taktrate wieder deutlich unter die 2,0-GHz-Marke, aber dann geht es mit jeglicher Single-Thread-Performance selbst unter einer optimierten ARMv8-Architektur zum Teufel (außer man heißt Apple).
Unter dem Kontext, dass mit Qualcomm wohl der mit Abstand größte "Hoffnungsträger" im ARM-Lager möglicherweise wie auch schon einige andere vorher das Handtuch wirft, stellt sich bei Cavium nur die eine Frage: Sind sie glaubwürdig genug, auch noch die nächsten Jahre Produkte und vor allem schnelle Weiterentwicklungen zu liefern...und das nicht nur auf schicken PowerPoint-Folien. Eine Produktgeneration wird nicht ansatzweise reichen, um dauerhaft ernsthaft Marktanteile von x86 abknabbern zu können.
Intel und AMD hauen i.d.R. einmal pro Jahr ein Architektur-Update raus und der Gegner für die ThunderX2 werden in wenigen Monaten nicht mehr Skylake-SP und EPYC 7000 Naples sein, sondern Ende 2018 Cascade-Lake-SP in 14 nm++ und sowie AMD EPYC Starship mit wie viel Kernen auch immer (48/64) und womöglich irgendwann in 2019 Ice-Lake-EP (10 nm+).
Unter dem Kontext, dass mit Qualcomm wohl der mit Abstand größte "Hoffnungsträger" im ARM-Lager möglicherweise wie auch schon einige andere vorher das Handtuch wirft, stellt sich bei Cavium nur die eine Frage: Sind sie glaubwürdig genug, auch noch die nächsten Jahre Produkte und vor allem schnelle Weiterentwicklungen zu liefern...und das nicht nur auf schicken PowerPoint-Folien. Eine Produktgeneration wird nicht ansatzweise reichen, um dauerhaft ernsthaft Marktanteile von x86 abknabbern zu können.
Intel und AMD hauen i.d.R. einmal pro Jahr ein Architektur-Update raus und der Gegner für die ThunderX2 werden in wenigen Monaten nicht mehr Skylake-SP und EPYC 7000 Naples sein, sondern Ende 2018 Cascade-Lake-SP in 14 nm++ und sowie AMD EPYC Starship mit wie viel Kernen auch immer (48/64) und womöglich irgendwann in 2019 Ice-Lake-EP (10 nm+).
Ähnliche Themen
- Antworten
- 39
- Aufrufe
- 9.301
- Antworten
- 41
- Aufrufe
- 13.632
- Antworten
- 52
- Aufrufe
- 9.999