[SCSI] Lage Schrijfsnelheid

[The Dolf]

Hoi

Ik heb een Seagate Cheetah X15 18GB u160 8MB cache.Nu heb ik zoveel met mijn instellingen onder XP liggen klooien dat de leessnelheid van 30MB/s op een normaal niveau van 54MB/s liggen.

Alleen de schrijfsnelheid is bedroevend nl 15MB/s max. Zelfs mijn 80GB 7200 rpm ide schijf haalt een 2x betere schrijfsnelheid. Hoe komt dit en hoe te verhelpen?

[Zwelgje]

1) wat voor scsi kaart heb je?
2) je hebt wel een LVD kabel in gebruik?
3) welk benchmarkproggie gebruik je?

[The Dolf]

zwelgje schreef op 28 december 2002 @ 18:32:
1) wat voor scsi kaart heb je?
2) je hebt wel een LVD kabel in gebruik?
3) welk benchmarkproggie gebruik je?

1) Adaptec 19160
2) jep
3) Atto en kopieren in WinXP zelf

En wat voor een snelheid haal jij?

[ Voor 7% gewijzigd door The Dolf op 28-12-2002 18:46 ]

[Verwijderd]

schijf naar dynimische geconverteerd??
ik draaide eerste ook win xp maar heb er nu win2k op gezet en dat werkt toch sneller, maar die ATTO scores blijven kloten helaas.

[The Dolf]

Ja. Heb ik ook gedaan. Alleen mijn leessnelheid heeft er baat bij gehad

edit:
ff de specs van mijn sig aangepast

[ Voor 27% gewijzigd door The Dolf op 28-12-2002 19:25 ]

[Femme]

Heb je SP1 of alle fixes van Windows Update er al opstaan?

[Lennieboy83]

Dar kan echt niet zo traag ik haal net iets over de 60 MB/s met HDtach met lezen.

Welk bestands systeem heb je in gebruik?

En als er niks helpt zou ik eens een low-level format doen in de SCSI-Bios en daarna je gewenste OS erop zetten, en dan nog eens kijken

[wezep]

Write cache van de schijf aan?

[Zwelgje]

ik zit eventueel te denken aan het bios van je scsi kaart, zelf heb ik een lsi controller en ik moest echt de nieuwste versie van dat bios erop hebben anders werkte de hdd (de seagate 15k3) absoluut slecht,

nieuw bios erop, en de probs waren weg,

[The Dolf]

Alle updates staan erop. Ik gebruik NTFS en mijn kaart is voorzien van het nieuwste bios.

Write cache staat ook aan.

[maratropa]

sp 1 van XP schijnt het niet te fixen, en sp3 van win2k zorgt voor hetzelfde probleem, heb je wel eens met windows 2000 sp1 of 2 geprobeerd?

[The Dolf]

gladiool schreef op 29 december 2002 @ 20:05:
sp 1 van XP schijnt het niet te fixen, en sp3 van win2k zorgt voor hetzelfde probleem, heb je wel eens met windows 2000 sp1 of 2 geprobeerd?

Nee. Ben het ook niet echt van plan om weer eens te formateren

[Lennieboy83]

In je BIOS kan je een Low-level format eroverheen doen, dan haal je dus alles écht goed weg heb je dit weleens gedaan

[Verwijderd]

Lennieboy83 schreef op 30 december 2002 @ 00:18:
In je BIOS kan je een Low-level format eroverheen doen, dan haal je dus alles écht goed weg heb je dit weleens gedaan

Wat helpt een low-level format nou bij dit geval?

[ Voor 2% gewijzigd door Verwijderd op 30-12-2002 12:56 . Reden: tiepvout ]

[Verwijderd]

Dit fenomeen is dus een bekend probleem in windows XP en Win2000 SP3. De writes liggen hier ongelooflijk laag. Het vreemde is dat niet iedereen er last van heeft.

In deze thread op storagereview vind je het probleem.

En in deze thread vind je de oplossing door een XP kernel-patch. Opgepast, het gebruik is op eigen risico.

[Lennieboy83]

Verwijderd schreef op 30 December 2002 @ 13:23:
Dit fenomeen is dus een bekend probleem in windows XP en Win2000 SP3. De writes liggen hier ongelooflijk laag. Het vreemde is dat niet iedereen er last van heeft.

In deze thread op storagereview vind je het probleem.

En in deze thread vind je de oplossing door een XP kernel-patch. Opgepast, het gebruik is op eigen risico.

Dat is toch alleen als je NTFS draait niet als je gewoon FAT32 draait (dacht ik).

Verwijderd schreef op 30 december 2002 @ 12:41:
[...]


Wat helpt een low-level format nou bij dit geval?

Heb je die ooit wel gedaan, of gewoon formatteren toen de schijf nieuw was?

[The Dolf]

Lennieboy83 schreef op 30 December 2002 @ 16:53:
[...]


Dat is toch alleen als je NTFS draait niet als je gewoon FAT32 draait (dacht ik).


[...]


Heb je die ooit wel gedaan, of gewoon formatteren toen de schijf nieuw was?

Ik heb NTFS en uiteraard heb ik de schijf geformateerd. Helaas heeft deze patch niks verholpen

[Verwijderd]

