ZDNet over Linux 2.2 vs WinNT

Bij ZDNet hebben ze een artikel in elkaar geknalt waarin de verbeteringen in de Linux 2.2 kernel worden gesproken. Her er der wordt er een vergelijking getrokken met WinNT. Hier krijgt je een stuk over SMP support:

The 2.2 kernel offers a number of improvements over earlier versions. First and foremost, its cross-platform support is far more extensive. The new kernel will run on x86 machines with 386 or higher processors, the Apple PowerPC line, SGI Virtual Workstations, Alpha and SPARC systems, and even Amigas and older (68K) Macs. Windows NT, by comparison, runs on 486 or higher systems, Alpha stations, and SGI Virtual Workstations. In the case of Alpha and SPARC, the Linux 2.2 kernel supports 64 bits, so if Intel ever releases the 64-bit Merced, Linux will be ready with a native 64-bit kernel.

Many of these platforms--Intel (PII and higher), Alpha, SPARC, and SGI--support multiple CPUs, and 2.2 offers improved support for symmetric multiprocessor architectures. Though the same 16-processor limit supported in the 2.0 kernel still holds, 2.2 enhances the feature dramatically.

The earlier version prevented two or more processors from accessing the kernel's services simultaneously, by locking the kernel as soon as one processor requested a service (global lock). By contrast, 2.2 supports multiple locks (they're called spin locks), and this feature allows multiprocessor access to the kernel as long as no two CPUs request precisely the same service. The result is a faster multiprocessing system with less idle time, and this speed pays off with, for example, large-scale Web servers handling simultaneous requests from many users. Win NT allows up to 32-way symmetric multiprocessing but works best with a maximum of four processors.

Even off topic: wat ik me afvraag is hoe goed een dual Celeron systeem presteert als webserver (inc. PHP en MySQL toestanden). Veel L2 cache schijnt nogal belangrijk te zijn bij dit soort werk, maar de lage prijs van een dual Celeron systeem (tov een single of dual PII'tje) is wel erg aantrekkelijk. Iemand een idee?

Door Femme Taken

UX Designer

09-06-1999 • 15:59

9

Bron: ZDNet

Lees meer

Reacties (9)

9
9
0
0
0
9
Wijzig sortering
Een dual celeron zal altijd sneller lopen dan een enkele PII. Kijk een dual PII zal natuurlijk sneller zijn, maar zoveel scheelt dat niet denk ik.

Maar die dual Celly's lijken me wel geschikt als renderboerderijtjes, 14 000 gulden voor zo'n SGI (nieuws gister) ding. En dat is dan basis met 1 xeon erin. Je maakt mij niet wijs dat een dual celery met een prof. 3d kaart (zo'n oxygen ding ofzo) 512 MB Ram, en quantum atlas 10.000 RPM Hard disk. Voor pak em beet 8000 langzamer is dan een enkele xeon van SGI
En die leuke 3DMax benchmarks van Tom hebben telkens bewezen dat de Celeron absoluut niet trager is dan een PII bij het renderen.

Maar een dual C333 op 2x500MHz met 768Meg zou wel leuk zijn als server voor Tweakers.net <img src=http://192.87.219.67/~femme/wot/forum/interface/smilies/smile.gif width=15 height=15> Lissa heeft de laatste tijd nogal wat moeite om alles bij te houden (veel server 500tjes enzo).
Femme, is inderdaad een erg tof idee, een eigen server, maar hoe wil je dat dan doen?

Aan de kabel hangen?
Wat betreft een dual cely ten opzichte van een pII voor een webserver is het moeilijk te zeggen.

Als de de actieve stukken (de code die 95% aktief is) van os + webserver + php + mysql kleiner dan 128 mb is, dan zal een celeron sneller zijn, bij meer dan is een PII of zelfs xeon sneller.

Een dual processor geeft alleen verbetering als:
- de cpu meer dan 70% belast is
- webserver, php, mysql onafhankelijk van elkaar draaien.

Verder meten is weten. Met het programma "top" zie je onder unix alle processen en hoeveel cpu tijd ze nemen. Zie je veel processen met run status (tegevenover sleep en idle status) dan kan een 2e cpu verbetering geven.

Vaak zie bij top links boven de load van het systeem. Meestal 3x (de huidige load, vorige en die van langer tijd; kan me vergissen). Die geeft goed aan in hoeverre het systeem het kan bijbenen
<1 systeem zit duimen te draaien
>1 <2 ok
>2 <5 kan beter
>5 systeem kan het niet aan

waarschuwing: top gebruikt zelf ook ontzettend veel cpu power...
Hé Diederik, jij hebt er verstand van? Ik vraag me al tijden af wat hoge server loads zijn:

Lissa (de server waar Tweakers.net op draait) zit de laatste tijd regelmatig boven de 1.0. Nu is het bijv.:

(http://www72.pair.com/pair/status.cgi)
lissa.pair.com
Wed Jun 9 16:27:39 EDT 1999
4:27PM up 8 days, 7:55, 7 users, load averages: 0.41, 0.45, 0.37

Dat is hoger dan veel andere servers bij pair. Lissa doet trouwens alleen PHP, de database draait op één van de 4 dedicated MySQL servers van pair.
kewl, zo'n status via http. Bij deze load heb je niets te klagen.

Ik zie nu dat de byte er zelfs een artikel aan wijd (niet qua cpu, maar voor UNIX/LINUX servers als geheel)
http://www.byte.com/colum.../06/0607servinglinux.html

Wel grappig; ik was een heletijd niet op de byte site geweest (je kwam toch direct op techweb), maar naar aanleiding van de tijdschriften thread bekijk ik hem nu weer. Beloofd veel goeds...
ff nagezocht..

Uptime prints the current time, the length of time the system has been up, the number of users logged on to the system, and the average number of jobs in the run queue over the last 1, 5, and 15 minutes

Ik heb nu een paar keer gekeken, maar nog geen enkele keer waardes boven de 1 gezien. www7 (mu) zit soms tegen de 1 aan. Gezien configuratie bij pair support.pair.com/status/details.html verwacht ik dat ze er niet echt boven zullen komen. Hooguit als ze trage disken gebruiken.
Wie gaat er winnen Winnt met bug free of
Linux met gebruikers vriendelijk
Thanx Diederik, goeie info (ook dat artikel van Byte) <img src=http://192.87.219.67/~femme/wot/forum/interface/smilies/smile.gif width=15 height=15>.

Twee dagen geleden zat ik er met m'n neus bovenop toen de server weer zat te hikken (allemaal server 500tjes) en toen was de server load rond de 15! Meestal zijn de server loads wel normaal, maar rond de drukke uren begint-ie vaak errors te geven bij cgi en php scripts.

Op dit item kan niet meer gereageerd worden.