KPN: ecomodus zorgt voor energiebesparing van 7 procent bij lowprofileserver

Bij een Nederlands project om het energiegebruik van datacenters te verlagen, heeft KPN gemeten dat een zuinige server in ecomodus zeven procent minder energie gebruikte, zonder dat gebruikers daar iets van merkten. Het ging om een lowprofileserver.

KPN hield een test met het draaien van een ecomodus op een server in het kader van het Lower Energy Acceleration Program, oftewel LEAP. Dit is een programma van het Amsterdam Economic Board in samenwerking met onder andere Dell, HPE, KPN en Booking.com, om het stroomverbruik van datacenters in en rond Amsterdam terug te dringen. Het gaat om een project van drie jaar en in de eerste fase wil de alliantie de impact van een energiezuinigere modus weten.

In feite gaat het bij 'de ecomodus' niet om een enkele instelling maar om verschillende op basis van de ACPI, oftewel de Advanced Configuration and Power Interface. Op basis van deze open standaard kunnen besturingssystemen energiebeheerschema's voor hardware opstellen. KPN maakte bij zijn test gebruik van zowel de P- als de C-staat. Een hogere P-staat betekent een lagere spanning en klokfrequentie van de processor, en daarmee een lager verbruik. Een hogere C-staat betekent een 'diepere' slaapmodus.

Deze zuinigere modi zijn er al heel lang voor servers, maar volgens Arnold Hoogerwerf, van KPN's Technology, Innovation, Roadmaps & Architecture-afdeling durven veel datacenters deze energie-instellingen niet te gebruiken. "Ze zijn bang dat daardoor de prestaties van de computers omlaaggaan en dat het niet zoveel oplevert." Het onderwerp staat nu op de agenda, omdat datacenters vanaf 2019 moeten rapporteren over energiebesparingen en powermanagement een van de genoemde maatregelen is. Voor eigen servers van bedrijven geldt daarnaast virtualisatie als erkende maatregel.

"Er is een maatschappelijke wil om energie te besparen in het licht van het klimaatakkoord. Bedrijven met veel dataverkeer zijn zich steeds meer bewust van de energie die dit gebruikt en hun rol aangaande duurzaamheid. Zij worden hier ook steeds vaker op afgerekend", aldus LEAP.

KPN activeerde bij een test de ecostand op een recente, gevirtualiseerde bladeserver-enclosure, waar niet de belangrijkste applicaties op draaien. Voorafgaand bekeek het bedrijf hoeveel machines op de enclosure draaiden en mat KPN het vermogen. Daarna schakelde KPN de ecomodus in om na een week de verschillen te meten. Daaruit bleek de besparing van zeven procent en de medewerkers van KPN die de server gebruiken, zouden niets gemerkt hebben van de aangepaste instellingen. KPN heeft hier ook metingen voor verricht. Dat ging voor dit project nog om maatwerk, maar het bedrijf wil dit in de toekomst misschien met standaard uitleesroutines in een database doen, waarin verschillende merken kunnen worden geanalyseerd.

KPN zou blij zijn met de besparing omdat het al om een efficiënt systeem ging. Het bedrijf richt zich nu op het efficiënter uit kunnen lezen van de enclosures, onder andere door de stekkerdozen aan te passen, om te kunnen bepalen welke server de meeste energie gebruikt.

Inmiddels is KPN bezig met de implementatie van de zuinige instellingen op een aantal servers waar interne it-applicaties op draaien. In aanvulling daarop bekijkt het bedrijf of de besparingen ook te realiseren zijn op een highprofileserver waar veel medewerkers gebruik van maken. "We hopen dat we ook op die server geen last van de energiebesparende aanpassingen hebben. Zo zullen we stap voor stap de aanpassingen doorvoeren totdat waar mogelijk ons hele datacenter is aangepakt."

Meer over LEAP en het verbruik van datacenters lees je in het achtergrondartikel Hoeveel datacenters kunnen we aan? De impact van rekencentra op het energienet.

Reacties (90)

[Hoover]

