CAD werk over X-verbinding

[VROEM!]

Ik werk de laatste tijd regelmatig via een X-verbinding op een andere compu. Wat ik me nu afvroeg is het volgende:

Stel dat ik werk zou doen waarbij vrij heftige dingen gerenderd worden (CAD of CFD visualisatie). Welke computer is daar dan het meest heftig mee aan het rekenen? De server (waar het
CAD programma op draait) of de client? Op zich leek mij dat de CPU van de server het meest belast wordt en de videokaart niet.
Zou de kwaliteit van de videokaart van de client er ook nog veel toe doen?

Ik vraag me ook af of mensen hier al eens op zo'n manier grafisch wat heftiger werk gedaan hebben. Loopt dat nog een beetje?

[webfreakz.nl]

Alleen het beeld van de remote computer wordt doorgestuurd, dit dus hetzelfde als dat je niet remote zou werken, dus wordt alles gerenderd door de remote computer

[VROEM!]

En dus ook door met name de CPU van de remote computer zeker? Ik neem tenminste aan dat de remote computer in principe niet eens een videokaart hoeft te hebben.

[dawuss]

Als er gerenderd moet worden, wordt dat allemaal op het "host"-systeem gedaan. De client hoeft alleen de X11-calls vanaf het netwerk weer te geven, dus de CPU van de server wordt het meeste belast. Afhankelijk van de X-calls (OpenGL bijvoorbeeld) die het programma maakt aan de andere kant, wordt de videokaart aan de client kant belast, maar het blijft echt bij wat simpel grafisch spul. Vrijwel al het werk wordt aan de kant van de server gedaan.

[chromeeh]

VROEM! schreef op dinsdag 21 maart 2006 @ 20:42:
En dus ook door met name de CPU van de remote computer zeker? Ik neem tenminste aan dat de remote computer in principe niet eens een videokaart hoeft te hebben.

Uhm... lijkt me wel handig...
Hoe ga je anders werken
Nee maar een terminal sessie geeft alleen maar de muis / tobo / video door, dus je render werk gebeurd zoals gezegt op de server.
De snelheid hiervan is dus afhankelijk van de cpu kracht van je server.

[engelbertus]

het renderen gebeurt op de server, maar ik vraag me dan wel af of dat nietd oor de videokaart van de server gebeurt?
stel je wilt een spelletje spelen over zon x-verbinding, en je hebt zelf een goedkoop kaartje, dan kan die niet je monitor net zo goed aansturen als een dure kaart van een paar honderd euro...

en cpu is geen grafische rekenaar, maar zal het ongetwijfeld wel kunnen...
hoe zit dat dan?
want volgens mij krijgt de client alleen "stills" te zien. stilstaande plaatjes die zijn gerenderd door de server dus eigenlijk .bmp-tjes oid?

[dawuss]

engelbertus schreef op dinsdag 21 maart 2006 @ 20:53:
het renderen gebeurt op de server, maar ik vraag me dan wel af of dat nietd oor de videokaart van de server gebeurt?
stel je wilt een spelletje spelen over zon x-verbinding, en je hebt zelf een goedkoop kaartje, dan kan die niet je monitor net zo goed aansturen als een dure kaart van een paar honderd euro...

Een spelletje is volgens mij niet bepaald hetzelfde als CAD-rendering.

volgens mij krijgt de client alleen "stills" te zien. stilstaande plaatjes die zijn gerenderd door de server dus eigenlijk .bmp-tjes oid?

Niet helemaal waar. VNC werkt bijvoorbeeld zo, maar remote X11 is wat intelligenter. In principe worden alle aanroepen op de X-server ("teken dit en dit voor mij") via het netwerk gedaan op de X-server van de client in plaats van die van de server. In de praktijk zal het vaak op pixmap-achtige tekenopdrachten gaan, maar dit kan net zo goed OpenGL of iets anders zijn.

[engelbertus]

ok cad is geen spelletje, maar waarom heb ik dan een mega dure videokaart nodig voor opengl zoals de ati fire gl, als ik cad tekenaar ben, en kan ik het niet aan de processor van gelijk mijn pc of de server overlaten?

