Upcoming Events

Collapse

There are no results that meet this criteria.

Announcement

Collapse
No announcement yet.

A solution to lag -- we need your help!

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

  • #16
    Omg. I cant understand a thing you guys r saying *Blush*

    Comment


    • #17
      Which bit Steak?
      Calini Anna'Des - Resentful of the Law's values and troubled with her Past.

      "The life of the creative person is lead, directed and controlled by boredom. Avoiding boredom is one of our most important purposes." - Saul Steinberg

      "Opportunity is missed by most people because it comes dressed in overalls and looks like work" - Thomas Edison

      Comment


      • #18
        Originally posted by Lallendos
        I noted the following:

        5 minute input rate 33000 bits/sec, 57 packets/sec
        5 minute output rate 69000 bits/sec, 62 packets/sec

        That output is from my network to the world. The following is the server's reading:

        5 minute input rate 74000 bits/sec, 69 packets/sec
        5 minute output rate 34000 bits/sec, 65 packets/sec
        You basically reverse it, as the server's outbound info is seen as the input rate to the port. Considering I am remote desktopped to the server, this makes sense. The oddity here, is that we have over 66Kilobits going out to the internet for server play.

        The complete interface poll is as follows:

        2916-XL-EN#sh int f 0/5
        FastEthernet0/5 is up, line protocol is up
        Hardware is Fast Ethernet, address is 0010.14d3.6c85 (bia 0010.14d3.6c85)
        Description: WAN link
        MTU 1500 bytes, BW 1000 Kbit, DLY 10 usec, rely 255/255, load 23/255
        Encapsulation ARPA, loopback not set, keepalive not set
        Full-duplex, 100Mb/s, 100BaseTX/FX
        ARP type: ARPA, ARP Timeout 04:00:00
        Last input never, output 00:00:01, output hang never
        Last clearing of "show interface" counters never
        Input queue: 0/75/0 (size/max/drops); Total output drops: 0
        Queueing strategy: weighted fair
        Output queue: 0/64/0 (size/threshold/drops)
        Conversations 0/1 (active/max active)
        Reserved Conversations 0/0 (allocated/max allocated)
        5 minute input rate 50000 bits/sec, 79 packets/sec
        5 minute output rate 93000 bits/sec, 85 packets/sec
        119237249 packets input, 272311216 bytes, 0 no buffer
        Received 115608 broadcasts, 0 runts, 0 giants, 0 throttles
        0 input errors, 0 CRC, 0 frame, 0 overrun, 277 ignored, 0 abort
        0 watchdog, 0 multicast
        0 input packets with dribble condition detected
        111239912 packets output, 1381950805 bytes, 0 underruns
        0 output errors, 0 collisions, 1 interface resets
        0 babbles, 0 late collision, 0 deferred
        0 lost carrier, 0 no carrier
        0 output buffer failures, 0 output buffers swapped out


        2916-XL-EN#sh int f 0/16
        FastEthernet0/16 is up, line protocol is up
        Hardware is Fast Ethernet, address is 0010.14d3.6c90 (bia 0010.14d3.6c90)
        Description: Proliant Srvr WAN link-vital data
        MTU 1500 bytes, BW 100000 Kbit, DLY 10 usec, rely 255/255, load 1/255
        Encapsulation ARPA, loopback not set, keepalive not set
        Full-duplex, 100Mb/s, 100BaseTX/FX
        ARP type: ARPA, ARP Timeout 04:00:00
        Last input never, output 00:00:00, output hang never
        Last clearing of "show interface" counters never
        Input queue: 0/75/0 (size/max/drops); Total output drops: 0
        Queueing strategy: weighted fair
        Output queue: 0/64/0 (size/threshold/drops)
        Conversations 0/1 (active/max active)
        Reserved Conversations 0/0 (allocated/max allocated)
        5 minute input rate 74000 bits/sec, 69 packets/sec
        5 minute output rate 34000 bits/sec, 65 packets/sec
        184390534 packets input, 4053144693 bytes, 0 no buffer
        Received 8075 broadcasts, 0 runts, 0 giants, 0 throttles
        0 input errors, 0 CRC, 0 frame, 0 overrun, 214 ignored, 0 abort
        0 watchdog, 662 multicast
        0 input packets with dribble condition detected
        124293997 packets output, 4128903649 bytes, 0 underruns
        0 output errors, 0 collisions, 1 interface resets
        0 babbles, 0 late collision, 0 deferred
        0 lost carrier, 0 no carrier
        0 output buffer failures, 0 output buffers swapped out
        2916-XL-EN#

        The only things I can can blame is 1 external remote desktop session, and Team Speak.
        No one but me is normally RD, so I pray that moving to a ventrillo/Team Speak server on the test server is solving the problem.

        We are using over 60% of the available bandwidth with 15 people on. That is ridiculous.At present, the only way to ensure > 48 players is to move to a 2 megabit or greater upstream capacity. This is not financially feasible, at this time.
        O_o. That bit. I rarely get what lallendos says anyways.

        Comment


        • #19
          Ouro, trust me, if I could recode the client and server, I'd definitely use a similar method to World of Warcraft's prediction scheme. Sure, some people like to movement hack, but banning them is no problem.

          I can assure you NWN2 does not use anything remotely close to that. When you hold down WASD keys, it's essentially sending movement commands to the server with short destination points. In other words, holding down the button you flood the server with however many packets are send over the elapsed time. NWN2 Also doesn't have prediction, the client is up to the will of the server, that means the server is replying with essentially an "Echo" of what you sent, then it's multiplied by players within range of movement messages, so 60 movement packets with 10 people around you just became 720 (60 to move, 60 replies, 600 broadcasts to other players). Imagine two people doing this at once?

          I imagine NWN1 at least used deltas on their movement, looking only for changes in direction and speed to be sent to the server. Essentially what you proposed in your implementation. Like I said, however, we have no ability to change the network layer of NWN2 or I would have. And thanks to gamespy we'd be in hot water if we made a server emulator (I was thinking about it).

          Comment


          • #20
            stupid gamespy

            Comment


            • #21
              OMG glad I read this, sorry guys I was using arrow keys last night only on for a shoirt time.

              It wont happen again, I had no IDEA that it would cause lag.

              Not that I know much about game code etc, but in todays modern era, why would it not be written to provide the best Multi play game possible?

              Seems very strange.

              Onec again sorry to all if I interfeared with your game.

              Comment


              • #22
                Ugh. From what i know of NWN2, as strong as it's Multiplayer base is, it seems to still be primarily a Single-Player optimized system. From my fiddeling, it almost seems that in Single Player mode, it effectively emulates a server within itself. I've had it Lag on myself, hows that eh? I'd be running and all of a sudden i'd stop and about 3 seconds later i would suddenly appear where i clicked. Looks like Lag to me. They seem to have used a method to simplify the Multiplayer element. The client element seems to NEED to get all of it's data from the server unlike other systems that would synchronise instead. It seems like a dodgey way to program by putting all of the responsibility on the server. Sure, it ensures data integrity and help prevent Player-Biased bugs and helps centralize the control of the entire system, but it's obvious that the design was a "Quickly Done" one. It's the easiest to use when you think about it. If you worked to Synchronize a Big chunk of memory of the world that the client was presented with, you would have to throw in a bucket load of backround protocols to update this mysterious data source and have the data source continue on it's own path until the Server updated it with new data. By what you say, it currently relies entirely on the Server. By the sounds of it, people using the WSAD keys would be bunny-hopping accross the screen for everyone. Ugh.

                By the sounds of it, if that's the case, don't expect Bioware / Atari to be recoding it anytime soon. It sounds like that is entirely what the engine has been built upon and would almost be like building a new game ground up. I don't think when they put it together, the thought of it expanding much further than a small community based multilpayer environment.
                Calini Anna'Des - Resentful of the Law's values and troubled with her Past.

                "The life of the creative person is lead, directed and controlled by boredom. Avoiding boredom is one of our most important purposes." - Saul Steinberg

                "Opportunity is missed by most people because it comes dressed in overalls and looks like work" - Thomas Edison

                Comment


                • #23
                  But I still don't get it why they didn't use some of the ol' nwn1 in the new game, since that game could actually handle alot of players at the same time, doing lots o' things.
                  I have a +1 question brewing in this skull somewhere...


                  www.myspace.com/riotsweden

                  Comment


                  • #24
                    They probably did use alot of it. With change of input methods, maps, scripting, AI, and more, it's kind of hard to say "Just use the NWN1 mechanisms". Sure, WASD worked in NWN1, but NWN1 didn't handle walk meshes like NWN2 handles and such.

                    Comment


                    • #25
                      In fact, NWN1 online was very laggy and broken initially also. Add to that the updates usually created some problems that needed to be fixed to optimize play. NWN1 was great and fun, but it had its problems also, IMO.

                      Comment


                      • #26
                        Yeah, people were unhappy with NWN1 for a LOOOONG time. I Remember waiting for patches to fix so much. We didn't get SetName until, what, months before NWN2's release? Now we are all over it.

                        Comment


                        • #27
                          yeah NWN1 had some major issues, I remember bein on quests with 6 people and then a lag storm would roll in for 5 minutes and we'd wake up dead. So nwn2 isnt such a far cry from its predecessor

                          Comment


                          • #28
                            Just wondering, how come this is just recently effecting the game play? When we first started on Sundren I used WASD keys all the time and I'm sure many others did, when it was down and GBX had the server being turned into a different world I used it then too and didn't really notice any lag like we been having... So how come its suddenly affecting us instead of being with us the entire time if its part of the code?

                            Comment


                            • #29
                              Could be that other patches have slowly been adding to the processor load instead of decreasing it (i.e. New features)? Maybe as the world gets large, the strain has been gaining somewhat exponentially? Have the number of people logging it at any time increased above the usual amount? Could very well be an area in the original coding build that wasn't foreseen and the CPU load for the Server Program was properly analysed on a "Realistic Machine". Who knows, it's a real floating question by the sounds of it.

                              If it's is all the codings fault, it's what we call in Application Development "Failure to do a Proper, c omplete and Detailed Impact Analysis of ALL elements". The inherit fault is that this kind of analysis is rarely done in Off-The-shelf software. They often just assume they con go right ahead as they only need to pull resources from other computer resources (i.e. NWN2 uses the Graphics Component, rather than the Graphics Component pulling info from it). Obviously the impact of lengthy / inefficient algorithms and failure to terminate loops that have gone beyond their bounds will waste valuable CPU time.

                              Ugh. But it is a good point, it does seem unusual that the problem would develop now.
                              Calini Anna'Des - Resentful of the Law's values and troubled with her Past.

                              "The life of the creative person is lead, directed and controlled by boredom. Avoiding boredom is one of our most important purposes." - Saul Steinberg

                              "Opportunity is missed by most people because it comes dressed in overalls and looks like work" - Thomas Edison

                              Comment


                              • #30
                                This is poor analysis to say "I used WASD before and it didn't lag." The server used to lag all the time when I hosted it, I've had to unplug the network cable many times due to lag/latency issues. It's always been having issues. WASD keys also became more widely used after they made a fix to them due to that turn rate issue they had in 1.01. People used them less because it was hard to aim. The more people who used them the more lag probably grew.

                                I've notice the lag has gotten ALOT better, and I mean ALOT. So I think it's safe to say WASD keys contributed the most to the lag. As people have now moved away from them for the most parts, things have been much more instantaneous.

                                We just have to keep people informed and try to remind others not to use them until fixes are made.

                                As for CPU utilization, the CPU is going to be maxed out due to the processing methods of NWN2 server. It uses a poor design for process timing and such due to the D&D engine, not because the programmers just wanted to. Even NWN1 server used more CPU than it really needed to, and it only gets worse for 2 because 2 does more in essence.

                                OBsidian will be messing with this crud in the next couple months and getting it straight. After expansion, server stability is at the TOP of the TODO list. Rob assured us of that. So we just have to suffer a little longer.

                                Comment

                                Working...
                                X