Geen idee of hiermee ook de powerschemas in Windows worden bedoelt, maar dit heeft wel degelijk een nadelige impact op de performance van servers. Ik heb bij een grote zorgverzekeraar gewerkt en in de maand november bij het bekend maken van de nieuwe polisprijzen konden onze systemen amper het verkeer aan. Wat bleek, de powerschema's stonden op balanced. Hierdoor kunnen CPU's in parking mode gezet worden. Het in en uit parking mode zetten van CPU's zorgde op diverse SQL en Middleware servers voor zo'n grote performance hit dat we alles op high performance hebben gezet. Dit aangepast. Performance issue weg.

De virtualisatie laag zorgt ervoor dat er niet omlaag geclockt word overigens. Dus van balanced naar high performance zorgt er niet voor dat de clock naar max gezet worden. Deze staan al op max.

[Reactie gewijzigd door Hoover op 22 juli 2024 17:35]

[Rataplan_]

Wij leveren met name RDS diensten voor een heel scala aan MKB klanten. Op een aantal van onze Hyper-V hosts draait een script, waarbij 's nachts, als er niemand mee werkt, de schema's naar Balanced gaan. Dat scheelt nog best substantieel in het energieverbruik. Niet voor een servertje, maar voor een rack begint het toch wel serieus merkbaar te zijn. We doen dit alleen op machines die 's nachhts ook niet gebruikt worden.
Overigens, met Hyper-V in elk geval, zie je binnen de VM altijd de eigenlijke kloksnelheid van de host CPU, onafhankelijk van waar de fysieke CPU op dat moment werkelijk op draait. Als je een 6248R CPU hebt bv, 3GHz met een boost naar 4GHz, zie je in je VM ALTIJD 3GHz. Zelfs wanneer je de host op low-power zet, en hij bv maar op 1.5GHz draait oid. Maar ook wanneer je met Turbo wel degelijk op 4GHz zou draaien. Ik weet niet of VMWare of andere hypervisors daar anders mee omgaan, in Hyper-V zie je geen verschil in de VM, je merkt het natuurlijk wel in de performance.

[offtopic]
Ik ben nu overigens aan het testen wat er te halen valt met C-Stated aan of uit. Normaal wordt met klem aangeraden op hypervisors C-Stated uit te zetten. Maar, in elk geval bij HPe, houdt dat ook in dat Turbo niet werkt. Terwijl met C-Stated aan en de machine's power-scheme op High Performance, dan kan er wél Turbo gedaan worden. We zien dan ook op de host de CPU speed wel wat aangepast worden af en toe. De benchmark wijzen er zover op dat juist met C-States aan en mogelijkheid tot turbo, we best weer substantieel sneller zijn dan met c-states uit, en in geval van deze 6248R cpu's alle cores vast op 3GHz. Ook met C-States aan kunnen alle cores nog steeds op 3GHz blijven draaien bij zware belasting.
Maar een beetje ontopic weer: met C-States aan gaat het verbruik op rustigere momenten ook weer omlaag.

[MMaI]

Nog efficientier is uiteraard het automatisch uitzetten van servers die niet gebruikt worden, dit zou vele malen meer energie besparing opleveren dan C/P states en ACPI instellingen. Denk aan een automatische scheduler die je VMs uitzet tot een basis niveau, dan HyperV hosts leeg maakt, uit zet en in de ochtend netjes op tijd weer aan zet via de IPMI/Redfish standaard en resources weer aanzwengeld.

Er is vaak piek verbruik van maandag tot vrijdag 7-18, maar daarbuiten niet zo veel. Dat is theoretisch een besparing van 40% als je buiten de piektijden de helft van je infrastructuur uit kan zetten.

[Rataplan_]

Zeker, daar zijn we ook mee bezig. Ik hoef daar eigenlijk niks voor te doen, als ik maar zorg dat er genoeg met name memory capaciteit blijft, kan ik de hosts gewoon uitzetten, de vm's moven vanzelf ergens anders naar toe. En met ipmi / iLO weer aanzetten. Maar dan ben je ook daadwerkelijk een gedeelte van je capaciteit kwijt. Dus daar moet je een gedegen plan voor hebben, en dat heb ik nog niet voor onze omgeving

[tweazer]

