The return of the fat client

[elbizarre]

Allen, ik wil even een balletje opgooien waar ik afgelopen dagen op heb zitten broeden:

Het onderwerp is Distributed computing, CPU offloading en met name de combinatie van deze.

Ik las laatst een artikel over CPU offloading voor Android telefoons genaamd Cuckoo: http://www.asci.tudelft.n...asci2010_submission_9.pdf

Vervolgens dacht ik aan alle fat clients welke nog veelvuldig bij bedrijven staan te slapen, en de steeds zwaarder wordende Server back-end om alle compute af te handelen.
Een gemiddelde desktop is 90-95% niks aan het doen met de processor...

Wat nu als deze 2 zaken met elkaar gecombineerd kunnen worden, om de serverbelasting (deels) te offloaden naar alle machines in het pand?
Daarmee bespaar je een hoop dure stroom met bijbehorende koeling in het datacenter, en heb je ongeëvenaarde redundantie.

Als tweede: een desktop heeft tijdens het opstarten de meeste processorkracht nodig. Wat nu als hij deze kan laten uitvoeren door je collega's welke al eerder zijn begonnen met werken? Snellere opstart tijden?

Ik snap dat de huidige architectuur van programmatuur niet zomaar in losse CPU cycles verstuurd kunnen worden naar netwerkdevices, en zeker niet in het opstartproces van een PC. Maar hoe mooi zou dit zijn?
Heeft een van jullie meer ervaring op dit vlak qua CPU architectuur / offloading en Distributed computing om hier iets over te roepen?

[cyberbetica]

Direct kennis van CPU architectuur e.d. heb ik niet, maar ik zie wel waar je naar toe wil.

Zat klanten/projecten waar ik zit staan Quadcore Atom + 4GB + SSD thinclients. Op zich een prima kantoormachine maar worden enkel gebruikt om een Citrix-sessie te starten. Schiet een beetje z'n doel voorbij en is inderdaad zonde van de potentiele resources.

Hier en daar, niet op het gebied van "compute", doen we trouwens al wat offloading: BranchCache. Als binnen mijn organisatie 30.000 fatclients/laptops een update in hun cache hebben staan, hoeven de overige 30k deze niet van een drukke fileserver(DP) te halen.

[elbizarre]

cyberbetica schreef op maandag 07 maart 2016 @ 15:18:
Hier en daar, niet op het gebied van "compute", doen we trouwens al wat offloading: BranchCache.

Citrix Branchcache ken ik inderdaad. Echter zie je dat nog maar zelden wegens de snelle internet lijnen van tegenwoordig
Desalniettemin een mooi stukje intelligente software.
Maar network offloading etc is vrij gemakkelijk te verwezenlijken. Dat is I/O wat toch al in bitjes over de lijn gaan.
CPU lijkt me lastiger daar het in de basis niet gemaakt is om als requests over een ethernet lijn te transporteren. Latency lijkt me ook een issue.
Hoe dan ook: Ik hoop inderdaad meer mensen hun ideeën hierover te horen Ik heb helaas geen diepgaande kennis.

[Jazzy]

elbizarre schreef op maandag 07 maart 2016 @ 15:41:
[...]


Citrix Branchcache ken ik inderdaad.

Citrix doet schitterende dingen, maar BranchCache is gewoon een Windows Server feature.

[elbizarre]

Jazzy schreef op maandag 07 maart 2016 @ 15:43:
[...]

Citrix doet schitterende dingen, maar BranchCache is gewoon een Windows Server feature.

Yup. Fail...
Ik haal het even in de war met de Branch Repeater.
Dat krijg je als je zoveel verschillende certificaten hebt gehaald. Dan haal je het wel eens door elkaar haha

[NiGeLaToR]

Voor clustering van pc-hardware heb je bijvoorbeeld infiniband nodig om een acceptabel latency te behouden, tenzij je opzoek bent naar distributed computing. Daar kun je alleen geen real-time dingen mee doen omdat je eigenlijk alleen brokjes rekentaak kunt rondstrooien in de hoop dat een client het een keer verwerkt terugstuurt. Geen garantie over latency, wanneer het klaar is, of het ooit klaar is en hoe snel de overdracht plaats vindt.

Wat ik laatst wel hoorde in gesprek met een leverancier dat ze bewust offloading naar apps doen die op smartphones draaien - zo reduceren ze de belasting van servers die bij websites vaak zwaar belast zijn. Een server die apps info levert wordt minder belast dan een web server omdat de presentatie en evt andere logica lekker op de client gebeurt. Dus smartphone + app = fatclient anno 2016.

[elbizarre]

NiGeLaToR schreef op maandag 07 maart 2016 @ 15:54:
Wat ik laatst wel hoorde in gesprek met een leverancier dat ze bewust offloading naar apps doen die op smartphones draaien - zo reduceren ze de belasting van servers die bij websites vaak zwaar belast zijn.

Op zich is dat al een deel van de winst, maar dan zou het inderdaad naar een computer-cluster gestuurd moeten worden. Dan zou je er al zijn.

Ik heb overigens nog verder onderzoek gedaan en dit gevonden (bron: Wikipedia: TCP offload engine):
A generally accepted rule of thumb is that 1 Hertz of CPU processing is required to send or receive 1 bit/s of TCP/IP.
Dit betekend dus voor 1Ghz CPU offload je dus een 1Gbit netwerk stream hebt, in optimale benutting...
Daar wordt je niet bijzonder blij van.