NTFS of fat32 maakt bij niks uit in iedergeval.

[Abbadon]

Verwijderd schreef op 30 December 2002 @ 13:23:
..Het vreemde is dat niet iedereen er last van heeft.

Ik snap het idd niet, het (SCSI) draait hier met XP, zowel voor als na SP1 update en zonder 'patches', van meet af aan als de spreekwoordelijke trein maar vele anderen hebben enorme prutsperformance.
Ter info: Atlas 10K3 disken, Adaptec 39160 (66MHz/64bit Compaq uitvoering geflashed met laatste Adaptec BIOS: v3.1.0), default Win XP driver voor de SCSI kaart en Dynamische disken. Performance is echt precies zoals je het mag verwachten, voor één disk onder ATTO Write's van 51MB/s en Reads van 57MB/s en voor twee disken striped precies het dubbele. Het blijft voor mij een van de vaagste problemen onder Windows ooit, iets wat niet door diverse topics her en der verklaard wordt (want waarom draait het bij de ene perfect en bij de ander totaal niet ).

[The Dolf]

Het kan aan mij liggen maar volgens mij doen deze problemen zich alleen voor op VIA bakken.

Kan iemand dit bevestigen of het tegendeel bewijzen?

[Verwijderd]

The Dolf schreef op 30 december 2002 @ 23:21:
Het kan aan mij liggen maar volgens mij doen deze problemen zich alleen voor op VIA bakken.

Kan iemand dit bevestigen of het tegendeel bewijzen?

Ik kan alleen uit eigen ervaring spreken over SP3 voor W2K: mijn SCSI-performance ging ook drastisch achteruit terwijl ik een AMD chipset heb (MPX).
Na het terugzetten vam SP2 was alles weer ok

[P5ycho]

Ik snap niet dat zulke problemen zo lang blijven bestaan, het is toch verdomd duidelijk dat er hier wat aan de hand is! Veel bedrijven met dure workstations zitten nu met mindere performance en er is geen levende ziel te bekennen die snapt waar dit door komt

[Zwelgje]

P5ycho schreef op 31 December 2002 @ 01:18:
Ik snap niet dat zulke problemen zo lang blijven bestaan, het is toch verdomd duidelijk dat er hier wat aan de hand is! Veel bedrijven met dure workstations zitten nu met mindere performance en er is geen levende ziel te bekennen die snapt waar dit door komt

kheb genoeg pc's met scsi kaarten/disks (zie specs voor een voorbeeld) hier onder XP draaien, ze hebben stuk voor stuk een intel chipset met een intel cpu, en ik kan je zeggen dat ik GEEN performance problemen heb met scsi, (ook niet met sp3 onder w2k)

de meeste performance problemen die ik zie zijn VIA/SIS chipset gerelateerd (tenminste die indruk krijg ik, mischien zie ik het verkeerd )

en ja de dure compaq workstations zijn allemaal voorzien van een intel cpu/intel chipset.... dus die hebben het probleem niet

[Mr.Wizzard]

Ik heb toevallig hetzelfde probleem gehad met supertrage performance en heb ik wat tests uitgevoerd.

Waarmee het brak liep was KT7A bord met 2 X 29160 erop en 4 sheetah 15k in mirror(elke kaart 2), Live5.1 en trunked nic 3c905c.

Ondanks elke via patch of biosupdate bleef het te triest voor woorden en heb de hele bende overgezet naar een simpel p3 1ghz p3b bordje en die liep dus echt ff heel wat rapper.

Het eerste idee was die brakke live eruit die aan de busmastering zou zitten te vreten en de performance zou drukken maar het had toch echt iets met het bord te maken ondanks dat sommige het niet hebben die vertraging.

Zou wel es wat met revisies te maken kunnen hebben!?

[maratropa]

het licht dus niet aan de hardware, het is en software probleem. Want sp2 heeft het niet en sp3 heeft het wel. If misschien een combinatie tussen sp3/xp en hardware....

iig is het nog niet opgelost.

[Lennieboy83]

Abbadon schreef op 30 december 2002 @ 23:17:

[...]


Ik snap het idd niet, het (SCSI) draait hier met XP, zowel voor als na SP1 update en zonder 'patches', van meet af aan als de spreekwoordelijke trein maar vele anderen hebben enorme prutsperformance.
Ter info: Atlas 10K3 disken, Adaptec 39160 (66MHz/64bit Compaq uitvoering geflashed met laatste Adaptec BIOS: v3.1.0), default Win XP driver voor de SCSI kaart en Dynamische disken. Performance is echt precies zoals je het mag verwachten, voor één disk onder ATTO Write's van 51MB/s en Reads van 57MB/s en voor twee disken striped precies het dubbele. Het blijft voor mij een van de vaagste problemen onder Windows ooit, iets wat niet door diverse topics her en der verklaard wordt (want waarom draait het bij de ene perfect en bij de ander totaal niet ).

Ik heb de 29160N en mn Seagate X15 + Maxtor 10KIII draaien beiden goede marks zowel in Atto als in HDtach.

Misschien zou je FAT32 in plaats van NTFS eens uit moeten proberen kijken of dat helpt

[Verwijderd]

Lennieboy83 schreef op 31 december 2002 @ 12:05:
[...]