Een OS met lagere clocktick (niet 1000 maar veel lager), of zelfs clockless draaien scheelt erg veel. Ooit eens een redhat 5 systeem in idle modus naar 7 tot 0 Mhz volgens vmware weten te downsizen... Met latere OS'en valt dat zowel mee als tegen..
Ik kijk met name uit naar vmware 7 op ARM ...
Dockers met rpi's kunnen denk ik ook aardige duit opleveren...

[jongetje]

Precies! Dat doet/deed tele2/vodafone toch ook in de nacht als er minder capaciteit nodig was bepaalde frequenties uitzetten?

[RobbieB]

Het hele idee van een Eco-modus is natuurlijk dat deze niet aan moet staan bij piek-momenten. Maar piek-momenten zijn de uitzondering, niet de regel.

Maar als dit wel gebruikt kan worden op de andere momenten, en daarmee wordt flink wat energie gespaard, dan is dat natuurlijk een top idee.

[Hoover]

Daar heb je weinig aan in een virtualisatie platform. Alle gebruikte CPU's staan altijd op volle clocksnelheid.
Enige wat dan zou kunnen werken is het uitzetten van servers of het terugschroeven van het aantal CPU's
Maar dan loop je bij IBM al tegen een licentie probleem. Eenmaal opgeschaald kun je niet zomaar meer terug. Dus terugschalen gebeurt niet.

[Dennism]

Dat is niet correct, ook bij virtualisatie kunnen cpu's gewoon terug klokken en / of boosten. Dit is uiteraard wel afhankelijk van de instellingen binnen je hypervisor maar ook je bios instellingen.

Zie bijvoorbeeld voor vSPhere https://www.vmware.com/co...rmance-best-practices.pdf (o.a. pagina 29)

Maar ook: https://docs.vmware.com/e...C1-A8E6-EF3865603F5B.html

Maar ook Hyper-V

https://docs.microsoft.co...er-v-server/configuration

With the Balanced power plan, the highest power states (and lowest response latencies in tenant workloads) are applied only when the physical host is relatively busy. If you value deterministic, low-latency response for all tenant workloads, you should consider switching from the default Balanced power plan to the High Performance power plan. The High Performance power plan will run the processors at full speed all the time, effectively disabling Demand-Based Switching along with other power management techniques, and optimize for performance over power savings.

Het is zeker niet zo dat alle cpu's constant op volle snelheid lopen te draaien, ook bij virtualisatie wil je, waar mogelijk, de boel zo zuinig mogelijk laten draaien. Soms is dit echter niet mogelijk en dan zal je inderdaad een "high performance" mode moeten gebruiken, en dan zie je inderdaad dat de cpu's altijd op volle snelheid draaien, dit is echter niet de standaard en normaliter ook niet de best practise.

Misschien dat bepaalde virtualisatie platformen altijd volle kloksnelheid afdwingen, maar standaard is dit zeker niet.

[MMaI]

Standaard staat VMWare ESXi sind versie 5 op "balanced" en wordt de "high performance" modus alleen aangeraden voor latency-sensitive applicaties. Als je naar Hyperscalers (Google/Amazon/Microsoft) kijkt dan draaien daar vrijwel alle systemen met C/P states enabled en wordt zelfs buiten een deel reserve capaciteit een deel van de fysieke infrastructuur uit en aan gezet afhankelijk van de huidige consumptie.

[OruBLMsFrl]

VMWare kan dat afschakelen van hosts ook dynamisch, die techniek heet DPM (distributed power management). Dan kan die via integrated server management zoals ILO/BMC uit en ook weer ingeschakeld worden. Als zulke vHosts nu eens snel op zouden starten, of in geval van VSAN het je niet ook op storage gebied zou impacteren. Met losse storage kan zoiets een prima plan zijn, als je echt veel stroom wilt sparen en de boot tijd weinig problemen geeft.

Met DPM kom je makkelijk boven de 7% power save als de hele nacht een derde van je hosts uitstaan (8 uur per dag 33% servers uit is 11% saving). Kun je in mindere mate alsnog binnen die 7% van KPN wat stroombesparing halen met de instellingen per server. Zou je hopen zo rond 14% totaal netto besparing te scoren op je cluster(s), toch even de dubbele besparing al bekeken vanaf die 7% nu.

[Dennism]

