Announcement

**R00k** · 07-06-2016, 07:02 AM

I have noticed setting maxfps > monitor refresh rate and beyond provide false ping reports. I have not seen negative numbers but 1ms at 1000fps.
Is it a Qrack bug, a Quake bug, a tcp/ip bug? i never got around to finding/fixing it.

Spike, MH, or Lord Havoc would have a better inside explanation.

**Izhido** · 07-06-2016, 07:23 AM

Originally posted by Mindf!3ldzX View Post

If the engine dev's would kindly chirp in with their knowledge of Q1 network protocol

Not sure that we could get Carmack to comment on that issue, though...

I know. I'll kick myself out of the room.

**Spike** · 07-06-2016, 10:16 AM

quake clients have a main loop that runs something like this:
while(1)
{
if (!timefornextframe()) continue;
collectinput();
executeconsolecommands();
sendinputtoserver();
checkforresponse();
renderstuff();waitforvsync();
}

as part of sending stuff to the server, the client echos a timer value received from the server.
so with the above arrangement, the client must wait a full frame before it can ack anything, resulting in higher displayed pings than otherwise necessary.

icmp pings are responded to by the host operating system (async).
udp pings are responded to by the server process (syncronised with the server's main loop, including its host_framerate or whatever the cvar is that limits nq servers to some packet interval.

also, some buggy clients are abusive enough to spam the server with a new input frame EVERY SINGLE SECOND, which can even result in 0ms pings when the client is running above 1k fps (assuming the server isn't completely idle between frames in some lame way).
nq servers have no use for more than one input packet per server frame, but it *may* still be useful to lower pings thanks to additional packets being more likely to arrive closer to when the server actually uses the most recent.
if the client and server are both properly running at the same framerate.
connect to an fte server and check the server's status command. it'll tell you exactly how many packets the server is receiving/sending per second
qw clients tend to be kicked if they send more than 72 packets per second (mostly because this can result in people jumping further due to qw physics being framerate dependant).

unlike qw, with nq there is no real way to verify the pings from clients, so cheaty nq clients can completely spoof their pings, negative pings or excessive pings is just an addition/subtraction away.

you should normally expect your ping to be rounded up to 1/cl_netfps. if you're unlucky then it might fluctuate for two frames.

actual latency is much more complex than just the networking aspect, of course.
the user's mouse (especially wireless ones) will have a difference (USB has a fixed polling interval). the user may have interpolation enabled, so it takes a network frame for each entity to catch up with the server, or network drifting to cover packetloss/stalls, which can make stuff more laggy. the graphics card may be tripple buffering with the current scene not displayed until the vsync after the next. then there's lcd latencies (both response and total latency). and of course there's the user's reaction times too.
all of these things might change your actual latency and none will be visible to the server/scoreboard

the qw protocol rewrite thing was intended to reduce pings significantly, however in some ways, all that extra latency can actually be a good thing for balancing the game. by ensuring everyone has extra latency, you reduce the effectiveness of low-ping-bastards, and the result is slightly fairer.

so yeah, expect different pings, depending on different clients AND servers, etc.

**Mindf!3ldzX** · 07-06-2016, 08:30 PM

Why does QW rockets operate on a delay, I participated in the first round of QW Duel Mania and I couldn't peek fire over ledges & fire precisely as I normally would in NQ.

I ate so much fn splash damage from my peekaboo shots being way behind when I applied my play in the NQ servers, it was horrible I was my own worst enemy but it was because I when I clicked fire and began my backpedal to cover the shot was not registering immediately on clicking attack it was hanging out behind my backpedal input.

It doesn't matter what mod in nq I play, I experience near identical timings on when to fire and move around. QW was an alien flow of attack and movements and I was out of sync horribly. I bowed out of the tournament because it was alien to me, my attacking and moving for some reason differed extremely.

I use 500fps because its smooth, but my client has a capped network rate or something I requested it because I wanted to use thousands of fps without flooding my connection into an icon jack.

So I'm not experiencing any ping voodoo, but my last foray into QW was abysmal.

**R00k** · 07-07-2016, 08:22 AM

Why does QW rockets operate on a delay, I participated in the first round of QW Duel Mania and I couldn't peek fire over ledges & fire precisely as I normally would in NQ.

I think we are playing QW in the wrong area. WE usually use it to play on EU servers.
The thing is with QW, unfortunately, is that the +attack button still has lag; with netQuake having both movement and shots lagged.
So to Us, QW feels disjointed, unnatural.

if u play QW on a local regional server, the only complaint is physics differences.

**Spike** · 07-07-2016, 08:40 AM

quakeworld's player prediction moves your view around with effectively 0 ping, so that part feels fast, but if you're playing from the other side of the atlantic then your ping will be still be unplayable.
many qw servers have an antilag feature enabled, which is supposed to leave you on an equal footing regardless of ping, at least for the lightning gun+shotguns (this is the true benefit of modern shooters boringly having only instant-hit weapons for everything - yay 50 different types of rifle!).
but yeah, rockets, grenades, and nails will feel laggy compared to movement, which might feel quite weird at first. try cl_nopred 1 if you hate that feel so much.
(iiuc, q3 predicts these too)
alternatively, just try a server where you get 26ms ping instead of 260ms...

**killingtime187** · 07-08-2016, 05:18 PM

From just a pure udp latency POV, how can we test this ? I wrote the following program that sends the server info request, reads the response, then time the round-trip. I figure this would be approximately what our latency is to a server. ICMP/pings give much much lower values than this program. Here is the program:

/*
By: KT, 7/6/2016
For: Steve, Kimp, Dave - the ping pros
*/

#include <stdio.h>
#include <winsock.h>
#include <time.h>

// require windows socket library
#pragma comment(lib, "ws2_32.lib")

void main(int argc, char** argv)
{
// qping is always first argument, so must have host and port to continue
if (argc < 3)
{
printf("Usage: qping <host> <port> [number of requests]\n");
exit(-1);
}

// how many requests/pings to send
int numRequests = 10; // 10 by default
if (argc == 4)
{
numRequests = atoi(argv[3]);
}

// see server info request here - Unofficial Quake Network Protocol Specs v1.01b
char sInfo[] = {0x80, 0x00, 0x00, 0x0C, 0x02, 'Q', 'U', 'A', 'K', 'E', '\0', 0x03};

// initialize windows socket library
WSADATA wsaData;
if (WSAStartup(MAKEWORD(2, 2), &wsaData) != 0) {
printf("Failed to start Winsock!\n");
exit(-1);
}

// local address setup
struct sockaddr_in localAddr;
localAddr.sin_family = AF_INET;
localAddr.sin_port = 0; // bind to any available local port
localAddr.sin_addr.s_addr = INADDR_ANY; // any local interface

// create our udp socket
int sock = socket(AF_INET, SOCK_DGRAM, 0);
bind(sock, (struct sockaddr*) &localAddr, sizeof(struct sockaddr));

// lookup destination address
struct hostent* hostEnt = NULL;
if ((hostEnt = gethostbyname(argv[1])) == NULL)
{
printf("Unknown host: %s\n", argv[1]);
closesocket(sock);
WSACleanup();
exit(-1);
}

// destination address setup
struct sockaddr_in destAddr;
destAddr.sin_family = AF_INET;
destAddr.sin_port = htons(atoi(argv[2]));
destAddr.sin_addr = *((struct in_addr*) hostEnt->h_addr);

// set by server in response, we ignore
struct sockaddr_in srcAddr;
int srcAddrLen = sizeof(srcAddr);

// send requests, print times
int totalTime = 0;
clock_t start, end;
char sData[256]; // to hold server response, which we ignore
for (int i = 0; i < numRequests; i++)
{
// send request for server info
sendto(sock, sInfo, 12, 0, (struct sockaddr*) &destAddr, sizeof(destAddr));
start = clock();
// read response
recvfrom(sock, sData, 256, 0, (struct sockaddr*) &srcAddr, &srcAddrLen);
end = clock();
// get duration and print out
int duration = end - start;
totalTime += duration;
printf("Response Time: %d\n", duration);
}
// print avg time
printf("Average Response Time: %d", totalTime / numRequests);

// shutdown winsock and exit
closesocket(sock);
WSACleanup();
}

Pre-built binary + source is here https://drive.google.com/open?id=0B-...Ho0aWtSQkpqdmM

**R00k** · 07-08-2016, 09:29 PM

and to think the ELITE players, we all hold dear to skill and heart, who played this game >80ms ping.... to all those stats pffft.

**Dutch** · 08-07-2016, 01:56 AM

This is all pretty foreign to me, so excuse the uneducated question about to follow. I've read through this thread (and other similar ones) several times. What I'm gathering is latency != ping, and ping is not the end all be all of lag.

However, I hopped on dmtx today and got my ass kicked, mostly in part to lack of skill, but the 110 ping wasn't helping. I'm using the latest ProQuake with vsynch off. Aside from adjusting maxfps to 72, is there anything else you elite guys would recommend? Texas ain't all that far from me, considering I was getting a lower ping on the recent new york QW server for pcgamer's server for quake's 20th (which is a lot further away).

EDIT: I'm not the MP veteran you guys are, but back in the day when Quake had a hoppin' community, I just joined the closest servers and called it good. now I'm in a position where I NEED to make adjustments.

EDIT2: I understand QW and NQ are apples and oranges, so maybe this has something to do with it?

Announcement

Quake1, latency, >60fps ping lowering discussion.

Quake1, latency, >60fps ping lowering discussion.

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment