Dell kondigt prototype ARM-server aan
Als proof-of-concept heeft Dell een server op basis van ARM-quadcore-processors aangekondigd. De 'Copper'-server moet dienen als testbed voor ontwikkelaars en ict-afdelingen, en is interessant vanwege het lage energieverbruik.
Het Copper-serverprototype is opgebouwd uit een 3U-chassis, waarin twaalf serversledes passen, met elk vier ARM-processornodes. In totaal kan een Copper-server dus gevuld worden met 48 processors. Deze Armada XP-chips worden geleverd door Marvell, hebben vier ARM-kernen die op een kloksnelheid van 1,6GHz draaien en zijn voorzien van 2MB-L2-cache.
Elke Marvell Armada XP-chip is gekoppeld aan een 2,5"-hdd die op 7200 toeren draait, terwijl de serversledes voorzien zijn van vier dimm-slots voor unregistered ddr3-geheugen, tot een maximum van 8GB per slot. Marvell is ook de fabrikant die de interconnect-technologie voor Copper levert. Zo is elke processornode voorzien van een 1Gb-ethernet uplink die verbonden is aan een Marvell-switch.
Dell biedt de Copper-ARM-server aan aan een select aantal klanten die cloud- en zogeheten 'Big Data'-toepassingen voor dergelijke servers met lightweight-processors willen ontwikkelen en testen. Verwacht wordt dat de vraag naar ARM-servers pas echt van de grond komt als de eerste producten op basis van ARM's ARMv8-architectuur met 64bit-instructieset verschijnen.
Copper wordt voorzien van Canonicals Ubuntu 12.04 LTS-besturingssysteem en Dell levert onder meer zijn Crowbar-opensource-beheersoftware en een ARM-versie van Apache Hadoop-software voor het analyseren van grote hoeveelheden, gedistribueerde data.
Naast Dell hebben ook andere fabrikanten serveroplossingen op basis van ARM-cpu's aangekondigd. Zo heeft HP eind vorig jaar een server met 288 ARM-quadcores aangekondigd, terwijl de firma Calxeda net als Dell een server met 48 ARM-quadcores gedemonstreerd heeft.
Reacties (47)
Het interessante hieraan is dat het vanwege het energiegebruik bijna een volwaardig alternatief is voor virtualisatie. In plaats van een heleboel virtuele servers heb je gewoon een heleboel echte. Het grote voordeel daarvan is natuurlijk dat je niet meer afhankelijk bent van een grote server die met zich een heleboel kleintjes neerhaalt bij problemen, maar dat elke server volledig zelfstandig kan werken.
Het is inderdaad correct dat het een stuk energiezuiniger is, maar waarom een alternatief voor virtualisatie? Deze dingen kunnen ook meerdere virtuele servers draaien. Waarom zou je zoveel kracht nodig hebben voor een simpele webserver? Laat de grote inderdaad op een aparte draaien, maar de kleinere gewoon samen?
Niemand heeft het over een webserver?
En niet elkvirtualisatie platform schaalt goed over meerdere machines. Daarom kan het juist handig zijn één grote machine te hebben.
En niet elkvirtualisatie platform schaalt goed over meerdere machines. Daarom kan het juist handig zijn één grote machine te hebben.
Ik denk inderdaad dat dit niet als vervanging van een virtuele machine moet worden gezien maar eerder als een aanvulling hier op. Hoeveel file servers kennen we wel niet die totaal niets te doen hebben (print servers is nog zo'n mooi voorbeeld). We hebben er honderden draaien (minimaal 1 voor elk land op deze planeet). Als ik die dingen op een virtuele machine op zo'n server kan plaatsen kan ik met veel minder ruimte veel meer hosten met veel minder verbruik en dus koeling etc...
Al met al spaar ik heel erg veel geld uit als ik alle machines die eigenlijk nooit echt een processor nodig hebben maar alleen behoefte hebben aan geheugen dan wel schijf ruimte.
Ook web servers zijn natuurlijk erg gebaad bij dit soort machines zeker als je high load servers hebt staan de hoge load is meestal voornamelijk het aantal threads dat je moet verwerken en niet zo zeer de reken intensieve taken die je uit moet voeren.. Op zo'n moment is zo'n machine erg handig om te hebben.
De reken kracht van dit soort oplossingen mag dan misschien niet al te groot zijn maar dat heb je in veel gevallen ook helemaal niet nodig. Voor big data zou ik toch voor een andere oplossing kiezen in veel gevallen maar goed dat hangt natuurlijk ook af van de taak (ik kan me op het moment niet zo snel een niet reken intensieve taak bedenken voor een big data project dat is alles)
Al met al spaar ik heel erg veel geld uit als ik alle machines die eigenlijk nooit echt een processor nodig hebben maar alleen behoefte hebben aan geheugen dan wel schijf ruimte.
Ook web servers zijn natuurlijk erg gebaad bij dit soort machines zeker als je high load servers hebt staan de hoge load is meestal voornamelijk het aantal threads dat je moet verwerken en niet zo zeer de reken intensieve taken die je uit moet voeren.. Op zo'n moment is zo'n machine erg handig om te hebben.
De reken kracht van dit soort oplossingen mag dan misschien niet al te groot zijn maar dat heb je in veel gevallen ook helemaal niet nodig. Voor big data zou ik toch voor een andere oplossing kiezen in veel gevallen maar goed dat hangt natuurlijk ook af van de taak (ik kan me op het moment niet zo snel een niet reken intensieve taak bedenken voor een big data project dat is alles)
Euh, als webhosting je business is, virtualiseer je dat niet. Dat heeft dan namelijk geen nut, want je hebt juist de performance van zo'n machine volledig nodig. Virtualisatie is voor een groot deel berust op het overhebben van machinecapaciteit, waardoor het efficient is om een stuk hardware te delen voor meerdere taken.Waarom zou je zoveel kracht nodig hebben voor een simpele webserver?
M.a.w, als deze dingen ook nog 's goedkoop zijn (zodanig dat je niet meer betaalt voor dezelfde hoeveeheid processing power) is dit voor webhosting een heel interessant product.
Virtualisatie doe je om verscheidene redenen. Niet meer afhankelijk zijn van hardware is er zo eentje. Dit creëert een bepaalde flexibiliteit, bijv. als je onderhoud aan hardware wilt doen. Je kunt de vm dan middels live migration naar een ander deel van je virtualisatie cluster verhuizen zonder enige downtime.
Bij veel kleine servers is het vaak ook zo dat de hardware die je kunt kopen pure overkill is (denk aan licentieservers). Als je dan meer servers op 1 stuk hardware. Het hebben van minder fysieke servers is veel vaker de reden waarom men virtualisatie gebruikt. Het bespaart kosten op beheer van hardware, ruimte, energie en koeling.
Als je overcapaciteit als reden voor virtualisatie geeft heb je het ook niet echt begrepen. Over virtualisatie moet wat meer nagedacht worden. Niet alles leent zich voor virtualisatie (bepaalde software die dan gewoonweg niet lekker werkt) en virtualisatie is om diverse andere redenen ook lang niet altijd wenselijk. Er komt ook een bepaalde complexiteit bij kijken omdat dingen wat moeilijker te visualiseren zijn (een switch met kabels kun je zien en de kabels kun je volgen; bij een virtuele omgeving wordt dat wat lastiger). Daarnaast wordt er eerst gekozen voor virtualisatie om daarna de juiste hardware binnen het budget er bij te zoeken. Dat is dus exact het tegenovergestelde als wat je hier suggereert. Jij lijkt te doelen op het recyclen van reeds aangeschafte hardware.
Of dit een interessant product is ligt er aan in hoeverre de performance is. Als het ding net zoveel energie gaat verstoken als de rest en dezelfde performance (of minder) levert is het geen optie. Als het weinig energie verstookt en ook minder performance heeft (wat je vaak ziet bij energiezuinig spul) dan is het ook nog maar de vraag of dit interessanter is. Dan zul je moeten gaan bepalen wat belangrijker weegt. Als je geen virtualisatie wilt doen en ook niet zit te wachten op de huidige hardware dat overkill is voor wat je wilt dan is dit prototype ARM server ongetwijfeld interessant. Moet alleen de software op ARM kunnen draaien...
Voor de goede orde: deze server is bedoeld om te spelen met ARM zodat men kan achterhalen welke dingen er wel/niet mogelijk zijn. Klanten hebben er om gevraagd, Dell geeft gehoor. Het is dus eigenlijk meer een project om te zien of dit uberhaupt wel interessant is of niet. Ben benieuwd.
Bij veel kleine servers is het vaak ook zo dat de hardware die je kunt kopen pure overkill is (denk aan licentieservers). Als je dan meer servers op 1 stuk hardware. Het hebben van minder fysieke servers is veel vaker de reden waarom men virtualisatie gebruikt. Het bespaart kosten op beheer van hardware, ruimte, energie en koeling.
Als je overcapaciteit als reden voor virtualisatie geeft heb je het ook niet echt begrepen. Over virtualisatie moet wat meer nagedacht worden. Niet alles leent zich voor virtualisatie (bepaalde software die dan gewoonweg niet lekker werkt) en virtualisatie is om diverse andere redenen ook lang niet altijd wenselijk. Er komt ook een bepaalde complexiteit bij kijken omdat dingen wat moeilijker te visualiseren zijn (een switch met kabels kun je zien en de kabels kun je volgen; bij een virtuele omgeving wordt dat wat lastiger). Daarnaast wordt er eerst gekozen voor virtualisatie om daarna de juiste hardware binnen het budget er bij te zoeken. Dat is dus exact het tegenovergestelde als wat je hier suggereert. Jij lijkt te doelen op het recyclen van reeds aangeschafte hardware.
Of dit een interessant product is ligt er aan in hoeverre de performance is. Als het ding net zoveel energie gaat verstoken als de rest en dezelfde performance (of minder) levert is het geen optie. Als het weinig energie verstookt en ook minder performance heeft (wat je vaak ziet bij energiezuinig spul) dan is het ook nog maar de vraag of dit interessanter is. Dan zul je moeten gaan bepalen wat belangrijker weegt. Als je geen virtualisatie wilt doen en ook niet zit te wachten op de huidige hardware dat overkill is voor wat je wilt dan is dit prototype ARM server ongetwijfeld interessant. Moet alleen de software op ARM kunnen draaien...
Voor de goede orde: deze server is bedoeld om te spelen met ARM zodat men kan achterhalen welke dingen er wel/niet mogelijk zijn. Klanten hebben er om gevraagd, Dell geeft gehoor. Het is dus eigenlijk meer een project om te zien of dit uberhaupt wel interessant is of niet. Ben benieuwd.
[Reactie gewijzigd door ppl op donderdag 31 mei 2012 19:59]
Nu wel, ja. Maar dit is er allemaal later bijbedacht. Toen virtualisatie in de kinderschoenen stond was dit allemaal compleet niet aan de orde. Maar al doende leert men en is men erachter gekomen dat er meer voordelen zijn.Virtualisatie doe je om verscheidene redenen. Niet meer afhankelijk zijn van hardware is er zo eentje.
Maar in de eerste instantie ging het om het efficienter omgaan met resources. (Voor servers-- op je desktop is 't een ander verhaal.)
Overigens-- ze zullen er wel zijn natuurlijk maar zover ik weet ken ik persoonlijk geen mensen die virtualiseren om de hardwareonafhankelijkheid.
Euh, dit is tegenstellend. Statische content moet je niet moeilijk over doen inderdaad, daar is elke moderne server makkelijk genoeg voor. Maar "web-apps" en "statische content" zijn mutually exclusive, en als je app-servers hebt (en dat kan net zo lief apache met php zijn als een java servlet engine) zit je waarschijnlijk al snel tegen de limieten van je machine aan te kijken. Als je app tenminste in enige mate gebruikt wordt.Als het statische content is krijg je een 1Gbit lijn op je sokken vol met een moderne CPU dus virtualiseren van web-apps heeft wel degelijk zin om efficientere hardware-reuse te hebben
[Reactie gewijzigd door CyBeR op vrijdag 1 juni 2012 01:18]
Juist die insteek (theoretisch dan, als Dell echt geluisterd heeft) trekt mij, gewoon simpelweg een server bouwen zodat je kan zien wat je wel/niet kan. Misschien dat je moeite hebt met de firmware of andere low-level hardware abstractie/interface laag, of dat er bepaalde management taken compleet anders lopen. En wat als je iets met controllers of hardware uitbreidingen wil doen? Of KVM/Serial remote management.. LOM? Alles wat je echt in de praktijk in productie wil hebben kan je gewoon 'echt' testen. In theorie kan alles, maar als er inderdaad in de praktijk een mogelijkheid is om gewoon een server te nemen, daar je software op te zetten, de normale procedures volgen (en dan natuurlijk niet op het allerlaagste niveau - sommige dingen bestaan misschien gewoon niet) en kijken of je dan uitrollen. Dat gaat alleen maar lekker bekeken worden met een fysiek apparaat. Misschien komen we er met z'n allen wel achter dat een betere opbouw van voedingen (bijv. een nieuwe DC (direct current) standaard zoals in sommige DC's (datacenters) beschikbaar is) een groot voordeel kan leveren. Of dat je anders over je hardware uitbreidingen / upgrade path moet denken, om dat daar verschillen in zitten. Misschien dat oude technieken gewoon niet meer bestaan, om dat de backwards compatibility die je met x86 (helaas) nog altijd hebt er voor ARM niet altijd in zit. Er zijn zo veel variabelen! Eindelijk ook ruimte voor het 'wegdoen' van oude dingen die je gewoon niet meer moet gebruiken, ook al 'waren ze zo makkelijk'.
Stel dat ze gewoon zeggen: deze server krijgt geen video support. Het is een server, je gebruikt maar gewoon een SSH verbinding of serial console. Why not? Geen gekloot meer met VGA/KVM of VNC via een iLO/IMM achtige setup. Geen rare webmanagement tooltjes die nooit 100% lekker werken. Of als ze zo goedkoop worden dat je in 1 u gewoon 4 van die dingen kwijt kan? Of een 4u bak met 16 nodes. Ik schiet een beetje door, maar met een fysieke versie van een nieuw platform kan je zo veel meer voorbereiden, testen, plannen en experimenteren! Als Itanium ooit doorgebroken had was het misschien wat ARM nu (gaat worden/) is. Backwards compatibility is leuk, maar maak software gewoon goed (van kwaliteit), en portable. Obscure shit is bijna nooit echt iets wat in je voordeel werkt. Zelfs je datacenter op POWER architectuur servers runnen is dan nog beter.
Ben ook zeer benieuwd! Als de prijs niet te hoog is (wat natuurlijk wel goed zou kunnen bij een 1e model van een nieuwe architectuur in de wereld van Dell) zou ik zelfs prive een model aanschaffen, puur voor de zelfstudie.
Stel dat ze gewoon zeggen: deze server krijgt geen video support. Het is een server, je gebruikt maar gewoon een SSH verbinding of serial console. Why not? Geen gekloot meer met VGA/KVM of VNC via een iLO/IMM achtige setup. Geen rare webmanagement tooltjes die nooit 100% lekker werken. Of als ze zo goedkoop worden dat je in 1 u gewoon 4 van die dingen kwijt kan? Of een 4u bak met 16 nodes. Ik schiet een beetje door, maar met een fysieke versie van een nieuw platform kan je zo veel meer voorbereiden, testen, plannen en experimenteren! Als Itanium ooit doorgebroken had was het misschien wat ARM nu (gaat worden/) is. Backwards compatibility is leuk, maar maak software gewoon goed (van kwaliteit), en portable. Obscure shit is bijna nooit echt iets wat in je voordeel werkt. Zelfs je datacenter op POWER architectuur servers runnen is dan nog beter.
Ben ook zeer benieuwd! Als de prijs niet te hoog is (wat natuurlijk wel goed zou kunnen bij een 1e model van een nieuwe architectuur in de wereld van Dell) zou ik zelfs prive een model aanschaffen, puur voor de zelfstudie.
Als het statische content is krijg je een 1Gbit lijn op je sokken vol met een moderne CPU dus virtualiseren van web-apps heeft wel degelijk zin om efficientere hardware-reuse te hebben. Als je webserver al op 100% staat dan heb je waarschijnlijk dikke logica in je pagina's staan en moet je eerst maar eens partitioneren inderdaad.
het nadeel dat je dan ook terughebt is een groot deel van idle time van je servercpu's en dus weliswaar prima watt verbruik per proc maar waardeloos in rendement.
Dus geen goed plan en ook niet wat de bedoeling is van deze jongens!
Dus geen goed plan en ook niet wat de bedoeling is van deze jongens!
Het voordeel van virtualisatie is dat het ook makkelijk schaalbaar is. en failover cluster makkelijk te realiseren zijn.
ook zorg je er voor de je machine een langere uptime heeft.
ook zijn virtuele machine erg makkelijk te monitoren en de beheren.
ook zorg je er voor de je machine een langere uptime heeft.
ook zijn virtuele machine erg makkelijk te monitoren en de beheren.
Wat je nu noemt heeft niets met virtualisatie te maken. Het is gewoon een normaal gevalletje single point of failure. Die kun je ook creëren met deze server. Als je maar 1 webserver hebt en die gaat om wat voor reden dan ook pleite dan doet geen enkele website het meer. Als je nou middels clustering 2 van die servers hebt dan heb je en iets van load balancing en iets van high availability. Mocht er eentje het te druk krijgen of helemaal wegvallen dan heb je de andere als vangnet en gaat er geen enkele website offline.
Dit is dus domweg zorgen dat je zaakjes op orde zijn en heeft helemaal niets te maken met dingen als ARM, X86, virtualisatie, Windows, Linux of noem maar op.
Dit is dus domweg zorgen dat je zaakjes op orde zijn en heeft helemaal niets te maken met dingen als ARM, X86, virtualisatie, Windows, Linux of noem maar op.
Zijn er nu al benchmarkts hoe een arm cpu zich vergelijkt met intal en amd cpu's.
uiteindelijk gaat het om de snelheid per watt en zou dus leuk zijn een goede benchmark te zien.
uiteindelijk gaat het om de snelheid per watt en zou dus leuk zijn een goede benchmark te zien.
Snelheid voor wat?
Het mooie van ARM is, is dat je een licentie neemt. Je kan op basis van ARM, bijvoorbeeld chips ontwerpen gespecialiseerd in instructies voor databases. Of een variant voor webserver specifieke taken.
Daarom zie je bij Apple in de AppleTV, iPad en iPhone allemaal een andere variant van hun ARM ontwerp. Zo heeft ieder aparaat optimale benutting.
Dit is het sterke punt van ARM en als dit gaat groeien zal Intel gedwongen worden om hun businessmodel te herzien.
Het mooie van ARM is, is dat je een licentie neemt. Je kan op basis van ARM, bijvoorbeeld chips ontwerpen gespecialiseerd in instructies voor databases. Of een variant voor webserver specifieke taken.
Daarom zie je bij Apple in de AppleTV, iPad en iPhone allemaal een andere variant van hun ARM ontwerp. Zo heeft ieder aparaat optimale benutting.
Dit is het sterke punt van ARM en als dit gaat groeien zal Intel gedwongen worden om hun businessmodel te herzien.
Euh, dat is je reinste onzin. Het is waar dat ARM architectuur zelf te implementeren valt, waardoor de ene ARM-cpu niet geheel te vergelijken valt met de andere (de scorpion cores zijn hierbij een mooi voorbeeld) maar jij laat uitschijnen dat er een grote variatie in zit. En dat is niet zo. 2 cortex a9 chips, ook al zijn ze van 2 verschillende fabrikanten, zijn in termen van prestaties per kloktik heel gelijkaardig, veel beter te vergelijken dan bv Intel vs AMD x86 chips.
Het beetje waarheid in je bewering (de licentie die je neemt op een ARM-ontwerp waar je zelf dan een alternatieve implementatie van mag maken) komt dan weer helemaal niet terug in je voorbeelden: de Apple TV, iPad en iPhone hebben EXACT dezelfde CPU, enkel op andere kloksnelheden. Het enige dat wat varieert is de SOC, maar dat is een groter geheel waarvan de ARM-cpu deel uitmaakt.
Het verhaal dat jij heir ophangt, dat de ene ARM-chip supergoed is in datbase-bewerkingen en de andere in bv single-threaded int instructies, is puur gebakken lucht en ik heb geen idee waar je het vandaan haalt.
Het beetje waarheid in je bewering (de licentie die je neemt op een ARM-ontwerp waar je zelf dan een alternatieve implementatie van mag maken) komt dan weer helemaal niet terug in je voorbeelden: de Apple TV, iPad en iPhone hebben EXACT dezelfde CPU, enkel op andere kloksnelheden. Het enige dat wat varieert is de SOC, maar dat is een groter geheel waarvan de ARM-cpu deel uitmaakt.
Het verhaal dat jij heir ophangt, dat de ene ARM-chip supergoed is in datbase-bewerkingen en de andere in bv single-threaded int instructies, is puur gebakken lucht en ik heb geen idee waar je het vandaan haalt.
Het is dus niet uit de lucht gegrepen je kunt instructies naar eigen inzicht toe voegenEuh, dat is je reinste onzin. Het is waar dat ARM architectuur zelf te implementeren valt, waardoor de ene ARM-cpu niet geheel te vergelijken valt met de andere (de scorpion cores zijn hierbij een mooi voorbeeld) maar jij laat uitschijnen dat er een grote variatie in zit. En dat is niet zo. 2 cortex a9 chips, ook al zijn ze van 2 verschillende fabrikanten, zijn in termen van prestaties per kloktik heel gelijkaardig,
Apple gebruikt dus gemodificeerde chips naar eigen inzicht in elkaar gebreid.
Je weet wel dat er een aantal jaren geleden een chipontwerpstudio was op gekocht door Apple ? Intrinsity en daar voor? was PA Semi ook al ingelijfd.
weet je wat ze daar hebben gedaan met de arm chips? design flink aangepast
dus het is helemaal geen hete lucht eerst maar eens goed google gebruiken. ARM chips kunnen worden aan gepast aan een doel.
Waar Kiang vast op doelt, is dat:
-Apple ten eerste geen ARM-instructieset licentie heeft (zoals MSFT bijv. wel), dus de instructieset optimaliseren ze helemaal niets aan,
-Apple het kant en klare Cortex A9 microarchitectuur-resistor–transistor logic (RTL) van ARM afneemt, dus het CPU-ontwerp optimaliseren ze ook al niets aan. Dit geeft aan dat ze helemaal geen instructies 'toevoegen', want als ze dat zouden doen zouden ze dus niet de Cortex A9-RTL afnemen van ARM, maar net als Marvell (Sheeva) en Qualcomm (Scorpion / Krait) hun eigen microarch ontwerpen. Of als ze echt zo 'baanbrekend' zouden zijn, zouden ze ook al hun eigen ARMv8 64bit-microarch kunnen maken net als de X-Gene van AppliedMicro.
-Apple waarschijnlijk afhankelijk is van het Samsung bakprocede, juist omdat ze Intrinsity gekocht hebben (Fast14 is afhankelijk van het Samsung bakprocede).
PA Semi was trouwens een PowerPC-boer, en van zowel Intrinsity als PA Semi schijnen behoorlijk wat mensen weggegaan te zijn nadat ze overgenomen waren door Apple, dus hoeveel dit de Apple SoC's uiteindelijk heeft beinvloed, valt nog te bezien.
Met andere woorden: Nee, het CPU-ontwerp heeft Apple juist helemaal niet aangepast, en ook niet het maak-procedé.
GPU ontwerp is ook standaard (Imagination Technologies PowerVR).
Men zou dus kunnen beredeneren dat de meeste Exynos-CPU's van Samsung voor 90% hetzelfde zijn als de Apple Ax processoren.
Verschillen zitten vooral in memory controllers / bussen etc; dat is een van de redenen waarom de Tegra3 naar verhouding vrij 'traag' is (bijv. in vergelijking met HiSilicon's K3V2). En natuurlijk het maakprocedé: NVidia gebruikt voor zover ik weet als enigste fabrikant voor de 'companion core' een 'low power' eilandje met speciale technologie van TSMC tussen het 'normale' TSMC proces, waar bijvoorbeeld een TI helemaal geen gebruik maakt van TSMC maar van UMC, en bijv. Qualcomm de laatste tijd wat meer van GloFo.
-Apple ten eerste geen ARM-instructieset licentie heeft (zoals MSFT bijv. wel), dus de instructieset optimaliseren ze helemaal niets aan,
-Apple het kant en klare Cortex A9 microarchitectuur-resistor–transistor logic (RTL) van ARM afneemt, dus het CPU-ontwerp optimaliseren ze ook al niets aan. Dit geeft aan dat ze helemaal geen instructies 'toevoegen', want als ze dat zouden doen zouden ze dus niet de Cortex A9-RTL afnemen van ARM, maar net als Marvell (Sheeva) en Qualcomm (Scorpion / Krait) hun eigen microarch ontwerpen. Of als ze echt zo 'baanbrekend' zouden zijn, zouden ze ook al hun eigen ARMv8 64bit-microarch kunnen maken net als de X-Gene van AppliedMicro.
-Apple waarschijnlijk afhankelijk is van het Samsung bakprocede, juist omdat ze Intrinsity gekocht hebben (Fast14 is afhankelijk van het Samsung bakprocede).
PA Semi was trouwens een PowerPC-boer, en van zowel Intrinsity als PA Semi schijnen behoorlijk wat mensen weggegaan te zijn nadat ze overgenomen waren door Apple, dus hoeveel dit de Apple SoC's uiteindelijk heeft beinvloed, valt nog te bezien.
Met andere woorden: Nee, het CPU-ontwerp heeft Apple juist helemaal niet aangepast, en ook niet het maak-procedé.
GPU ontwerp is ook standaard (Imagination Technologies PowerVR).
Men zou dus kunnen beredeneren dat de meeste Exynos-CPU's van Samsung voor 90% hetzelfde zijn als de Apple Ax processoren.
Verschillen zitten vooral in memory controllers / bussen etc; dat is een van de redenen waarom de Tegra3 naar verhouding vrij 'traag' is (bijv. in vergelijking met HiSilicon's K3V2). En natuurlijk het maakprocedé: NVidia gebruikt voor zover ik weet als enigste fabrikant voor de 'companion core' een 'low power' eilandje met speciale technologie van TSMC tussen het 'normale' TSMC proces, waar bijvoorbeeld een TI helemaal geen gebruik maakt van TSMC maar van UMC, en bijv. Qualcomm de laatste tijd wat meer van GloFo.
[Reactie gewijzigd door kidde op donderdag 31 mei 2012 21:29]
Intel chips ook (in samenwerking met TSMC) dus dat is niet nieuw. Het is echter niet erg waarschijnlijk dat men custom instructies toevoegd: dan zit je met een draak van een backwardscompatibility issue en moet je de hele software-stack (compilers, OS) aan gaan lopen passen. Dat hoort niet echt als time-to-market in je woordenboek staat.
Wat wel eenvoudig kan is cache vergroten/verkleinen de SoC aanpassen met betere video/audio/generic IO etc. Dus de core aanpassen is zeldzaam, het moederbord (de SoC) aanpassen is gewoon. Dat is wat apple dan wel doet.
In zekere zin heb je dus gelijk: je kunt een ARM CPU erg optimaliseren voor databases door er 2terrabyte aan level-2 cache aan te hangen, maar dat zie ik niet snel gebeuren
Wat wel eenvoudig kan is cache vergroten/verkleinen de SoC aanpassen met betere video/audio/generic IO etc. Dus de core aanpassen is zeldzaam, het moederbord (de SoC) aanpassen is gewoon. Dat is wat apple dan wel doet.
In zekere zin heb je dus gelijk: je kunt een ARM CPU erg optimaliseren voor databases door er 2terrabyte aan level-2 cache aan te hangen, maar dat zie ik niet snel gebeuren
En daar heb je het mis. De AppleTV, iPad en iPhone gebruiken "allemaal" dezelfde ARM chips...
iPad 2, iPhone 4S: Apple A5
AppleTV, iPad 2 (nieuw): 32nm Apple A5 (voor de TV is één core uitgeschakeld)
iPad 3: Apple A5X
En ja, je kan een licentie nemen en de chip herontwerpen voor zodat deze sneller is voor bepaalde toepassingen maar daar heb je toch echt een degelijk ontwerp studio voor nodig. Momenteel is Qualcomm nog altijd de enige die eigen processors maakt aan de hand van ARM's instructieset.
Het alternatief is dat je functionaliteit toevoegd in de vorm van co-processors (zoals bijvoorbeeld voor media decode/encode gedaan wordt), maar dan zit je weer met het probleem dat je daar extra instructies voor krijgt en de SW er voor aangepast moet worden.
Het feit dat het mogelijk is om aanpassingen te doen zou een sterk punt van ARM kunnen zijn, als er ook gebruik van werdt gemaakt. Echter momenteel zitten de grote verschillen tussen de verschillende ARM chips vooral in alles wat om de processor heen zit: GPU, co-processors (voor encode/decode), baseband, perepheral interfaces, etc.
iPad 2, iPhone 4S: Apple A5
AppleTV, iPad 2 (nieuw): 32nm Apple A5 (voor de TV is één core uitgeschakeld)
iPad 3: Apple A5X
En ja, je kan een licentie nemen en de chip herontwerpen voor zodat deze sneller is voor bepaalde toepassingen maar daar heb je toch echt een degelijk ontwerp studio voor nodig. Momenteel is Qualcomm nog altijd de enige die eigen processors maakt aan de hand van ARM's instructieset.
Het alternatief is dat je functionaliteit toevoegd in de vorm van co-processors (zoals bijvoorbeeld voor media decode/encode gedaan wordt), maar dan zit je weer met het probleem dat je daar extra instructies voor krijgt en de SW er voor aangepast moet worden.
Het feit dat het mogelijk is om aanpassingen te doen zou een sterk punt van ARM kunnen zijn, als er ook gebruik van werdt gemaakt. Echter momenteel zitten de grote verschillen tussen de verschillende ARM chips vooral in alles wat om de processor heen zit: GPU, co-processors (voor encode/decode), baseband, perepheral interfaces, etc.
Ja, die zijn er (bij het HP-lab waar ze deze dingen testen, maar Calxeda zal ze ook hebben), en nee, die zijn (nog) niet publiek. (ed: Linkje toegevoegd).Zijn er nu al benchmarkts
Overigens gaat het niet alleen om "performance per watt", maar kennelijk ook om aantal CPU's per vierkante meter serverruimte (zoek op 'ARM physicalizaiton').
ed: 'niet publiek' verwijst naar de serverbenchmarks voor server-SoC's op basis van ARM architectuur. Allicht, men roept '10x zo zuinig', maar door derde partijen gecontroleerd en gepubliceerd is dit nog niet.
[Reactie gewijzigd door kidde op donderdag 31 mei 2012 21:33]
Het gaat uiteindelijk nog altijd om de rauwe snelheid, niet om de snelheid per watt. Zou dit laatste wel het geval zijn dan had ARM Intel al lang van de kaart geveegd....
uiteindelijk gaat het om de snelheid per watt ...
Ja.. al lang:
http://www.tux.org/~mayer/linux/results2.html
Beetje zoeken kan geen kwaad.. Pas wel op dat deze scores PER CORE zijn. Zo geschat is een ARM CPU (kijk naar die van de panda board) ongeveer gelijk aan een Pentium 3.
http://www.tux.org/~mayer/linux/results2.html
Beetje zoeken kan geen kwaad.. Pas wel op dat deze scores PER CORE zijn. Zo geschat is een ARM CPU (kijk naar die van de panda board) ongeveer gelijk aan een Pentium 3.
En wat mag laag energiegebruik precies zijn? Ik vind dat mijn atom met 18 Watt energie zuinig is en een pc van 200Watt+ veel verbruikt. Heeft iemand hier getallen van?
En ja in dat geval is er waarschijnlijk een performance verschil (daar gaat het even niet om).
En ja in dat geval is er waarschijnlijk een performance verschil (daar gaat het even niet om).
[Reactie gewijzigd door Pimmetje16 op donderdag 31 mei 2012 14:33]
http://en.community.dell....l-servers-on-the-way.aspx
•Each ARM server node draws about 15 watts max power, so the total power draw for a full chassis is less than 750 watts.
Ik weet dat op de Pagina van Dell ook "1GB Marvell Ethernet uplink" beschreven staat , maar dit moet toch 1Gb zijn ?
Aangezien Microsoft nu voor Windows 8 ook een ARM kernel heeft ben ik benieuwd of er in de (nabije?) toekomst, als dit platform succesvol wordt voor servers, ook een Windows 8 server versie op ARM-basis komt.
Een Windows Server 2012 voor ARM komt er niet:
http://www.computerworld....No_Windows_Server_for_ARM
Ik quote:
One immediate problem with porting Windows Server to ARM is that the OS was written for 64-bit processors, while the current ARM architecture is limited to 32-bit processing,
Server-based ARM might initially look like an easy way to cut server power usage, but it would have only a minimal impact on energy usage.
"On a server, the chip is only one part of the power consumption," he said. The motherboard, memory, network controllers and other components all consume power as well. "Even if you dramatically drop the power requirement [of the chip] there are definitely some other power requirements,"
http://www.computerworld....No_Windows_Server_for_ARM
Ik quote:
One immediate problem with porting Windows Server to ARM is that the OS was written for 64-bit processors, while the current ARM architecture is limited to 32-bit processing,
Server-based ARM might initially look like an easy way to cut server power usage, but it would have only a minimal impact on energy usage.
"On a server, the chip is only one part of the power consumption," he said. The motherboard, memory, network controllers and other components all consume power as well. "Even if you dramatically drop the power requirement [of the chip] there are definitely some other power requirements,"
[Reactie gewijzigd door dycell op donderdag 31 mei 2012 15:02]
Welke onnozelaar heeft dat geschreven?On a server, the chip is only one part of the power consumption,"
Iedereen weet toch wel dat ARM-oplossingen met System-on-Chip vaak veel stroom 'bezuinigen' door zoveel mogelijk in 1 chip te combineren. Dus geheugencontroller, geheugen (zelf) GPU enz. Dan is praktisch geen moederbord meer nodig, of in ieder geval met veel minder functies.
Deze persoon leeft kennelijk nog in de vorige eeuw (iets met onder een steen enzo), waar 'the chip' vermoedelijk op de losstaande-CPU-chip moet slaan. Maar zelfs Intel is al verder dan dat.
Dus zelfs al zal het 'cpu' praktisch niets gebruiken, juist op de integratie van 'liefst heel het moederbord' in 1 enkele chip (ideaal, in de praktijk niet te doen maar hier gaat het toch naartoe) wordt het verschil gemaakt.
GPU in een server? Die heb je al niet. Geheugencontroller is ook op x86 geintegreerd. x86 heeft bovendien (veel) meer PCI-e lanes vanuit de CPU zelf, en de server chips hebben een veel, veel betere interconnect dan de 1Gb Ethernet hier. (AMD HyperTransport bijvoorbeeld).
Ach sorry, had gemist dat de CUDA's 'los' zaten...
http://ragingbull.quote.c...board=ARMH&read=27509
Zou een logische stap zijn die in de toekomst misschien wel te combineren (voor OpenCL?), maar dat is idd meer voor zuinige supercomputers dan voor servers.
Beter linken naar de lijst van wat er wel in zit...
http://ragingbull.quote.c...board=ARMH&read=27509
Zou een logische stap zijn die in de toekomst misschien wel te combineren (voor OpenCL?), maar dat is idd meer voor zuinige supercomputers dan voor servers.
Beter linken naar de lijst van wat er wel in zit...
[Reactie gewijzigd door kidde op donderdag 31 mei 2012 21:42]
Meestal wel een GPU maar dan een eenvoudige (matrox zie je veel). Handig tijdens het installeren bijvoorbeeld.
Goed punt, ik zie net dat de 64-bits ARM pas in 2014 verwacht wordt.
Echter, het feit dat de hardware er nog niet is, betekent niet dat Microsoft er achter de schermen niet al mee bezig is.
Aangezien Windows 8 toch al gemaakt wordt met de ARM instructieset in gedachten, zou het me niets verbazen als Microsoft de ontwikkelingen op het gebied van ARMv8 in de gaten houden. (Windows 2012 Server R2 ?
)
Aangezien Windows 8 toch al gemaakt wordt met de ARM instructieset in gedachten, zou het me niets verbazen als Microsoft de ontwikkelingen op het gebied van ARMv8 in de gaten houden. (Windows 2012 Server R2 ?
)
Ben ik nou de enigste die SSD in dit plaatje mist?
Dit soort systemen gebruiken meestal centrale opslag (SAN) voor hun belangrijke data. Alleen het OS draait lokaal en vereist bijna geen IO (7200RPM is zat).
Toch begrijp ik M3nno's reactie wel (hoewel ik liever 'enige' dan 'enigste' zie ;-)
Ik begrijp de keuze voor HDD's niet zo goed als je doel een lage power consumptie is... dan liever SSD!
Weegt een SSD met minder 'moving parts' niet op tegen een Raid1 HDD oplossing in zo'n server? Wat kan de reden voor de keuze van die harddrives zijn? centen?
Ik begrijp de keuze voor HDD's niet zo goed als je doel een lage power consumptie is... dan liever SSD!
Weegt een SSD met minder 'moving parts' niet op tegen een Raid1 HDD oplossing in zo'n server? Wat kan de reden voor de keuze van die harddrives zijn? centen?
RAID1? Elk van de 4 HDDs is gekoppeld aan 1 ARM CPU, dus RAID-1 is het zeker niet. Ik gok dat dit inderdaad voor OS-achtige zaken bedoeld is.
Niet alleen centen, maar ook betrouwbaarheid: van HDD's is het al (bijna) perfect te voorspellen wanneer een bepaalde serie kan uitvallen (naargelang levensduur componenten), of hoe lang hij zal meegaan.
SSD's voor servertoepassingen zijn daarentegen nog niet lang genoeg in omloop (nog maar enkele jaartjes) waardoor er nog bijna niets gekend is hoe lang ze wel degelijk meegaan (aantal uren in gebruik)
Prijsverschil tussen enterprise-level disks en SSD's is ook redelijk te verwaarlozen in zo'n aantallen als dit: +- 100 euro per schijf, uitgaand van 120GB opslagcapaciteit, wat al meer dan genoeg is voor een server als deze (zullen vast wel vooral gebruikt worden naast een SAN waar alles opstaat)
SSD's voor servertoepassingen zijn daarentegen nog niet lang genoeg in omloop (nog maar enkele jaartjes) waardoor er nog bijna niets gekend is hoe lang ze wel degelijk meegaan (aantal uren in gebruik)
Prijsverschil tussen enterprise-level disks en SSD's is ook redelijk te verwaarlozen in zo'n aantallen als dit: +- 100 euro per schijf, uitgaand van 120GB opslagcapaciteit, wat al meer dan genoeg is voor een server als deze (zullen vast wel vooral gebruikt worden naast een SAN waar alles opstaat)
De prijzen van Enterprise SSD (SLC) liggen anders wel flink hoger dan de consumenten (MLC) SSD's. Betrouwbaarheid van de SLC is ook hoger.
Dat is dan weer vrij raar, gooi het OS op het SAN en doe een PXE boot oid. Gebruik local-storage voor swap en temp-space is veel logischer (ook lekker makkelijk images klonen op het SAN, scheelt tig schijfjes volpompen met OS).
Ik zou idd eerder flashgeheugen oid verwachten of netboot.
Om nu 48 draaiende hd's in een kast te hebben...
Om nu 48 draaiende hd's in een kast te hebben...
Dell kennende zal het ook gewoon een configuratie optie zijn. Dus als je PXE boot gebruikt kun je deze schijven achterwege laten.
Het bijgevoegde plaatje laat 3.5" disks zien, en de tekst in dit artikel heeft het daar ook over. Maar 2.5" lijkt mij ook logischer.
3u is zo'n 12,5cm dus als je plaatje bekijkt zijn het gewoon 3,5" disken
3U = 5.25 in = 133.35 mm
3.5" HDD = 4 in × 1 in × 5.75 in = 101.6 mm × 25.4 mm × 146 mm
2.5" HDD = 2.75 in × 0.275–0.59 in × 3.945 in = 69.85 mm × 7–15 mm × 100 mm
Een 3.5" HDD past dus niet, overigens staat op de pagina van Dell bij de specs ook dat het 2.5" HDD's zijn.
3.5" HDD = 4 in × 1 in × 5.75 in = 101.6 mm × 25.4 mm × 146 mm
2.5" HDD = 2.75 in × 0.275–0.59 in × 3.945 in = 69.85 mm × 7–15 mm × 100 mm
Een 3.5" HDD past dus niet, overigens staat op de pagina van Dell bij de specs ook dat het 2.5" HDD's zijn.
Maar wie zegt dat de 12x blades vertikaal naast elkaar komen?
Racks zijn qua breedte in 19" maar ook in 24" versies beschikbaar.
Ik ga echter uit van het populaire 19" formaat, want de 24" is meer voor telecommunicatie en kom dan uit op blades van 6.25" breed en 1.3" hoog.
Dan passen er 3 rijen naast elkaar en 4 op elkaar voor de 12 blades.
En wat blijkt een 3.5" HDD past dan precies, zoals in de foto duidelijk te zien is, met 6" lengte en 1" hoogte.
De diepte van de meeste 19" racks is 42" (107cm), dus de 4x schijven naast elkaar en dan nog ruimte voor het moederbord met de 4x CPU is helemaal geen probleem.
Racks zijn qua breedte in 19" maar ook in 24" versies beschikbaar.
Ik ga echter uit van het populaire 19" formaat, want de 24" is meer voor telecommunicatie en kom dan uit op blades van 6.25" breed en 1.3" hoog.
Dan passen er 3 rijen naast elkaar en 4 op elkaar voor de 12 blades.
En wat blijkt een 3.5" HDD past dan precies, zoals in de foto duidelijk te zien is, met 6" lengte en 1" hoogte.
De diepte van de meeste 19" racks is 42" (107cm), dus de 4x schijven naast elkaar en dan nog ruimte voor het moederbord met de 4x CPU is helemaal geen probleem.
"If you were plowing a field, which would you rather use: Two strong oxen or 1024 chickens?" - Cray
Ik zie dit niet werken. Je moet heel erg veel van die chips hebben om pakweg een Xeon bij te benen. En in totaal zit je dus aan heel veel gedupliceerde hardware die samen veel verbruiken. Bovendien is er nog geen ondersteuning voor 64-bit, en dat gaat een heel pak efficientie kosten.
Ik zie dit niet werken. Je moet heel erg veel van die chips hebben om pakweg een Xeon bij te benen. En in totaal zit je dus aan heel veel gedupliceerde hardware die samen veel verbruiken. Bovendien is er nog geen ondersteuning voor 64-bit, en dat gaat een heel pak efficientie kosten.
Op dit item kan niet meer gereageerd worden.
Populair: Samsung Websites en communities Mobiele telefoons Google Sony Games Microsoft Politiek en recht Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
