Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

olcPGEX_network : Latency while using a very small network: two Computers and one Switch Fast Ethernet device #293

Open
JoaoBaldissera opened this issue Aug 3, 2022 · 2 comments

Comments

@JoaoBaldissera
Copy link

I have tested the basic server example with "olcPGEX_network.h" and the correspondent YouTube videos, in a local network. It is connected by a physical cable with two Windows OS computers (the 1st with Win11_x64 and the 2nd with Win7_x64) and one switch device.

The issue is that I have measured around 200-300 ms while "pinging" the client and the server by pressing the number '1' on the keyboard. For comparison, I also measured the Windows ping command and obtain around 1 ms.

Remark 1: This latency is also occurring for other messages than "ping".
Remark 2: This latency is not occurring while using LocalHost (127.0.0.1) - In that case, I have measured less than 1 ms.

@bXi
Copy link

bXi commented Aug 3, 2022

Not remotely related to this exact issue but I've been seeing a 300~ ms latency in an application of mine serving files to a web browser where I'm not expecting these kind of delays. Perhaps it is a problem inside WinSock?. That would be the only point of overlap for PGE and my application.

@jmscreation
Copy link

I would suggest checking to make sure you don't have any kind of constant socket IO directly within the PGE OnUserUpdate() method. Especially if you don't have vsync enabled. The reason for this is because PGE generally sits around 800 to 1000fps for any modern PC; therefore having constant writes inside the game loop will mean it will try to write 800 to 1000 TCP packets a second into the windows socket IO API. This is very inefficient and can cause the TCP buffers to get filled very quickly causing delays as such.

Otherwise, it may be related to something else. I figured I'd just mention this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants