hundred thousands would explain it being unable to go above 990, so that
clears something up :)

I'm not using a plugin, I'm using an OS override to correct the interframe
sleep time so its "should" have the most accurate view of the simulation
possible, unless I'm missing something.

If its using Plat_FloatTime that cold easily explain the issues as it
uses gettimeofday on Linux which is not guaranteed to be monotonic, so you
could see the value decrease as ntp nudges the system clock for example.
Obviously if this happened, it could cause all sorts of strange edge cases.

Yes you would need to ensure that you still avoid div by zero. Seems the
display code can deal with %5.1 easily enough for high FPS servers
just need the value of m_flServerFramerate to be correct.

The fact that the fps is guarded by if ( flFrameTime > 0.001f ) but
stdev value isn't would explain why its always appears to be way more
accurate which gives more weight to my suspicions about the fps value
having a problem somewhere, possibly server side given the current info.

   Regards
   Steve


----- Original Message ----- From: "Tony Paloma" <drunkenf...@hotmail.com>
To: "'Half-Life dedicated Linux server mailing list'" 
<hlds_linux@list.valvesoftware.com>
Sent: Monday, August 02, 2010 10:05 PM
Subject: Re: [hlds_linux] High FPS?


The frame time transmitted over the network to clients should be precise to
the hundred thousandths, so I don't think that's the issue. However, it also
only receives FPS updates as fast as the update rate.

Perhaps the discrepancy between what you are recording on the server and
what you see on the client is method of recording? The value transmitted to
clients to show on the net graph is calculated by Host_AccumulateTime which
just seems to set the frame time to the value passed into _Host_RunFrame (in
the default case) which seems to be the difference in time (Plat_FloatTime)
between calls to CEngine::Frame. The engine frame function seems to call up
to CServerPlugin::GameFrame so if you are using a plugin to calculate the
frame time yourself, I am not sure where the discrepancy would come in.

A client mod could remove the check for > 0.001, though not easily. Also, I
assume the check is there to prevent division by zero.

-----Original Message-----
From: hlds_linux-boun...@list.valvesoftware.com
[mailto:hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Steven
Hartland
Sent: Monday, August 02, 2010 1:22 PM
To: Half-Life dedicated Linux server mailing list
Subject: Re: [hlds_linux] High FPS?

Useful info there Tony thanks for that, any idea what precision that is?

I still suspect something odd is going on with that as logging the frame
times on the server doesn't show any variation during normal play that would
cause the behaviour you see on the fps on netgraph.

As you say though a single long frame will easily cause this and the changes
do all seem to be around round restart where the server is doing the most IO
so could easily be that.

So in theory a server which is consistently above 1000 fps is more likely to
display wildly inaccurate fps with this check in place.

Wonder if a client mod could remove this > 0.001 check and let it display
properly?

   Regards
   Steve

----- Original Message -----
From: "Tony Paloma" <drunkenf...@hotmail.com>
To: "'Half-Life dedicated Linux server mailing list'"
<hlds_linux@list.valvesoftware.com>
Sent: Monday, August 02, 2010 8:28 PM
Subject: Re: [hlds_linux] High FPS?


Actually, it is true that it displays the last value under 1000fps. From
vgui_netgraphpanel.cpp:
void CNetGraphPanel::UpdateEstimatedServerFramerate( INetChannelInfo
*netchannel )
{
float flFrameTime;
netchannel->GetRemoteFramerate( &flFrameTime,
&m_flServerFramerateStdDeviation );
if ( flFrameTime > 0.001f )
{
m_flServerFramerate = 1.0f / flFrameTime;
}
}

m_flServerFramerate is what is displayed on the netgraph (see
CNetGraphPanel::DrawTextFields) and m_flServerFramerate is updated only if
flFrameTime > 0.001 (i.e. less than 1000fps). All it takes is a single
frame
to take longer than normal for you to dip below a calculated 1000fps which
may explain why you see it getting stuck at values the server never seemed
to report.

There is no integer overflow as far as I am aware.


================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the
person or entity to whom it is addressed. In the event of misdirection, the
recipient is prohibited from using, copying, printing or otherwise
disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please
telephone +44 845 868 1337
or return the E.mail to postmas...@multiplay.co.uk.


_______________________________________________
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


================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please 
telephone +44 845 868 1337
or return the E.mail to postmas...@multiplay.co.uk.


_______________________________________________
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