Die boot tijd valt ook wel mee toch? De meeste hosts die wij beheren starten vanaf SD kaartjes en die booten toch vrij vlot.

VSAN kan inderdaad wel een issue zijn.

[To_Tall]

Volgens mij kan je met Horizon het zelfs zo regelen dat je dynamisch RDS servers kan bij of af schalen.

Je hebt dan wel een basis load wat het systeem aan kan.

[Kees]

Ik merk het inderdaad ook op Tweakers, als een server perongeluk in powersave mode staat in linux dan is elke pagina vanaf die server ongeveer 30% langzamer dan vanaf een server met de 'performance' mode aan.

[MMaI]

Zou op zich een interessante case zijn voor Tweakers om te onderzoeken. Als een pagina 30% langzamer uitgeserveert wordt is het zelfs mogelijk dat het energieverbuik van die enkele pagina hoger is omdat de CPU langer aan het werk is. Daarnaast neem ik aan dat jullie Load Balancer niet zo maar round-robin distributeert maar ook kijkt naar het aantals actieve connecties of zelfs de responstijd, dus als één server op powersave staat is het prima mogelijk dat alle andere servers ook harder moeten werken.

[fastedje]

Over het algemeen is de relatie van het opgenomen vermogen afgezet tegen de klokfrequentie niet lineair maar eerder kwadratisch: bij een hogere klok is vaak ook een hogere cpu spanning nodig.

[MMaI]

voor consumenten CPUs is dat zeker waar, maar in servers hebben de CPUs over het algemeen een strict power budget. Als je taak op een hogere frequentie en dus sneller klaar kan zijn betekent dit dat een andere taak op dezelfde CPU ook sneller kan draaien binnen hetzelfde power budget.

Server CPUs zitten (per core) niet op het randje van de frequentie/vermogen curve en daarom kan snel single threaded taken afhandelen en daarna weer terug naar idle/C/P state schakelen efficienter zijn dan de gehele CPU belasten maar op een lagere frequentie.

Lees bijvoorbeeld "Sustainable Cloud and Energy Services: Principles and Practice" of "Green, Pervasive, and Cloud Computing: 12th International Conference, GPC 2017" publicaties maar eens die onder anderen het optimale winst (in geld) punt berekenen per CPU gebasert op de frequency/power curve.

[Kees]

Klopt, daarom merkte ik het ook (loadbalancer kijkt naar de responsetijd). 1 (recent gereboote) server kreeg veel minder requests van de loadbalancers. Overigens is sindsdien een zabbix item die de cpu-governor in de gaten houd

[Dennism]

Powersave mode is inderdaad vaak niet aan te raden. Testen tussen balanced en high performance normaliter wel omdat de verschillen in performance vaak zeer klein (wel afhankelijk van workload, voor sommige workloads is "balanced" of de linux variant daarvan niet geschikt) en is high performance vaak een stuk minder efficiënt.

[arjankoole]

Dat zijn toch wel stevige verschillen.

Ik denk dat dynamiek voor de modi wel nuttig kan zijn. Als je de situatie hebt dat ‘s nachts het een stuk rustiger is: powersave. Vanaf 6 uur ‘s ochtends (bijvoorbeeld): performance.

Alhoewel zelfs ‘s nachts een penalty van 30% misschien niet altijd te verteren is.

[itguy013]

Same here. Je kunt het bijvoorbeeld ook in de BIOS aanpassen. Standaard bij HPE staat deze op Dynamic Power Savings. Zodra je High Performance instelt, heb je echt wel merkbaar performance verschil. Wel is het zo dat het stroomverbruik daarmee ook stukje hoger ligt. Kan me voorstellen dat het bij enkele server bijvoorbeeld 10 watt extra verbruik niet uitmaakt, maar doet maar keer 1000

[DeevieP]

Op HPE servers zet ik dat eigenlijk steeds op OS Control Mode. Dat laat toe dat het OS toch nog anders beslist.

[freshy98]

Kan zijn dat ik het verkeerd heb, maar wat jij bedoelt is wat anders de instelling die je via het BIOS instelt.

[Hoover]

Veel zaken uit de powerschemas worden bepaald door wat de bios kan. Bijvoorbeeld intel speedstep voor het terugklokken bij lagere belasting. Als je dit aanpast naar high performance zal je pc standaard niet terugklokken.

[Dennism]

Best practise is om dat juist niet via de bios te laten lopen en dat soort zaken op OS-Controlled te zetten in de bios. Dan kun je inderdaad de powermanagement opties van het OS of de Hypervisor gebruiken.

Je kan dit soort zaken echter ook vaak in de bios regelen en dan worden de OS waardes genegeerd.

[freshy98]

Dat weet ik. Stond mij alleen bij dat de Eco mode in het BIOS daar buiten viel.

[citruspers]

Het nadeel van de performance mode in veel servers is dat CPU's wel gelockt worden op hun maximale (sustained) performance, maar functies zoals turbo boost juist niet meer werken.

[mr_evil08]

Dat "parking" mode bedoel je dan dat er threads/cores niet aangesproken kunnen worden of dat er overhead aanwezig waardoor de thread minder efficient werkt.

[the_stickie]

Het gaat om de technoligie die achter die powerschema's zit inderdaad. En daar is veel te halen, maar bijna niks is helemaal gratis.
In veel gevallen wil je betalen voor performance, maar in veel gevallen ook zo weinig mogelijk. Voor heel veel (variabele) workloads is het best interessant (zoals webservers). In andere gevallen kan je die paar % performanceverlies op een andere manier opvangen (scaling?). Maar een "datastamper" met hoge load zal nooit profiteren van aan/uit gedoe
Het is volgens mij wel zo dat de meeste systemen out of the box powermanagement doen en het dus juist admins zijn die energiebesparingen uitschakelen

[HollowGamer]

Het is opzicht opvallend, je zou zeggen dat terugklokken van de frequentie(s), (eventueel) de actieve cores en active lanes; de warmte ten goede zou komen en daardoor de CPU weer sneller en beter zou moeten kunnen opschalen. Het waken van de CPU kost dan mogelijk wat latency, maar zou voor de meeste gevallen niet problematisch moeten zijn.

HW.info heeft een aantal jaren terug nog een goed artikel hierover geschreven: https://nl.hardware.info/...uitgelegd-core-en-package

Ik twijfel om eerlijk te zijn of het niet aan jullie applicatie(s)/inrichting van de server ligt. Normaal gesproken zou dus één core (+ evt. wat threads) actief zijn en daarna opschalen als er meer gevraagd wordt. Ik dacht dat dit ook met de nieuwe chips verbetert was t.o.v. een paar gens terug.

Ik heb bijvoorbeeld thuis een server met nginx, databases, ZFS, etc. draaien, en ik merk niet super veel verschil bij het aanroepen met of zonder C-/P-state draaiend op een hoger level. Misschien duurt het een paar ms seconden langer, maar dat weegt niet op tegen de energie winst en lagere warmte (dus ook geluid). Het zijn niet honderden gebruikers in één keer, maar dan nog zou een goede VPS en OS prima moeten kunnen opschalen.

Het irriteert mij enorm als ik systeembeheerders of de gebruiker het energieprofiel zetten op Max. Performance. De accuduur gaat achteruit, warmte omhoog en prestaties zullen van zelf minder worden door de continue boosts. Ze hadden het beter kunnen noemen Max. Boost, want ik twijfel dus erg aan die performance claim. Op Linux gebruik ik dan ook zoveel mogelijk TLP, powertop en thermald, al moet je ook nog de BIOS induiken in de meeste gevallen.

Ik ben dus erg voor en blij dat KPN hiermee testen doet. Als afnemer van een VPS kan je vrij weinig, want meestal draaien deze op een andere level en zijn de clocks en cores wel gelocked. Ik weet dus niet zeker of je cores/states dynamisch kunt (laten) instellen.

[Reactie gewijzigd door HollowGamer op 22 juli 2024 17:35]

[Q]

Ik heb zelf thuis een HP Proliant Gen8 server, het soort server wat je in een datacenter kunt verwachten. Menig tweaker hier zal met zo'n ding gewerkt hebben.

Je kunt in het BIOS instellen of je maximum performance of balanced performance wilt. De impact op de performance is fors.

