ET is still power hungry

[daredevil]

Big yellow spikes like those in S3ti screenshots mean he didn't have snap#2 but only snap#1, and his client has to predict whet happens next. I'm not sure if this can happen as a 'chain effect', with the client being too much ahead for some frames in a row or not. I should check it in more detail.

 

If that's the case then he should have yellow lines inside his green line instead he is seeing hitters in his green lines. That's my lagometer screenshot with my broken GPU in laptop lol.. ... In game or spec.. perfect blue and straight green. His spikes in green suggest some issue either @his internet or in his PC.

 

 

[Ann!b@l]

I got these green peaks me too when I set the polling rate of my mouse at 1000hz and less when I decrease at 500hz.. Also, spikes caused by my graphic card driver him too.. Fixed my issue in uninstalling the whole of my driver (it means registry keys included) with RevoUninstaller and reinstalled all this.. All this fixed my issue..

Edited May 15, 2013 by Ann!b@l

[S3ti]

If that's the case then he should have yellow lines inside his green line instead he is seeing hitters in his green lines. That's my lagometer screenshot with my broken GPU in laptop lol.. ... In game or spec.. perfect blue and straight green. His spikes in green suggest some issue either @his internet or in his PC.

 

Is that screen with 25+ players on jay3 server? The issue only occurs on crowded servers with a lot of players, so I thought it's a server issue somehow. Up to 20 players it's totally fine, and I don't get it in any Q3 engine game with lagometer on.

[SunLight]

If that's the case then he should have yellow lines inside his green line instead he is seeing hitters in his green lines.

As far as I know, yellow in the lower part means that the snap was delayed because of rate limit. And in his case apparently it's not. I will try to set a low rate on purpose, and see if I get yellow mixed with green to confirm this.

 

But of course there are many nodes from pc to server and back, and any of them can have delays and ping instability, so even if the server has no problems, it's impossible to get server frames exactly every 50.0000ms probably not even on a local server this is possible.

[daredevil]

As far as I know, yellow in the lower part means that the snap was delayed because of rate limit. And in his case apparently it's not. I will try to set a low rate on purpose, and see if I get yellow mixed with green to confirm this.

 

But of course there are many nodes from pc to server and back, and any of them can have delays and ping instability, so even if the server has no problems, it's impossible to get server frames exactly every 50.0000ms probably not even on a local server this is possible.

 

No what i mean to say was if server/client rate is limiting factor then he should see yellow lines in lower green part of lagometer but it's not and hence he has none.

 

My bet is .. he is probably receiving fragmented packets some how or his CPU HD is doing something else. I don't think it's HD cos if it is then he would see long yellow line instead of blue .. in descending order.. 

[S3ti]

No what i mean to say was if server/client rate is limiting factor then he should see yellow lines in lower green part of lagometer but it's not and hence he has none.

 

My bet is .. he is probably receiving fragmented packets some how or his CPU HD is doing something else. I don't think it's HD cos if it is then he would see long yellow line instead of blue .. in descending order.. 

 

So am I the only one facing this with 25+ players or does anyone else's lagometer look the same then? Would be nice to see some feedback or screens from other jay3 guys Connection settings for my router and PC like MTU are set on spot what for my isp is capable of, I don't get fragmented packets when pinging around in the web and such...

 

Pretty sure too it's no network/connection issue, ping is fine most of the time and the green line is ok, maybe some PC issue eventually (given I'm the only one or someone else doesn't get those yellow spikes)

[Death_Reincarnated]

Yellow means the game time is past the time of the last received server snapshot.

Red is another thing, becuse the bottom part shows snapshots and ping, the upper part is updated every frame (so it changes according to your fps)

 

The server sends 20 snaps per seconds (1 every 50ms).

 

The client (without timenudge) shows everything with 50ms delay, because it shows snap#1 when snap#2 is already arrived.

This is done becuse the client runs faster than 20fps, if you just displayed server frames as they arrive, you would see everything going at 20fps. So a smooth transition is done between the second-to-last and the last snapshot.

