Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 91 reacties

Na zeven release candidates heeft Linus Torvalds versie 3.4 van de Linux-kernel vrijgegeven. De kernel ondersteunt recente hardware, zoals Nvidia's Kepler-gpu, Intels Medfield-graphics, AMD's Trinity-apu en de Radeon HD 7000-serie.

De opensource-Nouveau-driver in kernel 3.4 kan overweg met GeForce GTX 680-grafische kaarten waarop Nvidia's Kepler-gpu is te vinden. De ondersteuning is echter nog beperkt; niet alle features van de gpu zijn beschikbaar. Ook bezitters van een systeem met een Trinity-apu van AMD of een grafische kaart uit de Radeon HD 7000-serie kunnen grafische ondersteuning verwachten vanuit de nieuwe kernelrelease, terwijl ook de Medfield-soc van Intel met behulp van opensource-drivers aangestuurd kan worden.

De ontwikkelaars van Intel hebben ook verbeteringen in de kernelcode aangedragen voor systemen die met Sandy Bridge-processors zijn uitgerust. Zo wordt de rc6-modus standaard ingeschakeld, waardoor de grafische kern minder stroom verbruikt als deze idle is. Nieuw is ondersteuning voor het displaylink-protocol in de vorm van de zogeheten udl-driver.

Kernel 3.4 bevat ook de mogelijkheid om x64-code te compileren met behulp van de x32-application binary interface. Deze laat programma's draaien op 64bit-cpu's, maar de code maakt gebruik van 32bit-pointers. Dit leidt tot minder overhead, waardoor programma's die genoegen kunnen nemen met minder dan 4GB adresseerbaar geheugen compacter zijn. Dit is vooral nuttig voor smartphones en embedded systemen.

Traditioneel bevat de nieuwe kernelrelease weer een groot aantal nieuwe of verbeterde drivers voor diverse hardware. Ook is er opnieuw gesleuteld aan het nog steeds experimentele btrfs-bestandssysteem, waarbij onder andere de foutafhandeling zou zijn verbeterd.

Moderatie-faq Wijzig weergave

Reacties (91)

Ik snap al dat positieve nieuws over Linux dan niet echt, sommige zweren erbij maar imo komen dit soort updates toch echt te laat uit. Voor gamers is dit al geen optie, zo lang wachten tot je eindelijk je kaart goed kan gebruiken.
Ik snap al dat positieve nieuws over Linux dan niet echt, sommige zweren erbij maar imo komen dit soort updates toch echt te laat uit. Voor gamers is dit al geen optie, zo lang wachten tot je eindelijk je kaart goed kan gebruiken
Je hebt er niet zoveel van begrepen Royeboi. Goede closed-source ondersteuning is er al jaren voor AMD en Nvdia-gpu's onder linux: Dat is een kwestie van downloaden en installeren: Binnen 10 min. klaar (gewoon met GUI). Gamen met die hap, desnoods onder Wine.

In de kernel zitten open-source drivers, die er meer-en-meer voor zorgen dat basic 2D en 3D-versnelling (dus niet voor games!) op de desktop out-of-the-box werkt. Zo hoeven mensen met een low- of midrange AMD of Nvidia kaart die niet gamen (de meerderheid) na installatie vaak verder niets meer te doen, want ook de 3D-snufjes onder Gnome en KDE werken dan gewoon.

Als je alles uit de kan wilt halen blijf je vast zitten aan de closed-source drivers die dus in een oogewenk zijn geÔnstalleerd.

edit: typo

[Reactie gewijzigd door Jack Flushell op 21 mei 2012 17:00]

Opzich zelf heb je een punt, maar het gaat hier om de open-source drivers. Die worden door de community zelf in elkaar geflanst en dat kost tijd. Daarnaast hebben ze de kaart vaak pas tegelijk met de consument dus is de driver niet op dag van release klaar.

Hou er ook rekening mee dat veel applicatie's op Linux niet zoveel kracht van de GPU vragen (het is immers voornamelijk een programmeer/browse platform), dus is het ook niet perse nodig om goede optimalisatie te hebben voor je GPU.
Eh sorry? Een programmeer/browse platform? Het is voornamelijk een server en embedded platform, programmeren uiteraard ook wel (maar dat is ieder platform, zonder programmeren geen platform...).

Voor een echt goed 'browse' platform is met name flash nog redelijk vaak te brak (then again... zo fantastisch is het op windows ook niet ;)) en java crashed ook nog wel eens (vaker dan op windows, is ook trager en heb niet het idee dat het verbeterd is sinds Oracle het overgenomen heeft (sterker nog, imo is het meeste alleen maar achteruit gegaan met Oracle... blijft ook een rare club, willen per se een ZFS like in linux, bouwen BTRFS (niet al te snel overigens...) terwijl ze gewoon de ZFS license aan kunnen passen)).

FYI: Ik gebruik het voor van alles en nog wat sinds slackware 3.0, ook als mijn desktop en draai windows alleen voor gaming. Ik zou derhalve dus graag zeggen dat de desktop erg goed is, hij is ook best aardig, maar met name programma's (waaronder met name games en financiele pakketten) ontbreken.
Sorry, forgot about the servers.

