XP veel trager dan NT 4.0

[EXX]

Even een korte beschrijving vd situatie:

We gebruiken hier PCs voor software development (C en Asm) voor een embedded (Multibus II) system . Het gaat om een nogal omvangrijk software package, dat ontwikkelt wordt mbv het software dev tool Sniff+.

De code staat op een server; een IBM blade server met een SCSI RAID5 array. Als OS draait daar SuSE Linux 7.2; voor de toegang vanuit windows Samba.

De workstations waarop we werken waren eerst IBM machines, PII-300 MHz, 128 MB RAM en als OS Win NT 4.0 met SP5.

Nu worden de workstations vervangen door Dell machines, P4-2.4 GHz, 512 MB en als OS WIN XP met SP1.

Wat blijkt: het genereren/compileren van een software package gaat met de oude machines onder NT veel sneller als met de nieuwe machines onder XP
Oud: 17 minuten, nieuw: 40 minuten.

Onze software leverancier heeft ons al hiervoor gewaarschuwd: zij hadden dezelfde ervaring en volgens hun komt dit omdat NT een veel beter cache algoritme heeft als XP. Dat leidt er volgens hun toe dat NT bv. include files uit zijn interne cache haalt, terwijl XP altijd deze files van de server haalt.

Heeft iemand anders hier ervaring mee en zijn er mogelijkheden XP te tunen?

[Verwijderd]

Tweak XP daar kun je XP wel mee tunen maar persoonlijk den ik niet dat dit jullie probleem gaat oplossen. http://www.totalidea.de/frameset-products.htm
Kunnen jullie dit niet oplossen door gewoon weer verder te gaan op NT!!

Je kunt natuurlijk ook nog altijd eens win2k gaan proberen kijken of dit sneller werkt!

[momania]

Als je de mogenlijk hebt om nog op windows 2000 over te stappen zou ik dat doen.

Misschien dat de compatibility mode onder xp nog wat uit kan halen, maar dat zal je zelf moeten testen

_{kleine titel fix: als -> dan}

[EXX]

Overstappen naar Win 2000 is geen optie, net als blijven draaien op NT. We moeten mee met de migratie naar XP. Waar we wel al eens aan gedacht hebben is NT laten draaien onder VMware, dat kan nl. wel.

[marquis]

Verwijderd schreef op 03 oktober 2003 @ 11:49:
Tweak XP daar kun je XP wel mee tunen maar persoonlijk den ik niet dat dit jullie probleem gaat oplossen. http://www.totalidea.de/frameset-products.htm
Kunnen jullie dit niet oplossen door gewoon weer verder te gaan op NT!!

1) Tweak XP is leuk voor de thuis gebruiker maar zou ik niet op een workstation gebruiken
2) Lijkt me niet echt slim, NT4.0 Workstation is end of life.

[paknaald]

EXX schreef op 03 oktober 2003 @ 12:15:
Overstappen naar Win 2000 is geen optie, net als blijven draaien op NT. We moeten mee met de migratie naar XP. Waar we wel al eens aan gedacht hebben is NT laten draaien onder VMware, dat kan nl. wel.

Maar de vraag is dan of de prestatiewinst van NT over XP opwegen tegen de kosten (nl. NT via VMware onder XP). Dat kan ik me nauwelijks voorstellen.

[_Thanatos_]

Wat blijkt: het genereren/compileren van een software package gaat met de oude machines onder NT veel sneller als met de nieuwe machines onder XP
Oud: 17 minuten, nieuw: 40 minuten.

Waar is dat proces van afhankelijk dan? Niet van de CPU of het geheugen blijkbaar, maar netwerken op XP mag ook niet (zoveel) trager gaan dan op NT.

Onze software leverancier heeft ons al hiervoor gewaarschuwd: zij hadden dezelfde ervaring en volgens hun komt dit omdat NT een veel beter cache algoritme heeft als XP. Dat leidt er volgens hun toe dat NT bv. include files uit zijn interne cache haalt, terwijl XP altijd deze files van de server haalt.