High performance idle verbruik: 100 Watt
Balanced performance idle verbruik: 76 Watt

Ten opzichte van de 'zuinige' optie zag ik een piek performance verbetering van 20% voor ~30% meer continue idle gebruik.

Ik zou zelf er voor zorgen dat mijn workloads op minder servers draaien, die op high performance laten werken zodat idle verbruik niet uitmaakt. Dan kun je de rest uit zetten (nog zuiniger!).

Bron:
https://louwrentius.com/m...ds-and-128-gb-memory.html

[Rataplan_]

Inhakend op mijn reactie hierboven, test eens met eerst settings op High Performance, en dan omzetten naar custom. Dan hou je in weze de settings van high performance nog aan. Maar dan zet je C-States aan. Normaal staan die namelijk uit, maar dan kan je CPU de turbo niet gebruiken, en draait altijd op de nominale snelheid van de CPU (de niet turbo-snelheid dus). Als je VM's constant 100% zitten te stampen ga je weinig merken, want dan hhoudt de turbo toch geen stand. Maar met een reguliere workload die hier en daar eens piekt, merken wij door het wel kunnen gebruiken van de turbo, substantieel betere performance daardoor. Wel in geval van Windows (of Hyper-V, ook Windows dus) je power-scheme op high-performance zetten op de host anders wordt je te snel teruggeklokt.

[Reactie gewijzigd door Rataplan_ op 22 juli 2024 17:35]

[Q]

Bedankt voor de tip. Ik zal er eens mee testen. Dat heb ik denk ik nog niet op deze manier uitgeprobeerd.

Overigens staat de server meestal uit en gaat hij alleen aan voor lab-doeleinden.

[Reactie gewijzigd door Q op 22 juli 2024 17:35]

[Q]

Ik vond net een tooltje 'powertop' (Linux) die ook een hoop settings laat tunen. Ik weet niet wat het voor de performance precies doet (niet getest) maar toen ik alle 'bad' values op 'good' zette scheelde dat idle 10 watt.

[Cergorach]

Ik vind het een beetje misleidende titel (zoals wel vaker voorkomt). Het gaat hier imho om servers welke niet optimaal benut worden, nogal wiedes dat er dan energie te besparen is door dat ding langzamer te laten draaien...

Ik ben het eens dat veel dienstverleners hier amper naar kijken ivm. dat al die capaciteit door wordt berekend aan de klant. Ik verwacht dat leveranciers zoals Amazon, Google en Microsoft veel verder zijn op dit onderwerp dan een KPN, voornamelijk gezien hun efficiënte server containers.

[pixeled]

Ik vind het een beetje misleidende titel (zoals wel vaker voorkomt). Het gaat hier imho om servers welke niet optimaal benut worden, nogal wiedes dat er dan energie te besparen is door dat ding langzamer te laten draaien...

Ik begrijp je opmerking niet helemaal. Door ecomodus te activeren (= lager vermogen en dus lager energieverbruik) kan er 7 procent energiebesparing plaatsvinden bij een bepaalde server in een van de datacenters van KPN. Dat is toch accuraat? Wat is daar misleidend aan?

[Cergorach]

ecomodus activeren = lager vermogen en dus lager energieverbruik = minder performance

Als je dat doet op een server die wel volledig wordt benut gaan gebruikers dat wel merken, afhankelijk van wat voor hardware je gebruikt. De CPUs van de afgelopen paar jaar gaan daar tegenwoordig een heel stuk beter mee om dan de oudere CPUs en schakelen veel makkelijker tussen verschillende 'standen'. Daarnaast had je voorheen ook een hele hoop gelazer met VMs en ecomodi, ook dit zal nu vast beter gaan, mits je moderne hard/software gebruikt. Ik kom echter, zowel bij het MKB als de Enterprise, best veel oudere servers tegen die nog prima draaien en vraag me af of die servers wel zo netjes omspringen met die ecomodi.

[pixeled]

Ah okee, je mist in de titel dus de relatie tussen energiebesparing en gelijk blijvende prestaties. Kan me voorstellen dat je dat op kan vatten als misleidend, hoewel ik dat zelf niet zo sterk heb. Bedankt voor de verduidelijking in ieder geval.

