identify problems with FPS and LAGOMETER

[Lenovo]

Someone can produce a kind of tutorial, to analyze the LAGOMETER
example:
What does the GREEN LINE represent?
What does the BLUE LINE represent?
What does YELLOW TRIANGLES represent?
What does the BLUE LINE break off at some points?
What do the RED LINES represent suddenly?
so what number 20 appears in green?
what changes to the LAGOMETER happen with the cl_timenudge command in its variants?
What is the enlarged GREEN LINE?

add you other questions, and let's see if we can give the audience that is interested in understanding better, how to interpret the LAGOMETER

 

 

my sample demo 

 

2019-01-30-042433-fueldump.dm_84

 

 

 

Edited January 30, 2019 by Lenovo

[daredevil]

7 minutes ago, Lenovo said:

2019-01-30-042433-fueldump.dm_84

Share the screenshot? What you need help with? 

[Lenovo]

1 minute ago, daredevil said:

Share the screenshot? What you need help with? 

my sample screenshots

[daredevil]

Blue line is perfect - No issues. You got stable 76 FPS. 

 

Your green line height as jitters. i.e. your ping is changing. The height of green bar = your ping changes. 

[Lenovo]

I do not need help myself personally, I would like to be able to contribute on this subject too, and to help those who know nothing about the LAGOMETER

 

😎

[daredevil]

2 minutes ago, Lenovo said:

I do not need help myself personally, I would like to be able to contribute on this subject too, and to help those who know nothing about the LAGOMETER

 

😎

You sometimes annoy me my friend. How are you contributing to subject while just sharing demo? You kidding me man? 

 

Your first post initially was just this - 

 

Quote

my sample demo 

 

2019-01-30-042433-fueldump.dm_84

 

[Lenovo]

I edited I was finishing my post, I do not make you loose LoL
, it's you that this morning you're so quick to answer that you do not give me the time, you know I'm Italian I have to check everything, the spelling and the punctuation

[Lenovo]

I have an example right now on Jay1 the server is laggando to all I think

 

 

even the number that usually remains stable at 20 has changed

[Xernicus]

48 minutes ago, Lenovo said:

I have an example right now on Jay1 the server is laggando to all I think

even the number that usually remains stable at 20 has changed

Hmm... don't know about that.
See how green spikes below are like one/two frames before yellow up top? That's extrapolation. Bottom spikes could be from resource constraints (CPU, Disk, etc.) or ping spikes. In any case snap updates were delayed, so the netcode estimated your location. (this also correlates to 14 snaps indicator) Not sure what happened in 2nd SS. FYI: It's relatively normal to miss some frames in heavy fire, because of flame/smoke, field ops, etc. But the server isn't dropping packets...
 

[Lenovo]

I noticed that the packages are unchanged, but these are the screenshots of when there is a lag for everyone on jay1 confirmed by everyone, which lasts a 20 seconds, and nobody can almost move or shoot

Edited January 30, 2019 by Lenovo

[daredevil]

2 minutes ago, Lenovo said:

I noticed that the packages are unchanged, but these are the screenshots of when there is a lag for everyone on jay1 confirmed by everyone, which lasts a 20 seconds, and nobody can almost move or shoot

Is that 11 PM EST lag? If yes that's known thing. See here - 

 

 

[Lenovo]

anyway I mean a tutorial similar to this one:

 

 

 

 

Lagometer

 

Enemy Territory provides a small graph with some network information which can be enabled by setting cg_lagometer to 1. Although this is not a feature specific to ET Pro, it has never been well-documented.

The lagometer consists of two graphs--the upper is the frame graph, and the lower is the snapshot graph. New data is added to the frame graph every time the client renders a frame (so this graph will move faster at higher framerates), and new data is added to the snapshot graph every time a snapshot packet is received from the server.

Contents

 

1 Snapshot Graph

2 Frame Graph

3 AntiWarp

4 FPSometer

Snapshot Graph

 

The snapshot graph

is the easiest to understand--it is essentially a graph of the latency (ping) between you and the server. The graph's colors provide some additional information: green is normal, yellow indicates that the snapshot was delayed so that the server would not exceed the rate value (either rate on your client, or sv_maxRate on the server, whichever is lower), and red indicates that a snapshot was lost entirely (i.e. a snapshot sent by the server never made it to the client, probably due to network problems.)