Maar alles goed en wel, het duurt nog een eeuw voor 3.4 op servers komt en daarnaast zullen die waarschijnlijk op een aangepaste versie van SB draaien en waarschijnlijk geen GPU bevatten. Dat zijn de wijzigingen waar ik het over had, impliciet dus alleen over de consumentenmarkt pratende en dan kom je weer terug op browse/programmeer platform.
Eh sorry? Een programmeer/browse platform? Het is voornamelijk een server en embedded platform, programmeren uiteraard ook wel (maar dat is ieder platform, zonder programmeren geen platform...).
Er zijn platformen die prima applicaties kunnen draaien, maar waarop programmeren onpraktisch is. Dat soort platformen worden dan ook ontwikkeld op andere platformen.
Voor een echt goed 'browse' platform is met name flash nog redelijk vaak te brak (then again... zo fantastisch is het op windows ook niet ;))
Dit ligt aan Adobe, niet aan de Linuxdistributies.
en java crashed ook nog wel eens (vaker dan op windows, is ook trager en heb niet het idee dat het verbeterd is sinds Oracle het overgenomen heeft
Oracle Java JRE op Linux? Voor 80% van de Java applicaties is OpenJDK JRE (meegeleverd met Ubuntu) en die is best wel stabiel. In de overige 20% zit veel prut waar zelfs Java JRE moeite mee heeft (ja, er zijn een groot aantal slechte Java programmeurs...).
(sterker nog, imo is het meeste alleen maar achteruit gegaan met Oracle... blijft ook een rare club, willen per se een ZFS like in linux, bouwen BTRFS (niet al te snel overigens...) terwijl ze gewoon de ZFS license aan kunnen passen)).
Oracle heeft haar eigen problemen: met de overname van Sun hebben ze een groot portfolio gekregen van software die niet in hun eigen straatje ligt of dat concurreert met hun eigen software. ZFS zit echter meer in de patentenoorlog, waar ze met BTRFS omheen hopen te werken.
FYI: Ik gebruik het voor van alles en nog wat sinds slackware 3.0, ook als mijn desktop en draai windows alleen voor gaming. Ik zou derhalve dus graag zeggen dat de desktop erg goed is, hij is ook best aardig, maar met name programma's (waaronder met name games en financiele pakketten) ontbreken.
Het is een cirkel: bedrijven zullen Linux pas ondersteunen als er meer vraag naar is. Consumenten en andere bedrijven zullen Linux pas gaan gebruiken als er meer ondersteuning voor is voor de door hun gebruikte programma's. Wel is de situatie al een stuk beter dan 10 jaar geleden en wellicht kan Steam onder Linux het nog een redelijke boost geven. Verwacht echter geen wonderen. ;)
Ja op dezelfde manier ligt het aan Blizzard, EA, noem ze maar op dat er geen games zijn. Dat weerhoudt de consument er gek genoeg echter niet van om over te stappen. Maakt geen reet uit wiens 'fout' het is.

Zelfde geldt met flash. Dat het aan Adobe ligt zal de gebruiker aan z'n reet roesten. Op linux werkt het slecht, op windows werkt het (minder slecht ;P).

OpenJDK doet het vaak niet voor me, helaas.

Wat betreft je stelling rond ZFS heb je daar bronnen van? Heb zelf namelijk veel meer het idee dat ze het uit willen buiten. Het is ook closed source nu (d.w.z. de bron was toegankelijk via opensolaris en dat is dood, van de recente nieuwe features is dan ook niet bekend hoe ze geimplementeerd zijn waaronder encryptie). Veel aannemelijker dat ze er geld op willen verdienen dus (en nee dat is niet onderbouwd, Oracle doet echter niet bijzonder veel uitspraken over dit soort dingen en het onderbouwen zal dus ook niet meevallen).

De situatie verbeterd idd, alhoewel het soms ook verslechterd (de vele openoffice forks die door het geneuzel met Oracle zijn ontstaan evenals MySQL forks zijn niet echt bevordelijk voor consumenten vertrouwen bijv.).

Om een echte boost te krijgen moeten er wat killer apps komen die het alleen op linux doen. Echter, ik ken geen enkele (goede) applicatie onder linux die geen windows (en/of mac) port heeft.
Om een echte boost te krijgen moeten er wat killer apps komen die het alleen op linux doen. Echter, ik ken geen enkele (goede) applicatie onder linux die geen windows (en/of mac) port heeft.
Dat is nu juist het voordeel van open source. Je kan de code pakken en compileren voor een ander platform (mits goed geschreven).
Echter, ik ken geen enkele (goede) applicatie onder linux die geen windows (en/of mac) port heeft.
Een port van open source naar closed source is ook een stuk makkelijker dan andersom...

[Reactie gewijzigd door ByteBusters op 22 mei 2012 15:43]