Dat betekend dus dat je moet proberen de ontvangende partij slimmer om te laten gaan met requests. Met andere woorden moet je dus een soort functies / API's / DLL / Webservices aanroepen om de berekeningen te laten doen. Op die manier doe je alleen een request met parameters, en krijg je een object oid terug.
Daarmee haal je dus winst.
Probleem daarmee is weer dat je dus Agents moet gaan bouwen... Daar gaat je flexibiliteit.

[Question Mark]

elbizarre schreef op maandag 07 maart 2016 @ 16:03:
[...]
Ik heb overigens nog verder onderzoek gedaan en dit gevonden (bron: Wikipedia: TCP offload engine):
A generally accepted rule of thumb is that 1 Hertz of CPU processing is required to send or receive 1 bit/s of TCP/IP.
Dit betekend dus voor 1Ghz CPU offload je dus een 1Gbit netwerk stream hebt, in optimale benutting...
Daar wordt je niet bijzonder blij van.

Ik heb dat artikel even bekeken en ook het brondocument opgezocht... Je weet dat dit getest is met een 486 cpu en dat de conclusie uit ditzelfde brondocument is dat deze regel niet meer opgaat bij snellere cpu's?

Niet alles wat op Wikipedia staat is even waar....

Offloading van TCP features naar dedicated hardware (om zo de CPU te ontlasten) bestaat overigens al een aantal jaar.

[ Voor 6% gewijzigd door Question Mark op 08-03-2016 14:58 ]

[MAX3400]

NiGeLaToR schreef op maandag 07 maart 2016 @ 15:54:
Voor clustering van pc-hardware heb je bijvoorbeeld infiniband nodig om een acceptabel latency te behouden, tenzij je opzoek bent naar distributed computing. Daar kun je alleen geen real-time dingen mee doen omdat je eigenlijk alleen brokjes rekentaak kunt rondstrooien in de hoop dat een client het een keer verwerkt terugstuurt. Geen garantie over latency, wanneer het klaar is, of het ooit klaar is en hoe snel de overdracht plaats vindt.

Nou nou... Er zijn voldoende clustered oplossingen die helemaal geen interesse hebben in latency omdat het cluster-mechanisme er zelf al voor het gekozen iets niet realtime te versturen maar in batches / incrementals / whatever.

Daarnaast, maar nu kijk ik even opzij naar het serverhok; je kan ook zonder problemen een Windows-cluster opbouwen volgens best practice zonder allerlei hele dure hardware of low-latency componenten. Microsoft heeft hier een HCL voor en stelt zelfs limieten/ondergrenzen aan bepaalde zaken. Zo hoef je voor een aantal scenario's echt niet meer dan "enkele KB's bandbreedte" te hebben voor een active-active configuratie.

Tja, natuurlijk zijn er andere personen op deze wereld die diep in de clustering zitten om, bijvoorbeeld, zo goed als realtime een orkaan te tracken en te voorspellen. Ik denk dat je dan wel iets meer aan investering nodig hebt dan "gewone" PC hardware.

[Bigs]

Je zou het uitvoeren van bepaalde jobs wel over willekeurige clients kunnen op de zelfde manier zoals bijvoorbeeld 3D rendering over meerdere nodes wil. Echter de gevolgen van een kantoor waar alle PC's continu op 100% CPU staan te stampen (geluidsoverlast, warmteproductie) zijn over het algemeen ongewenst. Tel daar de inherente onbetrouwbaarheid en de extra beheerslast bij op en dan kun je beter gewoon je servers opschalen als je extra prestaties nodig hebt.

[NiGeLaToR]

MAX3400 schreef op dinsdag 08 maart 2016 @ 14:59:
[...]

Nou nou... Er zijn voldoende clustered oplossingen die helemaal geen interesse hebben in latency omdat het cluster-mechanisme er zelf al voor het gekozen iets niet realtime te versturen maar in batches / incrementals / whatever.

Daarnaast, maar nu kijk ik even opzij naar het serverhok; je kan ook zonder problemen een Windows-cluster opbouwen volgens best practice zonder allerlei hele dure hardware of low-latency componenten. Microsoft heeft hier een HCL voor en stelt zelfs limieten/ondergrenzen aan bepaalde zaken. Zo hoef je voor een aantal scenario's echt niet meer dan "enkele KB's bandbreedte" te hebben voor een active-active configuratie.

Tja, natuurlijk zijn er andere personen op deze wereld die diep in de clustering zitten om, bijvoorbeeld, zo goed als realtime een orkaan te tracken en te voorspellen. Ik denk dat je dan wel iets meer aan investering nodig hebt dan "gewone" PC hardware.

Ja tuurlijk, net wat het doel van het cluster is en dat kan kinderlijk eenvoudig zijn. Ik liet me wat meevoeren in real-time calculatie oplossingen, maar inderdaad, webservers zijn een mooi voorbeeld van clusters met loadbalancing waar de onderlinge latency niet zo heel spannend/cruciaal is.

Wat wel leuk is, is dat de oplossingen anno 2016 bijna nooit meer bestaan uit een active-passive oplossing voor bijvoorbeeld failover, maar inderdaad meestal active-active zijn zodat je altijd alles kunt benutten en backup hebt als eentje faalt. Vind het intrigerende technologie.

Qua offloading naar de client en gebruik maken van de rekencapaciteit van de client weet ik overigens ook niet of de apps het eeuwige leven hebben.

[elbizarre]

Bigs schreef op dinsdag 08 maart 2016 @ 15:10:
Echter de gevolgen van een kantoor waar alle PC's continu op 100% CPU staan te stampen (geluidsoverlast, warmteproductie) zijn over het algemeen ongewenst.

True, maar ze hoeven ook niet per se op 100% te staan natuurlijk.
een goeie 50% zou natuurlijk al een enorme hoeveelheid CPU zijn, alles bij elkaar gerekend.