Announcement

Collapse
No announcement yet.

Review of R2 Lag Detection Script

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

  • Review of R2 Lag Detection Script

    Recently I got access to script that R2 is using for lag detection, it contains only 4 information detections, let us review them:

    1) description of all interfaces

    I really do not know how it helps, especially if players sitting after NAT. The same holds for listed dead interfaces.


    2) routing table

    Again, how it helps. If I get to R2 servers, the interfaces and the routing table is correct.


    3) ping to portal

    How it helps, the game is served from other servers, especially in Europe. And the response times differs a lot.

    4) traceroute to portal

    Again how it helps especially as networks and firewalls mask the responses to '*' and game servers are different to portal?



    But it point out the area where the lag lays - game serving servers - and not the Flash game by 7road (nobody asks for endless memory consumption), JavaScript issues (in browser breaks, mini browser has it solved) and overloaded TCP/IP kernel (due to opening so many connections instead of reusing old, and heavy use of burst mode - check what is loaded of start of any sylph fight). First two can be detected from task list (memory and CPU usage respectively), the latter by listing active connections repeatedly during some period and I/O statistics.

    So I tried to ping to the game servers with the following results:
    (1) Normal run - standard response time (in my case 45 ms) in consecutive pings
    (2) Minor breaks - under heavy multiplayer load (entering arena, BG fight, going sylph mode in BG fight), it reduces speed (in my case over 900 ms or packet loss) for 1-2 pings (in reality starts 2 good pings, 1-2 bad pings repeatedly 4 times), in browser debug mode often followed by response times like 403/404 or 408/409 indicating that proxies cannot serve from application servers regularly.
    (3) Major breaks - appearing suddenly due to DNS round robin issue and shown as destination unreachable (but recovers).

    I've sent in past list of traffic from developer mode of browser (it indicates details like how long it takes to load parts of application, responses from the proxies with 404, retransmits etc.), I got this script as a response. This indicate a lot to me about ability to tune and solve the issue on CentOS based Xen virtualisation R2 uses.

  • #2
    Originally posted by P-J-J View Post
    Recently I got access to script that R2 is using for lag detection, it contains only 4 information detections, let us review them:

    1) description of all interfaces

    I really do not know how it helps, especially if players sitting after NAT. The same holds for listed dead interfaces.


    2) routing table

    Again, how it helps. If I get to R2 servers, the interfaces and the routing table is correct.


    3) ping to portal

    How it helps, the game is served from other servers, especially in Europe. And the response times differs a lot.

    4) traceroute to portal

    Again how it helps especially as networks and firewalls mask the responses to '*' and game servers are different to portal?



    But it point out the area where the lag lays - game serving servers - and not the Flash game by 7road (nobody asks for endless memory consumption), JavaScript issues (in browser breaks, mini browser has it solved) and overloaded TCP/IP kernel (due to opening so many connections instead of reusing old, and heavy use of burst mode - check what is loaded of start of any sylph fight). First two can be detected from task list (memory and CPU usage respectively), the latter by listing active connections repeatedly during some period and I/O statistics.

    So I tried to ping to the game servers with the following results:
    (1) Normal run - standard response time (in my case 45 ms) in consecutive pings
    (2) Minor breaks - under heavy multiplayer load (entering arena, BG fight, going sylph mode in BG fight), it reduces speed (in my case over 900 ms or packet loss) for 1-2 pings (in reality starts 2 good pings, 1-2 bad pings repeatedly 4 times), in browser debug mode often followed by response times like 403/404 or 408/409 indicating that proxies cannot serve from application servers regularly.
    (3) Major breaks - appearing suddenly due to DNS round robin issue and shown as destination unreachable (but recovers).

    I've sent in past list of traffic from developer mode of browser (it indicates details like how long it takes to load parts of application, responses from the proxies with 404, retransmits etc.), I got this script as a response. This indicate a lot to me about ability to tune and solve the issue on CentOS based Xen virtualisation R2 uses.
    hey thanks for taking the time to diagnose lag! unfortunately, i highly doubt they would care. some people had reported similar things before, and got either a formatted response or no response at all.

    i used to have a few good assistants who understand the tech stuff & report bugs with useful info like this. but not any more. they were gone in the august patch last year & the february patch this year. now i'm being left with no techies in guild & no one to tell me what to do when something breaks and/or glitches.

    Comment

    Working...
    X