Die discussie wordt al gevoerd sinds ik in 2001 begon met Linux.
Opzich zelf heb je een punt, maar het gaat hier om de open-source drivers. Die worden door de community zelf in elkaar geflanst en dat kost tijd. Daarnaast hebben ze de kaart vaak pas tegelijk met de consument dus is de driver niet op dag van release klaar.
Dat het tijd kost komt niet alleen doordat de community trager is dan de 'professionele' ontwikkelaars van AMD/nVidia. Het grootste probleem bij de ontwikkeling ligt aan de brakke of missende documentatie van de hardware. Dit betekend dat de 'amateur' programmeurs vaak lopen bezig zijn met reverse engineering om vervolgens datgene na te bootsten wat de binary drivers normaal doen. (de vraag is dan ook wie is er nou eigenlijk professioneel). Pas de laatste tijd verstrekken de grafische kaarten hardware fabrikanten een beetje meer documentatie (uitgezondert nVidia; zij blijven er blijkbaar bij dat de consument altijd een dom persoon (in de zin van computers) is die niets hoeft te weten)
Documentatie is overrated. Als het klaar is voor release loopt je product achter op de markt. Snelheid is de sleutel tot succes.
Je gebruikt Linux ook niet als je alleen maar games speelt op je desktop. Maar voor de wat meer serieuze taken wint Linux het toch echt.

[Reactie gewijzigd door Slurpgeit op 21 mei 2012 15:30]

Je kan gewoon de nvidia of amd driver downloaden en die gebruiken. Het gaat hier om de opensource driver die met de kernel meegeleverd wordt. Deze is niet zo compleet als de driver van AMD of nvidia zelf.
Je kaart is al prima te gebruiken, mits je de closed-source drivers van nVidia of AMD gebruikt.
Niet iedereen speelt games enzo.
Vergeet niet dat een hoop werk vanuit de community komt, dit zijn vaak ook nog eens vrijwilligers.

In tegenstelling tot commerciele bedrijven die miljoenen in research and development kunnen steken om een innovatief maar gesloten product te leveren, ontwikkelt dit zich tot een open product waarbij ook zeker innovatie om de hoek komt kijken, maar meestal wat trager tot stand komt of waarvan de uitwerking in niet alle gevallen op een consistente manier uitgewerkt wordt.

Helaas is het voor de meeste spelontwikkelaars gewoonweg niet rendabel games voor Linux uit te brengen, echter sinds 2005 is er al veel meer keuze dan daarvoor en dit breidt zich alleen maar uit.
Tja, het is dan waarschijnlijk ook slechts het meest gebruikte OS in de wereld. Enkel op de desktop markt wil het maar niet lukken.

Voor gamers is linux geen optie zolang er geen games zijn. Drivers zijn er al langer dan vandaag. AMD en nVidia leveren gewoon zelf binaire drivers. Waar hier naar verwezen word zijn de open source drivers.
weet t niet dus het kan waar zijn dat het t meest gebruikte os in de wereld is, maar dat het op de desktop niet wil lukken vind ik geen vreemde zaak. ik heb Kubuntu geprobeerd op onze oude laptop, en heb tot 4x toe de hele zaak opnieuw kunnen installeren omdat de laptop aangaf dat er updates waren (en ja ik update dan ook maar gelijk), en dat de laptop tijdens het updaten uit viel (en ja de oplader gewoon aangesloten dus batery leeg was geen issue) en dat na restart de laptop niet verder kwam als de dos prompt (dacht grub ofzo ), nadat ik dit tot 4x toe in klein 1,5 jaar heb gehad toch weer lekker terug naar windows gegaan en geen problemen meer, en nog altijd dezelfde install.
Kijk je bijvoorbeeld naar webservers, dan is Linux een dominant OS. Kijk je naar de smarphones dan word Android tegenwoordig het meest verkocht. Vele settop boxen voor digitale TV maken ook gebruik van Linux. Heb je een router in huis bestaat er een reŽele kans dat er Linux op draait en ga zo maar verder. Ik heb geen cijfers om het te staven, maar Linux is zeker niet iets dat niet wil lukken.
Ik ben benieuwd wanneer deze kernel in de (ubuntu 12.04) repositories verschijnt.
Ik heb hem net geinstalleerd vanaf hier: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-precise/ met deze instructies: http://penreturns.rc.my/2...linux-340-999-kernel.html (Instructies even aanpassen naar nieuwe link uiteraard :).
Niet. Kernel upgrades(wat anders dan updates) komen nooit in 1 distro versie. Waarschijnlijk zal dit in 12.10 komen. Eerder denk ik dat 3.5 of 3.6 pas weer in een Ubuntu distro zal verschijnen.
Of je zoekt met google naar kernel ppa en je installeerd zelf je kernel.
Kortom: goed nieuws voor nieuwere high-end systemen, met name Sandy-bridge based servers zullen baat hebben bij deze release met de rc6 support...
Dit is vooral nuttig voor laptops en desktops. Servers hebben (bijna?) altijd een aparte grafische chipset met eigen geheugen (vaak van ATI of Matrox). Op servers wil je namelijk niet dat je performantie achteruit gaat doordat de geheugenbus belast wordt voor graphics.