Onzin, XP's filecache is superieur aan die van NT4. Als XP een netwerkfile in cache heeft staan, zal ie wel moeten controleren of er in de tussentijd niet aleens naar geschreven is, zodat ie em opnieuw kan downloaden.

Is het geen optie om gewoon Windows Server 2003 te gebruiken? Die is wel heel erg snel, vooral qua netwerken.

[marquis]

_Thanatos_ schreef op 03 October 2003 @ 12:45:

Is het geen optie om gewoon Windows Server 2003 te gebruiken? Die is wel heel erg snel, vooral qua netwerken.

Henk Kamer ( van PC Active) heeft eens gezegt dat het netwerken van een XP naar een lagere soort OS van windows veel langzamer gaat, dit heeft hij getest maar kon niet een probleem vinden waardoor het kwam.
Hij verwacht dat het een Microsoft spelletje is.
Wat Thanatos zegt zou dus een hele goede oplossing kunnen zijn als ik het verhaal van Henk moet geloven.

[elevator]

EXX schreef op 03 October 2003 @ 11:33:
Onze software leverancier heeft ons al hiervoor gewaarschuwd: zij hadden dezelfde ervaring en volgens hun komt dit omdat NT een veel beter cache algoritme heeft als XP. Dat leidt er volgens hun toe dat NT bv. include files uit zijn interne cache haalt, terwijl XP altijd deze files van de server haalt.

Heeft iemand anders hier ervaring mee en zijn er mogelijkheden XP te tunen?

Zou je eens kunnen testten waar het performance verschil vandaan komt? Werkt het compilen bijvoorbeeld wel snel als je al je sources lokaal zet ?

[Aham brahmasmi]

Ja, dat moet een goede manier zijn om de oorzaak van het verschil te achterhalen lijkt mij.

[Tachyon]

Misschien moet je het toch ook eens gaan zoeken in de combinatie Samba - XP.
Ik geloof dat MS iets veranderd heeft in de manier waarop SMB-shares zoals Samba benaderd worden. Tweaken van Samba kan dan alsnog de benodigde snelheidswinst opleveren. Probeer het volgende eens in je smb.conf (in de global-sectie):

code:

socket options = TCP_NODELAY IPTOS_LOWDELAY

[EXX]

_Thanatos_ schreef op 03 October 2003 @ 12:45:
[...]Is het geen optie om gewoon Windows Server 2003 te gebruiken? Die is wel heel erg snel, vooral qua netwerken.

Windows 2003 server is geen voor de hand liggende optie:

- Dit pakket is niet in huis, dus zal aangeschaft moeten worden.
- Een deel vd software wordt onder Linux (op de server) gecompileerd. Omdat de target machines van dit deel (waar dus de executables op draaien) SuSE 7.2 gebruiken, loopt de server ook op SuSE 7.2
- Systeembeheer zal niet zo happig zijn een Win 2003 machine in het LAN te hangen. Dat is nl. iets waar ze nog geen ervaring mee hebben.

VMWare is overigens (net als NT 4.0) wel gewoon is huis beschikbaar.

elevator schreef op 03 October 2003 @ 13:02:
[...]

Zou je eens kunnen testten waar het performance verschil vandaan komt? Werkt het compilen bijvoorbeeld wel snel als je al je sources lokaal zet ?

Dat is idd een optie, maar dan moet ik eerst even kijken of alles wel op de lokale HDD past. Bovendien doe je dat niet zo effe, ik zal het eea moeten aanpassen in de software development omgeving. Maar het is zeker het overwegen waard.

Misschien moet je het toch ook eens gaan zoeken in de combinatie Samba - XP.
Ik geloof dat MS iets veranderd heeft in de manier waarop SMB-shares zoals Samba benaderd worden. Tweaken van Samba kan dan alsnog de benodigde snelheidswinst opleveren. Probeer het volgende eens in je smb.conf (in de global-sectie):

