Strange lag/pause in BGEE 1.2 single-player

Sivar

Expected behavior: No lag or odd pauses on a modern computer

Actual behavior:
My game pauses for maybe half-a-second fairly frequently, usually when opening a container (like dropped items or a chest) and sometimes when walking. It happens fairly consistently.
It seems to happen when BGEE might be accessing files, so I put the entire installation on a RAM drive and tested. The pauses went away.

The thing is, BGEE is on a dedicated game hard drive: A Western Digital Red 4.0TB drive which is less than half-full and whose performance is quite good. I know it seems like a problem with the drive, but I am VERY familiar with storage technology (I was the first moderator of StorageReview.com, was a technical editor for them, have a CS degree, and am the resident enterprise storage nerd at my work, which is a Fortune 1000 technology company). The drive maintains below 1% active time while playing and, on average, a queue length of about 0.02. Latency is consistent with its specs and no other software accesses the drive while running BG.
The pause is not consistent with a "powered down" hard drive, and my delay is set to 90 mins. No other applications (all games or sims on this drive) experience a similar issue. Benchmarks show normal performance for the drive.

System:
Overkill CPU for BGEE, 32GB RAM, nVidia 580 (331.58 driver), Win7 Pro 64, Intel SSD for system, new WD Red 4TB drive for game install.
My "My Documents" is on a network share, but it's an obscenely overkill network share with enterprise-grade hardware. Also, the lag disappears when on a RAM drive (so far), so that variable is probably eliminated.

I'd be happy to run a logging package, debug build of BGEE, etc. if that would help.

Taeter

You're running this from a WD Red. WD Reds default to having TLER on. That is bad(tm) if you don't run it via a proper RAID controller, in a RAID, as I'm sure you know. You should use smartctl to turn off TLER before taking any future debugging steps, using smartctl -l scterc,0,0 /dev/yourdiskhere

Note: The setting doesn't stick on WD Reds, so you have to re-apply it every time they lose power. I use a scheduled task on boot and on event (looking for SATA hotplug events from IAStor) for that purpose.

Maybe you've already done this, but your post doesn't make it clear. I'm not saying this will fix it (I doubt it will), but it should be done before taking any further steps.

Sivar

Thank you for the response, @Taeter. To the best of my knowledge, TLER does is reduce the amount of time the drive spends recovering data when it finds a bad sector, because a RAID controller won't wait long while the drive re-reads possibly hundreds of times. This shouldn't be harmful to performance and should have no affect unless a bad sector is found, in which case the drive would just be faster to report bad data (probably leading to a crash, not a pause) without making as much of an effort to recover that data.
A surface scan found no bad sectors and there are not yet any remapped sectors, so I'd expect everything to be normal. Ultimately, all BG does is request data from the file system. Note that I got this drive to review -- if I'd purchased it, I would have bought a WD Green or one of its competitors.

It used to be that you could *enable* TLER (once per reboot, as you described) on most consumer drives, but manufacturers decided to charge more for the privilege. Doing so never caused a problem, but of course wasn't very useful for non-RAID setups.
Still, the one remaining variable is the drive, so I'll consider installing a different one and running BG from there.