Increasing Frequency of Packet Loss

Has anyone else been experiencing packet loss more frequently in the last month? I've noticed it a few times when streaming shows or Twitch and lately it's been pretty severe when playing League of Legends.

What state are you located in? Twitch in general has been having tons of issues that they aren't owning up to. I've had a ticket open with them for a month now showing that there is a ton of issues on their end.
However, I have been having issues with packet loss in other games. Mainly with routing through the main Los Angelas Data Center. This started a month ago for me as well. I used to get a latency of 20-30 through the LA Hub. Now it spikes anywhere from 200-300ms after a certain time of day (usually 6:00PM PST). Using ping plotter, I can clearly see that the LA hub is causing most of my issues and later down the route I'm getting 10-20% packet loss in 2 other hubs before I reach the data centers for the game I'm playing.
As a gamer, you'd know the difference between 20ms and 250ms, which is what I feel after 6pm pst. Verizon Support has not owned up that it is their issue so far and the support I've reached out to from the gaming companies can clearly point out that the issue is with the Verizon data center at different hops.
I'm getting annoyed with this and it hasn't been fixed for well over a month.

Similar Messages

Why Packet loss increases

Hi,
I implemented a QoS for VoIP purposes and I used ip sla measurements for jitter to observe the changes of jitter and packet loss.
From comparison I have that a jitter is decreased but the packet loss is increased getting worse the MOS and the ICPIF. Why?
I applied the CBWFQ & LLQ on output WAN subinterfaces (ATM).
thanks
Paolo

Try this link for troubleshooting jitter issues
http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a00800945df.shtml

Increased Packet Loss...

I've had a number of complaints from the kids in May about games have frequent issues, and I've experienced some odd issues off and on as well. When I got the May report from SamKnows, I noticed that packet loss since early May has been unacceptably high with more than 10 days during the month of packet loss in excess of 2.5% (as high as 6.5%), and the first few days in June are looking just as bad (all above 2.5%). This would definitely be the root cause of the kids problems with the games as well as the issues I've observed. Generally, 2.5% to 5% is considered poor network performance and 5% to 12% is very poor network performance, so this is not really acceptable.
I verified with older SamKnows reports that prior months didn't have these issues (maybe once or twice a month, but most months didn't have notable packet loss days at all).
Anybody have any ideas as to what is going on? Does Verizon Tech Support look at this boards and investigate issues like this, or do I need to call them?

I will try digging deeper, but for it to suddenly get worse like that at such a consistent level at this point is almost certainly not the internet in general.

EEM- Email alert with IP SLA Based on Packet Loss

hi joseph,
i need your advise, i want to get alert email based on IP SLA Packet loss
the scenarion as below :
1. If the traffic hit threshold packet loss greater than 20% as long 15 minutes --> send email
2. If reset condition packet loss eq 0% as long 15 minutes --> send email again
I don't know how to configure it condition. could you help me to verify my configuration below?
ip sla logging traps
ip sla 1
icmp-jitter 10.216.0.105 source-ip 10.216.0.107 num-packets 100 interval 40
frequency 50
ip sla schedule 1 life forever start-time now
ip sla reaction-configuration 1 react Packetloss threshold-value 3 1 threshold-type immediate action-type trapOnly
ip sla enable reaction-alerts
event manager applet TEST
event syslog pattern "IP SLAs$1$: Threshold exceeded"
action 2.0 mail server "10.240.0.10" to "[email protected]" from "[email protected]" subject "Alert for Intermittent Link" body "link intermittent in x %"
thank you

