3 People on same router. Super lag.

12
Comment below rating threshold, click here to show it.

Chaos Dunk

Junior Member

11-17-2010

I live in a house with a couple roomates and we all wanna play LoL at the same time (whether it be in the same game or not). However, if we all try to play at the same time we get some insane lag issues. Our regular internet speeds are fine from this one router. Is there something i should do with ports to fix this problem?


Some assistance please,
Thank you




EDIT: Two of us can play at same time just fine


Comment below rating threshold, click here to show it.

Tyaeth

This user has referred a friend to League of Legends, click for more information

Senior Member

11-17-2010

I would head over to http://netalyzr.icsi.berkeley.edu/ and run the test there to have it report a profile of your network and connection.

I'm not very well versed in router configuration and QoS settings, but having that report will save time for those who are able to assist you.

I did run into the exact same issue though around six months ago (the game worked with one or two people but never three), and it turned out that the uplink on my router (LinksysWRT120N) was inadequate and I ended up having to buy another router.


Comment below rating threshold, click here to show it.

Chaos Dunk

Junior Member

11-17-2010

Kk, here's what netalyzer gave me.

Herm, well, im not buying a new router just so we can all play LoL, haha



Quote:
Major Abnormalities
Your DNS resolver returns results even when no such server exists
Minor Aberrations
Certain TCP protocols are blocked in outbound traffic
Fragmented UDP traffic is blocked
None of the server's bandwidth measurement packets arrived at the client
The network blocks some or all EDNS replies
The NAT's DNS proxy doesn't fully implement the DNS standard
Address-based Tests +
NAT detection (?): NAT Detected
Local Network Interfaces (?): OK
DNS-based host information (?): OK
Reachability Tests –
TCP connectivity (?): Note
Direct TCP access to remote FTP servers (port 21) is allowed.
Direct TCP access to remote SSH servers (port 22) is allowed.
Direct TCP access to remote SMTP servers (port 25) is allowed.
Direct TCP access to remote DNS servers (port 53) is allowed.
Direct TCP access to remote HTTP servers (port 80) is allowed.
Direct TCP access to remote POP3 servers (port 110) is allowed.
Direct TCP access to remote RPC servers (port 135) is blocked.
This is probably for security reasons, as this protocol is generally not designed for use outside the local network.
Direct TCP access to remote NetBIOS servers (port 139) is blocked.
This is probably for security reasons, as this protocol is generally not designed for use outside the local network.
Direct TCP access to remote IMAP servers (port 143) is allowed.
Direct TCP access to remote SNMP servers (port 161) is allowed.
Direct TCP access to remote HTTPS servers (port 443) is allowed.
Direct TCP access to remote SMB servers (port 445) is blocked.
This is probably for security reasons, as this protocol is generally not designed for use outside the local network.
Direct TCP access to remote SMTP/SSL servers (port 465) is allowed.
Direct TCP access to remote secure IMAP servers (port 585) is allowed.
Direct TCP access to remote authenticated SMTP servers (port 587) is allowed.
Direct TCP access to remote IMAP/SSL servers (port 993) is allowed.
Direct TCP access to remote POP/SSL servers (port 995) is allowed.
Direct TCP access to remote OpenVPN servers (port 1194) is allowed.
Direct TCP access to remote PPTP Control servers (port 1723) is allowed.
Direct TCP access to remote SIP servers (port 5060) is allowed.
Direct TCP access to remote BitTorrent servers (port 6881) is allowed.
Direct TCP access to remote TOR servers (port 9001) is allowed.
UDP connectivity (?): Note
Basic UDP access is available.
The applet was able to send fragmented UDP traffic.
The applet was unable to receive fragmented UDP traffic. The most likely cause is an error in your network's firewall configuration or NAT.
The maximum packet successfully received was 1982 bytes of payload.
Direct UDP access to remote DNS servers (port 53) is allowed.
Direct UDP access to remote NTP servers (port 123) is allowed.
Direct UDP access to remote OpenVPN servers (port 1194) is allowed.
Direct UDP access to remote MSSQL servers (port 1434) is allowed.
Traceroute (?): OK
It takes 13 network hops for traffic to pass from our server to your system, as shown below. For each hop, the time it takes to traverse it is shown in parentheses.
10.248.108.2 (0 ms)
ec2-75-101-160-164.compute-1.amazonaws.com (0 ms)
216.182.232.64 (0 ms)
*
72.21.222.146 (1 ms)
72.21.220.186 (2 ms)
72.21.199.33 (1 ms)
xe-7-1-0.edge1.Washington1.Level3.net (1 ms)
COMCAST-IP.edge1.Washington1.Level3.net (67 ms)
te-2-1-ar01.staplesmllrd.va.richmond.comcast.net (73 ms)
te-1-1-ur01.boulevard.va.richmond.comcast.net (73 ms)
68.85.71.158 (68 ms)
*
Path MTU (?): OK
The path between your network and our system supports an MTU of at least 1500 bytes, and the path between our system and your network has an MTU of 1500 bytes.
Network Access Link Properties –
Network latency measurements (?): Latency: 45ms Loss: 0.0%
The round-trip time (RTT) between your computer and our server is 45 msec, which is good.
We recorded no packet loss between your system and our server.
TCP connection setup latency (?): 86ms
The time it takes your computer to set up a TCP connection with our server is 86 msec, which is good.
Network background health measurement (?): no transient outages
During most of Netalyzr's execution, the applet continuously measures the state of the network in the background, looking for short outages. During testing, the applet observed no such outages.
Network bandwidth measurements (?): Upload 2.0 Mbit/sec
Your Uplink: We measured your uplink's sending bandwidth at 2.0 Mbit/sec. This level of bandwidth works well for many users.
None of the bandwidth measurement packets sent between the server and client arrived at the client when testing the downlink, which prevented us from measuring the available bandwidth. One possible reason for this is dynamic filtering by access gateway devices. Another possibility is simply a transient error.
Network buffer measurements (?): Note
None of the buffer measurement packets sent by the server arrived at the client, which prevented us from measuring the available buffer size. One possible reason for this is dynamic filtering by access gateway devices.
HTTP Tests +
Address-based HTTP proxy detection (?): OK
Header-based HTTP proxy detection (?): OK
HTTP proxy detection via malformed requests (?): OK
Filetype-based filtering (?): OK
HTTP caching behavior (?): OK
JavaScript-based tests (?): OK
DNS Tests –
Restricted domain DNS lookup (?): OK
We can successfully look up a name which resolves to the same IP address as our webserver. This means we are able to conduct many of the tests on your DNS server.
Unrestricted domain DNS lookup (?): OK
We can successfully look up arbitrary names from within the Java applet. This means we are able to conduct all test on your DNS server.
Direct DNS support (?): OK
All tested DNS types were received OK
Direct EDNS support (?): Note
EDNS-enabled requests for small responses are answered successfully.
EDNS-enabled requests for medium-sized responses are answered successfully.
EDNS-enabled requests for large responses remain unanswered. This suggests that a proxy or firewall is unable to handle large extended DNS requests or fragmented UDP traffic.
DNS resolver address (?): OK
The IP address of your ISP's DNS Resolver is 68.87.73.244, which resolves to mana-nrcns02.manassaspr.va.dc02.comcast.net. Additional nameservers observed for your host: 68.87.73.243
DNS resolver properties (?): Lookup latency 120ms
Your ISP's DNS resolver requires 120 msec to conduct an external lookup. It takes 92 msec for your ISP's DNS resolver to lookup a name on our server.
Your resolver correctly uses TCP requests when necessary.
Your resolver is using QTYPE=A for default queries.
Your resolver is not automatically performing IPv6 queries.
Your DNS resolver does not use EDNS.
Your DNS resolver can successfully accept large responses.
Your resolver does not use 0x20 randomization, but will pass names in a case-sensitive manner.
Your NAT has a built-in DNS proxy. We sent it a DNS request and our server received it from 68.87.73.243.
Some or all specialized DNS types checked are not properly interpreted by the NAT's DNS proxy. The following tested queries were blocked/failed:
RTYPE=169 (deliberately unknown) records
Your ISP's DNS server can't use IPv6.
No transport problems were discovered which could affect the deployment of DNSSEC
DNS glue policy (?): OK
Your ISP's DNS resolver does not accept generic additional (glue) records — good.
Your ISP's DNS resolver does not accept additional (glue) records which correspond to nameservers.
Your ISP's DNS resolver does not follow CNAMEs.
DNS resolver port randomization (?): OK
Your ISP's DNS resolver properly randomizes its local port number.
The following graph shows DNS requests on the x-axis and the detected source ports on the y-axis.

