Sorry to bud in here, but I have noticed performance degradation on Linux when I've had over ten thousand files in my downloads directory. This performance degradation would include freezing randomly mid game (whenever a file was uploaded, or what it had looked like from the servers console).
What would be pretty cool is an adjustable tickrate (rather then FPS). All in an effort to minimize the thundering heard problem with syscalls. This has been accentuated due to the increased CPU usage which was a direct result of the Engine swap. Inside of the OB engine, FPS is absolutely meaningless provided it's above the tickrate. Unless of course I've been ill-informed. Kyle. On Mon, Nov 15, 2010 at 9:32 PM, John <[email protected]> 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. > > 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. > > 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 > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