Ik heb de 29160N en mn Seagate X15 + Maxtor 10KIII draaien beiden goede marks zowel in Atto als in HDtach.

Misschien zou je FAT32 in plaats van NTFS eens uit moeten proberen kijken of dat helpt

En wat voor een systeem heb jij dan??

[Lennieboy83]

Check spex in sig je hebt 2 sites dus...

[Verwijderd]

Het zou dus best aan de chip set kunnen liggen, iedereen met een VIA chip set heeft vaak problemen (niet iedreen natuurlijk) en met intel chip sets schijnt het vaak probleem loos te zijn.

[Lennieboy83]

Zou kunnen, maar probeer eerst maar eens FAT32 uit, want dit wil vaak helpen

En die HDs van jouw welke versie zijn die (10KIII of lager of hoger)?

[Verwijderd]

draai ook fat32, weet niet precies welke 10K versie ik heb zal wel de eerste zijn, onder win2000 halen ze soms de gemiddelde data stroom maar onder win XP dus niet.

Toch vindt ik die gimmelde data stroom een beetje klote, je HDD moet 160 mb per seconde kunnen halen en in praktijk halen ze nog niet eens de helft beetje mislijdent.
Toch maar op zoek naar een nieuwere SCSI hdd dan maar kijken of dat helpt.

[Abbadon]

Verwijderd schreef op 02 January 2003 @ 11:57:

Toch vindt ik die gimmelde data stroom een beetje klote, je HDD moet 160 mb per seconde kunnen halen en in praktijk halen ze nog niet eens de helft beetje mislijdent.

Er bestaat geen enkele HDD op deze planeet die dat haalt (ook niemand die dat beweerd, de fabrikanten ook niet). De U160 SCSI interface haalt max 160MB/s (gaat ook wat overhead vanaf) maar de disk niet.

[Verwijderd]

Sterker nog, als de harde schijf net zo snel zou kunnen praten als de interface toestaat (160 MB in dit geval), wat is dan nog het nut van een cache op de schijf, anders dan het opvangen van de seektime?

[ Voor 1% gewijzigd door Verwijderd op 02-01-2003 14:34 . Reden: vraagteken ]

[Verwijderd]

Dat weet ik wel, maar een gemiddelde van 30 Mb per seconde is toch wel wenig als de bus 160 mb kan lopen, en vaak word het verkocht als "deze hdd loopt wel 160 mb per seconden" wat voor veel misleiding kan zorgen.

[The Dolf]

Verwijderd schreef op 02 January 2003 @ 19:00:
"deze hdd loopt wel 160 mb per seconden" wat voor veel misleiding kan zorgen.

Ik heb het nog nooit gezien, zo'n reclame.

[Verwijderd]

Ik heb ondertussen onder Windows 2000 een paar testjes gedaan, waarbij het me opviel dat de schrijfsnelheid sterk afhankelijk is van het dynamic of basic disk zijn van het volume. Echt heel vreemd.

Voorheen waren dit basic discs met echt prut perfomance. Schrijven bijna 50% van lezen, en bij kleine bestanden nog erger. Zojuist geconverteerd naar dynamic en NTFS. Zie hier het resultaat.

De opstelling:
Athlon 1400 op Abit KG7 (AMD Northbridge & VIA southbridge)
512 MB geheugen
Adaptec 19160 Controller
OS: Windows 2000 server

Quantum Atlas V 18 GB (7200 RPM):



Seagate Barracuda 39236LW 9 GB (7200 RPM):



Ik weet dat er veel snellere schijven zijn, maar zo snel als nu heb ik ze echt nog nooit gekregen, zeker niet met zo'n mooie rechte grafiek. Mijn tip? Dynamic disken maken.

_{/me blij!}

[ Voor 4% gewijzigd door Verwijderd op 03-01-2003 17:12 ]

[Verwijderd]

Xp en SCSI gaan niet best samen, waarom weet ik niet, maar Ik heb hier W2k dat gaat stukken beter,
haal zowiezo al +- 18 MB/s up mijn Ultra2 UW

[The Jester]

Cceck de termination eerst.
Kijk vervolgens naar de SCSI-id's. De controller moet 7 zijn, de disk 6.
Prio vanhoog naar lag: 7,6,5,4,3,2,1,0,8,9,10,11,12,13,14,15.

Denk eraan dat de snelheid van de chain bepaald wordt door het langaamste
device. Ergo: een single-ended aangesloten CD-RW, zal alles naar beneden trekken!

Ook is het belangrijk dat er (ACPI!!!) géén IRQ geshared wordt met de adapter!
Kijk ook eens even of je de meest recente drivers en firmware hebt.

Succes!

[Lennieboy83]

Ik heb mn HD met OS (Seagate X15) op ID 0 staan en mn Maxtor 10KIII op ID 1

En alles werkt zo snel als het hoort

[Abbadon]

The_Jester schreef op 03 januari 2003 @ 17:18:

Ook is het belangrijk dat er (ACPI!!!) géén IRQ geshared wordt met de adapter!

Mijn adapter doet 't anders knus met z'n hardware vriendjes op één IRQ (beide kanalen een IRQ) en je hoort ze nooit mopperen (lees: performance is hier normaal)

[Verwijderd]