Uit "What every programmer should know about memory" (https://lwn.net/Articles/259710/)
Finally it should be mentioned that some cheap systems
have graphics systems without separate, dedicated video
RAM. Those systems use parts of the main memory as
video RAM. Since access to the video RAM is frequent
(for a 1024x768 display with 16 bpp at 60Hz we are talk-
ing 94MB/s) and system memory, unlike RAM on graph-
ics cards, does not have two ports this can substantially
influence the systems performance and especially the la-
tency.
aan de gegevens in de quote is al goed te zien hoe oud het document is waar je naar verwijst, ik denk niet dat de conclusies uit 2007 nog net zo toepasbaar zijn in 2012
En waarom niet?

1024x768x16bpp@60Hz is nog steeds 94MB/s. Sterker nog, als je het over een server OS hebt wat ook nog is mooie graphics wil, 1024x768x32bpp (eigenlijk 24bpp)@60hz heb je het over 188MB/s wat continue over je bus vliegt. (Vaak zijn dit soort systemen via VGA op kvm's aangesloten en moet het beeld dus elke 1/60'ste ververst worden, tenzij powermanagement van het beeld wordt ingesteld, wat vaak niet wordt gedaan, omdat het 'toch maar een server zonder monitor' is.

Dus toepasbaar zeker en dit mag nog meer onder de aandacht gebracht worden als je 1280x1024x32bpp op je server hebt draaien.
ahum

Mooie graphics op een server kunnen mij gestolen worden
Een linux server is een server en geen pc op afstand.

Meestal laat je een server in runlevel 3 (multiuser) werken en niet in runlevel 5 (X).

Beheer van de server gebeurd via ssh, management board (ilo en dergelijke) en grafische dinenge via tools zoals NX (van nomachine).

KVM kom ik eigenlijk meestal niet meer tegen.
Het lijkt erop dat de management boards die functie hebben overgenomen
Eindelijk iets zinnigs. Een server heeft idd geen grafische interface nodig.
Hij gebruikt NoMachine NX, dat is een gecomprimeerde ( door middel van een 2 proxies aan server- en client zijde ) vorm van het X protocol, getunneled over SSH. Dat is dus wel degelijk grafisch, je hoeft alleen geen lokale X server te starten, je bent nog steeds gewoon gevoelig voor dezelfde exploits. Dat gezegd hebbende schat ik het risico hiervan nog wel redelijk laag in, tenzij je echt gaat zitten browsen of andere gekke dingen gaat doen waarvoor een server niet bedoeld is.
Mocht een server niet meer op de officiŽle manier reageren dan gebruiken wij inderdaad ook DRAC of ILO.
Yep,

InitiŽle linux installatie doe ik via de ILO en daarna zet ik er NX op om de (Oracle) software erop te zetten.
Ik zou hiervoor ook vncserver of xming kunnen gebruiken, maar NX vind ik gewoon prettiger werken.

Dagelijks beheer gebeurd via ssh (en sqlplus voor de database).

Firefox en dergelijke zet ik inderdaad niet op een server :-)
Op een linux server wil je niet eens een Xserver hebben draaien want het is ook nog eens een security risk gezien het berucht is om zijn gaten.
1024x768x16bpp@60Hz is nog steeds 94MB/s
Het is niet dat je videokaart constant gevoed wordt, dus er is ook geen continue datastroom van 94MB/s over de PCIe bus.

Als dat zo was, dan waren de systemen van toen (met PCI) niet vooruit te branden.

http://www.tomshardware.c...d-windows-gdi,2539-2.html
Nah effectief is het een paar gigabyte per seconde aan bandbreedte wat je kwijt bent voor simpele graphics al, omdat de manier van het TEKENEN van je beeldscherm achter de schermen megainefficient gaat.

Er worden letterlijk beelden over elkaar heen gerommeld en vooral schermpjes met verschillende fonts (hoezo hoor ik het woord BROWSERS klinken?) vreet megabandbreedte.

Dan komt daarbij dat de render engine werkelijk vaak gebakken zijn door figuren met lagere school, dus wiskundig niet geheel handig is het geprogrammeerd (echt understatement van het jaar) en dat is waarom het van de moderne videokaarten zoveel bandbreedte vreet.

Vergis je niet erin, de moderne videokaarten leveren handsdown 140-200 GB/s om over de dubbele gpu's te zwijgen; je pc'tje gaat echt alleen in 1 of andere benchmark met alles geoptimaliseerd tegen de 20GB/s halen als het een snelle hooggeklokte i7 is.

In praktijk ga je dat niet halen.

Dus het gaat hier niet zozeer over je pci-e maar met name over de BANDBREEDTE die de gpu gebruikt van de RAM om de OpenGL/DirectX instructies uit te voeren.

*dat* vreet bandbreedte. 20GB/s vullen is echt *peanuts* op 1024x768.
Nogmaals ik zeg niet dat dat komt DOORDAT het dat ook echt vreten moet.
De praktijk is: ze vreten het.

Overigens de communicatie van gpu on board de cpu naar memory heeft niks met pci-e van doen. De memory controller en 4 memory channels zitten ingebakken in de i7 sandy bridge core. Dus dat hamert direct in de geheugenbanken.

[Reactie gewijzigd door hardwareaddict op 21 mei 2012 19:18]

Die 188 MB/s is ongeveer 5.2% van de DDR max datarate. Dit is dus een redelijk marginale hoeveelheid verkeer op die bus. Vooral omdat die video pixels redelijk makkelijk in een burst verstuurd kunnen worden.
aan de gegevens in de quote is al goed te zien hoe oud het document is waar je naar verwijst, ik denk niet dat de conclusies uit 2007 nog net zo toepasbaar zijn in 2012
Want de architectuur van een PC is nu anders?

Niet dus. Het is allemaal iets sneller geworden natuurlijk, maar die belasting is er nog wel degelijk.
Want de architectuur van een PC is nu anders?
Uh.. ja, want toen was Sandy Bridge met ingebouwde GPU nog niet uit ;), en kan me voorstellen dat dat toch wel een en ander wijzigt.