vandaar dat ik toch denk dat je wel een beetje fatsoenlijke videokaart nodig hebt op een van beide systemen.

ik heb geen ervaring met vnc of x11, maar als je bureaublad overneemt, of een terminalservr start bestaat het beeld uit een aantal vakjes die die een voor een geupdate worden.

ik zie dit aan bijv het monitoring prgje van asus dat bij opstarten eerst chinese tekens gebruikt oid en die later vervangt door engelse tekst.
werk ik op de machine zelf zie je dat niet, start ik een terminalserver waar dat prgje op start, zie ik het eeld dus bloksgewijs van rare tekens naar engels gaan.

het "teken dit en dat voor mij" opdrachtje moet dus in beide gevallen door een videokaart worden berekend. en anders zou het voorwerk ( de "dit"en "dat") al door de server moeten worden uitgerekend voordat het naar 1 van de videokaarten wordt vesrtuurd.
er zijn dan denk ik ook twee zaken die je moet onderscheiden, en dat is een remote sessie en een x-tunnel
bij linux is het toch ook zo dat op de "client" een xserver moet draaien en op de server een x-client om op de server in te kunnen loggen?

[VROEM!]

Ik heb het net even geprobeerd (bedacht me dat ik het thuis prima gewoon kon doen
Anyway, hier is de setup:
Server: Dual PIII 1GHz/512MB
Client: Via Epia 533MHz Eden/64MB
Netwerk: 100MBit full duplex

Met X -query etc. wordt remote ingelogd op de server, daar wordt blender gestart en een file geopend die ik ergens anders al gemaakt had. Om "heftig" renderen te simuleren open ik een vrij eenvoudig metro-achtig vormpje nog zonder textures e.d. en roteer die wat.

Ook als ik "render view" oid doe (waarin dus in een venster even een extra opgeleukte render komt) rekent de client zich helemaal suf en geeft de server geen kik.
Hier was even wat vreemds gebeurd. Met een herkansing ging het ineens verbazingwekkend snel en werd de server ook daadwerkelijk belast. Ik denk dat ie hiervoor gewoon een keer vastgelopen is oid.

Het resultaat:
Op de server:
-Het netwerkverkeer neemt wat toe bij het roteren.
-De CPU's worden niet zichtbaar belast, behalve bij het starten van blender (eventjes 70%)

Op de client:
-Renderen is denk ik zo rond de 4 fps
-CPU rekent zich helemaal suf
-Netwerk verkeer neemt ook hier toe (duh) maar bij beide komt het niet echt richting de 100MBit.

Max netwerkverkeer zo rond de 40MBit op 1024x768 beeldpunten@24 bit

Mijn conclusie:
Renderen gebeurt toch voornamelijk op de client. De cpu belasting kwam makkelijk aan de 100% terwijl de server geen noemenswaardige belasting laat zien (schommelt continue rond de 5-7% per cpu).
Speciaal renderen van een los plaatje gebeurt wel duidelijk op de server.

Al met al is het wat jammer dat toch erg veel rekenwerk op de client gedaan moet met name bij dingen als het roteren van je vormpje. Voor de rest is het wel werkbaar. Als ik zou moeten kiezen tussen een trage client met een snelle server of direct op de trage client zelf werken zou ik denk ik toch het liefst op de server werken. Met name het opnieuw berekenen van surfaces e.d. en het maken van je mooie renders gaat toch duidelijk vlotter. Ik denk zelfs dat het roteren in deze setup sneller ging dan als ik die vorm direct op de epia zelf moest draaien.

[ Voor 30% gewijzigd door VROEM! op 21-03-2006 21:56 ]

[engelbertus]

dat klopt. wat jij doet, zon x sessie, beteket feitelijk alleen dat je de programmas die op je server geinstaleerd staan ziet als lokaal aanwezig. ze draaien dan op je eigen pc. doe je een terminal service satrten dan draait het wel op de server.

[VROEM!]

engelbertus schreef op dinsdag 21 maart 2006 @ 22:38:
dat klopt. wat jij doet, zon x sessie, beteket feitelijk alleen dat je de programmas die op je server geinstaleerd staan ziet als lokaal aanwezig. ze draaien dan op je eigen pc. doe je een terminal service satrten dan draait het wel op de server.

Oh? En hoe verklaar je dit dan:

Ook als ik "render view" oid doe (waarin dus in een venster even een extra opgeleukte render komt) rekent de client zich helemaal suf en geeft de server geen kik.
Hier was even wat vreemds gebeurd. Met een herkansing ging het ineens verbazingwekkend snel en werd de server ook daadwerkelijk belast. Ik denk dat ie hiervoor gewoon een keer vastgelopen is oid.

De CPU's van de server trokken hier toch duidelijk beide even een flinke belasting (70%/stuk als ik me goed herinner).
Bovendien ging het renderen echt veel en veel sneller dan op een celeron 500 van mijn vriendin. Daarop was ik wel een seconde of 20-30 bezig en dit was duidelijk binnen 5s gepiept.

[ Voor 11% gewijzigd door VROEM! op 22-03-2006 09:35 ]

[deepbass909]

Het ligt er helemaal aan wel protocol je gebruikt voor je terminal service. VNC en NX draaien volledig op je server, X-forward op je cliënt.
Beide versies hebben hun voor en nadelen. VNC/NX zijn vooral geschikt in de situatie waarin je een dikke server, goed netwerk en extreem lichte thin cliënts gebruikt.
X-forward bij een relatief dunne netwerk verbinding, lichte server (maar wel met snelle schijven) en fat cliënts.

Vooral bij VNC/NX kan een snelle videokaart wel degelijk van invloed zijn. De server maakt namelijk gebruik van je X-server en als die een goede videokaart heeft, kan hij sneller en beter beeld opbouwen. Ik heb ooit een server gehad die niet hoger kwam dan 800x600 32bit daardoor. Hoger was wel mogelijk, maar dan moest ik een software driver pakken, en dan werd het helemaal onwerkbaar.
M'n huidige server heeft een Matrox Mystique en die bouwt z'n 2d-desktop wel lekker snel op (ok, het kan altijd sneller, maar m'n vnc is ook alleen voor even mail checken).

Wat jij wil is met X-forward heel waarschijnlijk niet mogelijk. VNC/NX zou wel kunnen, maar is ook niet echt aan te raden.

[engelbertus]

VROEM! schreef op woensdag 22 maart 2006 @ 09:34:
[...]

Oh? En hoe verklaar je dit dan:

[...]

De CPU's van de server trokken hier toch duidelijk beide even een flinke belasting (70%/stuk als ik me goed herinner).
Bovendien ging het renderen echt veel en veel sneller dan op een celeron 500 van mijn vriendin. Daarop was ik wel een seconde of 20-30 bezig en dit was duidelijk binnen 5s gepiept.

"de eerste keer "
is denk ik het keyword.
de eerste keer moest alle data van de hd gehaald worden, dingen worden in cache geplaats zowel op de server als op jou pc. de tweede keer hoeft alleen wat er nog bij moest gedaan worden.

het beeld berekenen moest opnieuw gebeuren, en dat gebeurt de tweede keer op het systeem met de grafische kaart van de xservr. en dat is in dit geval gewoon jou client.

de data die normaal naar de vidokaart wrdt gestuurd gaat naar de videokaart van je client.

als je een dikke videokaart in de server gooit wordt het nog lastig, want de output daarvan gaat naar de vga uit. en niet weer terug en via de netwerkkabel naar hjou pc.

de grafische bewerkingen op de data die door een programma wordt geleverd word dus altijd op de client gedaan, tenzij de server het zelf kan uitrekenen zonder het naar een videokaart te sturen.
dan kom je dus bij een oplossing in software die het rekenwerk op de cpu van de server verricht, wat voor de server natuurlijk een flink karwei is. een cpu is geen gpu.

[deepbass909]

En daar komt de magie van FrameBuffer en VNC om de hoek kijken. Via FrameBuffers is het mogelijk de output van de meeste GPU's om te leiden naar het netwerk. Maar je zult nooit de snelheid halen die op de machine zelf te halen is, omdat er JPG-compressie tussen zit, en die moet je niet onderschatten in belasting.

[engelbertus]

hmm dus wat jij wilt zeggen is dat de uitgang van de videokaart weer terug gaat naar de pci / agp pci-e kant?

dat is wel nieuw voor me, maar idd, daarmee kun je geen coole spellen spelen, of zwaar cadwerk verrichten ( zoomen of draaien in #D model oid.) en.. zonder goeie videokaart in de sever komt er ook niet veel soeps in die framebuffer te voorschijn neem ik aan.

conclusie is dan dat je altijd minimaal 1 videokaart nodig hebt om een beetje zwaar grafisch werk te doen, en dan bi voorkeur op de client pc.

dat framebuffer is nl een software oplossing die dus niet de kwaliteit of snelheid van echt videowerk heeft, en zzeker niet de 3d mogelijkheden van een beetje grafische kaart

[VROEM!]

engelbertus schreef op woensdag 22 maart 2006 @ 15:45:
[...]


"de eerste keer "
is denk ik het keyword.

Dat denk ik niet.

Beide renders zijn vanuit een ander standpunt genomen, dus helemaal nieuw. Enige dat hetzelfde is het object dat gerenderd werd.

Data van de HD halen is geen bottleneck geweest, want:
-Om te beginnen was dit nooit meer dan een paar honderd K (het is echt een simpel modelletje)
-Verder is de client diskloos en was er geen piek in het netwerkverkeer, dus die heeft niet bijzonder veel data op lopen halen. Als die dat al wel had moeten doen was het nog steeds een paar honderd K over 100MBit. Dat had nooit een merkbaar verschil kunnen geven tenzij je opzettelijk die data in miniscule stukjes over de hele harddisk hebt uit lopen strooien.

Verder ging het opnieuw renderen van dezelfde scene vanuit het zelfde standpunt etc etc. niet sneller dan de eerste keer. Op de PC van mijn vriendin, that is.

Tot slot is het raar dat het roteren e.d. van het object in het edit venster geen merkbare cpu belasting geeft op de server, maar het renderen van de scene wel.

Renderen is hierbij: Een extra mooi plaatje maken voor opslag, niet het roteren e.d. tijdens normaal bewerken van het 3d object. Renderen doe je met F12 onder Blender.

[deepbass909]

engelbertus schreef op donderdag 23 maart 2006 @ 11:49:
hmm dus wat jij wilt zeggen is dat de uitgang van de videokaart weer terug gaat naar de pci / agp pci-e kant?

dat is wel nieuw voor me, maar idd, daarmee kun je geen coole spellen spelen, of zwaar cadwerk verrichten ( zoomen of draaien in #D model oid.) en.. zonder goeie videokaart in de sever komt er ook niet veel soeps in die framebuffer te voorschijn neem ik aan.

conclusie is dan dat je altijd minimaal 1 videokaart nodig hebt om een beetje zwaar grafisch werk te doen, en dan bi voorkeur op de client pc.

dat framebuffer is nl een software oplossing die dus niet de kwaliteit of snelheid van echt videowerk heeft, en zzeker niet de 3d mogelijkheden van een beetje grafische kaart

Ik weet niet precies hoe het werkt, ik weet wel dat ik in verschillende manuals/howtos heb gelezen dat een VNC/NX verbinding baadt heeft bij een hardware geaccellereerde server.
Er is 1 situatie (die zich met name bij vnc voor kan doen) waarbij het verschil echt zichtbaar is. Namelijk wanneer je scherm :0 deelt. Omdat dit ook je actieve scherm op de server is, wordt een kopie op het netwerk gezet. Ik heb daarbij echt grote snelheidsverschillen gemerkt tussen de vesa en MGA driver (op de server zelf was het verschil minder sterk merkbaar).