DNS lookups of popular domains (?): OK
79 of 79 popular names were resolved successfully. Show all names.
13 popular names have a mild anomaly. The ownership suggested by the reverse name lookup does not match our understanding of the original name. The most likely cause is the site's use of a Content Delivery Network. Show all names.
One popular name has a mild anomaly: we are unable to find a reverse name associated with the IP address provided by your ISP's DNS server. This is most likely due to a slow responding DNS server or misconfiguration on the part of the domain owner. Show all names.
DNS external proxy (?): OK
Your host ignores external DNS requests.
DNS results wildcarding (?): Warning
Your ISP's DNS server returns IP addresses even for domain names which should not resolve. Instead of an error, the DNS server returns an address of 208.68.139.38, which does not resolve. You can inspect the resulting HTML content here.
There are several possible explanations for this behavior. The most likely cause is that the ISP is attempting to profit from customer's typos by presenting advertisements in response to bad requests, but it could also be due to an error or misconfiguration in the DNS server.
The big problem with this behavior is that it can potentially break any network application which relies on DNS properly returning an error when a name does not exist.
The following lists your DNS server's behavior in more detail.
www.{random}.com is mapped to 208.68.139.38.
www.{random}.org is mapped to 208.68.139.38.
fubar.{random}.com is correctly reported as an error.
www.yahoo.cmo [sic] is mapped to 208.68.139.38.
nxdomain.{random}.netalyzr.icsi.berkeley.edu is mapped to 208.68.139.38.
IPv6 Tests +
DNS support for IPv6 (?): OK
IPv6 Connectivity (?): Not Executed
IPv6 TCP connectivity (?): Not Executed
IPv6 and Your Web Browser (?): No IPv6 Support
IPv6 Path MTU (?): Not Executed
IPv6 Traceroute (?): Not Executed
Host Properties +
System clock accuracy (?): OK
Browser properties (?): OK
Uploaded Data (?): OK