[Reactie gewijzigd door anoko op 21 mei 2012 16:58]

het is alleen nog maar erger geworden sindsdien - grafische kaarten worden enorm belast op de memory bandbreedte. Een grafische kaart kan dat met DDR5 makkelijk trekken, maar het veel oudere DDR3 van cpu's is vrij kansloos daar, factor 10 bandbreedte verschil effectief in voordeel van grafische kaarten, *praktisch* gesproken.

Ja ja theoretisch is het factor 8 ofzo, maar dan nog steeds enorm verschil.

Dus dit maakt enorm uit zo'n feature.
DDR5 bestaat niet eens. GDDR5 wel, maar
Like its predecessor, GDDR4, GDDR5 is based on DDR3 SDRAM
DDR5 heeft 256 bytes cachelines in de gpu's en DDR3 dus 64 bytes.
DDR5 van de videokaarten heeft ingebouwde CRC, DDR3 dus niet. Voor servers kun je wel DDR met ECC krijgen overigens (ook bij DDR5 nog mogelijk zoals bij de Tesla's hier die ik heb).

Dus voor 1 memory channel is de bandbreedte van de videokaarten al factor 4 groter. Komt bij dat ze meer memory channels hebben.

Sandy Bridge/Ivy bridge hebben er 4. Dus 4 memory channels van sandy bridge leveren zelfde bandbreedte als DDR5 met 1 memory channel.

Dat verklaart ook waarom de bandbreedte van de GPU's zo enorm groter is en waarom als je dat ding inbouwt op een CPU, hij 20 GB/s maar niks vindt :)

DDR3 is overigens qua latency sneller omdat die al na 32 bytes kan aborten, wat voor CPU's vaak handig is en bij GPU's niet. DDR5 kan dit NIET.

dus er zitten enorme verschillen tussen DDR3 en DDR5.
DDR3 is dus latencywise sneller, maar videokaarten gebruiken BANDBREEDTE en dan hamert DDR5 alles en iedereen weg ineens.

[Reactie gewijzigd door hardwareaddict op 21 mei 2012 20:14]

Je kan je het voorstellen, maar dat lijkt me een wat dunne grond voor een bewering. Heb je een linkje?
http://www.nvidia.de/obje...-690-de.html#pdpContent=2

bandbreedte van de GTX 690 : 384 GB/s

Hier review van 1 van de grootste memory experts die online schrijft:

http://www.lostcircuits.c...d=42&limit=1&limitstart=4

Hij weet zelfs 36GB/s uit de intel i7-3960x te peuteren (met turboboost) en dat is met geheugen dat jij en ik niet hebben, want dat bouwt hij zelf.

Dat ligt ver af van de claim van intel voor de i7-3960x hier: 51.2GB/s

http://ark.intel.com/prod...-%2815M-Cache-3_30-GHz%29

Er zit best wel een megaverschil tussen de claim van 51.2GB/s en 36GB/s voor de snelste intel cpu op dit moment voor gaming.

Bij Nvidia haal je dat maximum er veel makkelijker uit. 384GB/s is heel wat meer dan 36GB/s . Dat is ver boven factor 10 verschil in het voordeel van GPU's.

De meeste GAMES zijn BANDBREEDTE gelimiteerd. Dus grotere memory bandbreedte die je ook kunt achieven, dat betekent direct dat de game sneller loopt.

Daarnaast is er overigens vaak nog een ander knullig iets bij *sommige* games, namelijk dat ze veel dingen vanaf 1 cpu core lanceren richting de GPU. Dus een hele snelle cpu hebben met de laatste pci-e scheelt ook. Nieuwste standaard is pci-e 3.0 technologie. De nieuwe i7's en mainboards ondersteunen dat.

Enige serverborden die ik hier heb waarop ik tesla's draai die ondersteunen maar pci-e 1.0 dus dat schiet niet op. Dan haal je maar 2.2GB/s richting de GPU's. Dat is overigens beide kanten op. Dus zowel 2.2GB/s ene kant op en 2 GB/s de andere kant op.

Daar ik de tesla's priemgetalletjes voer is dat met met name richting GPU dus. Ik kom enorm bandbreedte tekort, terwijl er wel 16 cpu cores nodig zijn (amd barcelona) om die gpu's te voeren.

Dat vertaalt zich dan aan interne bandbreedte van de cores in de orde grootte van enige terabytes per seconde op de registers.

Bandbreedte is dus heel erg belangrijk.

[Reactie gewijzigd door hardwareaddict op 21 mei 2012 20:45]

En de south of northbridge is toch weggehaald? Of is dat niet bij servers!? Iedereen heeft het over KVM is dat kvm zoals met qemu? of is dat die andere kvm?
Keyboard-video-mouse. Er bestaan daar 2 vormen van: een bekabelde versie zodat je met 1 monitor/muis/tobo meerdere PCs kunt bedienen (waarbij je hardwarematig wisselt) of in het geval van servers heb je een interne oplossing waarbij in de server bijkomende hardware zit die dit alles laat aansturen over het netwerk (er bestaan ook hybride oplossingen waarbij externe KVMs zich over het netwerk laten bedienen).
Ter aanvulling:
In een serverrack heb je natuurlijk niet voor elke server een monitor/muis/toetsenbord.
Daar zit dus een schakelkastje tussen zodat je af kunt met 1 setje. Dat is een KVM switch.
Een doorontwikkeling daarvan is dat er in het serverrack helemaal geen monitor hangt, maar dat deze ergens anders staat en dat het allemaal aangesloten zit via een vorm van netwerk.

Nog verder: Helemaal geen monitor, maar een webinterface zodat je de console gewoon in je browser kan zien/beheren.....maar dat valt eigenlijk onder Remote Access, niet meer onder KVM.
Servers hebben (bijna?) altijd een aparte grafische chipset met eigen geheugen (vaak van ATI of Matrox).
Servers hebben bijna nooit een aparte grafische kaart, die draaien of headless, of met een igp. Discrete kaarten heb je alleen nodig voor zware 3D toepassingen, en dat doe je niet op servers.

Workstations, dat is een ander verhaal.

[Reactie gewijzigd door Dreamvoid op 21 mei 2012 16:12]

Eigenlijk is de ideale server 1 zonder GPU. Ofwel direct headless installeren mbv de rs232 of anders even een GPU kaart insteken voor eerste install en eenmaal sshd draait van daar af verder werken.
Lijkt me juist niet, als je toch even wat via de GUI wilt doen (omdat SSH niet werkt oid) dan moet je eerst de server uitzetten (wat weer downtime geeft).
Dan neem je rs232
Geen aparte kaart op een dochterkaart nee, wel een aparte chip op het moederbord mťt dedcated videogheugen. Dat is het geval voor alle servers die ik hier beheer. De meesten een Matrox MGA200-variant (yep, Matrox bestaat nog!), en ik heb er ook eentje met een ATI ES1000 (met 16 MB eigen videogheugen).

Hp ProLiant DL185 G51e:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200e [Pilot] ServerEngines (SEP1) (rev 02)
Dell Poweredge R410: 04:03.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200eW WPCM450 (rev 0a)
IBM System x3550: 01:01.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02)
Supermicro: 05:01.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200eW WPCM450 (rev 0a)

