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