Comment below rating threshold, click here to show it.

Chaos Dunk

Junior Member

11-18-2010

Helpful bump :\


Comment below rating threshold, click here to show it.

Eambo

This user has referred a friend to League of Legends, click for more information

Senior Member

11-18-2010

Is your router old? It could be one of three things I can think of:

- Insufficient bandwidth to handle three players
- If you have port forwarding, that could cause problems for other users
- If your router is old, it may not be able to handle multi-connections forwarding the same ports. If you have UPnP (Universal Plug'n'Play), enable it on the router.


Comment below rating threshold, click here to show it.

Polly

This user has referred a friend to League of Legends, click for more information

Senior Member

11-19-2010

I have a similar problem. My desktop is rarely used and is plugged in via ethernet to my router. Whenever I turn on the computer, not even running any programs, League of Legends and every other game will have insane latency on any wireless computer. I use speedtest on the Desktop and my laptop and I have perfect speeds, 20mb dl and 3mb ul on both, but all my games have huge latency on my Laptop while my Desktop is perfectly normal.

Any idea? :/


Comment below rating threshold, click here to show it.

Eambo

This user has referred a friend to League of Legends, click for more information

Senior Member

11-19-2010

AzN can you open a new thread for that one? Although similar, your issue isn't directly related, and we would need to work with you in your own thread :-)


Comment below rating threshold, click here to show it.

King Bear I

This user has referred a friend to League of Legends, click for more information

Junior Member

10-18-2011

I also cant have more then 3 ppl logged in to LoL in my house.

I did some comparisons myself. At my place I have a 15mbps-25mbps download connection with an upload of 1mbps and this problem is present in my house. Meanwhile at my friends house he has a 3mbps download connection and a 500kbps upload connection and the problem is no present there.

My guess is that there must be something wrong with the router, I have one of the new wireless linksys routers.

Any Ideas?


Comment below rating threshold, click here to show it.

