I believe, and I could be wrong, that all recent versions of glibc call gettimeofday as a virtual syscall, which means the context switching doesn't occur. I'm not sure that fixing the overuse of gettimeofday() will solve all these problems, I think there are just some serious issues with the way the main loop of srcds works in linux. As an example, a server with 20 people will hover at 1000fps, drop to 300, jump to 1000, drop to 200, etc. Even when there is CPU to spare. And will use more CPU, generally, than two full unboosted windows servers. :-/
- Neph [EMAIL PROTECTED] wrote: > Gary Stanley Wrote: > >> Have you tried an older kernel? I don't see those issues (at all). >> However, I have plenty of hacks in place in kernel/time.c to make >> gettimeofday() return for speed, no accuracy (saves a couple mpy and >> divl cycles), and i don't use 2.6.26 series on my development stuff. >> > > Any chance you published any of these modifications? I've been looking for > either > some patches to make gettimeofday() less of a bear or for Monk > (http://www.gsptruth.com/forum/lounge/257-recent-project.html) > or anyone with more experience to post some further details on how to > do this syscall -> userland redirecting. > > _______________________________________________ > 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