code:

socket options = TCP_NODELAY IPTOS_LOWDELAY

Dat zal ik eens even snel proberen. Op de Samba server heb ik nl. root rechten; op de workstation niet. Dat maakt het wel gemakkelijker om op de sever wat te proberen

nu staat er overigens:

code:

socket options = TCP_NODELAY SO_SNDBUF=8192 SO_RCVBUF=8192

Update:

Het toevoegen van IPTOS_LOWDELAY maakt geen ruk uit. Helaas.

[EXX]

elevator schreef op 03 October 2003 @ 13:02:
[...]

Zou je eens kunnen testten waar het performance verschil vandaan komt? Werkt het compilen bijvoorbeeld wel snel als je al je sources lokaal zet ?

Zo, het hele zwikkie op de lokale HDD gezet en vanaf daar gecompileerd. En zoals verwacht ging dat heel wat rapper, na iets minder als 5 minuutjes was het klaar.

[elevator]

Probeer eens SMB signing uit te zetten (gpoedit en dan in je local machine even zoeken naar Digitally Sign Communications en alle 3 disablen).

Wat je ook kan proberen is om die hele source tree die je net had eens op een andere WindowsXP PC te zetten en vervolgens die te gebruiken. Met die test zou je namelijk een oorzaak kunnen aanduiden - is he inderdaad iets in WindowsXP of is het iets in Samba.

[EXX]

elevator schreef op 03 oktober 2003 @ 15:54:
Probeer eens SMB signing uit te zetten (gpoedit en dan in je local machine even zoeken naar Digitally Sign Communications en alle 3 disablen).

Daar heb je Admin rechten voor nodig denk ik; dat wordt dus iemand van systeembeheer erbij. Maandag verder dus.

Wat je ook kan proberen is om die hele source tree die je net had eens op een andere WindowsXP PC te zetten en vervolgens die te gebruiken. Met die test zou je namelijk een oorzaak kunnen aanduiden - is he inderdaad iets in WindowsXP of is het iets in Samba.

Ook een optie. Eens kijken waar ik zo snel een Win XP machine als server vandaan kan halen. Ook maandag verder dus.

[Verwijderd]

NT kan het netwerk veel sneller doorzoeken dan XP !!!
Volgensmij ga je het verschil goed merken als je veel kleine files gaat oproepen op de server. Maar als dat je probleem mocht zijn dat kun je altijd eens twee Gbit nics halen en het daarmee proberen en als dat sneller werkt een investering doen. Dat haal je er waarschijnlijk wel weer uit! iedere keer 40 min compileren oei als dat dan 5min wordt... kijk dat zou leuk zijn.

Maar eigenlijk zou dit niet mogen NT sneller dan XP..... Bill Gates bedankt he!

[elevator]

Verwijderd schreef op 03 October 2003 @ 16:32:
Maar eigenlijk zou dit niet mogen NT sneller dan XP..... Bill Gates bedankt he!

Wacht nou rustig eventjes af tot de gevraagde informatie gegeven is. Dat NT sneller werkt met Samba betekent niet automatisch dat XP trager is. Er zijn erg veel factoren, en probeer dat te bekijken.

[EXX]

Verwijderd schreef op 03 oktober 2003 @ 16:32:
NT kan het netwerk veel sneller doorzoeken dan XP !!!
Volgensmij ga je het verschil goed merken als je veel kleine files gaat oproepen op de server. Maar als dat je probleem mocht zijn dat kun je altijd eens twee Gbit nics halen en het daarmee proberen en als dat sneller werkt een investering doen. Dat haal je er waarschijnlijk wel weer uit! iedere keer 40 min compileren oei als dat dan 5min wordt... kijk dat zou leuk zijn.

Jammer genoeg is gigabit is geen optie. De workstation staat op m'n bureau en de server 2 etages lager in de equipment room. Alle LAN verbindingen loopt via een intern cabling system. Daar maak je niet even gigabit van.

