I've been testing 1000fps gameservers myself and i found after long
research a kernel + patch combination that gives always 1000fps (with
pingboost2). It stays on 1000fps constantly even with many players on
server and multiple 1000fps servers on the same hardware. It didn't even
use much CPU.
I still consider the perfect kernel as some kind of business secret so
im not telling anything more than that its possible with pingboost2 +
real time patchset from /Ingo Molnár. Rest you have to figure out
yourself. =)/
kabukiUkie kirjoitti:
> This is the best we got it to with our configuration and pingboost 2. Output
> from console stats (output from rcon stats are more consistently 1000). :
> stats
> CPU In Out Uptime Users FPS Players
> 0.00 142.87 231.76 5059 7723 1000.00 20
> stats
> CPU In Out Uptime Users FPS Players
> 0.00 143.05 229.28 5059 7723 980.39 20
> stats
> CPU In Out Uptime Users FPS Players
> 0.00 143.02 230.85 5059 7723 984.25 20
> stats
> CPU In Out Uptime Users FPS Players
> 0.00 143.26 232.51 5059 7723 981.35 20
> stats
> CPU In Out Uptime Users FPS Players
> 0.00 141.28 232.72 5059 7723 956.02 20
> stats
> CPU In Out Uptime Users FPS Players
> 0.00 142.59 234.15 5059 7723 505.31 20
> stats
> CPU In Out Uptime Users FPS Players
> 0.00 144.81 237.62 5059 7723 492.85 20
> stats
> CPU In Out Uptime Users FPS Players
> 0.00 143.50 237.01 5059 7723 946.07 20
> stats
> CPU In Out Uptime Users FPS Players
> 0.00 142.39 235.56 5059 7723 492.37 20
> stats
> CPU In Out Uptime Users FPS Players
> 0.00 141.01 227.23 5059 7723 975.61 20
> statsDropped sway adr * mysway.net from server
> Reason: Client sent 'drop'
>
> CPU In Out Uptime Users FPS Players
> 0.00 127.23 203.21 5059 7723 975.61 19
> stats
> CPU In Out Uptime Users FPS Players
> 0.00 126.72 197.65 5059 7723 928.51 19
> stats
> CPU In Out Uptime Users FPS Players
> 0.00 129.82 198.30 5059 7723 970.87 19
> stats
> CPU In Out Uptime Users FPS Players
> 0.00 136.97 213.33 5059 7723 948.77 19
> stats
> CPU In Out Uptime Users FPS Players
> 0.00 140.09 223.73 5059 7723 1000.00 19
>
> top:
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 16994 ndsg2 20 0 273m 256m 7608 S 38 7.8 1508:40 hlds_i686
>
>
> On Fri, Nov 14, 2008 at 2:38 PM, Kveri <[EMAIL PROTECTED]> wrote:
>
>
>> I think stable 980+ fps on 20 slot public with 20 players is not possible.
>>
>> Kveri
>>
>> Kveri wrote / napísal(a):
>>
>>> 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
>>>
>>>
>> _______________________________________________
>> 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
