Why do you need 980+ fps on public? It's waste of resources, and no hardware can handle that.
Kveri Faustas Buškevičius wrote / napísal(a): > What are the chances of sustaining 980+ fps on a public server with > 20+ players and max rates ? > > On Thu, Nov 13, 2008 at 1:09 PM, Kveri <[EMAIL PROTECTED]> wrote: > >> Interesting, it looks like a bug in documentation. I'll test it on >> brand new dual E5335 xeon server. >> >> Kveri >> >> Sent from my iPhone >> >> On 13 Nov 2008, at 08:00, "John" <[EMAIL PROTECTED]> wrote: >> >> >>> Gary: >>> >>> >>>>> With -pingboost 2, HL1 actually uses select() for its delays. >>>>> >>>> -pingboost 2 uses alarm(), -pingboost 1 uses select() >>>> >>> I was careful to check this before I originally posted; what I said >>> about >>> was accurate, as least at the OS level. You can confirm this with >>> "strace". >>> I see output like this for -pingboost 2: >>> >>> ... >>> gettimeofday({1226558338, 85065}, NULL) = 0 >>> gettimeofday({1226558338, 85091}, NULL) = 0 >>> gettimeofday({1226558338, 85122}, NULL) = 0 >>> gettimeofday({1226558338, 85147}, NULL) = 0 >>> gettimeofday({1226558338, 85170}, NULL) = 0 >>> select(1, NULL, NULL, NULL, {0, 1000}) = 0 (Timeout) >>> select(1, [0], NULL, NULL, {0, 0}) = 0 (Timeout) >>> gettimeofday({1226558338, 85971}, NULL) = 0 >>> gettimeofday({1226558338, 85996}, NULL) = 0 >>> recvfrom(5, 0xbfa3efe4, 4010, 0, 0xbfa3ff90, 0xbfa3efcc) = -1 EAGAIN >>> (Resource temporarily unavailable) >>> gettimeofday({1226558338, 86058}, NULL) = 0 >>> gettimeofday({1226558338, 86083}, NULL) = 0 >>> gettimeofday({1226558338, 86102}, NULL) = 0 >>> gettimeofday({1226558338, 86120}, NULL) = 0 >>> gettimeofday({1226558338, 86161}, NULL) = 0 >>> ... >>> >>> In constrast, -pingboost 1 gives output like this: >>> >>> gettimeofday({1226558633, 60244}, NULL) = 0 >>> gettimeofday({1226558633, 60272}, NULL) = 0 >>> recvfrom(5, 0xbfb5ecb4, 4010, 0, 0xbfb5fc60, 0xbfb5ec9c) = -1 EAGAIN >>> (Resource temporarily unavailable) >>> gettimeofday({1226558633, 60340}, NULL) = 0 >>> gettimeofday({1226558633, 60360}, NULL) = 0 >>> gettimeofday({1226558633, 60388}, NULL) = 0 >>> gettimeofday({1226558633, 60415}, NULL) = 0 >>> gettimeofday({1226558633, 60442}, NULL) = 0 >>> setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 1000}}, >>> NULL) = 0 >>> pause() = ? ERESTARTNOHAND (To be >>> restarted) >>> --- SIGALRM (Alarm clock) @ 0 (0) --- >>> rt_sigaction(SIGALRM, {0x804a910, [ALRM], SA_RESTART}, {0x804a910, >>> [ALRM], >>> SA_RESTART}, 8) = 0 >>> setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 1000}}, >>> NULL) = 0 >>> sigreturn() = ? (mask now []) >>> select(1, [0], NULL, NULL, {0, 0}) = 0 (Timeout) >>> >>> It sounds like Valve flipped the definitions of the functions since >>> creating >>> the versions you posted. >>> >>> With our kernel configuration, load-balancing, etc, both -pingboost 1 >>> and -pingboost 2 provide very stable framerates with extremely low >>> jitter. >>> On a Core2-based machine, we typically see a stable ~982fps with - >>> pingboost >>> 1 and a stable 1000fps with -pingboost 2. Rarely, either method will >>> dip >>> slightly. Typically with -pingboost 2, the dips are into the upper >>> 990s. >>> >>> -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 >> >> > > _______________________________________________ > 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