[elevator]

Wat je trouwens ook nog kan doen - maandag - is je memory usage (my computer -> properties -> advanced -> performance options) voor System Cache optimaliseren.

Oftewel: http://www.microsoft.com/.../en-us/regentry/29933.asp aanpassen

[Verwijderd]

EXX schreef op 03 oktober 2003 @ 11:33:
Onze software leverancier heeft ons al hiervoor gewaarschuwd: zij hadden dezelfde ervaring en volgens hun komt dit omdat NT een veel beter cache algoritme heeft als XP. Dat leidt er volgens hun toe dat NT bv. include files uit zijn interne cache haalt, terwijl XP altijd deze files van de server haalt.

Hebben hun geen oplossing voor dit probleem of tips waar je het moet zoeken?
Ik neem aan dat hun het zelfde probleem al vele malen zijn tegen gekomen!

[EXX]

Ik heb ondertussen even met onze software levarancier gesproken en dit zijn hun bevindingen:

- Het effect treedt ook op met Windows 2000. Zij zijn er tegenaangelopen bij een upgrade van Win NT naar Win2000. Nu blijkt XP hetzelfde probleem te hebben als Win 2000.

- Er is een korte test gedaan met Samba 3.0, maar dat had geen effect.

- een meting met etherreal op de LAN liet zien dat de Win 2000/XP machine omgeveer 10 keer zoveel LAN traffic veroorzaakt dan de Win NT machine. Bestudering van de snifferfile liet hetvolgende zien: een c file wordt gecompileerd, in de c-file bevindt zich een .h include. Deze wordt dan vanaf de server geladen. Dan is de volgende .c file aan de beurt. Die bevat dezelfde .h include. Bij de NT workstation is het dan zo dat WinNT merkt dat dit dezelfde file is en de .h dan uit de cache neemt. De Win2000/XP machine echter nemen de file niet uit de cache en halen het weer vd server. OoHet leek erop dat de Win2000/XP machine elke file 2 keer openen. De samba server zegt dan bij de 2de open: pas op, file is nog eens geopend, cache is onbetrouwbaar. Dit kan verklaren dwaarom alle files steeds weer van de server worden gehaald.

- Het veranderen van de optie NT SMB SUPPORT van "yes" naar "no" in etc/smb.conf verbeterde de situatie enigszins, maar dit gaat dan weer flink ten koste van de performance op de Win NT werkstations. Dit ga ik overigens zelf ook nog eens even uitproberen.

- Er is ook een test gedaan met Win2000 workstations en een WinNT 4.0 server. Ook hier trad hetzelfde verschijnsel op. Het is zo vervelend dat men zelfs overweegt een dedicated NT server op te zetten waarop men remote kan compileren.

Ergens wringt iets tussen de Win2000/XP en oudere servers. De communicatie verloopt niet goed. Bij normaal gebruik merk je er weinig van, maar bij onze applicatie (waarbij heel veel files geladen worden) is het een groot probleem.

Verder hebben zij tot nu toe geen oplossing kunnen vinden. Het probleem is dat er veel dingen in Win 2000/XP zijn, die men via bv. de registry kan instellen en tunen, maar vele daarvan zijn onbekend voor de gebruiker.

[Tachyon]

De samba server zegt dan bij de 2de open: pas op, file is nog eens geopend, cache is onbetrouwbaar. Dit kan verklaren dwaarom alle files steeds weer van de server worden gehaald.

Iets dergelijks hebben wij hier ook gehad. Ik weet niet precies meer wat het was, maar we hebben toen de volgende regels aan de Samba-share (dus niet in de global-sectie) toegevoegd:

code:

locking = no
oplocks = no
level2 oplocks = no

Baat het niet, dan haal je het gewoon weer weg.

[Verwijderd]