[Olaf]

Het was even puzzelen, maar ik heb in de titel en de lead verduidelijkt dat het om een lowprofileserver ging. Eigenlijk wil je ook de claim in de titel hebben dat gebruikers er niets van zouden merken, maar dat past niet. Bij komende testen moet blijken of die claim standhoudt bij het draaien van applicaties met hoger gebruik en hopelijk kan KNP dan specificeren hoe ze dit meten en wat de precieze uitkomsten zijn (dat hebben ze voor dit bericht niet gedaan, anders dan dat ze de prestaties 'met maatwerkrapportages' hebben gemeten.

[Cergorach]

Fijn dat je het aanpast! Die resultaten zijn echter in een heel specifieke situatie, dus waarom niet iets als: "KPN experimenteert met ecomodus in servers en laat positieve resultaten zien"

[tweazer]

Google maakt zijn eigen servers, Amazon zit ver in ARM ontiwkkelland. Microsoft, nog zoekende bij het Zune ontwerp, powernap bij Microsoft BOB(tm) wellicht ?

[klakkie.57th]

Als dit "en de medewerkers van KPN die de server gebruiken, zouden niets gemerkt hebben" de onderbouwing is van de bevindingen
Dan kan ik enkel maar zeggen dat de servers meer virtuele machines zouden kunnen verwerken dan ze tot nu toe deden.

Volledige hosts down -en upscalen enkel wanneer het nodig is zal een nog veel grotere besparing opleveren.

[Reactie gewijzigd door klakkie.57th op 22 juli 2024 17:35]

[Verwijderd]

Even los van of het de enige onderbouwing is, het is wel de onderbouwing die er toe doet toch? We kunnen alle microseconden willen besparen, maar als dat meer energie kost en mensen het niet door hebben dan ben je dus eigenlijk energie aan het verspillen voor niks.
Ik heb het gevoel dat in PC land de focus nog heel erg ligt op getalletjes en alles op papier zo snel mogelijk laten draaien. Maar mensen zijn uiteindelijk degene die het gebruiken. Als we 7% energie kunnen besparen zonder dat medewerkers het door hebben, moet dat dan onderbouwd worden met dat de performance exact hetzelfde is? Want nee deze is puur op papier waarschijnlijk iets slechter, maar dat maakt dus niet uit.

[klakkie.57th]

Mijn punt is dat die 7% energie al lang bespaard had moeten worden "server-farm-wide", door dynamisch hele hosts op of aan te zetten naargelang de load en daarvoor heb je geen gebruikers nodig om dit te meten.

[Verwijderd]

Maar dat is alleen gebaseerd op een persbericht wat ze hebben uitgezet natuurlijk. Als jij vanuit hier kan zien wat ze allemaal hebben gedaan en meteen heel KPN 10% beter kan maken in je vrije tijd denk ik dat ze je graag een baan aanbieden. Zonder complete informatie is het nutteloos om te roepen 'dit hadden ze al moeten doen' want dat is een beetje sturen vanaf wal met een blinddoek op, makkelijk te doen op het internet maar vrij nutteloos.

[klakkie.57th]

Dan hadden ze een beter persartikel de wereld moeten insturen.

[MadEgg]

Sowieso is het erg subjectief en relatief. Als de servers sowieso al te traag zijn dan zou je misschien een stijging van responstijd van 6 naar 7 seconden zien, ik denk niet dat dat de gebruikers op zou vallen. Terwijl een stijging van 0.1 naar 1.1 seconde je wel op zou vallen.

Maar goed, leuk voor deze specifieke server. Als de gebruikers het niet merken en vooraf ook al niet te klagen hadden over de snelheid, dikke prima, houden zo. En experimenteer rustig verder. Maar het is geen goede basis om conclusies uit te trekken.

[BENx1996]

Dus in principe gaat het om het finetunen van de ACPI instellingen?
Is het gemakkelijk te doen, of heb je hier een heel projectteam voor nodig?

Want in het geval van een projectteam zie ik het bedrijven nog niet enorm snel doen. Er wordt, vooral nu, voornamelijk gekeken naar besparingen op de korte termijn. Op lange termijn komt o.a. het bedrijf waar ik momenteel gedetacheerd ben zeker in de problemen hierdoor. Maar probeer dit maar eens te laten doordringen.

[vlaaing peerd]

Je hebt in principe alleen de fabrikant nodig om dat in de BIOS te implementeren. Het lijkt me echter stug dat de eindgebruiker (KPN) beter weet hoe de stroom te verminderen dan de fabrikant.

Je kan servers inderdaad wel finetunen op de load en de omgevingsfactoren zoals temperatuur, in een maar beperkt aantal gevallen heb je dan een custom BIOS nodig.

Ik vind dit verder ook niet echt nieuwswaardig. Het lijkt me vrij logisch en eigenlijk ook standaard dat je de server underclockt als je geen load gebruikt en dat lijdt tot minder stroomverbruik. Stroomverbruik is een constant doorlopende kostenpost op grote serverparken.

[GoT]

Het zal niet om 1 KPN servertje gaan, maar een volledig server park in een data center.
In verband met de omvang heb je wel een team nodig.

[Blasterxp]

Opruimen van oude zooi, uitzetten van oude testomgevingen, en weggooien. Er staat zo veel aan wat ' niets' aan het doen is.

Dit is zo'n vage pleister; los het probleem niet op.

Oh, mijn ervaring? Machines die 'bijschakelen' en dus hun kloksnelheid verhogen zijn altijd te laat hiermee. Dus als ze zeggen: "gebruikers merken er niets van." ; daar ben ik het niet mee eens.

[jqv]

Ze meten zelf de impact. Daar kun je twijfels bij hebben. Iets met wij van wc-eend.

Maar iedere besparing is er 1.
Ook als het gaat om oude testomgevingen of apparaten die niet tot nauwelijks gebruikt worden.

En de vraag is natuurlijk of de eindgebruiker die vertraging herkent als de machine weer moet opschalen.

[Shadow771]

Wat ook veel stroom kan schelen: sites op donkere modes..

[Verwijderd]

Ja, vooral veelbezochte websites, zoals tweakers

[DJMaze]

Dat kan...
custom css snippet: Dark in progress zonder !important

Maar de backlight van je monitor blijft aan

[Verwijderd]

Mwah, de local dimming crew en de oled gang hebben er zeker wel profijt van, naast dat het prettiger is voor je ogen

edit: zo die css is wel meteen een stuk beter

[Reactie gewijzigd door Verwijderd op 22 juli 2024 17:35]

[Shadow771]

LoL.. ik dacht nog ik laat tweakers achterwege in mn comment. xD

[Jeroenneman]

Tenzij je een OLED monitor hebt, gaat een zwarte site meer energie kosten op een beeldscherm met een backlight.

[vlaaing peerd]

Dat is alleen het geval bij de oude beeldbuis. LCD schermen hebben altijd backlight en het maakt niet uit hoe de kristal gedraaid is voor het stroomverbruik.

[Verwijderd]

Behalve het feit dat laptops en desktops vrijwel nooit OLED hebben, maar LCD. Oftewel, voor die use-cases maakt het precies niks uit.

[t link]

vindt het merkwaardig hoe veel mensen hier meteen beweren dat het niet kan dat gebruikers het niet merken e.d. neem toch aan dat KPN daar echt wel onderzoek naar heeft gedaan. misschien dat wij als techies het merken, maar als de eindgebruiker niks merkt was dat blijkbaar ook niet nodig.

[verstrooid_prof]

niet gemerkt ==> de tickets die gelogd werden konden niet een op een hieraan gekoppeld worden.
Die eindgebruikers zijn eerst voor de elf-en-dertigste keer hun pc aan het herstarten om te kijken of het probleem daarmee verdwenen is. En na de reboot is die server wel "op snelheid gekomen"...

[Uberprutser]

Meerdere clusters waarbij hosts uitschakelen in de off-peak tijden; dat scheelt pas echt energieverbruik.

[T_elic]

Ik ben een totale leek op dit gebied, maar is het nu dan zo dat alles wat ik in de cloud opsla dezelfde hoeveelheid energie kost? Ik ging er gemakshalve vanuit dat content die ik weinig meer gebruik of in zie in een soort van eco stand werd gezet.