Help! slow scsi setup

Hotrodsun

I am having problems, with my new scsi set up. I got a fresh install of XP pro with all the latest drivers and updates. When every I try play games they are real laggy. And when I try to watch quicktime movies they mostly just show one frame every 15 second, but the sound keep playing just fine. I have converted the hard drive to NTFS dynamic disk, but that didn't help much. But when I do the above off of my secondary IDE everything works fine. Heres what I got for a system.

Iwill MPX2
(2)mp2000
1gig pc2700 ecc
Tekram DC-390u3w
IBM 36 gig U160
Game theater XP
Intel Pro/MT 1000 nic
GF4 ti4600
TTGI 520w EPS ps

Does anyone got any Ideas? Thanks, Adam

Tex

How does it benchmark? I don't know much about the tekram board but use a lot of scsi and have both and asus and msi dual amd board here at the house with scsi raid. How is it bencmarking? Is that a 64 bit board? IS it sharing on IRQ with other onboard devices ? The framerate makes me suspect it is sharing an IRQ with the agp card on the board level. One of my 64bit slots does on my asus I know. Try swapping the 64bit cards. I mean switch the 64bit slots they are installed in and see what happens. You more then likely don't need the bandwidth of the gigabit NIC in a 64 bit slot. Stick it in a 32bit slot for now and make sure the tekram does not share an IRQ.

Your sure the cables and termination is sound?

Tex

Hotrodsun

Ok, I know that it is terminated correctly, It is a 64bit/66mhz card, the nic is in a 32 bit slot, and It is sharing an IRQ but XP says there is no conflict. Here is a bench mark (not the highest quality pic). Thanks, Adam

Tex

Your is showing the effects that some controllers do with the write_thru_flag and teh onboard disk cache with atto. My LSi u160 also did like yours and effected the reads and I am not sure why.

Usually the dynamic disk arrangement cures it. Have you tried newer drivers from tekram versus the XP drivers?

On teh board level when it boot and you see the box that lists the drevices and then a list of acrds and IRQ's.... Does the scsi share an IRQ there? Move the tekram to another 64bit slot.

Tex

Hotrodsun

Moved to other slot after I posted. Much better I think. Does this look like what I am suppost to get? Thanks, Adam

Tex

Yep. Sometimes you can run the mps multi hal and it takes care of those probs but one of the damn 64bit slots shares with AGP which sucks..,, and really screws with some boards.

Check with powerstrip and you can maybe get it to hold tighter and not vary as much. I bet the latency is at 32. Try even 64 instead.

tex

Hotrodsun

I have it set at 72 it was the one that worked best in the other slot, I will play around with it some more and see what I can come up with. Thank you very much Tex, you are truely a great man. Talk to you later, Adam

Tex

Anytime bud ! Glad to help always.

Cheers

Tex

Ageek

One thing to note about write_thru that applies to all SCSI.

Controllers have cache, so do HDs. Write thru says not to use cache. BUT, drive can only do one thing if it is not caching and putting data into a holding area at need (the cache). So, if you use a benchmark that writes and then reads, the whole test file needs to be written if no caching is allowed, or slower systrem RAM (has to be more latent than cache, and cahch accept and send caching due to modules used ALSO). The benchmark then gets not even an OK to the read request from the drive itself until the drive writes the file. Write thru is passed to the drive, not only used by controller. Yes, you have speeded up write.

Yes, you have guaranteed the reads to same file will get pended until not only the block but the whole FILE get written.

If you do not do the write-thru thing, a couple things happen to the benches:

Some controllers will actually read a block after a write block when given quick requests to do write and then read, and interleave the requests. There is less latency before the first block is returned from read this way, and the bench shows more even results. Some HDs will also do this, and the streams will show results for read and write that are closer together.

So, if you use write-thru you do get faster benchs for write than you do for read. This is nice for what RAID was first used for, which is mostly backup copies that had to be current but rarely (proportionately to writes) were read actively.

However, lets say someone is working on making a vry realisitic game and needs to read an write (both) a lot because his or her array was designed to bridge two drives into one volume to allow for files or directories bigger than a HD. In that case write-thru is NOT wanted as many controllers will not beable to interleve requests that way and wilth modern fast HDs interleaving reads and writes can be faster than skewing writes to complete before reads are handled if you are talking big files and need to both read and write them often.

File size and how often you need to read stuff you wrote recently or read to work on while writing (by reading blocks in between writing blocks) determine what postion of that soft switch is best for your application, regardless of pure bench for everyone.

John Danielson.

Tex

Th write thru flag in XP makes it skip the HD's internal disk cache anbd kills all performance really.

Win2k3 allows you to set the disk device dettings and not honor that flag basicaly. Only scsi honors it at all. There is no equivalent command for IDE. The only twoplaces I have seen it used is in ATTO and in file copies using explorer and its stupid to of implemented it for file copies in Explorer since its only valid for scsi and makes scsi file copies much slower then just ide file copies. Its basicaly controller/driver related and not all manufacturers are even honoring it the same. My Elite 1600's never honored the write_thru_flag on XP. this has nothing to do with the cache settings on teh controller. Thgis is supposed to be the disk cache onboard the drive itself. They keep saying we will get a patch for XP so that it functions like win2k3 but I have my doubts. I don't see it yet in SP2 for XP anyway.

tex

Ageek

True. Some folks think that write_thru is neat, but only in a mirrored RAID target (the array part that accepts backup data)does it make sense. Source, or main drive, never should be write_thru'd in a normal circumstance.

Tex

Your not understanding. This is not a controller setting. Its part of ntfs. MS fixed a bug in their ntfs file system and started supporting the write thru flag finaly after all these years. This isnt the controller. Its the disk itself that is now not not cacheing the writes. There is a flag to bypass the cache on the controller. This concerns the raid controller settings like write back or write thry etc...

We are talking about using the disk cache on the drive itself. And in real life there is almost nothing in thi sowrld you would ever want to bypass the disks internal cache

After all the wailing over the sorry scsi performance on XP they have implemeted a fix by way of adding another flag on the disk device itself below write caching called optimize performance. My LSI u160 had this option appear under win2k and it restored the scsi write performance. But its still not available as far as I know under XP in any patch or form.

Tex

Ageek

I guess Iam used to O\Ss that use direct access to HDs more. Those do use Write_Thru, but use it to tell the drive to bypass cache and burst write directly to platters.

*bows out as point was not understood

Hotrodsun

So do these look any better?

Tex

I would guess you are thrilled with those atto's

Tex