Trouwens, enkel een beperkt aantal low-end Xeon E3-servermodellen hebben geÔntegreerde graphics, de meeste Xeon-processoren hebben zelfs niet eens een GPU: https://en.wikipedia.org/...ntel_Xeon_microprocessors

[Reactie gewijzigd door freggy op 21 mei 2012 16:29]

Discrete kaarten heb je alleen nodig voor zware 3D toepassingen, en dat doe je niet op servers.
Discrete GPU's heb je daarintegen vaak wel nodig voor IP-KVM integratie. Natuurlijk hoeft dit geen snelle GPU te zijn.
uh? Intel (wazige llc pilot 2 controller) of Supermicro

Weinig IGP dus maar veel dedicated GPU met eigen geheugen. Workstations daarentegen hebben er vaak geen bips aan (doe maar eens autocad op een matrox G200).

Dat het op het mobo gesoldeerd is betekent niet dat het een IGP is, het is gewoon een normale videokaart, maar omdat het ding nooit iets anders nodig heeft dan deze kaart is het goedkoper en stabieler (geen connectoren) om het ding direkt vast te solderen. Zit je ook niet met driver issues.

Een reden dat die dingen vaak een gpu hebben is dat je remote management dan vaak iets makkelijker verloopt (VNC achtige oplossing met een framebuffer via het netwerk versturen. Moet je wel een framebuffer hebben). Als je zomaar een videokaart erop zou moeten doen dan is het onmogelijk de remote management stabiel te krijgen (moet je IPMI gaan updaten iedere keer als NVidia een nieuwe driver uitbrengt? Ik dacht het niet).
Hoe zit dat dan met Sandy Bridge systemen die de videokaart op de processor hebben? Gebruiken deze ook het werkgeheugen of zit er al videogeheugen op de chip?

Gaat overigens hard met de kernel ontwikkelingen, goede zaak.
Deze gebruikt het werkgeheugen. 'shared memory' :)
Euhm, meeste servers draaien headless. Indien de gfx on board zijn word het gehuigen gebruik automatisch minimaal gezet omdat er toch geen scherm aanhangt. Er is dan ook geen echte verspilling aan geheugenbandbreedte. De enige keren dat een gfx output op een scherm ververst moet worden is bij systeemberichten, die komen wel door op de console.

Enige uitzondering in principe is windows.
Reden waarom servers veelal met Matrox G200eW zijn uitgerust is simpel: veel servers hebben tegenwoordig IPMI onboard, of iig ondersteuning daarvoor. De veelgebruikte chip komt van Nuvoton/Winbond, en daar zit gewoon een G200eW in geintegreerd. Waarom intern een VGA output vanaf de IGP naar een KVM-oplossing prutsen als je ook gewoon de geintegreerde chip van de IPMI KVM oplossing kunt gebruiken?