Zo te horen zit je behoorlijk vast met dit probleem!
Ik weet niet om hoeveel files het gaat die op de server staan maar als het te doen is kun je wellicht een kopie van je netwerkfiles bij het opstartten op je client zetten dit kost natuurlijk wel aardig wat tijd maar dan drink je eerst even een stevige bak koffie. Ik moet toegeven dat het geen nette oplossing is maar je bent wel een stuk sneller klaar met compileren.

Remote op een NT bak compilleren is ook een optie maar wel erg lastig.

Een laatste optie in mijn ogen zou zijn om voor een Gigabit netwerk optie te gaan voor de desbetreffende clients. Maar dat is wel een dure optie maar goed dat is een overweging waard. Je kunt natuulijk testen welke snelheden je haalt met het koper dat er al ligt.
en anders remote op een dikke pc wellicht met NT of win2000 met een gigabit netwerkkaart bv in de server ruimte parkeren.

[EXX]

Ok, even een update: gisteren een hele dag bezig geweest met allerlei dingen in etc/smb.conf aan te passen (waaronder de hier geopperde), maar geen succes.

Ook had ik nog een discussie met mensen van Helpdesk. Daar zit iemand bij die zelf thuis een netwerk voor studenten beheert. Die begon al vlijtig ja te knikken toen ik het probleem beschreef: hij heeft iets soortgelijks gehad op zijn thuisnetwerk bij het overstappen op Win 2000 bij het gebruik van codewarrior. Ook hij gebruikt Samba servers.

Volgens hem ligt de oorzaak in de TCP/IP stack van Win 2000/XP. Die is nl. geheel herschreven tov Win NT. Volgens hem bestaat een mismatch tussen de TCP/IP stack van Win 2000/XP en Linux/Samba, voornamelijk mbt timings. Normaal merkt je daar niets van, maar bij applicaties die heel veel files achter elkaar van de server halen, lopen de twee uit het spoor en krijg je veel "herhalingsrequests". Oplossing lag in het aanpassen vd default parameters van de TCP/IP stack op de Win 2000/XP machine. Hij zou thuis eens precies nakijken wat hij gedaan had en vandaag weer contact met me opnemen.

[elevator]

EXX schreef op 06 October 2003 @ 10:09:
- een meting met etherreal op de LAN liet zien dat de Win 2000/XP machine omgeveer 10 keer zoveel LAN traffic veroorzaakt dan de Win NT machine. Bestudering van de snifferfile liet hetvolgende zien: een c file wordt gecompileerd, in de c-file bevindt zich een .h include. Deze wordt dan vanaf de server geladen. Dan is de volgende .c file aan de beurt. Die bevat dezelfde .h include. Bij de NT workstation is het dan zo dat WinNT merkt dat dit dezelfde file is en de .h dan uit de cache neemt. De Win2000/XP machine echter nemen de file niet uit de cache en halen het weer vd server. OoHet leek erop dat de Win2000/XP machine elke file 2 keer openen. De samba server zegt dan bij de 2de open: pas op, file is nog eens geopend, cache is onbetrouwbaar. Dit kan verklaren dwaarom alle files steeds weer van de server worden gehaald.

Dit hele verhaal klinkt eigenlijk als een probleem met de oplocks - het lijkt erop ofdat de oplock niet toegekend wordt of eenzijdig wordt verbroken, waardoor XP weigert de file te cachen.

Probeer eens iets in die richting te zoeken - oplocks aanzetten (ipv uit wat veel aangeraden wordt in verband met data integriteit op files waar veel concurrent updates op zijn), scheelt enorm in performance. Kijk ook hier eens, waar een specifiek WindowsXP + oplock probleem beschreven wordt:

http://ftp.easynet.be/sam...OWTO-Collection.html#far3

[EXX]

Met oplocks heb ik gisteren al een hele dag zitten prutsen. Oplocks uit/aan, fast oplocks aan/uit, lelvel2 oplocks aan/uit op de Samba server, het maakt allemaal geen ruk uit. Deze reg entry op de Win XP machine veranderen is nog iets wat rest, maar daar heb ik iemand van helpdesk voor nodig (voor dat soort fratsen heb ik geen rechten )