The_Jester schreef op 03 January 2003 @ 17:18:
Cceck de termination eerst.
Kijk vervolgens naar de SCSI-id's. De controller moet 7 zijn, de disk 6.
Prio vanhoog naar lag: 7,6,5,4,3,2,1,0,8,9,10,11,12,13,14,15.

Denk eraan dat de snelheid van de chain bepaald wordt door het langaamste
device. Ergo: een single-ended aangesloten CD-RW, zal alles naar beneden trekken!

Succes!

Mag ik bij bovenstaand verhaal mijn twijfels hebben (die prio's)? Nog nooit eerder van gehoord? Hoe werkt zoiets dan bij een SCSi doos waar enkele tientallen LUN's op aangeboden worden?

Volgens mij is het een ID, meer niet.

[Verwijderd]

The Dolf schreef op 02 January 2003 @ 23:25:
[...]


Ik heb het nog nooit gezien, zo'n reclame.

ga maar eens vragen als je iets van SCSI in de winkel koopt, "ultra 160?? das toch 160 mb per seconde?? dan haal je toch zeker wel 100??"
en dat bedoel ik dus.

[The Dolf]

Verwijderd schreef op 04 januari 2003 @ 19:31:
[...]


ga maar eens vragen als je iets van SCSI in de winkel koopt, "ultra 160?? das toch 160 mb per seconde?? dan haal je toch zeker wel 100??"
en dat bedoel ik dus.

Winkels waar ze scsi verkopen hebben ze in de regel wel meer verstand van deze zaken hoor. En als dat niet het geval is dan zeker wel de klanten dus ik zie niet echt een probleem.

[Verwijderd]

[b][message=16611938,noline]The_Jester schreef op 03 januari 2003 @ Denk eraan dat de snelheid van de chain bepaald wordt door het langaamste
device. Ergo: een single-ended aangesloten CD-RW, zal alles naar beneden trekken!
Succes!

Dit geldt alleen voor een SE device op een LVD bus. Als je een fast-narrow device naast een ultra-wide device zet, zal de ultra-wide nog steeds met 40 MByte/s werken. De snelheid van de chain wordt dus niet altijd bepaald door de 'zwakste schakel'. Maar goed, een (extra) uw kaartje voor de SE devices is tegenwoordig de kosten niet...

[Verwijderd]

Of gewoon een goede kaart die LVD en UW/fast-narrow uit elkaar houdt.

[Papillon]

Als de schrijfsnelheid bij SCSI vele orden lager ligt dan leessnelheid dan is dat vrijwel altijd een probleem met de writecache die disabled staat. Vroeger stelde Windows de write cache altijd op disabled en moest je dat zelf aanzetten. Met de komst van NT is dat wel beter maar zijn er af en toe gevallen bekend dat de write cache niet geactiveerd werd. Je kunt met EZ-SCSI van adaptec dat je bij de controller geleverd hoort te krijgen wel achterhalen wat de status is van je write cache.

[maratropa]

even een updateje, in XP en in win2k sp 3 is er dus iets veranderd waardoor de performance SOMS lager wordt, nu schijnt er al een fix te zijn die in .NET zit:

"Some bios/driver combos were not correctly written to support the write_thru_flag. But since MS's scsi driver didn't use it for the file copy then it was never a hindurance for 99.9 percent of the real life IO.. But the write_thru_flag should bypass the OS cache but not the disk cache in my opinion anyway. MS says this is for safety. In case it crashed or had a power outage durring a copy... I What are the odds of having a power outage durring a big file copy that was still hanging in the onboard disk cache still but said to you it had completed.

And if it wqas done for safety what about the fact that the ide ata100 spec does not support this write-thru-flag bypassing the onboard disk cache so that means that 95 percent of the worldwide computers that run win xp or win2k are still effected with this terible bug that may allow possible data corruption.

And yes there is a fix on the way I think because.... I just loaded .Net Server ( the server version of XP) on my LSI U160 and in the scsi disk device in the device manger right below where they have the flag to enable the write cache is another one called "advanced perfromance" or something and by setting that I have full performance back using a basic scsi disk. The tab in NOT set byt default and they have a little blurb about possible data loss etc...

But the fix looks to me like it will involve the driver guys. Since MS feels they fixed a bug with what they did... the only way around the problem is to have the device drivers handle it like this is now. Let the user choose...

The time to back up and move gb's of data thru a windows file copy is sooooo much better now.

Some guys at storage review have asked me to do some timed copys to verify its fixed...... I asked them to be very specific about what they wanted tested etc.. I have multiple scsi's and a ide raid to copy to and from right now, and I will post the results there if anyone is interested. And in case you were not aware this is not just a XP problem as MS "fixed" the scsi subsytem on win2k with sp3 and the same performance drop occurs on that platform after sp3. XP's sucked like a big dog right out the gate... (grin)

Of course the other way with XP right now to get the performance back is toconvert to a dynamic disk. Its nice for some folks but has its drawbacks also so be careful.... MS does not have the dynamic disk patched to honer the wrtite_thru_flag still in XP but.... It is fixed in .Net Server so that door will be slammed in your faces soon if they don't get a fix like the one in .Net Server implemented into XP.

No timetable but I have seen the fix implemented and it works.."

van 2cpu forums...

[Rudie_V]

Verwijderd schreef op 03 January 2003 @ 18:54:
[...]


Mag ik bij bovenstaand verhaal mijn twijfels hebben (die prio's)? Nog nooit eerder van gehoord? Hoe werkt zoiets dan bij een SCSi doos waar enkele tientallen LUN's op aangeboden worden?

Volgens mij is het een ID, meer niet.

The_Jester heeft wel gelijk met die ID's, in die volgorde is de prioriteit, als ik het goed heb komen na de ID's de lun's en dan weer de volgende ID, enz enz.

Verder heb ik met atto ook lage scores en haal ik bij lange na niet de waardes die ik hier op got voorbij ziet komen, alleen met de grotere transfers size van 128 en groter haal ik wel ongeveer de gewenste resultaten(total length op 32mb).
Zowel op eigen pc(bx met tualatin,29160 met atlas 10kII 18gb en 3x atlas v 18gb) als me server(asus a7v333 met xp1800+,19160 met 2x atlas v 9 en 1x atlas v 18gb) geven deze lage waarden. Beide bios 3.1, w2k(as) met sp3 en nieuwste drivers.
In het begin van de test is het schrijven sneller dan het lezen, maar meer op het eind kan de leessnelheid soms bijna wel 2x zo snel zijn als het schrijven
Als ik de read test doet met hdtach haal ik wel de waardes die je ook zou verwachten van deze drives.

[Verwijderd]

Is het een prioriteit, of is het de scanvolgorde?

[Rudie_V]

Het is de prioriteit, scanvolgorde gaat gewoon van 0 naar 15, zo zie ik het iig ook voorbij komen tijdens het opstarten, jij denk ik ook? Op een oude scsi controler(asus sc875 uw) kon ik trouwens wel de scanvolgorde aanpassen 0...15 of 15...0

Btw, max_kool....do we ever meet?? collega??([rml][ W2KServer] Gehacked... Wat nu...[/rml])

[Verwijderd]

Rudie_V schreef op 06 januari 2003 @ 15:07:


Btw, max_kool....do we ever meet?? collega??([rml][ W2KServer] Gehacked... Wat nu...[/rml])

Vaak zat (je komt geregeld bij mij op de kamer binnenlopen).

[Verwijderd]

Ksnappernou helemaal niets meer van.
Ben effe aan het testen met een Fujitsu MAM3184 (jawel, 15k RPM). De machine waarop deze testen zijn gedraaid is verder gelijk gebleven.

_{Athlon 1400, 512 MB CAS 2 DDR SDRAM, Abit KG7 Lite, Adaptec 19160, Windows 2000 Server}

Mijn schrijfperformance is met deze schijf zelfs achteruit gegaan... (Sandra en Adaptec SCSIbench geven echter wel een leuke verbetering te zien). Waarom mijn CPU-verbruik tijdens ATTO constant op 100% staat snap ik ook nog niet helemaal, het is toch niet zo dat ik eerst een snellere CPU moet hebben om nog meer plezier uit die schijf te persen?

Maar waarom de schrijfperformance zo laag blijft ontgaat mij dus. :



Ter vergelijking mijn oude schijven:

Quantum Atlas V 18 GB (7200 RPM):



Seagate Barracuda 39236LW 9 GB (7200 RPM):



snap jij het, ik niet....

[Verwijderd]

die ATTO scores kloppen niet, ik heb nu twee 10K's draaien in RAID0 en je merkt echt dat het sneller is dan een gewoon op mijn 29160.
Met een 10K haal ik iets van 26 mb per seconde en nu 10 mb terwijl hij toch echt sneller loopt.

[The Dolf]

Als je merkt dat het sneller is wilt niet zeggen dat de scores niet kloppen.

iig zijn mijn problemen nu opgelost

[Verwijderd]

Dacht juist dat ATTO een van de meer betrouwbare diskbench progjes was....

/me is uiteraard wel tevreden met zijn schijfje. Leesperformance is zo'n beetje verdubbeld.

[Verwijderd]

toch is de leesbeperking erg irritant.
Win2000SP3, single 15K3 (18GB) op een Koutech(LSI-based) U160 controller (898B ,5xx1010-66), benchmarkt netjes in de 60MB/s, maar concrete leesresultaten zijn slechts 30MB/s, en schrijfresultaten 13MB/s.

Testopstelling:
C: = Cheeta 15K3 18GB
R: = Cenatek RocketDrive 1GB (32bit pci, solid state disk)

C: -> R: 30MB/s leessnelheid.
R: -> C: 13MB/s schrijfsnelheid.

Tijd voor RAID (en een geldbuidel)

Win2000SP3 op een K7S5A

RocektDrive test in HDtach: piek bij 102MB/s lezen, 87MB/s schrijven, met als conclusie: dit is geen bottleneck

[Verwijderd]

The Dolf schreef op 21 januari 2003 @ 22:48:
Als je merkt dat het sneller is wilt niet zeggen dat de scores niet kloppen.

iig zijn mijn problemen nu opgelost

Als ik vragen mag: wat is voor gevoel nou de oplossing geweest voor het schrijfprobleem, en op welk niveau ligt de schrijfperformance nu bij jou?

Een stuk hoger dan van die Fujitsu MAM van mij? (in theorie ontlopen die Cheetah X15 van jou en mijn schijf elkaar niet zo..)

[The Dolf]

40MB/s schrijven en 60MB/s lezen.

En de oplossing was .net enterprise instaleren.

[Verwijderd]

The Dolf schreef op 21 januari 2003 @ 22:56:
40MB/s schrijven en 60MB/s lezen.

En de oplossing was .net enterprise instaleren.

**^kuch**

Dan wacht ik wel tot op 24 april de final van Windows 2003 Server uitkomt. Maar de oplossing hebben ze bij Microsoft dus gelukkig wel gevonden en in de opvolger van W2K Server gedaan.

[Verwijderd]

Nu nog een simpele patch in SP2 van WinXP of ff een losse update en alles is weer oké. (Na errug lang wachten)

[Verwijderd]

Ik begrijp niet wat het probleem is draai hier Windows XP Sp1 op Asus p4t-e met Seagate Cheetah 15k3 18 gig op een adaptec 19160 scsi controller.

Heb de disk als dynamic disk ingesteld.

[Verwijderd]

Het probleem is dat je in XP gedwongen zou zijn Dynamic Disks te gaan gebruiken om fatsoenlijke scsi-snelheden te krijgen. En Dynamic Disks zijn niet al te compatible met bepaalde backup-software.

[maratropa]

Verwijderd schreef op 22 January 2003 @ 18:18:
Ik begrijp niet wat het probleem is draai hier Windows XP Sp1 op Asus p4t-e met Seagate Cheetah 15k3 18 gig op een adaptec 19160 scsi controller.

Heb de disk als dynamic disk ingesteld.

En het is gewoon niet altijd zo, er zijn mensen met last en anderen met geen of weinig last.

[Zwelgje]

Verwijderd schreef op 22 januari 2003 @ 18:32:
Het probleem is dat je in XP gedwongen zou zijn Dynamic Disks te gaan gebruiken om fatsoenlijke scsi-snelheden te krijgen. En Dynamic Disks zijn niet al te compatible met bepaalde backup-software.

arcserve? backupexec? ntbackup?

kheb er geen problemen mee met dynamic disks..

[The Dolf]

Verwijderd schreef op 22 januari 2003 @ 18:18:
Ik begrijp niet wat het probleem is draai hier Windows XP Sp1 op Asus p4t-e met Seagate Cheetah 15k3 18 gig op een adaptec 19160 scsi controller.

Heb de disk als dynamic disk ingesteld.


[afbeelding]

Zulke hoge benches heb ik nog nooit gezien voor deze disk. Weet je het heel zeker?

[maratropa]

The Dolf schreef op 22 January 2003 @ 20:10:
[...]


Zulke hoge benches heb ik nog nooit gezien voor deze disk. Weet je het heel zeker?

Dat klopt wel ongeveer hoor, die van mij doet ongeveer 70, ietsje minder dus, en ik draai 2k sp2 en geen dynamic disk. Lekker schijfje.

[JHMvP]

Je moet voor de aardigheid de IDE apparaten eens lostrekken en dan nog eens benchmarken.

Op mijn VIA-bordje met XP Pro wilde de 19160 alleen maar snel als géén IDE-apparaten aangesloten waren! :-/ Ook niet met SP1, SP2, SP3, de nieuwste 4in1, BIOS etc. etc.

[The Dolf]

gladiool schreef op 22 januari 2003 @ 20:20:
[...]


Dat klopt wel ongeveer hoor, die van mij doet ongeveer 70, ietsje minder dus, en ik draai 2k sp2 en geen dynamic disk. Lekker schijfje.

Dan neem ik alles terug. Mijn schijf zuigt nog steeds dus.
Maar er is iig wel verbetering

[Verwijderd]

Verwijderd schreef op 22 januari 2003 @ 18:32:
Het probleem is dat je in XP gedwongen zou zijn Dynamic Disks te gaan gebruiken om fatsoenlijke scsi-snelheden te krijgen. En Dynamic Disks zijn niet al te compatible met bepaalde backup-software.

Wat ik graag wil weten is of ik dan nog steeds een backup met norton ghost kan maken en weer kan terug zetten als dat nodig mocht zijn. Meestal maak ik van mijn 1e volledige install een mooie norton backup.

[Verwijderd]

Je kan gewoon met Ghost 2003 een image maken van een dynamic disk en terug zetten alleen na het terug zetten is je schijf weer een gewone partitie dan moet je hem alleen weer even converteren naar dynamic disk.

[Verwijderd]

Ik heb 2 SCSI (NTFS) schijven in mijn comp zitten, moeten die allebij omgezet worden of alleen de schijf waar het OS op staat??

Is het probleem ook aanwezig bij een fat 32 indeling?

[ Voor 23% gewijzigd door Verwijderd op 23-01-2003 08:08 ]

[Verwijderd]

Verwijderd schreef op 22 January 2003 @ 18:18:
Ik begrijp niet wat het probleem is draai hier Windows XP Sp1 op Asus p4t-e met Seagate Cheetah 15k3 18 gig op een adaptec 19160 scsi controller.

Heb de disk als dynamic disk ingesteld.


[afbeelding]

Als ik vragen mag, wat is je CPU usage, (en wat voor CPU heb je trouwens) tijdens het runnen van ATTO? Bij mij staat het op 100% (op een Athlon 1400!!), en dat verbaast mij een beetje, ik ben toch zeker bezig met een disk-benchmark, niet met een CPU stresstest.

/me vind wel dat scores hebt om je vingers bij af te likken.

[BalusC]

Verwijderd schreef op 23 January 2003 @ 09:14:
Bij mij staat het op 100% (op een Athlon 1400!!)

Dat betekent dat DMA niet wordt gebruikt (HDD invoer/uitvoer gaat dan via CPU ipv direct via RAM). Check dus de DMA settings, zie ook de OM FAQ

[maratropa]

balusc, het is SCSI, dus daar heb je geen DMA... (oh wacht je bedoelde max cool:))

ATTO staat er om bekend dat ie CPU vreet.

[ Voor 17% gewijzigd door maratropa op 23-01-2003 11:01 ]

[Verwijderd]

BalusC schreef op 23 January 2003 @ 10:52:

[...]
Dat betekent dat DMA niet wordt gebruikt (HDD invoer/uitvoer gaat dan via CPU ipv direct via RAM). Check dus de DMA settings, zie ook de OM FAQ

Waar stel ik in dat mijn SCSI controller wel of geen DMA moet gebruiken? Ik kan in mijn device manager niets vinden...

Ik gebruik momenteel de "V40a, sp3a" drivers van de site van Adaptec (gaat hier om een 19160).

[maratropa]

ah, SCSI heeft dus geen DMA, dus dat ken nie.

[Verwijderd]

Dus het klopt dat tijdens het runnen van ATTO je CPU verbruik hoog is (100%)?

Dat scheelt weer (ik krijg dit systeem echt moeilijk een beetje fatsoenlijk getuned ).

Misschien moet ik maar eens ophouden met al die synthetische benchmarks ATTO zegt dit, Adaptec SCSIBench zegt dat, Sandra weer wat anders... Voor mijn gevoel is mijn disk subsystem bloedjesnel (voor mijn girorekening ook trouwens).

[maratropa]

hehe AMEN, ik heb alleen atto en hdtach erop staan om soms te cheken of alles nog goed is, maar als het snel voelt in real life gebruik dan is dat al heel wat. Plus dat doorvoer zo weinig zegt, en hoe brak je doorvoer is, een 10k of 15k schijf blijft snel door de lage acces tijd.

[Verwijderd]

Subtiel kickje.

In dit draadje werd gesproken over het feit dat de lage schrijfsnelheid problemen in Windows .NET server (Windows Server 2003 dus) opgelost zouden zijn.

Dus ik braaf afwachten tot 24 april, want dat wilde ik wel meemaken. Ahemmm 24 april. Gisteravond een upgrade gedaan van Windows 2000 Server naar Windows Server 2003 Standard, en het maakt geen snars uit. De SCSI schrijf performance is exact gelijk gebleven (beetje laag dus).

Bummer!!

Meer mensen met dezelfde negatieve (of juist niet) ervaring?

(Zal toch niet zoals reeds gesuggereerd gewoon een VIA mobo probleem zijn? Draai namelijk zelf op een Abit KG7, met AMD Northbridge, en VIA Southbridge)

[Verwijderd]

Verwijderd schreef op 09 April 2003 @ 20:32:
Subtiel kickje.

In dit draadje werd gesproken over het feit dat de lage schrijfsnelheid problemen in Windows .NET server (Windows Server 2003 dus) opgelost zouden zijn.

Dus ik braaf afwachten tot 24 april, want dat wilde ik wel meemaken. Ahemmm 24 april. Gisteravond een upgrade gedaan van Windows 2000 Server naar Windows Server 2003 Standard, en het maakt geen snars uit. De SCSI schrijf performance is exact gelijk gebleven (beetje laag dus).

Bummer!!

Meer mensen met dezelfde negatieve (of juist niet) ervaring?

(Zal toch niet zoals reeds gesuggereerd gewoon een VIA mobo probleem zijn? Draai namelijk zelf op een Abit KG7, met AMD Northbridge, en VIA Southbridge)

dat het aan de chipset kan liggen heb ik en andere al eerdere gemeld, zal het niet helpen als je een schone instalatie doet??

[Verwijderd]

Kuch, staat wel heel veel progjes op die ik niet weer opnieuw wil installeren.

Mijn machine staat verder echt helemaal vol met zooi die op mijn FTP-server heb staan. Heleboel software, ISO's en MP3 tjes. Omdat ik "maar" 2 x 18 GB opslag heb, heb ik op mijn D: schijf een FTP root gemaakt met daarin Reparse Points naar diverse directories op zowel C: als D: Vrij complex dus.

Verder is deze machine ook de doos waarop Internet binnenkomt en vervolgens geNAT wordt. Hij draait verder stabiel, dus eigenlijk heb ik niet zo'n zin om de boel schoon te poetsen. Ik vraag me verder af of het wat zal uitmaken. Die Windows 2000 install was heel erg schoon, logfiles blijven netjes leeg...

De SCSI driver die door Windows 2003 gebruikt wordt is tijdens de installatie netjes geupgrade naar de versie die bij Windows Server 2003 hoort, dus ik verwacht eigenlijk geen wonderen. Nou zie ik wel dat tijdens Atto mijn processor 100% belast wordt, dus als ik binnenkort een snellere processor heb zien wel weer verder.

[Verwijderd]

Hier een stukje uit het forum van storagereview.net

Here is the last, the final, definitive scoop on XP SCSI performance.

It's really time for us to close the thread 'Terrible SCSI Performance in Windows XP". 678 posts, and no one reads any of the previous information because there's too much of it. This leads to a kind of self-perpetuating rant, which serves no purpose other than to keep circulating a myth about SCSI and XP.

So here's the bottom line, followed by a FAQ.

Windows 2000 had a minor bug where application requests to write through the cache (i.e. ignore the drive/controller cache and write directly to the disc) were not honored. In other words, writes were being cached even if the application asked for them not to be cached. This provided artificially high write performance in Windows 2000 for such applications (which are rare). Unfortunately, a number of benchmarks (e.g. ATTO) incorrectly used the WRITE_THROUGH flag in an attempt to provide what they thought was the most accurate, uncached, performance result.

Windows XP correctly honors the WRITE_THROUGH flag for Basic disks. When people upgraded from Windows 2000 to Windows XP, and ran a benchmark like ATTO, they saw greatly "decreased" write scores. That's because the writes were no longer being cached. While this is an accurate measurement of totally uncached writes, it's not the kind of performance result that ATTO wanted to provide their users.

Many people found that changing from Basic to Dynamic disks in Windows XP "reclaimed" their performance in ATTO. This is because Microsoft forgot to fix the WRITE_THROUGH issue with the Dynamic disk code path. Dynamic disks do not "reclaim" any "lost" performance, because the performance was never lost. It's an artificial benchmark phenomenon. Oh, sure, some file copy operations were affected, because they were using the WRITE_THROUGH flag. That's by design to ensure files are copied/moved with integrity. It doesn't affect 99.9% of system performance on non-server platforms.

The next version of Windows will likely have a checkbox under the "enable write caching" checkbox in the disk properties, to turn on and off the ignore WRITE_THROUGH flag behavior (for people who are using battery-backup and/or UPS and are therefore sure of disk integrity). In the meantime, users can choose one behavior or the other by choosing Basic or Dynamic disks.

OK, so that's the bottom line, please read over it carefully. Here is the FAQ.

Q: Is there a Windows XP BUG that reduces SCSI performance?
A: Absolutely NOT.

Q: Should I move back to Windows 2000, or to some other OS, due to this issue?
A: No, read the opening statements of this post again.

Q: Is this a SCSI related issue? Does it affect IDE or IDE RAID?
A: This is in no way SCSI related. The only reason it occurs on SCSI-class devices (SCSI & IDE RAID) and not on standard IDE, is that IDE does not have a WRITE_THROUGH flag in its command set. This could be considered a flaw in the IDE specification, which I understand is due to be rectified in a future spec revision. Note that any IDE controller which has its own drivers is a SCSI-class device and will appear as such (e.g. Promise Ultra100) even if it isn't RAID.

Q: If this is just due to ATTO writes being uncached, why is my write performance SO SLOW? I should have xxMBps to the platter...
A: The only way you can truly have sequential writes is if they are cached in the drive buffer. Without a cache, you can only write a chunk at a time, and in between chunks, you'll have missed the heads coming around and have to wait on rotational latency. That's why you'll see writes peaking after a certain block sized is reached in ATTO.

Q: You said I could choose behaviors by using Basic or Dynamic disks. What if I have XP Home, which doesn't support Dynamic disks?
A: SCSI (and IDE RAID) are high-end / enthusiast platforms. It would be very unusual for anyone to run XP Home on such platforms. For example, workstation-class machines from Dell, HP, etc. are not even offered with XP Home.

Q: How do I convert to Dynamic disks?
A: Control Panel, Administrative Tools, Computer Management, Disk Management, right-click on "Disk n" and choose "Convert to Dynamic Disk". Read the online help about Dynamic Disks to make sure you understand the restrictions, etc.

Q: Does XP Service Pack 1 affect the issue?
A: No.

Q: I heard that Windows XP was "made for the masses" and therefore "isn't optimized for best performance". Are there any tweaks I can use to improve disk performance?
A: Not really. That whole "made for the masses" stuff sounds slick but in fact, XP is very self-optimizing. Defragment your disk often, delete temp files and temporary internet files first. Be aware of an IE bug that leaves extraneous files in your Temporary Internet Files\Content.IE5 directory under randomly generated temporary directory names (basically, it dumps a file there every time you hit Stop while a page is loading, or navigate to another page before a page completely loads). Establish a paging file on each physical drive. Ensure write caching is enabled (some SCSI controllers will cause the write caching flag to be turned off on every reboot unless you set the controller to turn on write caching in its BIOS). Avoid converting FAT32 to NTFS, format as NTFS in the first place.

Q: I think you're wrong about this, because I have xxx SCSI performance problem under Windows XP.
A: There are dozens of reasons you may be experiencing poor performance that have nothing to do with this issue, and are not due to any global issue with SCSI performance under Windows XP.