FerrariCake

This user has referred a friend to League of Legends, click for more information

Junior Member

11-21-2011

I am having the same issue, so I'll post here unless I'm told to post elsewhere... 3 people can NOT be logged into LoL at the same time. I have an 8mb connection through Midcontinent Communications, My router is a Linksys Wireless-N Home Router WRT120N by Cisco®.

EDIT:

Quote:
Originally Posted by Tyaeth View Post
it turned out that the uplink on my router (LinksysWRT120N) was inadequate and I ended up having to buy another router.
Quote:
Originally Posted by Armageddor View Post
I have one of the new wireless linksys routers.


Netalyzer
Quote:
Summary of Noteworthy Events –
Major Abnormalities

Your DNS resolver returns IP addresses for names that do not exist

Minor Aberrations

Certain TCP protocols are blocked in outbound traffic
Fragmented UDP traffic is blocked
None of the server's bandwidth measurement packets arrived at the client
Your computer's clock is slightly slow

Address-based Tests +
NAT detection (?): NAT Detected
Local Network Interfaces (?): OK
DNS-based host information (?): OK
NAT support for Universal Plug and Play (UPnP) (?): Yes
Reachability Tests –
TCP connectivity (?): Note
Direct TCP access to remote FTP servers (port 21) is allowed.
Direct TCP access to remote SSH servers (port 22) is allowed.
Direct TCP access to remote SMTP servers (port 25) is allowed.
Direct TCP access to remote DNS servers (port 53) is allowed.
Direct TCP access to remote HTTP servers (port 80) is allowed.
Direct TCP access to remote POP3 servers (port 110) is allowed.

Direct TCP access to remote RPC servers (port 135) is blocked.

This is probably for security reasons, as this protocol is generally not designed for use outside the local network.

Direct TCP access to remote NetBIOS servers (port 139) is blocked.

This is probably for security reasons, as this protocol is generally not designed for use outside the local network.
Direct TCP access to remote IMAP servers (port 143) is allowed.
Direct TCP access to remote SNMP servers (port 161) is allowed.
Direct TCP access to remote HTTPS servers (port 443) is allowed.

Direct TCP access to remote SMB servers (port 445) is blocked.

This is probably for security reasons, as this protocol is generally not designed for use outside the local network.
Direct TCP access to remote SMTP/SSL servers (port 465) is allowed.
Direct TCP access to remote secure IMAP servers (port 585) is allowed.
Direct TCP access to remote authenticated SMTP servers (port 587) is allowed.
Direct TCP access to remote IMAP/SSL servers (port 993) is allowed.
Direct TCP access to remote POP/SSL servers (port 995) is allowed.
Direct TCP access to remote OpenVPN servers (port 1194) is allowed.
Direct TCP access to remote PPTP Control servers (port 1723) is allowed.
Direct TCP access to remote SIP servers (port 5060) is allowed.
Direct TCP access to remote BitTorrent servers (port 6881) is allowed.
Direct TCP access to remote TOR servers (port 9001) is allowed.
UDP connectivity (?): Note
Basic UDP access is available.

The applet was able to send fragmented UDP traffic.

The applet was unable to receive fragmented UDP traffic. The most likely cause is an error in your network's firewall configuration or NAT.
The maximum packet successfully received was 1925 bytes of payload.
Direct UDP access to remote DNS servers (port 53) is allowed.
Direct UDP access to remote NTP servers (port 123) is allowed.
Direct UDP access to remote NetBIOS NS servers (port 137) is blocked.
Direct UDP access to remote NetBIOS DGM servers (port 138) is blocked.
Direct UDP access to remote IKE key exchange servers (port 500) is allowed.
Direct UDP access to remote OpenVPN servers (port 1194) is allowed.
Direct UDP access to remote Slammer servers (port 1434) is allowed.
Direct UDP access to remote L2 tunneling servers (port 1701) is allowed.
Direct UDP access to remote IPSec NAT servers (port 4500) is allowed.
Direct UDP access to remote RTP servers (port 5004) is allowed.
Direct UDP access to remote RTCP servers (port 5005) is allowed.
Direct UDP access to remote SIP servers (port 5060) is allowed.
Direct UDP access to remote VoIP servers (port 7078) is allowed.
Direct UDP access to remote VoIP servers (port 7082) is allowed.
Direct UDP access to remote SCTP servers (port 9899) is allowed.
Direct UDP access to remote Steam gaming servers (port 27005) is allowed.
Direct UDP access to remote Steam gaming servers (port 27015) is allowed.
Traceroute (?): OK