Overigens is 94MB/s (of 188MB/s bij 32bpp) peanuts als je kijkt naar de bandbreedte van moderne servers. In de tijd van de i810 kon je duidelijk performanceverschil merken tussen een machine met 4MB displaycache of een machine zonder die module erin, bij een modern systeem met duizenden MB/s doorvoer op de geheugencontroller en IGPs die de CPU-cache kunnen misbruiken is het verschil niet meer denderend.
ATI word nog zeer weinig gebruikt hoewel hun 8MB/16MB chipje wel erg goedkoop is. Matrox zie ik eigenlijk ook nooit meer. Aspeed, Nuvoton en Volari zijn op dit moment de spelers vanwege hun geintegreerde BMC.

Verder lijkt me GPU computing nogal booming, voorlopig nog met dure kaarten maar ook daar zullen gauw "mainstream"kaarten voor worden gebruikt.

Daarnaast zijn de in het artikel genoemde kaarten al wel netjes voorzien van hun eigen geheugen!

Daar weer naast enkele nogal erg server gerichte fixes:
https://lkml.org/lkml/2012/5/20/126

Wat mij betreft is dit dus ook een hele nuttige update voor servers, wat bij linux updates nogal erg snel het geval is natuurlijk.
Servers lopen meestal toch een paar updates achter denk ik. volges mij worden Ubuntu servers dan weer wel vaker geupdate dan Windows maar desondanks mooie ontwikkelingen.
Bovendien kun je, als je de voordelen groter vind dan de nadelen, je kernel vanaf source compileren.
Je hoeft natuurlijk niet die alternatieve Nouveau driver te gebruiken, nVidia's eigen drivers werken een stuk beter. Alleen niet open source, maar dat is behalve voor developers niet echt een issue.

[Reactie gewijzigd door Dreamvoid op 21 mei 2012 15:23]

Zeker, ik heb op de worstations die ik beheer niets dan ellende met Nouveau.
Zo werkt Nouveau niet met Stereo mode 7, de interlace mode van Zalman. Laat er nou net zo'n display aan elk workstation hangen.

De ellende is dat die Nouveau driver in de kernel zit, en het bijna onmogelijk is om hem niet te laten starten als je redhat of centos als vanille installatie doet.
Je moet vanaf het begin de boel 'with minimal graphics' doen, maakt meteen de installatie maar ook het boot scherm lelijk. Ook als je de Nvidea driver er op zet, want die komt pas later tot leven.
Probeer nouveau te blacklisten in /etc/blacklist.d/<iets>.conf, of te booten met nomodeset als kernel option. In beide gevallen zal nouveau niet worden geladen. Normaal gesproken maakt de nVidia installer overigens deze blacklist regel voor je aan.

Edit: dat je "bootscherm" lelijk is is omdat nVidia niet aan kernel mode setting doet. Dwz: slechts in X.org wordt je resolutie aangepast. Wel kan je handmatig een resolutie kiezen door als kernel option vga=<iets> mee te geven, waarbij ik zo uit het hoofd niet weet wat <iets> is, maar deze verschilt per resolutie.

[Reactie gewijzigd door RSpliet op 21 mei 2012 22:10]

Ik weet 95% zeker dat je ofwel een of andere hexwaarde op kunt geven, ofwel gewoon iets als vga=1280x1024,32 , hoeft niet altijd moeilijk te zijn :).
Opnieuw de kernel compileren, maar dan zonder de Nouveau drivers - een heel gedoe!
Ik kan je 1 ding vertellen: Nouveau werkt vele malen beter voor mij dan de binary drivers.

Het blijkt dat de binary drivers bij meerdere monitors nu en dan GPU geheugen lekken. Nadat mijn pc een paar uur aan stond duurde het bv. 5 seconden voordat een window op een click-event wilde reageren. Video ging haperend. Er was gewoon niet mee te leven.