What's you have could work with a few modifications. First, increase that threshold-value of 3 to 20. You can leave the falling threshold value of 1. You'll need to add another applet to match the falling threshold syslog message. Not sure exactly what that one will look like.
The first applet will look like this:
event manager environment q "
event manager applet ipsla-threshold-exceeded
event syslog pattern "IP SLAs$1$: Threshold exceeded"
action 001 cli command "enable"
action 002 cli command "config t"
action 003 cli command "no event manager applet ipsla-healthy"
action 004 cli command "event manager applet ipsla-unhealthy"
action 005 cli command "event timer countdown time 900"
action 006 cli command "action 1.0 mail server $q 10.240.0.10$q to $q [email protected]$q from $q [email protected]$q subject $q Alert for Intermittent Link$q body $q link intermittent in 20 %$q"
action 007 cli command "action 2.0 cli command enable"
action 008 cli command "action 3.0 cli command $q config t$q"
action 009 cli command "action 4.0 cli command $q no event manager applet ipsla-unhealthy$q"
action 010 cli command "action 5.0 cli command end"
action 011 cli command "end"
And the second applet (the one where you'll need to fill in the appropriate syslog pattern) will look like:
event manager applet ipsla-threshold-normal
event syslog pattern "FALLING THRESHOLD PATTERN HERE"
action 001 cli command "enable"
action 002 cli command "config t"
action 003 cli command "no event manager applet ipsla-unhealthy"
action 004 cli command "event manager applet ipsla-healthy"
action 005 cli command "event timer countdown time 900"
action 006 cli command "action 1.0 mail server $q 10.240.0.10$q to $q [email protected]$q from $q [email protected]$q subject $q Link is stable$q body $q Link has been stable for 15 minutes$q"
action 007 cli command "action 2.0 cli command enable"
action 008 cli command "action 3.0 cli command $q config t$q"
action 009 cli command "action 4.0 cli command $q no event manager applet ipsla-healthy$q"
action 010 cli command "action 5.0 cli command end"
action 011 cli command "end"

Wifi packet loss after upgrading to 10.7.4

After upgrading all three macs (mb pro, mb air, imac) in the house to 10.7.4 they all experience wifi packet loss. I ping to the local router. I have connected to a multitude of wireless routers with similar result.
But here is strong evidence that is a the OS X software problem. I am running linux inside of vmware fusion. I have run the exact same ping commands simultaneously in (1) mac and (2) vmware linux. The linux ping experiences zero packet loss, not even a single packet. The mac at its best will lose 1% packets, but can increase beyond that.
We are suffering from slow internet in our corrent location as it is, and this has a noticable impact on our performance. I am a bit afraid to upgrade to Mountain Lion for fear it may be even worse.
Any thoughts?

Your
com.apple.systempreferences.plist
file is likely corrupt in your
(use the Finder > Go > Go To folder and paste & Go)
~/Library/Preferences
folder, Trash the flle you can (may be two of them, one is a lock file) and reboot.
Reset your system preferences again.
Also see OnyX here: It has a plist checker for corruption
Step by Step to fix your Mac

Help- WDS with Extreme-N & 2x Airport Express with ~ 40% packet loss

So this problem is driving me crazy. I recently moved into a house that has enough metal in the walls (don't ask) to prevent me from using a single base station so I expanded my network as a WDS utilizing an Airport Extreme (mixed NGB mode) and two Airport Express (one as a relay and one as remote). The configuration appears to work normally some times but other times (especially evenings) I get a very high rate of dropped packets between the client notes (which are connected through the WDS-enabled Expresses) and the base station (using a simple ping 10.0.1.1 to check connectivity to the APBS-N). The problem manifests itself from a users' perspective as very long DNS lookups which causes slow page loads in a browser but it's very reproducible via ping.
So far I've tried changing the channels on the network but I haven't seen a huge payoff there. iStumbler reports no additional networks on channel 2 which I'm using, there are some on channel 1, 5, and 13. I've also tried channels 7 and 11. We have no microwave in the house and our cordless phone (5.8ghz) never interrupted with our simpler Express-based network at our old house, n/m the fact that the phone is never in use when we have this problem.
I don't seem to see the problem when I'm local to (in the same room as) the AEBS; it really seems to happen only when I'm on the WDS-enabled remote and/or relay.
Other data points that may help are that the AEBS-N drops out of the Airport utility at the same time. Sometimes isn't gone for 30 seconds, other times for > 30 minutes. The other base stations continue to report "Green" in that they are not having any WDS problems. If I disconnect the remote node the relay will correctly reflect a status of yellow, so I know it somewhat works.
It's an open network (no encryption, open SSID) so it's unlikely that there's an issue there.
Clients include an Apple TV, iBook G4, MacBook, Tivo Series 3, Intel Mini and Dell Latitude D810. Because of the diversity of clients I don't think it's a driver or NIC adapter issue on any of the clients.
Does anyone have any experience working in a similar environment? Suggestions on troubleshooting packet loss (or other performance issues) in a WDS network?
Thanks,
Mike

Hello errorsupply. Welcome to the Apple Discussions!
I suggest downloading a copy of iStumbler. Use iStumbler's Inspector feature (select Edit > Inspector from iStumbler's menu) to determine the Signal-to-Noise Ratio (SNR) at different points around your house, by performing a simple RF site survey. Within the Inspector, note the values for "signal" & "noise" at these locations. Start with your MacBook near the main base station, note the readings, and then, choose the locations where you have the relay and remote base stations.
SNR is the signal level (in dBm) minus the noise level (in dBm). For example, a signal level of -53dBm measured near an access point and typical noise level of -90dBm yields a SNR of 37dB, a healthy value for wireless LANs.
The SNR, as measured from the MacBook, decreases as the range to the base station increases because of applicable free space loss. Also an increase in RF interference from microwave ovens and cordless phones, which increases the noise level, also decreases SNR.
SNR Guideline
o 40dB+ SNR = Excellent signal
o 25dB to 40dB SNR = Very good signal
o 15dB to 25dB SNR = Low signal
o 10dB to 15dB SNR = Very low signal
o 5dB to 10dB SNR = No signal
If the SNR is 20dB+ at each of these locations, then you should be getting reasonable performance from your AirPorts. If less, either try to locate/eliminate the source of the Wi-Fi interference or try relocating the relay and/or remote base station until they are within a 20dB SNR range of the main (and for the remote, of the relay).

Packet Loss frequently for a week?

Hello all, I am currently experiencing a massive amount of packet loss throughout various devices in my household. The main issues are with my SmartTV and the HuluPlus/HBO GO applications. After running my own tests, I have noticed that I am experiencing a whoping 38% packet loss to Hulu and HBO, and a regular 15% loss with any website on my PC and while gaming. Several hours with Verizon has not helped solve the issue and it is becoming increasingly frustrating. Anyone else experiencing this issue?

I would start by checking your local connection.
Run to speedtest.verizon.net
That will test your connection to the Verizon network.
Try and do it when you notice the issues.
If that doesn't give you the speed you are paying for, Verizon should be able to use that to help troubleshoot.
If it passes, that means it could be in Verizon network or farhter down the line.
If a forum member gives an answer you like, give them the Kudos they deserve. If a member gives you the answer to your question, mark the answer as Accepted Solution so others can see the solution to the problem.

ME3600 packet loss problem - reboot to fix.

One of our ME3600 units has developed a problem where we would lose IPv6 Neighbours and OSPFv3 neighbours, followed by the device not passing MPLS traffic. IPv4 traffic suffering bad packet loss.
I discovered that devices attached to the Gigabit ports were receiving errored frames so the ME3600 seemed to be sending out bad frames.
rebooting the device would fix it for a while but it kept happening at regular intervals, usually when the box was carrying more ipv6 traffic.
We have upgraded to the latest firmware which did not help, and performed a full hardware replacement from Cisco only to find we are still seeing the same issue!
there was no configuration change that I could point as being a catalyst for the problem, the most recent thing was enabling ipv6 VRFs, but IPv6 is also carried in the global table while we move some services around.po
Has anyone else experienced similar problems with the ME3600?

This sounds very similar to a problem we have seen across multiple boxes.
I've not noticed whether OSPFv3 neighcors drop, however have seen MPLS stop forwarding and heavy v4 loss. Control plane for v4 seems to stay up (ie v4 OSPF neighbors keep their adjacany) so routes still advertised etc. Performing a shut / no shut of one of the core interfaces will generally result in a complete failure of the interfaces on that ASIC (the two 10G ports in our case) - can't ping adjacent devices after the no shut, but the GE ports still work.
10G ports are core facing on our boxes, and adjacent neighbors see increasing input errors when the issue occurs.
Issue has only been seen during peak traffic times. Reboot fixes the problem.
Did you find any resolution? We've been pointed at CSCui23725, and advised to use the command "platform acl egress-disable". This appears to be working so far.

IPSLA-ICMP Jitter-Packet loss count

Hi,
I wanted to monitor the packet loss in my link using IP SLA. So i configured ipsla jitter and started monitoring it. When i analyze the output i found that ip sla statictics shows heavy drop in my link, but when i ping from the router no drop is observed. Why there is such difference in the out put. I read that normal ping and icmp jitter uses different icmp types messages but now i am confused whether my link proper or not. Which data i should belive.
Here is my config and statistics:
ip sla 2166
icmp-jitter 10.70.194.137 num-packets 100
frequency 300
ip sla schedule 2166 life forever start-time now
Type of operation:              icmpJitter
        Latest RTT: 7 milliseconds
Latest operation start time: 13:56:49.468 IST Sat Dec 24 2011
Latest operation return code: OK
RTT Values:
        Number Of RTT: 92               RTT Min/Avg/Max: 3/7/158
Latency one-way time:
        Number of Latency one-way Samples: 0
        Source to Destination Latency one way Min/Avg/Max: 0/0/0
        Destination to Source Latency one way Min/Avg/Max: 0/0/0
Jitter Time:
        Number of Jitter Samples: 89
        Source to Destination Jitter Min/Avg/Max: 1/4/20
        Destination to Source Jitter Min/Avg/Max: 1/1/1
Packet Late Arrival: 0
Out Of Sequence: 0
        Source to Destination: 0        Destination to Source 0
        In both Directions: 0
Packet Skipped: 0
Packet Loss: 8
        Loss Period Length Min/Max: 1/7
Number of successes: 1
Number of failures: 0
Operation time to live: Forever

Hello mate !
For how long you left the IP sla running ? 24 hours ?
I would disable session time out in your router, set the IP Sla running for 60 minutes for example and in the meantime i would leave a ping running too with high repetition in the background.
I saw you only had 8 pkt loss....   we need two "tools" running for a good comparison, tried what i proposed and let me know.
cheers

Packet loss

Hi,
Going to keep it short and sweet, many of you know about the FIFA/BT/EA problem and the terrible connection online. Here is my latest traceroute to EA, don't know much about this kind of stuff, so are these results normal or is there something distinctly wrong?
Thanks.

Ignore the 100% packet loss - it's a red herring. Those hops will be configured to not respond to traceroute type traffic. If you really did have 100% packet loss, then you'd also get no response from subsequent hops which isn't the case.
Your "issues" appear to be twofold:
A significant increase in latency on the transatlantic hop within level3's network.
Packet loss at EA - possibly (but not necessarily) due to congestion on their network.
HTH.

ME 3400 PACKET LOSS

e3400 packet loss
I have a me3400 connected as follows:
in port G1 / 0 fiber optic switch connects 7 WS-C2960-24TC-s.
The switches are running vlans 2960 and serves to intervlan ME3400 routing.
All of the GTW vlans are defined in the ME3400, in addition this does dhcp for network VLANs.
In the port f0 / 1 is defined as non-me3400 swichport and create an interconnection network with a firewall that outputs the internet
in ports f0 / 5 f0 / 6 is set up a vlan me3400 additional servers
problem:
When a machine that is in the vlans, located in any switch in 2960, seeking access to the servers connected to the f0 / 5 f0 / 6 has lost and slowly, the same is true if you want to access the internet.
Tests done from a PC on the vlans.
If it pings with size 100 to the servers or the firewall is not a problem.
but if you increase the size of the datagram to 500 or 1000 are lost. \
If ping with size of 1000 from a PC to me3400 no problem.
From me3400 If you ping the router or 100 servers with no loss size, but if it increases to 500 or more lost packets again has all of the above results that both the internet as accceso to this rather slow servers . It is worth mentioning that the vlan voip telephony and servcio not a problem.
Assistant to the configuration of me3400
sh ver
Switch Ports Model SW Version SW Image
* 1 26 ME-3400-24TS-A 12.2(55)SE ME340x-METROIPACCESSK9-M
CPU utilization for five seconds: 9%/3%; one minute: 10%; five minutes: 9%
SWICHT-MAIN#sh run
Building configuration...
Current configuration : 5733 bytes
version 12.2
no service pad
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
hostname SWICHT-MAIN
boot-start-marker
boot-end-marker
enable secret 5 $1$EBwk$LIAacdQj3VxvaNUUiBuzk1
no aaa new-model
system mtu routing 1500
ip routing
ip dhcp excluded-address 192.168.150.2 192.168.150.33
ip dhcp pool wifi-alumnos
network 192.168.152.0 255.255.255.0
default-router 192.168.152.1
dns-server 190.4.6.194
ip dhcp pool telefonos
network 192.168.151.0 255.255.255.128
default-router 192.168.151.1
ip dhcp pool wifi-administrativa
network 192.168.153.0 255.255.255.128
default-router 192.168.153.1
dns-server 190.4.6.194
ip dhcp pool AP+SIN-IP
network 192.168.150.0 255.255.255.0
default-router 192.168.150.1
crypto pki trustpoint TP-self-signed-2032354048
enrollment selfsigned
subject-name cn=IOS-Self-Signed-Certificate-2032354048
revocation-check none
rsakeypair TP-self-signed-2032354048
crypto pki certificate chain TP-self-signed-2032354048
certificate self-signed 01
30820244 308201AD A0030201 02020101 300D0609 2A864886 F70D0101 04050030
31312F30 2D060355 04031326 494F532D 53656C66 2D536967 6E65642D 43657274
69666963 6174652D 32303332 33353430 3438301E 170D3933 30333031 30303031
30335A17 0D323030 31303130 30303030 305A3031 312F302D 06035504 03132649
4F532D53 656C662D 5369676E 65642D43 65727469 66696361 74652D32 30333233
35343034 3830819F 300D0609 2A864886 F70D0101 01050003 818D0030 81890281
8100EC3D 75F8B980 C2788415 51766BB5 17CA2AFC 6FA69FE7 E1CCF252 A82EFFE6
1B2A4B25 F4B93A0F BA1DE932 FEFDA3E6 B2B8A20C 6322D58F 1164F87A 0AC837B3
E602E824 9E692394 F616E907 6779C8C8 12111E3B C8F3BF57 1ED89E10 76767BB0
7658715F B95F2D47 B7986E5B DE1A8C7C 71358900 1A9B7F00 0845E024 170B6031
73650203 010001A3 6C306A30 0F060355 1D130101 FF040530 030101FF 30170603
551D1104 10300E82 0C535749 4348542D 4D41494E 2E301F06 03551D23 04183016
8014D21E 00624A3E A7974522 3D33F971 714928BC 412A301D 0603551D 0E041604
14D21E00 624A3EA7 9745223D 33F97171 4928BC41 2A300D06 092A8648 86F70D01
01040500 03818100 BC45CDE9 CD7B23D8 44B1E597 70D088D6 19935AB0 D8D52735
5BFEC71B C8D688BA 76425E3F C220BAC7 D076C4C1 3EA78927 D35A8CF6 228F69AD
EDB74205 897C32E4 645B788C F20F8247 26DB7755 B280E433 B8BA112D 68510F82
BA44600E DF4A316E C3928098 440870B1 028677FF AF6CBA07 1B66200A EC57221E
1C934403 9900B785
quit
spanning-tree mode rapid-pvst
spanning-tree extend system-id
vlan internal allocation policy ascending
vlan 2-6
ip tcp mss 1430
class-map match-any ping-class
match access-group 101
policy-map ping-policy
class ping-class
police cir 1000000
interface FastEthernet0/1
description HACIA FORTINET
port-type nni
no switchport
ip address 192.168.149.2 255.255.255.252
ip accounting output-packets
ip tcp adjust-mss 1430
service-policy input ping-policy
interface FastEthernet0/2
switchport trunk allowed vlan 1-4
switchport mode trunk
service-policy input ping-policy
interface FastEthernet0/3
switchport access vlan 4
switchport trunk allowed vlan 1-4
service-policy input ping-policy
interface FastEthernet0/4
switchport access vlan 5
switchport trunk allowed vlan 1-5
service-policy input ping-policy
interface FastEthernet0/5
switchport access vlan 6
service-policy input ping-policy
interface FastEthernet0/6
switchport access vlan 6
service-policy input ping-policy
interface FastEthernet0/7
shutdown
service-policy input ping-policy
interface FastEthernet0/8
shutdown
service-policy input ping-policy
interface FastEthernet0/9
shutdown
service-policy input ping-policy
interface FastEthernet0/10
shutdown
service-policy input ping-policy
interface FastEthernet0/11
shutdown
service-policy input ping-policy
interface FastEthernet0/12
shutdown
service-policy input ping-policy
interface FastEthernet0/13
shutdown
service-policy input ping-policy
interface FastEthernet0/14
shutdown
service-policy input ping-policy
interface FastEthernet0/15
shutdown
service-policy input ping-policy
interface FastEthernet0/16
shutdown
service-policy input ping-policy
interface FastEthernet0/17
shutdown
service-policy input ping-policy
interface FastEthernet0/18
shutdown
service-policy input ping-policy
interface FastEthernet0/19
shutdown
service-policy input ping-policy
interface FastEthernet0/20
shutdown
service-policy input ping-policy
interface FastEthernet0/21
shutdown
service-policy input ping-policy
interface FastEthernet0/22
shutdown
service-policy input ping-policy
interface FastEthernet0/23
shutdown
service-policy input ping-policy
interface FastEthernet0/24
shutdown
service-policy input ping-policy
interface GigabitEthernet0/1
port-type nni
switchport mode trunk
interface GigabitEthernet0/2
port-type nni
switchport mode trunk
interface Vlan1
description LAN EQUIPOS SWITCH Y APS
ip address 192.168.150.1 255.255.255.192
interface Vlan2
description RED TELEFONOS IP
ip address 192.168.151.1 255.255.255.0
interface Vlan3
description RED WIFI ALUMNOS
ip address 192.168.152.1 255.255.255.0
interface Vlan4
description RED WIFI ADMINISTRATIVA
ip address 192.168.153.1 255.255.255.0
interface Vlan5
description RED LAN CABLEADA
ip address 192.168.154.1 255.255.255.0
interface Vlan6
description LAN HOTELES Y PAGINA WWW
ip address 192.168.155.1 255.255.255.248
ip http server
ip http secure-server
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.149.1
ip sla enable reaction-alerts
access-list 101 permit ip any any
line con 0
line vty 0 4
password
login
line vty 5 15
login
end

Have you try to remove the service-policy from the interfaces or increase the CIR?

Security and packet loss problem

Guys,
I'm using WRTP54G-NA and I have 2 problems with it...
First one: is about security, if I access direclty http://192.168.0.1/admin/voice or any other subfolder it doesn't ask me the password...
The other problem is that I can't let my connetion 100%, It always has packet loss, in both way, wired and wireless (more in wireless), I had already tried to fix the Negotiation to 100Mbps Full duplex, changed the MTU values for different values and there is always packet loss...
I tried to plug my pc directly to the cable modem and it works perfectly...
I'm using firmware version 3.1.24, I also tried with 3.1.27, but with 3.1.27 the number of problem increases including now ones...
Any advice ??
http://brunozp.com || http://brunozp.com.br
Solved!
Go to Solution.

I don't think that the rotuer will ask you for username & pasword once you login to setup page ... Only once it will show you the same when you are typing http://192.168.0.1 on the browser address bar ...

Packet loss / pausing when using 802.11N (Intel 6300)

Hi,
Previously, I had posted a thread involving the Intel 6250, and lack of detection of N WiFi on that card. Some time later, I bit the bullet and got an Intel 6300 card off eBay. After receiving it today, I popped it into my Thinkpad X220, and it worked.... sort of. I can definitely see wireless N support, and can associate with my 2.4 GHz mixed-mode B/G/N network at 130 Mbps, and my 5 GHz N-only router at around 243 - 270 Mbps. However, right off the bat, it seems the number of "Tx Excessive Retries" in iwconfig climb up to several thousand within ~ 15 - 20 minutes of connecting. Also right off the bat, pings are rather inconsistent (typically at least 2 ms greater than when the card is forced to work in G-only mode, and with pauses and spikes up to 800 - 2000 ms, and packet loss from 5 - 10%)
From what I have gathered so far, there has been a bug in the iwlwifi kernel tree that affects N wireless users, and this bug has been around since around 2010 or even earlier. However, I was under the impression that some sort of fix has been merged into the mainline Kernel at this point (I'm on 3.5.3-1-ARCH BTW), and my symptoms are somewhat less aggressive than the ones others described (basic web browsing works reasonably well, though there is often noticeable lag in the response times, but anything latency/packet loss-sensitive will suffer in a major way.) Has anyone managed to get wireless N to actually work reasonably well on Arch (or for that matter, ANY linux distro)? As I understand it, the matter is one of relation to the kernel module itself, so distro-distro variations of userspace apps shouldn't be as much a factor anyway. I am using WICD for my network manager, and am happy to say that it does its job admirably well (assuming the card is set to G-only mode, but the connection itself is actually maintained quite stably even in N mode.)
While I understand that the 11n_disable=1 "fix" allows most people to get on with their lives, I am rather alarmed that this is being considered a long-term solution. Many laptop owners (ThinkPad owners like myself for example) are essentially locked into Intel WiFi cards, unless we are willing to take an expensive risk and flash our BIOS to one that that doesn't have a "whitelist" of approved cards (something that can void the warranty or worse, brick a laptop.) All the while, Intel is still claiming Linux support for a card whose major capabilities are essentially neutered purely based on the OS a user chooses to run (yes, I do consider N to be a major capability, considering 300 Mbps N WiFi is basically old news, with many manufacturers coming out with full 450 Mbps routers. Also, chipsets like Atheros seem to have no problems with offering both performance and stability under Linux... my desktop rig using an Atheros card manages perfectly fine on a full-rate wireless-N network with essentially no packet loss or latency spikes.)
Below is some information that might be useful:
iwconfig (802.11g, ~ 1 hour after connection and running a few speedtests, browsing, ping testing):
wlan0 IEEE 802.11abg ESSID:"dd-wrt"
Mode:Managed Frequency:2.437 GHz Access Point: XXXXXX
Bit Rate=54 Mb/s Tx-Power=15 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off
Link Quality=69/70 Signal level=-41 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:359 Missed beacon:0
iwconfig (802.11n, 5GHz after ~10 minutes browsing/ping testing):
wlan0 IEEE 802.11abgn ESSID:"net2"
Mode:Managed Frequency:5.745 GHz Access Point: XXXXXX
Bit Rate=243 Mb/s Tx-Power=15 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off
Link Quality=55/70 Signal level=-55 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:860 Invalid misc:50 Missed beacon:0
iwconfig (802.11n, 2.4 GHz after connecting and running a speedtest):
wlan0 IEEE 802.11abgn ESSID:"dd-wrt"
Mode:Managed Frequency:2.437 GHz Access Point: XXXXXX
Bit Rate=117 Mb/s Tx-Power=15 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off
Link Quality=66/70 Signal level=-44 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:974 Invalid misc:59 Missed beacon:0
dmesg | grep iwl :
[12011.488089] iwlwifi: Intel(R) Wireless WiFi Link AGN driver for Linux, in-tree:
[12011.488092] iwlwifi: Copyright(c) 2003-2012 Intel Corporation
[12011.488269] iwlwifi 0000:03:00.0: pci_resource_len = 0x00002000
[12011.488271] iwlwifi 0000:03:00.0: pci_resource_base = ffffc900050f8000
[12011.488273] iwlwifi 0000:03:00.0: HW Revision ID = 0x35
[12011.488585] iwlwifi 0000:03:00.0: irq 50 for MSI/MSI-X
[12011.491862] iwlwifi 0000:03:00.0: loaded firmware version 9.221.4.1 build 25532
[12011.492112] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUG disabled
[12011.492114] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUGFS disabled
[12011.492116] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TRACING enabled
[12011.492117] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TESTMODE enabled
[12011.492119] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_P2P disabled
[12011.492121] iwlwifi 0000:03:00.0: Detected Intel(R) Centrino(R) Ultimate-N 6300 AGN, REV=0x74
[12011.492206] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[12011.502925] iwlwifi 0000:03:00.0: device EEPROM VER=0x436, CALIB=0x6
[12011.502928] iwlwifi 0000:03:00.0: Device SKU: 0x1F0
[12011.502930] iwlwifi 0000:03:00.0: Valid Tx ant: 0x7, Valid Rx ant: 0x7
[12011.502946] iwlwifi 0000:03:00.0: Tunable channels: 13 802.11bg, 24 802.11a channels
[12011.503105] ieee80211 phy8: Selected rate control algorithm 'iwl-agn-rs'
[12011.503456] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[12011.503661] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
[12011.745631] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[12011.745868] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
[12073.651471] iwlwifi: Intel(R) Wireless WiFi Link AGN driver for Linux, in-tree:
[12073.651474] iwlwifi: Copyright(c) 2003-2012 Intel Corporation
[12073.651660] iwlwifi 0000:03:00.0: pci_resource_len = 0x00002000
[12073.651661] iwlwifi 0000:03:00.0: pci_resource_base = ffffc900050b8000
[12073.651663] iwlwifi 0000:03:00.0: HW Revision ID = 0x35
[12073.652241] iwlwifi 0000:03:00.0: irq 50 for MSI/MSI-X
[12073.655662] iwlwifi 0000:03:00.0: loaded firmware version 9.221.4.1 build 25532
[12073.655887] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUG disabled
[12073.655890] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUGFS disabled
[12073.655891] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TRACING enabled
[12073.655891] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TESTMODE enabled
[12073.655892] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_P2P disabled
[12073.655894] iwlwifi 0000:03:00.0: Detected Intel(R) Centrino(R) Ultimate-N 6300 AGN, REV=0x74
[12073.655975] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[12073.666587] iwlwifi 0000:03:00.0: device EEPROM VER=0x436, CALIB=0x6
[12073.666593] iwlwifi 0000:03:00.0: Device SKU: 0x1F0
[12073.666595] iwlwifi 0000:03:00.0: Valid Tx ant: 0x7, Valid Rx ant: 0x7
[12073.666618] iwlwifi 0000:03:00.0: Tunable channels: 13 802.11bg, 24 802.11a channels
[12073.667056] ieee80211 phy9: Selected rate control algorithm 'iwl-agn-rs'
[12073.667456] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[12073.667659] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
[12073.908411] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[12073.908632] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
[12087.261869] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[12087.262090] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
[12087.487757] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[12087.488010] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
[12087.699574] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[12087.699781] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
[12087.837322] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[12087.837526] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
[12097.329577] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[12097.329832] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
[12097.797748] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[12097.797970] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
[12098.016220] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[12098.016458] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
[12100.458762] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[12100.459006] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
[12100.608769] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[12100.609021] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
[12100.764093] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[12100.764341] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
[12100.979029] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[12100.979228] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
[12101.159987] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[12101.160208] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
lshw | less :
*-network
description: Wireless interface
product: Centrino Ultimate-N 6300
vendor: Intel Corporation
physical id: 0
bus info: pci@0000:03:00.0
logical name: wlan0
version: 35
serial: 00:24:d7:be:9e:74
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress bus_master cap_list ethernet phy
sical wireless
configuration: broadcast=yes driver=iwlwifi driverversion=3.5.3-
1-ARCH firmware=9.221.4.1 build 25532 ip=192.168.1.145 latency=0 link=yes multic
ast=yes wireless=IEEE 802.11abgn
resources: irq:50 memory:f2500000-f2501fff
Thanks,
- A.G.

I have an ASUS UX32VD-DB71 which has the Intel Centrino 6235 wifi card. I've been having this laptop for more than 6 months and I've tried different solutions to fix the issue with Wireless-N but none of them were stable other than disabling N completely using 11n_disable=1
I've tried different kernels all the way from 3.2 to the latest 3.7 series of kernels (both in the openSUSE tree as well as mainline) with no luck whasoever. I also tried installing the compat-drivers from 2013-01-23-1-u version onto my 3.6 kernel which provided the same results too. I see packet loss with N and the G speeds are just too slow. I have a workstation in my network and I can only transfer effectively at 1.5 MB /s max over G whereas an old laptop from 2007 which has an 1x1 MIMO antenna (again Intel though) can connect at 144 Mbps to my router and transfer files at least 3-4 times faster (if not more).
It is totally unacceptable for Intel to not just fix this issue for Linux.
Last edited by Tuxdude (2013-02-17 01:38:59)

High Packet Loss, High Ping and Slow Connection Ov...

Hi There,
I have been a customer with the BT unlimited broadband package for a little under two years and up until recently have had no real issues with the service. This was until around 3/4 weeks ago I noticed that the internet was very slow and certain online games or applications like Netflix would lose all of its quality or stop completely. At first I thought nothing of it and simply reset my BT Home hub router, and sure enough everything was back to normal. However after around 2-3 hours of moderate use (gaming online or watching Netflix) the problem surfaced again.
Now I am lucky if I can get the entire way through a 40 minute TV episode before the quality drops and/or the service requires buffering. I have already contacted BT via the helpline and the service lady ran through the obligatory steps (turn off, wait 5 minutes, reset the home hub etc.) but she failed to understand that although rebooting the home hub does alleviate the problem initially, the symptoms of a slow connection, high packet loss and high ping always return within an hour.
Four the last couple of weeks I have been trying to investigate the problem myself and I have done the following things:
Tested the line using the master socket (no difference)
Opened the ports on my firewall within the home hub (no difference)
Directly wired in the computer instead of relying on the wifi (no difference)
Tested for interference from neighbours wifi using inSSIDider office (it wasn’t, operating on different channels)
Switched every device that requires internet off apart from the PC (no difference)
So with all that in mind I am fairly confident that it is nothing within my house that has caused a significant reduction in internet quality.
Now I have tried my best to display the problem I am having by recording the connection quality for the last 24 hours. The table below represents the condition and quality of the connection after leaving it a period of time without resetting:
ADSL Line Status
Connection Information
Line state:
Connected
Connection time:
0 days, 21:52:14
Downstream:
12.96 Mbps
Upstream:
910 Kbps
ADSL Settings
VPI/VCI:
0/38
Type:
PPPoA
Modulation:
G.992.5 Annex A
Latency type:
Interleaved
Noise margin (Down/Up):
6.7 dB / 5.4 dB
Line attenuation (Down/Up):
29.4 dB / 16.4 dB
Output power (Down/Up):
20.4 dBm / 12.6 dBm
FEC Events (Down/Up):
987297 / 12745
CRC Events (Down/Up):
254 / 15268
Loss of Framing (Local/Remote):
0 / 0
Loss of Signal (Local/Remote):
0 / 0
Loss of Power (Local/Remote):
0 / 0
HEC Events (Down/Up):
2437 / 252630
Error Seconds (Local/Remote):
189 / 36430
And here is a result of the ping and packet loss during this time:
Now I immediately reset the home hub after running that test and ran the test again. These are the results I a achieved within 2 minutes of internet connectivity:
ADSL Line Status
Connection Information
Line state:
Connected
Connection time:
0 days, 00:01:05
Downstream:
13.77 Mbps
Upstream:
910 Kbps
ADSL Settings
VPI/VCI:
0/38
Type:
PPPoA
Modulation:
G.992.5 Annex A
Latency type:
Interleaved
Noise margin (Down/Up):
6.4 dB / 5.6 dB
Line attenuation (Down/Up):
29.4 dB / 16.4 dB
Output power (Down/Up):
20.4 dBm / 12.6 dBm
FEC Events (Down/Up):
159 / 12746
CRC Events (Down/Up):
1 / 15573
Loss of Framing (Local/Remote):
0 / 0
Loss of Signal (Local/Remote):
0 / 0
Loss of Power (Local/Remote):
0 / 0
HEC Events (Down/Up):
0 / 252639
Error Seconds (Local/Remote):
1 / 36438
Even within the time it has taken to compose this page my internet quality has nose-dived from the previous result above to the following:
Connection Information
Line state:
Connected
Connection time:
0 days, 00:52:31
Downstream:
13.77 Mbps
Upstream:
910 Kbps
ADSL Settings
VPI/VCI:
0/38
Type:
PPPoA
Modulation:
G.992.5 Annex A
Latency type:
Interleaved
Noise margin (Down/Up):
6.1 dB / 5.4 dB
Line attenuation (Down/Up):
29.4 dB / 16.4 dB
Output power (Down/Up):
20.4 dBm / 12.6 dBm
FEC Events (Down/Up):
14544 / 12749
CRC Events (Down/Up):
14 / 15584
Loss of Framing (Local/Remote):
0 / 0
Loss of Signal (Local/Remote):
0 / 0
Loss of Power (Local/Remote):
0 / 0
HEC Events (Down/Up):
72 / 252647
Error Seconds (Local/Remote):
10 / 36449
What is causing this poor quality in connection and what can be done to rectify the problem?
Thank you for your response in advanced.
Regards,
Richard.

Thank you for you quick reply, I have just moved my hub to the master socket again and re-run the test and I seem to be getting the same results.
ADSL Line Status
Connection Information
Line state:
Connected
Connection time:
0 days, 00:17:47
Downstream:
12.96 Mbps
Upstream:
910 Kbps
ADSL Settings
VPI/VCI:
0/38
Type:
PPPoA
Modulation:
G.992.5 Annex A
Latency type:
Interleaved
Noise margin (Down/Up):
6.0 dB / 5.2 dB
Line attenuation (Down/Up):
28.7 dB / 15.9 dB
Output power (Down/Up):
20.4 dBm / 12.6 dBm
FEC Events (Down/Up):
26417 / 5
CRC Events (Down/Up):
1 / 303
Loss of Framing (Local/Remote):
0 / 0
Loss of Signal (Local/Remote):
0 / 0
Loss of Power (Local/Remote):
0 / 0
HEC Events (Down/Up):
31 / 11
Error Seconds (Local/Remote):
10 / 36522
I have also checked if the bell wire was attached and it is not. My socket is of the new type with the inclusion of an inductor on the faceplate. My ADSL filters and modem cable already have the middle connecting pins removed so I don’t think it is a wiring problem, at least in my apartment anyway. I have also searched for problems with the exchange and they are showing green for my area. (Liverpool Central)
I have just rang the quiet line and I do not appear to have any noise on the line. However, all I have is a cordless phone and I know that is not ideal for determining noise due to the radio frequency interfering with the phone speaker.
Again thank you for you time on this issue.
Regards,
Richard

Excessive Packet Loss 1.87 Mb/s Down 39.63 Mb/s Up - 90.19% limited?

Hello everyone, my name is Sherri. I became a Fios Internet 50/25 subscriber 4 days ago. For the first 24 hours speedtest.verizon.net was giving me as much as a 60/30 speed results. The next morning I noticed web pages taking abnormally long to load (even google.com), so I decided to check my speed again and am now getting as low as 1MB/s download wired or wirelessly. My upload remains unaffected but browsing can get so slow it's almost unusable. Any large downloads I try end up failing (i.e. cyanogenmod nightlies). This has been going on for the past 3 days on all of my devices (android, PC, Macbook).
How can I check if this is a fixable problem on my end or if it's a problem with Fios in my area that I just need to wait out? I called tech support and they just want to send me a new router, but if it was the router wouldn't my upload be affected as well?
Network diagnostic tool:
Checking for Middleboxes . . . . . . . . . . . . . . . . . . Done
SendBufferSize set to [131768]
running 10s outbound test (client to server) . . . . . 39.63Mb/s
running 10s inbound test (server to client) . . . . . . 1.87Mb/s
------ Client System Details ------
OS data&colon; Name = Mac OS X, Architecture = x86_64, Version = 10.8.4
Java data&colon; Vendor = Oracle Corporation, Version = 1.7.0_25
------ Web100 Detailed Analysis ------
Client Receive Window detected at 131760 bytes.
100 Mbps FastEthernet link found.
Link set to Full Duplex mode
Information: throughput is limited by other network traffic.
Good network cable(s) found
Normal duplex operation found.
Web100 reports the Round trip time = 11.77 msec; the Packet size = 1448 Bytes; and
There were 169 packets retransmitted, 493 duplicate acks received, and 554 SACK blocks received
The connection stalled 17 times due to packet loss
The connection was idle 3.65 seconds (30.41%) of the time
This connection is sender limited 9.81% of the time.
This connection is network limited 90.19% of the time.
Excessive packet loss is impacting your performance, check the auto-negotiate function on your local PC and network switch
Web100 reports TCP negotiated the optional Performance Settings to:
RFC 2018 Selective Acknowledgment: ON
RFC 896 Nagle Algorithm: ON
RFC 3168 Explicit Congestion Notification: OFF
RFC 1323 Time Stamping: ON
RFC 1323 Window Scaling: ON
Information: Network Middlebox is modifying MSS variable
Server IP addresses are preserved End-to-End
Client IP address not found. For IE users, modify the Java parameters
click Tools - Internet Options - Security - Custom Level, scroll down to
Microsoft VM - Java permissions and click Custom, click Java Custom Settings
Edit Permissions - Access to all Network Addresses, click Eanble and save changes
Any help would be appreciated! Aside from the internet, I'm really happy with Fios TV . The customer service rep credited me the internet cost for this month because of my issues and for that I am very thankful! but... I would still like to get this fixed as soon as possible.
Things I've tried:
resetting ONT
Forced firmware upgrade and router reset
Verizon reset my service and gave me a new IP

By the way, I agree with sybrand: you need to tune
your redo log size.
Regards
Ignacio
http://oracledisect.blogspot.com
Ignacio,
The excessive waits on log file parallel write and the related client wait of log file sync may be due to insufficient CPU availability, and may not point at an actual redo log size problem or a problem with the disk speed where the redo is written to disk, especially if there are 3 Oracle instances on the server with a single CPU.
Paraphrased from "Optimizing Oracle Performance":
The log file sync wait event is one of the first events to show increased latencies due to the time a process spends waiting in a CPU wait queue while processing excessive logical IOs.
Kevin Closson wrote a couple blog entries that examined the potential problems of insufficient CPU capacity and its effects on log file parallel write when writing to solid state disks, and even when writing redo was explicitly disabled:
http://kevinclosson.wordpress.com/2007/07/21/manly-men-only-use-solid-state-disk-for-redo-logging-lgwr-io-is-simple-but-not-lgwr-processing/
"Once LGWR loses his CPU it may be quite some time until he gets it back. For instance, if LGWR is preempted in the middle of trying to perform a redo buffer flush, there may be several time slices of execution for other processes before LGWR gets back on CPU..." Fix the CPU problem, and the other significant waits may decrease.
JesusLuvR,
yingkuan's suggestion to look at the SQL statement that performs the 4,365,564 logical IOs, consumes 186.03 CPU seconds, and has an execution time of 225.06 seconds, is likely a very good starting point. You might also want to check the value of the SESSION_CACHED_CURSORS parameter to see if it needs to be adjusted.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

Increasing Frequency of Packet Loss

Similar Messages

Maybe you are looking for