It takes 13 network hops for traffic to pass from our server to your system, as shown below. For each hop, the time it takes to traverse it is shown in parentheses.

10.254.184.2 (0 ms)
ip-10-1-10-1.ec2.internal (0 ms)
ip-10-1-11-14.ec2.internal (0 ms)
216.182.224.74 (0 ms)
72.21.222.146 (1 ms)
72.21.220.140 (1 ms)
209.130.172.193 (2 ms)
ge4-1-0-10G.scr1.WDC2.gblx.net (2 ms)
te8-1-10M.ar5.CHI1.gblx.net (22 ms)
midcontinent-communications.tengigabitethernet7-1.ar7.chi1.gblx.net (38 ms)
host-1-6-220-24-static.midco.net (40 ms)
host-238-208-169-209.midco.net (58 ms)
*

Path MTU (?): OK
The path between your network and our system supports an MTU of at least 1500 bytes, and the path between our system and your network has an MTU of 1500 bytes.
Network Access Link Properties –
Network latency measurements (?): Latency: 48ms Loss: 0.0%
The round-trip time (RTT) between your computer and our server is 48 msec, which is good.
We recorded no packet loss between your system and our server.
TCP connection setup latency (?): 53ms
The time it takes your computer to set up a TCP connection with our server is 53 msec, which is good.
Network background health measurement (?): no transient outages
During most of Netalyzr's execution, the applet continuously measures the state of the network in the background, looking for short outages. During testing, the applet observed no such outages.
Network bandwidth measurements (?): Upload 1.0 Mbit/sec
Your Uplink: We measured your uplink's sending bandwidth at 1.0 Mbit/sec. This level of bandwidth works well for many users.
None of the bandwidth measurement packets sent between the server and client arrived at the client when testing the downlink, which prevented us from measuring the available bandwidth. One possible reason for this is dynamic filtering by access gateway devices. Another possibility is simply a transient error.
Network buffer measurements (?): Note
None of the buffer measurement packets sent by the server arrived at the client, which prevented us from measuring the available buffer size. One possible reason for this is dynamic filtering by access gateway devices.
HTTP Tests +
Address-based HTTP proxy detection (?): OK
Content-based HTTP proxy detection (?): OK
HTTP proxy detection via malformed requests (?): OK
Filetype-based filtering (?): OK
HTTP caching behavior (?): OK
JavaScript-based tests (?): OK
DNS Tests –
Restricted domain DNS lookup (?): OK
We can successfully look up a name which resolves to the same IP address as our webserver. This means we are able to conduct many of the tests on your DNS server.
Unrestricted domain DNS lookup (?): OK
We can successfully look up arbitrary names from within the Java applet. This means we are able to conduct all test on your DNS server.
Direct DNS support (?): OK
All tested DNS types were received OK.
Direct EDNS support (?): OK
EDNS-enabled requests for small responses are answered successfully.
EDNS-enabled requests for medium-sized responses are answered successfully.
EDNS-enabled requests for large responses are answered successfully.
DNS resolver address (?): OK
The IP address of your ISP's DNS Resolver is 24.220.0.10, which resolves to dns1.midco.net.
DNS resolver properties (?): Lookup latency 100ms
Your ISP's DNS resolver requires 100 msec to conduct an external lookup. It takes 83 msec for your ISP's DNS resolver to lookup a name on our server.
Your resolver correctly uses TCP requests when necessary.
Your resolver is using QTYPE=A for default queries.
Your resolver is not automatically performing IPv6 queries.
Your DNS resolver requests DNSSEC records.
Your DNS resolver advertises the ability to accept DNS packets of up to 8192 bytes.
Your DNS resolver can successfully receive a smaller (~1400 byte) DNS response.
Your DNS resolver can successfully receive a large (>1500 byte) DNS response.
Your DNS resolver can successfully accept large responses.
Your resolver does not use 0x20 randomization, but will pass names in a case-sensitive manner.
Your ISP's DNS server cannot use IPv6.
No transport problems were discovered which could affect the deployment of DNSSEC.
Direct probing of DNS resolvers (?)
Your system is configured to use 2 DNS resolver(s).
The resolver at 24.220.0.10 can process all tested types. It does not validate DNSSEC. It wildcards NXDOMAIN errors. Instead of an error it returns the following IP address(es): 184.106.31.189, 72.32.218.63. The resolver reports the following properties:

Hostname: xdr
Version: Version: main/12880

The resolver at 24.220.0.11 can process all tested types. It does not validate DNSSEC. It wildcards NXDOMAIN errors. Instead of an error it returns the following IP address(es): 184.106.31.189, 72.32.218.63. The resolver reports the following properties:

Hostname: xdr
Version: Version: main/12880

DNS glue policy (?): OK
Your ISP's DNS resolver does not accept generic additional (glue) records — good.
Your ISP's DNS resolver does not accept additional (glue) records which correspond to nameservers.
Your ISP's DNS resolver does not follow CNAMEs.
DNS resolver port randomization (?): OK
Your ISP's DNS resolver properly randomizes its local port number.

The following graph shows DNS requests on the x-axis and the detected source ports on the y-axis.

port sequence plot
DNS lookups of popular domains (?): OK
90 of 90 popular names were resolved successfully. Show all names.
16 popular names have a mild anomaly. The ownership suggested by the reverse name lookup does not match our understanding of the original name. The most likely cause is the site's use of a Content Delivery Network. Show all names.
One popular name has a mild anomaly: we are unable to find a reverse name associated with the IP address provided by your ISP's DNS server. This is most likely due to a slow responding DNS server or misconfiguration on the part of the domain owner. Show all names.
DNS external proxy (?): OK
Your host ignores external DNS requests.
DNS results wildcarding (?): Warning

Your ISP's DNS server returns IP addresses even for domain names which should not resolve. Instead of an error, the DNS server returns an address of 184.106.31.189, which does not resolve. You can inspect the resulting HTML content here.

There are several possible explanations for this behavior. The most likely cause is that the ISP is attempting to profit from customer's typos by presenting advertisements in response to bad requests, but it could also be due to an error or misconfiguration in the DNS server.

The big problem with this behavior is that it can potentially break any network application which relies on DNS properly returning an error when a name does not exist.

The following lists your DNS server's behavior in more detail.

www.{random}.com is mapped to 184.106.31.189.
www.{random}.org is mapped to 184.106.31.189.
fubar.{random}.com is correctly reported as an error.
www.yahoo.cmo [sic] is mapped to 184.106.31.189.
nxdomain.{random}.netalyzr.icsi.berkeley.edu is correctly reported as an error.

DNS-level redirection of specific sites (?): OK
Your ISP does not appear to be using DNS to redirect traffic for specific websites.
IPv6 Tests +
DNS support for IPv6 (?): OK
IPv4, IPv6, and your web browser (?): No IPv6 Support
IPv6 connectivity (?): No IPv6 Support
Host Properties –
System clock accuracy (?): Warning
Your computer's clock is 11 seconds slow.
Browser properties (?): OK
Your web browser sends the following parameters to all web sites you visit:

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0
Accept: text/html,application/xhtml+xml,application/xml; q=0.9,*/*; q=0.8
Accept Language: en-us,en;q=0.5
Accept Encoding: gzip, deflate
Accept Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Java identifies your operating system as Windows XP.
Uploaded data (?): OK
The applet uploaded the following additional content:

apache_404
custom_404
nxpage
plain_404
raw_http_content


Comment below rating threshold, click here to show it.

Dueliest

Senior Member

11-22-2011

I believe the issues is a max session cap on your router. Which simply translates into how much ram the router has for its routing tables. The game alone can use up to 7 sessions on its own. When you include other web applications like web browser, chat, email, voip. The max sessions on bottom end routers are easily exhausted. This is made worse with the more users on the same router.

Do a little research and try to find a router with around 200 session (connection) cap or more. This should give plenty of space for even a 5 man lan party.


12