Nouveau was een wereld van verschil. Alles blijft `snappy', hoe lang de pc ook aan staat (lees: weken). Bovendien werkte de framebuffer voor terminal mode opeens automatisch. Dat was me nog niet gelukt met nvidia drivers (kan ook aan mij liggen).
Er zat vorig jaar een bug in de binary driver waardoor die na 49 dagen memory ging lekken. Refereer je daar ?
Nee, zeker niet. Hij ging dus al lekken na een paar uur (of direct al, en duurde het even voor ik het merkte). Eens per maand mijn pc herstarten had ik niet zo erg gevonden.

[Reactie gewijzigd door Michiel op 21 mei 2012 17:00]

Diegenen wat Arch Linux draaien en de [testing] repo. aan hebben staan kunnen hem al binnen hengelen (als de mirrors gesynct zijn). x86_32 staat wel nog uit.

Bron

Over enkele weken zal deze dus ook mooi in [core] belanden, maar meestal is het dan een .1 of .2 en niet de .0.
En wie ook altijd de nieuwste wil hebben als het gaat om de RC-versies (RC1 van de volgende versie is pas over 1.5 week of zo) en geen zin heeft het zelf te compilen:
https://aur.archlinux.org/packages.php?ID=50893 (De locatie van de binary is te vinden in de comments).

[Reactie gewijzigd door Dr. Prozac op 21 mei 2012 16:47]

Dat is in principe met alle Testing/Unstable/Experimental branches van de Linux distributies daar is Arch niet speciaal mee. Het enige verschil is de kwaliteit van hoe het geÔntegreerd wordt...
Mooi, goede features. Ik vraag mij af of deze kernel ook zonder al te veel problemen te implementeren is in een oudere Ubuntu versie, zegge 10.10 x64.
Tuurlijk, zoek jezelf even een goede tutorial over het compileren van je eigen kernel en op 2 uurtjes draai je er mee.
precies 2 uurtjes compileren en 2 weekjes uitzoekwerk waarna je erachter komt dat je beter 12.04 kunt installeren en die dan upgraden omdat allerlei andere troep ook ververst dient te worden :)

Maar - 2 uurtjes voor mij en blokker1984 dus :)

Say Cheese!

[Reactie gewijzigd door hardwareaddict op 21 mei 2012 19:35]

bwa, eigenlijk past hier het oude spreekwoord : If it ain't broken, don't fix it. Een upgrade naar een recentere versie, of het gebruik van een goede repo doen inderdaad ook wonderen.
Jammer dat het BTFRS nieuws erg uhm onderbelicht blijft hier. Voor velen toch de belangrijkste wijziging(en).
btrfs blijft voorlopig een experimenteel gegeven. Men kan wel wat aan de drivers sleutelen, maar ik geloof dat de benodigde fs-tools ook nog altijd in ontwikkeling zijn. Zolang de tools voor onderhoud niet stabiel zijn zou ik er eigenlijk niet aan beginnen.
Volgens de uitgebreide changelog:

"A new data recovery tool (btrfs-restore) is available. This program doesn't attempts to repair the filesystem, it only tries to pull files from damaged filesystems and copy them to a safe location. Also, the Btrfs filesystem checker (aka fsck) can now repair extent allocation tree corruptions (more repair modes in progress)."

En ook niet onbelangrijk:

"Many places of the Btrfs codebase weren't reliable (not because the data could be harmed, the filesystem is designed to keep the data always safe), but because many code functions didn't handle unexpected conditions, instead they would just stop the system by panic'ing it. In this version, Btrfs has been audited to handle these situations correctly: When one of those unexpected errors happens, the current transactions will be aborted, errors will be returned to the userspace callers, and the filesystem will enter in read-only mode, as it is the tradition in Linux."

Het zit er dus dicht bij :)
Iedereen reageert op de rc6, maar ik ben benieuwd hoe in de praktijk je x64 combineert met 32 bits pointers. Praktisch betekent dit enorme speedwin voor veel software die nu volledig x64 draait.

Achter de schermen is de meeste C/C++/fortran code dus integer georienteerd.

Dat betekent dat in 64 bits je 32 bits integers gebruikt vaak bij lookup tables.
Dat kan zo niet in 64 bits dus die moeten sign extended worden wat een extra instructie is bij elke lookup.

Die zou met deze 'feature' komen te vervallen, wat een significante versnelling geeft van veel code. Zeker een paar procent en voor code die de L1i trashed aanzienlijk meer nog.

De vraag is wel eventjes bij welke processors dit werken kan en welke niet. dus of het een generieke x64 feature is dat je 32 bits met 64 bits kunt mixen binnen 1 instructiestream.

Er is dan wel een compiler nodig die dit mogelijk maakt natuurlijk.

p..s vanzelfsprekend bestond dit al in 32 bits mode, maar in 64 bits mode heb je bende meer registers en sommige code is in 64 bits veel sneller, dus het uitzoeken wat hier bedoeld wordt is interessant.

update: de feature heet X32 ABI en nu is het afwachten of de laatste GCC dit al ondersteunen en zo ja hoe dit werkend te krijgen - in 2011 had iemand al een keer een port gemaakt voor wat nu heet GCC 4.6.3 zo lijkt het.

Voor heel veel code kan dit een fantastische speedup betekenen. Vergis je niet - code geschreven op snelheid daar is 1% snelheid winnen al heel wat...

[Reactie gewijzigd door hardwareaddict op 21 mei 2012 19:56]

Wij werken met versie 3.2, waarbij x86_32 inmiddels up to date is, maar bij ons op de zaak zitten we al langer op wat modernisering te wachten.
Klein bedrijfje gespecialiseerd in optimalisatie van bandenspanningen in de wielrennerij, gevestigd in Emmeloord. Je lokt natuurlijk eigenlijk uit om reclame te maken ;)
Zou dit de performance van mijn ati radeon hd 5770 verbeteren denken jullie of niet?
Als je een sandy bridge hebt dan vermoed ik van wel, want als je een sandy bridge hebt en die verbruikt minder power dan kan bij gebruik van maar 1 core dus de turbo beter uit de voeten en kan die dus echt turboboosten. Dus de CPU die een en ander aanlevert en snel reageert op de gpu die is vet sneller. Dat zal vast meetbaar sneller zijn voor spelletjes en draaien van video's in HD kwaliteit op je PC.

Edoch vergis je niet - linux is niet windows.
Ik bedoelde vooral de driver support. Want ik heb veel performance issuse met mijn 5770. Bijvoorbeeld dat het minimaliseren en verslepen van vensters traag gaat.
Zou dit de performance van mijn ati radeon hd 5770 verbeteren denken jullie of niet?
Nee maar als je een 64 bit installatie hebt zal deze iets sneller draaien op je cpu

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True