Announcement

Collapse
No announcement yet.

Quake1, latency, >60fps ping lowering discussion.

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Quake1, latency, >60fps ping lowering discussion.

    Today was having a discussion in GroupMe , more or less a debate.





    Avatar
    sschm
    How can he keep up with K0ng when k0ng has typically -35 ms
    and since hardware means little with Quake1, a game created 20 years ago
    I'm on my laptop and just loving how I could game with it, especially in Q1

    Avatar
    [��]mindzx
    negative 35ms? Seems like a law is being violated, and I don't mean "SSCHM's Law of thou must not ping too low"
    Avatar
    sschm
    I had 85hz, but even with the 144hz hack, their advantage was not enough for me to cry over, although I know it makes a slight difference
    negative 35ms from Bruce's ping of 50
    So normally, if you had 35 to 50, you get 85ms, and that is quite a disadvantage that anyone with 50ms would know about
    if I was playing some guy with 85ms and I had 50ms, i would realize things aren't fair
    add* 35 to 50
    the problem with this realization comes from the k0ngs who claim their 15ms is not an advantage over 50ms, because once you hit 50ms, you are good
    it is stupidity and a means to feel good about yourself playing with a ping well below that of your opponents

    Avatar
    [��]mindzx
    I dont know how many times r00k has to explain that the ping reporting is incorrect for Quake when fps goes above 60/72 fps....
    Quake can't magically lower the network latency between hops 2 through whatever.

    Avatar
    sschm
    R00k is incorrect, because I ping higher than I really do to a server when my max_fps is set to 72
    They use two different protocols: UDP and ICMP

    Avatar
    [��]mindzx
    You're missing the entire point. Nothing Quake does can adjust the RESPONSE TIMES for the hops on any given route.

    Avatar
    sschm
    you check your ping with ICMP packets that are typically about 40bytes
    Even if you have a lot of routes in your traceroute, so long as those routes are low-latency, your ping to the server will be low. With each new route, there is a chance for added latency based upon that node and how stable it is. In old times, these routes were not as stable as they could be, but developments of high speed internet increased much further since 1996, when at that time most people had dialup
    I did a packet capture of UDP packets and they were not much larger per packet than the standard size of about 40 for ICMP
    7:00 PM

    Avatar
    sschm
    I am 59-65ms with the suggested fps @ 72 at crmod, but 50-56 @ 120. Pings would often show the same at crmod for most players, but then the accusations came in that these pings were not real but based on FPS... but I get even more ping than what my ICMP packet reports suggest
    i mean at dmtx*

    Avatar
    [��]mindzx
    I expanded this discussion to actual engine dev's, I am gonna point Spike in that posts direction.
    Avatar
    sschm
    so we had these guys that had equal showing pings in game claiming that the pings are not accurate

    ---------------

    If the engine dev's would kindly chirp in with their knowledge of Q1 network protocol, and the more fps = lower ping ??

    It is my opinion (because I have nothing technical to back it up,aside from what I would dub as common sense) that you can't ping lower than any given hops maximum ping/latency route to a server, acknowledging that network load can be higher or lower and some fluxuation can occur, but for the most part, routing dictates latency to a Q1 server, and any benefits from using 500fps vs a standard Vysnc 60fps can't be taken at face value.
    Last edited by Mindf!3ldzX; 07-05-2016, 05:06 PM.
    Want to get into playing Quake again? Click here for the Multiplayer-Startup kit! laissez bon temps rouler!


  • #2
    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.
    www.quakeone.com/qrack | www.quakeone.com/cax| http://en.twitch.tv/sputnikutah

    Comment


    • #3
      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.

      Comment


      • #4
        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.
        Some Game Thing

        Comment


        • #5
          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.
          Want to get into playing Quake again? Click here for the Multiplayer-Startup kit! laissez bon temps rouler!

          Comment


          • #6
            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.
            Last edited by R00k; 07-07-2016, 08:31 AM.
            www.quakeone.com/qrack | www.quakeone.com/cax| http://en.twitch.tv/sputnikutah

            Comment


            • #7
              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...
              Some Game Thing

              Comment


              • #8
                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

                Comment


                • #9
                  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.
                  www.quakeone.com/qrack | www.quakeone.com/cax| http://en.twitch.tv/sputnikutah

                  Comment


                  • #10
                    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?
                    'Replacement Player Models' Project

                    Comment

                    Working...
                    X