[mitsubishi]

this is related to sv_fps (snaps / second)

I'm playing around trying to add a "snaps per second" meter in an .exe build (linked on my sig, not yet in) and I found the following peculiar - and worrying behavior:


server snaps 20: (urt default and locked)



SPS (snaps/second from server -> to client) jumps from 20 to 19 all the time. 19 is a common mean. The common deviation from the mean ('standard deviation') is 2-3 snaps / second.

the trend continues with other values, e.g. 40:




and then - surprise - there are "magic values":

on 125:



solid, 0 deviation



a more realistic approach, 25:




again, solid, 0 deviation.




I may have a version of the .exe soon for anyone to test. Though a developer can just make his own meter i suppose.

(the images are from baseq3 but same deviation was shown on urt on 20)




edit:

Ignore the 0 columns (2nd column of 10s interval), it's not ready yet so it printed nothing.


I suspect it may be better for gameplay to use one of those magic values e.g. 25, it also reduces gameplay latency and needs some more resources but it may be worth it nowadays provided there are no bugs because of it as it has been discussed before.

update: this behavior appears to be related to FPS of the client, as it should have been obvious, however since most clients are going to be playing on a certain FPS anyway, certain sv_fps values might be more optimal relating to this behavior, regardless of the latency output due to their number.

[mitsubishi]

ok i released this meter in the relevant thread http://forums.urbant...n-urt-directly/

for anyone to see.

tests remember are done on baseq3 for other numbers, 20 can be also shown on urt.

[QA Delirium]

interesting..

what map is that?

[mitsubishi]

it doesn't matter what the map is for this behavior.

it's probably q3dm0.

[Well Cooked Nade Burgers (old)]

it was suggested to increase/unlock sv_snaps for 4.2

the question is will the devs listen

[mitsubishi]

Well Cooked Nade Burgers, on 23 November 2009 - 04:27 AM, said:

it was suggested to increase/unlock sv_snaps for 4.2

the question is will the devs listen

this might be important; if a more stable number is better for gameplay it might be better to at least lock it to another value, say 25.

I've also made an entry at the bug tracker on ioq3 in case anyone notices it.

edit: and maybe investigate it more.

This post has been edited by mitsubishi: 23 November 2009 - 03:17 PM

[mitsubishi]

I have news on this; apparently this is affected by the FPS of the client as it should have been obvious. e.g. a client on 20 FPS - which is unplayable but for the testing - appears to produce no such deviations.


Also, another "cryptic" piece of info is available. The server sends snaps in a fashion and the client deems them to be treated as "extrapolated" or not. This is apparently not the same kind of extrapolation shown on the net meter (as yellow) which appears to be dealt by game code there; this appears to be a more lower level indication (recorded on cl.extrapolatedsnapshot).





the new meter here shows the rate of that kind of extrapolation.

What is interesting is that this kind of extrapolation occurs always, even on local devmap and it goes away on certain sv_fps values, e.g. 125. In other values it appears to be extremely unstable, e.g. on sv_fps 80.

(all tests on baseq3 which allows changing of the vars)

This post has been edited by mitsubishi: 02 December 2009 - 02:41 PM

[FS TwentySeven]

Dont test this with a local host, theres a problem with client loopback that'll never get fixed, ever.

[mitsubishi]

ok though most of the behavior appears to be there on remotely.


btw, as mentioned in the 'latency' thread, if sv_fps '25' appears to be a more stable value to clients (per the 1st post here) why not be able to use it.

This post has been edited by mitsubishi: 04 December 2009 - 10:40 AM