Starting from snap#1, when it gets to display the scene at snap#2, snap#3 should be already arrived, and the interpolation can continue.

 

Of course this is based on the assumption that server snapshots arrive 'exactly' every 50ms, which in reality can never happen, due to network and timing both in the client and server. But I would say mostly network.

 

Big yellow spikes like those in S3ti screenshots mean he didn't have snap#2 but only snap#1, and his client has to predict whet happens next. I'm not sure if this can happen as a 'chain effect', with the client being too much ahead for some frames in a row or not. I should check it in more detail.

Yes I agree. This is what I was getting at - somewhat lol. Generally speaking, when you are about to lose a packet you tend to have few previous ones come in delayed - i.e. yellow then red. If certain players are loosing 'snaps' it can mainly be attributed to bad connection between client and server. The ammount of data increases with player numbers on the server and it is possible to at some point to lose information if the bandwidth of it too high because of the hops might be having high traffic. Try pinging an ET servers and then actually going on it - The ping that you get when running 'ping' from cmd will be lower then when actually being on the server.

 

Quake3 engine doesn't use DirectX at all, imho. There is some directinnput stuff in the source code but it's not implemented. On Linux there is a sort of 'direct input' instead. (I use quotes because it's not direct input from DirectX of course, which is Microsoft)

I'm talking about compatibility. Quake uses OpenGL to render the graphics while DirectX is used to handle it in windows. The rendered stuff (i.e. graphics) need to be handled by the OS, which RtCW/ET was designed to be handled via DirectX on Windows OS - The game later became compatible on Apple after tweaking.

 

not necessarily.

 

cl_maxpackets tells the game to wait at least 1000/cl_maxpackets milliseconds before sending a packet

 

example: 125fps, 100 maxpackets

 

125fps means a frame every 1000/125=8 ms

100 maxpackets means 1000/100 = 10ms are needed at least between commands.

 

So the 1st command gets sent, the second command is after 8ms, which is lower than 10ms and has to wait. Next frame, 16ms will have passed so it's greater than 10 and both get sent. And the whole thing resets.

In this example, you will send 1 packet every other frame, i.e. around 62/sec.

This means that with 125fps you can't send more than 62 packets/second even if your maxpackets are higher than that.

 

Of course you can have fps lags, and your fps might not be 125 steady all the time, so setting 100 maxpackets is still useful. In order to send as many commands as possible and as quickly as possible, you have to play with 100 fps.

That millisecond difference occuring means that the game will have to interpolate or extrapolate at some point in time - this will eventually cause a lag spike. Like you said, because the clients FPS is set to much higher than the servers, this can cause problems which are affected by many variables raning from OS, to game settings, to internet settings.

 

yes, but you can't get more snaps than the ones the server creates per second (20). You can't tell the server to send you 40 if the server itself creates only 20 frames. At most you could get an useless duplicate.

Not sure if server running jaymod is set to 20 snaps - I thought it was 40. But, yes, the client is limited by how well the server can send and receive the information.

 

This is a good read about lagometer - http://wolfwiki.anime.net/index.php/Lagometer

 

 

P.S. @daredevil lagometer pics in spectator mode are useless because you will receive information only (The same happens when you face a corner) You really need to take a pic whilst in the action (i.e. you moving about when players are around you). Better yet, upload a video.

 

P.P.S. @S3ti a demo/video would be good right now

Edited May 16, 2013 by Death_Reincarnated

[daredevil]

So am I the only one facing this with 25+ players or does anyone else's lagometer look the same then? Would be nice to see some feedback or screens from other jay3 guys Connection settings for my router and PC like MTU are set on spot what for my isp is capable of, I don't get fragmented packets when pinging around in the web and such...

 

Pretty sure too it's no network/connection issue, ping is fine most of the time and the green line is ok, maybe some PC issue eventually (given I'm the only one or someone else doesn't get those yellow spikes)

 

U or anyone else having that fragmented packet issue or it's Engine/mod issue.

[Ann!b@l]

So am I the only one facing this with 25+ players or does anyone else's lagometer look the same then? Would be nice to see some feedback or screens from other jay3 guys Connection settings for my router and PC like MTU are set on spot what for my isp is capable of, I don't get fragmented packets when pinging around in the web and such...

 

Pretty sure too it's no network/connection issue, ping is fine most of the time and the green line is ok, maybe some PC issue eventually (given I'm the only one or someone else doesn't get those yellow spikes)

Will provide some screenshots

 

Did you do a ping test to check at which moment your packets start to be fragmented in the command line.. Since my packets start to be fragmented at only 1472 I have no issue to set my MTU at 1500 and my MSS at 1460..

 

My settings connection as feedback in case of needed:

-MTU: 1500

-MSS: 1460

-TTL: 128 (default: 64)

-TCP Window (RWIN): 2348032 (should be a multiple of MSS but mine is NOT) 

-RWIN Scaling: 8 bits (2^8=256) 

-Unscaled RWIN : 9172 

-BDP limit (200ms): 93921kbps (11740KBytes/s)

-BDP limit (500ms): 37569kbps (4696KBytes/s) 

-MTU Discovery: ON 

-Timestamps: OFF 

-SACKs: ON 

-IP ToS: 00000000 (0) 

-Selective Acknowledgements (RCF2018): ON

-TCP Window Auto-Tuning: normal

-Congestion Control Provider: ctcp

-TCP Chimney Offload: enabled

-Receive-Side Scaling State: enabled

-Direct Cache Access (DCA): enabled

-NetDMA (TCPA): enabled

-ECN Capibility: enabled

-Windows Scaling heuristics: disabled

-Checksum Offloading: enabled (0)

-Window Scaling: enabled

-Timestamps: disabled

-Network Throttling Index: disabled

-TCPNoDelay: enabled

-TcpAckFrequency: enabled

-TcpDelAckTicks: disabled

-MaxUserPort: 65534

-TcpTimedWaitDelay: 30

 

Speed Info

Windows Name: Windows 7 Ultimate SP1 (x64) Multiprocessor Free (8 procs) 

Maximum Raw Send Speed: 131545 bytes/s 

Maximum Acked Send Speed: 123899 bytes/s 

Maximum Receive Speed: 2348281 bytes/s 

Minimum Delay: 7 ms 

Delay Variance: 6 ms 

MSS Limit: 65535 (65495) bytes 

Averager Time: 10 s 

Total Raw Sent Volume: 1038 mbytes 

Total Acked Sent Volume: 58 mbytes 

Total Received Volume: 6657 mbytes 

Inhibit Bridged: No 

Maximum IP Length: 1500 bytes 

Current Send Speed: 138122 bytes/s 

Send Delay: 10-17 ms 

Receive Delay: 20-28 ms 

Traffic Shaping Status: shaping is active

Edited May 16, 2013 by Ann!b@l

[SunLight]

U or anyone else having that fragmented packet issue or it's Engine/mod issue.

I played several maps in a row in jay3, and I had almost no yellow. I tried rate 90000. Anyway I have to pass from several nodes to reach that server, so it's more than likely it's an occasional delay on the way to my pc, in one of those nodes.

 

in my router's gui I have mtu=1478 (which should be optimal for PPPoA/VC-MUX, with no extra padding for ATM)

 

the weird thing is that if I connect to it via ssh and I type ifconfig I have (for ppp0):

UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1 ASYMMTU:1500

at this point I wonder where that 1478 I set in the browser interface goes...

 

on my pc I have mtu 1492 for eth0

 

if I do: ping -M do -s 1464 178.63.72.170

that is the highest value that doesn't get fragmented. 1464+28 = 1492 which is my mtu.

At this point I suspect that the router's mtu is also 1492 as ifconfig says, and not as the web interface says?

 

Am I doing something wrong?

 

 

[ot mode: on]

 

 

 

Try pinging an ET servers and then actually going on it - The ping that you get when running 'ping' from cmd will be lower then when actually being on the server.

That's because ET scoreboard ping is calculated in another way, and it depends on your fps or maxpackets, for example. And some pings like 48, 98, 148, tend to appear often (probably because server frames are every 50ms). It's not the real ping. Now I forgot how exactly it was calculated, but I think it's from the timestamp in client commands and the server time.

 

I'm talking about compatibility. Quake uses OpenGL to render the graphics while DirectX is used to handle it in windows. The rendered stuff (i.e. graphics) need to be handled by the OS, which RtCW/ET was designed to be handled via DirectX on Windows OS - The game later became compatible on Apple after tweaking.

imho no, but it doesn't matter much. ET and RTCW both use Quake3 engine. Quake3 was never DirectX, and afaik it was made both for Win and Linux at the same time. There is even a rewrite of Quake3 with DirectX called DXQuake3. If Quake supported directx already, that guy wouldn't have wasted months to rewrite it *from scratch* using DirectX, changing all the code.

 

That millisecond difference occuring means that the game will have to interpolate or extrapolate at some point in time - this will eventually cause a lag spike.

The game interpolates/extrapolates all the time. It's not occasional. Blue is when it interpolates, yellow when it extrapolates. And I think there is also a thing that makes this time delta adjust over time slowly. That's probably the reason why once you have yellow, that yellow will last for a while before going back to blue.

 

This is a good read about lagometer - http://wolfwiki.anime.net/index.php/Lagometer

this is even better

 

https://github.com/id-Software/Enemy-Territory/blob/master/src/cgame/cg_draw.c

line 838 is for the upper part (yellow/blue) data

line 856 is for the bottom part data

line 927 is the function that actually draws both

 

edit:

p.s.

in free spectator mode you both send and receive, because you can move

 

 

[ot mode: off]

Edited May 16, 2013 by SunLight

[jaie]

Restart your router

[daredevil]

Restart your router

 

Linux router don't need restart

 

PS Sorry Sunlight can't help you much. I tried to set MTU on my Tomato firmware router and it works fine for me. So I will not be of any help in your router case.

[SunLight]

Linux router don't need restart

 

PS Sorry Sunlight can't help you much. I tried to set MTU on my Tomato firmware router and it works fine for me. So I will not be of any help in your router case.

I did from the command line:

 

# ip link set mtu 1478 ppp0

# ip link show ppp0

mtu 1478 qdisc prio qlen 100

 

and now with ping:

$ ping -M do -s 1464 178.63.72.170

it says "Frag needed and DF set (mtu = 1478)"

 

So now it works as expected. I guess the default web interface of that dlink router sux same with qos, opening ports and stuff I always prefer to use Linux commands from the console, because they work better. Maybe I could try one of those alternative firmwares...

 

thanks the same

[Death_Reincarnated]

@SunLight

 

1st quote - Yep it does depend on FPS/packets. Mainly higher packets as this means you will be chewing through more bandwidth. Pinging from cmd uses much less data than in a game. As long as the client-to-server (and vice-versa) can support the bandwidth then your ping should not fluctuate due to this, albeit, in general it does fluctuate. 

 

2nd quote - I was under the impression that ET was initially developed for WinOS and soon after compatibile for Mac. Sorry, I might have been wrong here lol.

 

3rd quote - Sorry, meant that it continuously swtiches between interpolation and extrapolation due to this difference,

 

4th quote - Indeed a nice find on Lagometer - however, I wanted to provide a simpler version

 

5th quote - From what I understand when you are in spec your movement is not registered to the server. You only receive all the other player movement - youre like a ghost. I could be incorrect but we had this discussion on our servers once ages ago. When I had issues with lag, whenever I went spec mode it went away, and the only reason you would still get lag in spec-mode was because of inadequate bandwidth.

 

I have a feeling it is a software related issue now. Your CPU is not strong enough and you are probably have many other applications on your PC. I would remove anti-virus software first (if you have any), update your GPU drivers, clean your registry, close all unwanted processes in the task manager, and generally clean up your PC lol. How much ram do you have? I hope its 8GB at least.

 

Like you said, your CPU is going bonkers - but what is strange is you get fps lag at higher player numbers only.

[SunLight]

Sorry for the long post, but just to clarify some things (both for you and others who could be interested):
 

1st quote - Yep it does depend on FPS/packets. Mainly higher packets as this means you will be chewing through more bandwidth. Pinging from cmd uses much less data than in a game.

It's not a matter of data size, it's just a different way to calculate pings, so obviously the result will be different as well.

* ping outside the game is made via ICMP ECHO, the game (client or server) isn't involved at all.

* ping in external server browsers is made sending an UDP message to the server (getstatus or getinfo), and the server answers (more or less) as soon as it receives it, then you can calculate the time between when you send, and when you receive the answer. This will be lower than your ingame ping too.

* pings in game are calculated in another way again (and there is probably also a difference between different 'pings', for example the one on the scoreboard, the one you see when you type /cl_shownet 3, the one in your lagometer...).

About the scoreboard one, it should be something like this:
- when the server sends a message to the client, it stores the time when it was sent.
- when the client sends a message, it also tells that he received that server message, so the server can compare the times (sent vs. acknowledged) when the client message arrives. And make an average of the last n ones. that is the ping.

Since a command is generated by the client each frame (and maxpackets can limit how much you send), and the server sends you messages only when a new server frame is ready (every 50ms), this ping will be obviously higher, because the server doesn't just answer at once, actually it's not even an 'answer'. And it will depend on the combination of the timings of server frames (1 every 50ms) and client commands (1 every frame, provided that maxpackets don't limit).

ping in lagometer or shownet is calculated in a different way.

To summarize, it's a *totally* different thing. It's not the same thing with different sizes, it's just another thing.
 

5th quote - From what I understand when you are in spec your movement is not registered to the server. You only receive all the other player movement - youre like a ghost.

A spectator in 'free camera' mode is just like any other player.
It sends and receives. In fact you can see your own lagometer and ping (not in every mod), and if you type /cl_showsend 1 you clearly see you are sending stuff.

Even when you watch another player you send stuff, not mouse movements of course. So you will upload roughly as much as a player who stays in spec without moving his mouse.
 

I have a feeling it is a software related issue now. Your CPU is not strong enough and you are probably have many other applications on your PC. I would remove anti-virus software first (if you have any), update your GPU drivers, clean your registry, close all unwanted processes in the task manager, and generally clean up your PC lol. How much ram do you have? I hope its 8GB at least.

Like you said, your CPU is going bonkers - but what is strange is you get fps lag at higher player numbers only.

I don't run other things when I play. I said I use Linux, so I have no registry (and no antivirus)

 

Openbox is a very light window manager (I don't use heavy stuff like Gnome or KDE), Arch Linux is a distro known for its speed (if there is such a thing as distro speed, but you have to install it from scratch, so there is nothing running that I don't want there, or I didn't install myself) and I have latest drivers from AMD for my GPU (I also disable compositing when I play).

I play on Windows only occasionally, but I don't get more fps or less fps than on Linux. Well, in servers with pb Windows is less stable when it comes to fps, but in servers with no pb or with TZAC it's more or less as smooth as Linux (when it's different, Linux is the smoother one).

(Btw, 8Gb is overkill to play ET in my opinion...)

My cpu is not fast enough, so when there are too much entities and other effects to draw (players, medipacks on the ground, bullet tracers and whatnot) obviously I get less fps, if compared to a situation where I have to draw only the map itself and few entities, even if my config is optimized for speed and not quality.

Keep in mind that even players you don't see count. The game just draws the walls in front of them, which is not faster for the cpu than drawing a visible player.

I don't think there is much to do for me, unless I overclock or change cpu.