At 12:32 AM 11/16/2010, John wrote:
You're also missing the design limitations of the actual drives.
Assuming IDE/SATA, the disks do not support disconnected writes,
which is a significant performance bottleneck when you are writing
to the disk...SAS/SCSI drives have 128 concurrent writes (tagged
command queue depth).
I'm not sure what you mean by "also missing", since I have been
spot-on about disk writes potentially causing performance problems,
and what you're saying supports what I said before. This is
something that I have studied extensively.
I am talking about the physical drive design. Not the OS's inability
to stop causing huge amounts of latency because of x/y/z kernel
issue/bug/feature/design.
You are misinformed about SATA drives. Many do support NCQ, which is
the equivalent to TCQ on SAS/SCSI. The OS also maintains its cache
and uses a scheduler to try to optimize writes, usually doing a
decent job at maintaining a good rate of IOPs. Regardless of the
NCQ/TCQ capability, the same performance problem would exist, given
heavy enough disk access.
No. SATA drives don't seem to support disconnected writes. Writing to
disk on SATA is a latency killer. (Read through the SATA spec, it's
there, probably on wikipedia too). I didn't know NCQ allowed 32
commands to be store-and-executed, I thought it was 8 or 16.
I know how OS's work, btw.
My comment about log writes listed them as an example of something
that can make a tick take longer than anticipated, along with
plugins (and the game itself). This is a valid example, but even if
it were not valid, the overall assertion stands.
> I have no idea what baseline performance is in the context of a
game server.
The baseline performance in that case would be no background disk access.
mlock()? Memory backed filesystem that doesn't cause faults?
different drives? sockets? null?
I think there might be a misunderstanding here. My example was that
disk write delays due to logging during periods of heavy disk writes
are one factor that I have seen lead to a performance problem and at
the same time cause FPS dips. The baseline performance case for that
particular scenario is very simple and as I described. I was not
suggesting that there are no other reasons for FPS dips, or
suggesting a baseline performance description for all scenarios.
This is also a very small piece of what I said as a whole.
-John
If logging causes you performance.. problems, turn off logging? Stuff
your logs into a socket? How about hack in a fix yourself with
reverse engineering and .so's?
I guess they could have a separate thread with an IPI-like that is
only used for disk writes.
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