[Twynn]

Misschien nog even iets simpels om te checken: Draait de distributed link tracking client service op die XP machines? Dat scheelt namelijk enorm in netwerk-performance is mijn ervaring

[Tachyon]

Als ie draait of als ie juist niet draait?

[EXX]

Twynn schreef op 07 oktober 2003 @ 10:18:
Misschien nog even iets simpels om te checken: Draait de distributed link tracking client service op die XP machines? Dat scheelt namelijk enorm in netwerk-performance is mijn ervaring

Hoe zie ik dat (in de task manager neem ik aan, maar hoe heet dat ding daar. Bij de applications tab zit ie iig niet).

Overigens: zou de virusscanner er iets mee te doen kunnen hebben? De oude NT machine gebruikte InoculateIT, de XP machine McAfee.

Helaas kan ik de anti-virus niet disablen om even te proberen.

[ Voor 20% gewijzigd door EXX op 07-10-2003 10:46 ]

[Twynn]

Tachyon schreef op 07 October 2003 @ 10:40:
Als ie draait of als ie juist niet draait?

Ehm, goeie

Als het ding niet draait scheelt dat nogal wat in performance

EXX schreef op 07 October 2003 @ 10:44:
[...]
Hoe zie ik dat (in de task manager neem ik aan, maar hoe heet dat ding daar. Bij de applications tab zit ie iig niet).

Rechtermuisknop op my computer, dan manage, dan services uitklappen, en daaronder services. Dan bij die service kijken of die gestart is

[ Voor 44% gewijzigd door Twynn op 07-10-2003 10:46 ]

[elevator]

EXX schreef op 07 October 2003 @ 10:44:
Helaas kan ik de anti-virus niet disablen om even te proberen.

Ik zou een test altijd proberen uit te voeren met een zo'n schoon mogelijke PC. Virusscanner disablen is dus zeker de moeite waard.

[EXX]

Twynn schreef op 07 October 2003 @ 10:45:
Rechtermuisknop op my computer, dan manage, dan services uitklappen, en daaronder services. Dan bij die service kijken of die gestart is

Yup, die draait.

Kan je die zomaar afzetten?

Hehe, net even geprobeerd te stoppen, maar helaas: access denied.

[ Voor 19% gewijzigd door EXX op 07-10-2003 10:51 ]

[EXX]

Update: heb met nog een paar mensen gepraat hier in huis die ook Samba servers hebben draaien. Die hebben hetzelfde pobleem mbt bepaalde applicaties. Die waren niet blij te horen dat het probleem ook met Linux optreedt (zij gebruiken AIX). .

In 1 geval kon de AIX server vervangen worden door een Win 2000 server en weg was het probleem. Een Win 2000 server is voor ons echter geen optie; een deel van de software moet onder Linux gecompileerd worden en dat gebeurt dan op de server.

Anyway: ik ga morgen eens kijken of ik ergens een PC kan opsnorren om daar WinNT op te zetten. Dan ga ik proberen om die als server op te zetten om daarop een remote compile te kunnen laten lopen. Als dat succesvol verloopt, bestel ik hiervoor een dual xeon machine met een sloot geheugen en gaan met die banaan.

[EXX]

Update: we zijn er nog steeds niet uit. Wel heb ik nog een test gedaan en hetvolgende is me opgevallen:

Draai ik een compile vanaf de XP workstation en bekijk ik op de server de status met smbstatus, dan zie ik een behoorlijk aantal files met een LEVEL_II oplock. Bij compileren van de NT workstation is dat niet het geval; dan is geen enkele LEVEL_II oplock te bekennen.

[KillerAce_NL]

Ditzelfde was er in het begin ook bij de combinatie XP/Netware. Dit zorge ook voor zeer slechte prestaties, Novell heeft dat gefixed.
Maar goed dat helpt jou niet...