2008/11/15 Nander Paardekooper <[EMAIL PROTECTED]>

> ah crap... you too?!...
>
> Ferenc Kovacs schreef:
> > 2008/11/14 Valtteri Kiviniemi <[EMAIL PROTECTED]>
> >
> >> 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
> >>
> > /me built a perpetum mobile and a water-car but I don't bother to tell
> you.
> >
> > Tyrael
> > _______________________________________________
> > 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
>
tsss, its a secret.

Tyrael
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux

Reply via email to