http://www.themuffin.net/etpro/lagometer-snap.png

In the above image, arrow 1 points to a normal snapshot with a ping of about 130ms, arrow 2 points to 700ms of packet loss, and arrow 3 points to 2 snapshots that were delayed to stay under the rate limit.

 

Frame Graph

The frame graph is a little more complicated, and requires some background information about how Enemy Territory's network code works for a full understanding. In Enemy Territory, each client runs at a non-fixed frame rate (depending on configuration, system performance, etc.) while the server runs at a fixed rate of 20 frames per second. After running each frame, the server will send a snapshot to every client (so long as the client's snaps and rate settings allows it) describing everything that has changed since the previous snapshot. When the client receives this snapshot, it interpolates the values between the old snapshot and the snapshot that was just received--that is, it smooths out the movement so that things in the map don't appear to be jumping around when the client is drawing frames faster than the server is sending them. If the client doesn't receive a snapshot, it may have to guess where an object is going to be in order to keep things looking normal.

The client and the server each keep track of the current game time, and the differences between these times are expressed in the frame graph as well as object movement. For a simple example of this, imagine that the server has sent you two snapshots, snapshot a at time 12350, and snapshot b at time 12400¹, and then imagine that the client's current time is 12375. The client will interpolate² the position sent in snapshot a and in snapshot b to determine that the object in question should be drawn in the middle of the two points sent (because 12375 (the time our client is drawing for) is exactly halfway between 12350 and 12400.)

In the situation presented in the previous paragraph, imagine the client's time is 12425 and that no additional snapshots have been received yet. In order to maintain fluid motion, the client will need to guess where objects will be (using the last known position, angle, and velocity.) The calculation for this is quite not as easy to explain, so an example has been omitted for brevity.

The frame graph in the lagometer represents how far the time used for currently drawn image is away from the most recently received snapshot, and whether the client interpolated or extrapolated to obtain the positions used. Normally, the client interpolates positions, which is represented in blue on the lagometer; the graph height will spike downwards when a new snapshot is received, then crawl upwards towards the baseline), although it will sometimes be yellow to indicate extrapolation (and the graph will crawl upwards away from the baseline as the client extrapolates farther and farther from the last known data.) Since the cl_timenudge cvar causes the world to be rendered a certain number of milliseconds behind or ahead of the client's internal time, negative values may cause extrapolation during normal gameplay. For example, in the first situation described above (where the client's time is 12375), a cl_timenudge value of -30 would end up pushing the time used for rendering up to 12405 (which is newer than the data we have), so a small amount of extrapolation (5ms) would be required here.

http://www.themuffin.net/etpro/lagometer-frame.png

In the above image, arrow 1 points to an interpolated frame immediately after a new snapshot was received, and arrow 2 points to a frame where a fair bit of extrapolation was performed.

AntiWarp

If etpro AntiWarp is triggered, it the delay added by the antiwarp system is represented by translucent green bars in ths snapshot graph, like this

lagometer-antiwarp

FPSometer

In etpro, cg_lagometer 2 replaces the standard ET lagometer with a graph of frame time. The bars hight shows the time required to render a frame, and they are color coded as follows

Red > 35ms

Yellow > 20ms

Green <= 20ms

Footnotes

¹ Note the increase of exactly 50 -- remember that the server is running at 20 frames per second, so:

1 frame ·1000ms (1 second)20 frames= 50ms

² This is technically called linear interpolation (the simplest interpolation method), which is sometimes abbreviated to lerping.

 

[Lenovo]

you want to make the believers of this forum believe that I'm a poor guy, one who always complains about spam, one who does not understand anything, but I want to be useful, I'm a humble person, and I write smart posts, and also brilliant ones Instead, you still feel hatred towards me as I came out of = FA = and continue in all your replies to underline everything that is wrong with what I write

[Lenovo]

There are many discussions on the lagometer on the net, to elucidate players about what happens while playing Enemy Territory, this is an example

 

 

How to read the lagometer

[HOTSPUR]

Hi lenovo, I've was always lead to believe Green bar is your connection top Blue is the server. But please don't quote me on it. 👍