PAcket loss during gaming

Hello i have been dealing with bad wifi during gaming. The wifi in general is bad but it is horrible when trying to play online! I am pretty sure that packet loss is the cause of not being able to play online games like Guild Wars and Everquest 2. Have the wifi issues been solved for this computer?

it's a little be hard to help you without laptop model and installed OS. by the way you can try to open a Command prompt and have a ping test once in command prompt type: ping google.com -t check about packet loss or errors. to stop pinging, press Ctrl+C keys

Similar Messages

Packet loss during ARP

During a competitive pilot against another vendor, it has been observed that a ping packet is lost each time the MSFC router has to re-ARP the next hop.
With the other vendor, there is no ping lost. beside the fact that this is not a real problem, the client sees this as a difference with the other vendor...
Can someone telle me if this behaviour is normal and and if something can be done to eliminate the packet loss ?
Thank you
Yves

It is normal, in the sense that it is deliberately done in Cisco IOS.
Can be seen in other models too.Not an MSFC specific behavior.
Cannot be eliminated. Has to do with ARP implementation.
ARP requests are served asynchronously (no wait for a response).
This, to avoid the risk of waiting for a reply that may never come,
while you could be doing something more useful:
Forwarding packets for which ARP information is known and which are waiting behind
the packet that currently failed to be encapsulated out the same interface.
(When the ARP request is sent, the outgoing interface is known.
Unknown is the MAC address of the next-hop,
so that a packet can be encapsulated and sent to the medium.)
Note the word "probably" in the Packet Generation section of RFC826 :
http://www.ietf.org/rfc/rfc0826.txt?number=826
" The Address Resolution module tries to find this pair in a table.
If it finds the pair, it gives the corresponding 48.bit Ethernet address
back to the caller (hardware driver) which then transmits the packet.
If it does not, it probably informs the caller that it is throwing the
packet away (on the assumption the packet will be retransmitted
by a higher network layer), and generates an Ethernet packet with
a type field of ether_type$ADDRESS_RESOLUTION. "
I suppose this is an implementation specific detail,
and both vendors can somehow defend their choices.

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

90% Packet Loss while online gaming. Almost sure i...

I have been experiencing heavy packet loss for about 3 months now, hoping it would disappear at some point.
Now that I realise it won't go away, I have contacted BT and all they've done is "turn off my ping latency" which is complete bull, and refer me to the BT experts, which I'm also sure are useless.
I've been trying ping, pathping and tracert commands to the servers I connect to. Ping shows 0% packet loss, tracert has request timeouts, and pathping doesn't even go past the 1st hop.
I don't even know what to do now, this wasn't an issue before, it just popped up suddenly and I can't fix it.
After using the ping -t command to my gateway address, I am 100% sure it is a BT routing issue that needs to be fixed.

Hi neve1176,
Thanks for posting. Can you post up the results of your tracert and one from the BBC site for comparison and we'll take a look.
Cheers
David
BTCare Community Mod
If we have asked you to email us with your details, please make sure you are logged in to the forum, otherwise you will not be able to see our ‘Contact Us’ link within our profiles.
We are sorry but we are unable to deal with service/account queries via the private message(PM) function so please don't PM your account info, we need to deal with this via our email account :-)

Terrible Packet Loss in Game- Please help!

Computing statistics for 100 seconds...
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 Sam-PC.home [192.168.1.5]
0/ 25 = 0% |
1 2ms 0/ 25 = 0% 0/ 25 = 0% Wireless_Broadband_Router.home [192.168.1.1]
1/ 25 = 4% |
2 13ms 1/ 25 = 4% 0/ 25 = 0% L100.WASHDC-VFTTP-126.verizon-gni.net [173.66.228.1]
0/ 25 = 0% |
3 11ms 1/ 25 = 4% 0/ 25 = 0% G1-5-0-4.WASHDC-LCR-21.verizon-gni.net [130.81.213.68]
0/ 25 = 0% |
4 20ms 1/ 25 = 4% 0/ 25 = 0% so-12-1-0-0.RES-BB-RTR1.verizon-gni.net [130.81.151.230]
0/ 25 = 0% |
5 12ms 1/ 25 = 4% 0/ 25 = 0% 0.xe-8-0-0.BR2.IAD8.ALTER.NET [152.63.38.129]
0/ 25 = 0% |
6 34ms 1/ 25 = 4% 0/ 25 = 0% ae17.edge1.washingtondc12.level3.net [4.68.62.137]
0/ 25 = 0% |
7 33ms 2/ 25 = 8% 1/ 25 = 4% vl-3503-ve-117.ebr1.Washington12.Level3.net [4.69.158.26]
0/ 25 = 0% |
8 29ms 3/ 25 = 12% 2/ 25 = 8% ae-6-6.ebr1.Atlanta2.Level3.net [4.69.148.105]
0/ 25 = 0% |
9 30ms 2/ 25 = 8% 1/ 25 = 4% ae-63-63.ebr3.Atlanta2.Level3.net [4.69.148.241]
0/ 25 = 0% |
10 50ms 1/ 25 = 4% 0/ 25 = 0% ae-7-7.ebr3.Dallas1.Level3.net [4.69.134.21]
1/ 25 = 4% |
11 56ms 2/ 25 = 8% 0/ 25 = 0% ae-63-63.csw1.Dallas1.Level3.net [4.69.151.133]
0/ 25 = 0% |
12 54ms 2/ 25 = 8% 0/ 25 = 0% ae-1-60.edge2.Dallas1.Level3.net [4.69.145.11]
0/ 25 = 0% |
13 54ms 2/ 25 = 8% 0/ 25 = 0% 4.59.197.34
1/ 25 = 4% |
14 50ms 3/ 25 = 12% 0/ 25 = 0% 64.25.32.9
0/ 25 = 0% |
15 --- 25/ 25 =100% 22/ 25 = 88% 64.25.32.26
0/ 25 = 0% |
16 48ms 3/ 25 = 12% 0/ 25 = 0% 64.25.39.1
These are the results of a test I ran, but I don't know how to solve the problem. The game is unplayable because of the amount of packet loss. I know it is an issue of connection between the game and my router, so should I get a new router if mine is old?

The router I would imagine to be okay for the first bit, but for the sake of things, reboot the router and also try giving your ONT a reboot by unplugging it from AC power and then disconnecting the battery. Re-connect it after 30 seconds by connecting the battery and then plugging it back into AC power.
Also, see if the packet loss takes place during specific times of the day. If your router has a WAN connection over Coax (rather than an Ethernet connection) to your ONT, also consider checking your MoCa speeds based on this FAQ. Poor MoCa speeds can suggest shoddy coaxial causing some issues, too: https://secure.dslreports.com/faq/verizonfios/3.2_MOCA#16569
========
The first to bring me 1Gbps Fiber for $30/m wins!

Verizon FIOS Intermittent Packet Loss Problem - How to Convince Verizon Support it's NOT ME

Hi,
I have been having a problem with Verizon FIOS Internet AND Phone since Thursday afternoon.
Basically I have intermittent outages several times a day of 15-40 seconds where my download doesn't work, but upload still does. This happens on BOTH my phone and internet. Therefore it's not my router or computer equipment causing the problem.
Here's what happens:
- On the internet: I have a periodic download problem where I can receive no data for about 15 - 40 seconds. After that it returns to normal
- On the phone: If I'm on the phone at the same time then during that period of internet loss I also can not hear anything that the person I am talking to says. However they can hear me just fine (ie. download only problem)
I have been talking to Verizon technical support and they have blamed my router and ONT. I have tried switching off the router, and using a different one. Also they have replaced the ONT twice.
* This problem occurs on BOTH the phone and internet at the same time. This clearly suggests the problem is not in my own house.
In fact I know exactly where the problem lies. I did a traceroute to google below:
Tracing route to google.com [74.125.113.106]
over a maximum of 30 hops:
1     4 ms     1 ms    <1 ms 192.168.1.1
2     5 ms     4 ms     4 ms L300.NWRKNJ-VFTTP-122.verizon-gni.net [74.105.157.1]
3     9 ms     8 ms     7 ms G2-0-0-1822.NWRKNJ-LCR-08.verizon-gni.net [130.81.133.156]
4    11 ms     8 ms     7 ms P15-0.NWRKNJ-LCR-07.verizon-gni.net [130.81.30.148]
5     9 ms     6 ms     7 ms so-5-0-0-0.NWRK-BB-RTR1.verizon-gni.net [130.81.29.8]
6     7 ms     6 ms     7 ms 0.so-7-0-0.XL3.EWR6.ALTER.NET [152.63.19.177]
7     9 ms    10 ms     9 ms 0.so-1-0-1.XL3.NYC4.ALTER.NET [152.63.0.213]
8     9 ms     9 ms     9 ms TenGigE0-6-0-0.GW8.NYC4.ALTER.NET [152.63.22.41]
9    33 ms    31 ms    35 ms google-gw.customer.alter.net [152.179.72.62]
10     8 ms    11 ms    10 ms 209.85.252.215
11    18 ms    17 ms    16 ms 209.85.249.11
12    31 ms    29 ms    29 ms 209.85.241.222
13    30 ms    29 ms    29 ms 209.85.241.207
14    41 ms    39 ms    34 ms 209.85.243.1
15    27 ms    27 ms    29 ms vw-in-f106.1e100.net [74.125.113.106]
Trace complete.
Then I pinged each device for hops 2-4. When the problem occurs the first one in the hop - 74.105.157.1 - runs fine. The second device - 130.81.133.156 - times out, and all other devices further down the chain time out. This clearly suggest that the device:
130.81.133.156 has major problems.
I have mentioned this to tech support, but they have no way for me to send them logs. Apparently the support technicians at Verizon can not be trusted with even the most basic of tools like email and the web. They also shield me from the NT (Network technician), who is so special that even the tech support guys are only allowed to text chat with him, not actually talk to him. I have enough logs here to clearly show what the problem is.
The latest from tech support is that they are sending yet another guy by my house tomorrow to witness this problem firsthand. Then he will call support that will text chat with the NT, and MAYBE they'll start thinking it's not me.
My main question here is: "How do I get Verizon to believe it really could be a problem in their own network?"
Here are some threads from last year that explain exactly the same problem I'm having. So it wasn't just me:
http://forums.verizon.com/t5/FiOS-TV-Technical-Assistance/Verizon-FIOS-intermittent-connection-drops...
http://forums.verizon.com/t5/FiOS-Internet/Intermittent-Network-Timeouts/m-p/28138
One person said Verizon finally fixed it by replacing a PON card. I'm not sure if this is the same problem as that though.
I am an avid Starcraft player and this is driving me crazy because I am getting dropped from my games all the time. Also phone conversations suck when there's these big lags where I can't hear who I'm talking to.
I have had Verizon FIOS internet for 3 years now and this is the first problem I've ever had with it. But I'm starting to get majorly frustrated at how long it's taking to resolve the problem.
Here is a sample of the ping logs I was talking about for different devices all at the same time.
Device 2 in the Trace Route:
Reply from 74.105.157.1: bytes=32 time=78ms TTL=126
Reply from 74.105.157.1: bytes=32 time=57ms TTL=126
Reply from 74.105.157.1: bytes=32 time=41ms TTL=126
Reply from 74.105.157.1: bytes=32 time=35ms TTL=126
Reply from 74.105.157.1: bytes=32 time=34ms TTL=126
Reply from 74.105.157.1: bytes=32 time=41ms TTL=126
Reply from 74.105.157.1: bytes=32 time=43ms TTL=126
Reply from 74.105.157.1: bytes=32 time=59ms TTL=126
Reply from 74.105.157.1: bytes=32 time=24ms TTL=126
Reply from 74.105.157.1: bytes=32 time=48ms TTL=126
Reply from 74.105.157.1: bytes=32 time=5ms TTL=126
Reply from 74.105.157.1: bytes=32 time=5ms TTL=126
Reply from 74.105.157.1: bytes=32 time=5ms TTL=126
Reply from 74.105.157.1: bytes=32 time=4ms TTL=126
Reply from 74.105.157.1: bytes=32 time=3ms TTL=126
Reply from 74.105.157.1: bytes=32 time=20ms TTL=126
Reply from 74.105.157.1: bytes=32 time=19ms TTL=126
Reply from 74.105.157.1: bytes=32 time=18ms TTL=126
Reply from 74.105.157.1: bytes=32 time=17ms TTL=126
Reply from 74.105.157.1: bytes=32 time=17ms TTL=126
Reply from 74.105.157.1: bytes=32 time=17ms TTL=126
Reply from 74.105.157.1: bytes=32 time=17ms TTL=126
Reply from 74.105.157.1: bytes=32 time=37ms TTL=126
Reply from 74.105.157.1: bytes=32 time=17ms TTL=126
Reply from 74.105.157.1: bytes=32 time=16ms TTL=126
Device 3 in the Trace Route:
Reply from 130.81.133.156: bytes=32 time=7ms TTL=253
Reply from 130.81.133.156: bytes=32 time=7ms TTL=253
Reply from 130.81.133.156: bytes=32 time=8ms TTL=253
Reply from 130.81.133.156: bytes=32 time=8ms TTL=253
Reply from 130.81.133.156: bytes=32 time=8ms TTL=253
Reply from 130.81.133.156: bytes=32 time=10ms TTL=253
Reply from 130.81.133.156: bytes=32 time=9ms TTL=253
Reply from 130.81.133.156: bytes=32 time=10ms TTL=253
Reply from 130.81.133.156: bytes=32 time=13ms TTL=253
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 130.81.133.156: bytes=32 time=8ms TTL=253
Reply from 130.81.133.156: bytes=32 time=8ms TTL=253
Reply from 130.81.133.156: bytes=32 time=8ms TTL=253
Reply from 130.81.133.156: bytes=32 time=7ms TTL=253
Reply from 130.81.133.156: bytes=32 time=6ms TTL=253
Reply from 130.81.133.156: bytes=32 time=8ms TTL=253
Reply from 130.81.133.156: bytes=32 time=14ms TTL=253
Device 4 in the Trace Route:
Reply from 130.81.30.148: bytes=32 time=8ms TTL=252
Reply from 130.81.30.148: bytes=32 time=8ms TTL=252
Reply from 130.81.30.148: bytes=32 time=8ms TTL=252
Reply from 130.81.30.148: bytes=32 time=7ms TTL=252
Reply from 130.81.30.148: bytes=32 time=6ms TTL=252
Reply from 130.81.30.148: bytes=32 time=8ms TTL=252
Reply from 130.81.30.148: bytes=32 time=7ms TTL=252
Reply from 130.81.30.148: bytes=32 time=8ms TTL=252
Reply from 130.81.30.148: bytes=32 time=7ms TTL=252
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 130.81.30.148: bytes=32 time=8ms TTL=252
Reply from 130.81.30.148: bytes=32 time=8ms TTL=252
Reply from 130.81.30.148: bytes=32 time=7ms TTL=252
Reply from 130.81.30.148: bytes=32 time=6ms TTL=252
Reply from 130.81.30.148: bytes=32 time=8ms TTL=252
Reply from 130.81.30.148: bytes=32 time=7ms TTL=252
Reply from 130.81.30.148: bytes=32 time=6ms TTL=252
Any help, thoughts, suggestions, etc would be great appreciated!
~David

I understand your logic, but you have not eliminated 74.105.157.1 as the problem. It could be allowing packets out, like outside callers hearing you, but not allow them back in. Since you have results pinging out, trying ping back in. Use this packet loss tool. You do not need to catch it when it's not working because this tool will ping your IP address (and all the hops in between) for up to 7 days. You will easily see when packet loss is occurring.
If it can successfully ping 74.105.157.1 when the problem occurrs, then 130.81.133.156 is not the issue. This may not help dealing with the personalities at Verizon, but it will help definitively knowing which device is the issue.

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.

White noise, sort of packet loss when talking with...

Hi,
For some unknown reason when I talk with one specific person the call doesn't exactly drop out it sort of cuts the audio and gives me white noise (sort of like when you get packet loss when transferring files or gaming), I have 0 idea why it does it. Does it the reverse as well, but only for me and this person. Everyone else thats in the call doesn't get effected and its frustrating me.

When in a call goto call > Technical info. This will show you various info about the call connection (and a lot of useless info aswell). Amongst the info is packet loss, and relays (if relays = more than 0 you are not directly connected).
Being on the same Skype, version might help.

Home Hub 3.0 vs Home Hub 2.0 packet loss

So I upgraded the BT package that our family is on today, and with it came the Home Hub 3.0. Happy right? Better wireless, less connection problems etc... No.
For some reason, since upgrading, I get random moments of massive packet loss. Up to 50% packets are lost for periods of up to 5 minutes. I've tried resetting the router, tried turning it off for ten minutes etc but still get regular moments of packet loss.
My internet is not interleaved at the moment so that could be a problem, however before switching to the 3.0 i never had any packet loss with non-interleaved internet (on the 2.0 homehub).
Could anyone help me?!
Thanks
Solved!
Go to Solution.

ADSL Line Status
Connection Information
Line state:
Connected
Connection time:
0 days, 03:12:19
Downstream:
7.813 Mbps
Upstream:
448 Kbps
ADSL Settings
VPI/VCI:
0/38
Type:
PPPoA
Modulation:
G.992.1 Annex A
Latency type:
Fast
Noise margin (Down/Up):
9.1 dB / 24.0 dB
Line attenuation (Down/Up):
35.5 dB / 19.5 dB
Output power (Down/Up):
19.9 dBm / 12.1 dBm
FEC Events (Down/Up):
0 / 202
CRC Events (Down/Up):
91236 / 426
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):
619777 / 655
Error Seconds (Local/Remote):
2173 / 506
est1 comprises of Best Effort Test: -provides background information.
Download Speed
4095 Kbps
0 Kbps
7150 Kbps
Max Achievable Speed
Download speedachieved during the test was - 4095 Kbps
For your connection, the acceptable range of speeds is 600-7150 Kbps.
Additional Information:
Your DSL Connection Rate :8000 Kbps(DOWN-STREAM), 448 Kbps(UP-STREAM)
IP Profile for your line is - 4500 Kbps
I did a quiet line test and it sounded quiet.
Thanks for your answer, just hope someone can help me resolve it now

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.

Packet Loss on Xen and Coherence

We are currently experiencing packet loss issues with Coherence 3.4.2 during the datagram test.
Packet loss statistics are as follows:
Rx from publisher: /10.96.67.169:9999
elapsed: 149384ms
packet size: 1468
throughput: 66 MB/sec
46889 packets/sec
received: 7004519 of 8252377
missing: 1247858
success rate: 0.848788
out of order: 0
avg offset: 0
gaps: 535018
avg gap size: 2
avg gap time: 0ms
avg ack time: -1.0E-6ms; acks 0
The Coherence implementation is running on a Xen VM.
We see this happen for both Fully Virtual and Paravirtualized Guests.
This problem does not happen on physical hardware.
Here is the general sequence that we tried:
1. After finding the problem on coherence, we tried to simulate similar results on 2 HVM xen systems and we did not find the problem there.
        a. These boxes were HVM guests.
        b. Were running kernel 2.6.18-164 and redhat 5.4
        c. These guests were running on Dom-0 kernel of 2.6.18-164.2.1el5xen
2. We had 2 para virt machines on the same Dom-0 as above but they were redhat 5.2 so we ran the same test there and still we were running into problem.
3. We upgraded the para virt machines to redhat 5.4 with latest patch rev and still problem was present.
4. after this research found out that we need to disabled module ipv6 and that seems to fix the problem. After disabling IPv6 module ran some more tests between pl1rap704-beta and pl1rap706-beta. Results were performance improved but still packet loss.
5. We converted 2 para virt guests to HVM guests (pl1rap704-beta and pl1rap705-beta) and ran the tests it was still having problem.
6. Upgrade pl1rap704-beta and pl1rap705-beta to redhat release 5.4 and latest kernel rev and see if the problem is still there
We haven't tried this on Oracle VM, but think that would be the next step to see if the problem persists there, although Oracle support indicates that Coherence is not officially supported on Oracle VM.
We still see the packet loss issues and wonder if anyone has encountered this issue before and has a solution to it?

Just saw your post.
If still a problem.....send a PM to   Heather_VZ she has been very helpful to many people on many subjects
Tom
Freedom Essentials, QIP 7100 1,Bose SOLO TV Sound System,,QIP 7216 P2,M1424WR Rev F, iPad 2 WiFi,iPhone 5,TV SYST INFO Release 1.9.5 Build No. 17.45
Data Object 39.45

Packet loss and eventual shutdown of port 80 on RV180

I have been using my RV180 router for about a year now. I have had very little issues with it overall. I have seperate wireless access points connected and use those for my wireless devices.
Recently, I started getting very odd connection problems it started as packet loss and then turned into connection loss. The odd part is that it only effects port 80 or the secured port, 880, if I remember correctly. Thats right, everything else on the network works fine. However, I can not access the internet or the RV180 router via it's ip address to check the status. VOIP, other lan networking, gaming, and bitcoin mining is completely uneffected. Direct connection to the modem works without any problems.
I have tried updating the router firmware but no help.
Each time I have this issue the problem is cured simply by unplugging the router and plugging it back in. Nothing else works because I can not log into the router. This problem comes along once a week or so. I have also tried enabling the logs but I get absolutly nothing when I reset the router and log back in. I have had similar problems with routers in the past becoming "bent" after about a year of use and requiring a replacement. I sort of thought that this wouldnt be the case with the Cisco because it is a good brand and came with a five year warranty. I have also scanned every PC on the network for viruses and malware but nothing was located. The remainder of the devices are IP cameras and such.
Can anyone think of anything that could be causing this?

So I was able to get the logs tonight by repeatedly pinging the router and it would start letting me get traffic in again.
Wed Dec 4 20:03:02 2013(GMT-0500) [rv180][Kernel][KERNEL] [81097.390000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:02 2013(GMT-0500) [rv180][Kernel][KERNEL] [81097.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:02 2013(GMT-0500) [rv180][Kernel][KERNEL] [81097.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:02 2013(GMT-0500) [rv180][Kernel][KERNEL] [81097.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:07 2013(GMT-0500) [rv180][Kernel][KERNEL] [81101.770000] __ratelimit: 111 callbacks suppressed
Wed Dec 4 20:03:07 2013(GMT-0500) [rv180][Kernel][KERNEL] [81101.770000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:07 2013(GMT-0500) [rv180][Kernel][KERNEL] [81101.890000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:07 2013(GMT-0500) [rv180][Kernel][KERNEL] [81101.890000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:07 2013(GMT-0500) [rv180][Kernel][KERNEL] [81101.930000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:07 2013(GMT-0500) [rv180][Kernel][KERNEL] [81101.930000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:07 2013(GMT-0500) [rv180][Kernel][KERNEL] [81102.030000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:07 2013(GMT-0500) [rv180][Kernel][KERNEL] [81102.070000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:07 2013(GMT-0500) [rv180][Kernel][KERNEL] [81102.230000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:07 2013(GMT-0500) [rv180][Kernel][KERNEL] [81102.320000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:07 2013(GMT-0500) [rv180][Kernel][KERNEL] [81102.550000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:12 2013(GMT-0500) [rv180][Kernel][KERNEL] [81107.020000] __ratelimit: 102 callbacks suppressed
Wed Dec 4 20:03:12 2013(GMT-0500) [rv180][Kernel][KERNEL] [81107.020000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:12 2013(GMT-0500) [rv180][Kernel][KERNEL] [81107.020000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:12 2013(GMT-0500) [rv180][Kernel][KERNEL] [81107.270000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:12 2013(GMT-0500) [rv180][Kernel][KERNEL] [81107.320000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:12 2013(GMT-0500) [rv180][Kernel][KERNEL] [81107.420000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:12 2013(GMT-0500) [rv180][Kernel][KERNEL] [81107.430000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:12 2013(GMT-0500) [rv180][Kernel][KERNEL] [81107.520000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:12 2013(GMT-0500) [rv180][Kernel][KERNEL] [81107.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:12 2013(GMT-0500) [rv180][Kernel][KERNEL] [81107.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:12 2013(GMT-0500) [rv180][Kernel][KERNEL] [81107.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:17 2013(GMT-0500) [rv180][Kernel][KERNEL] [81112.120000] __ratelimit: 100 callbacks suppressed
Wed Dec 4 20:03:17 2013(GMT-0500) [rv180][Kernel][KERNEL] [81112.120000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:17 2013(GMT-0500) [rv180][Kernel][KERNEL] [81112.310000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:17 2013(GMT-0500) [rv180][Kernel][KERNEL] [81112.310000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:17 2013(GMT-0500) [rv180][Kernel][KERNEL] [81112.320000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:17 2013(GMT-0500) [rv180][Kernel][KERNEL] [81112.500000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:17 2013(GMT-0500) [rv180][Kernel][KERNEL] [81112.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:17 2013(GMT-0500) [rv180][Kernel][KERNEL] [81112.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:17 2013(GMT-0500) [rv180][Kernel][KERNEL] [81112.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:17 2013(GMT-0500) [rv180][Kernel][KERNEL] [81112.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:17 2013(GMT-0500) [rv180][Kernel][KERNEL] [81112.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:22 2013(GMT-0500) [rv180][Kernel][KERNEL] [81117.540000] __ratelimit: 107 callbacks suppressed
Wed Dec 4 20:03:22 2013(GMT-0500) [rv180][Kernel][KERNEL] [81117.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:22 2013(GMT-0500) [rv180][Kernel][KERNEL] [81117.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:22 2013(GMT-0500) [rv180][Kernel][KERNEL] [81117.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:22 2013(GMT-0500) [rv180][Kernel][KERNEL] [81117.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:22 2013(GMT-0500) [rv180][Kernel][KERNEL] [81117.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:22 2013(GMT-0500) [rv180][Kernel][KERNEL] [81117.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:22 2013(GMT-0500) [rv180][Kernel][KERNEL] [81117.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:22 2013(GMT-0500) [rv180][Kernel][KERNEL] [81117.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:22 2013(GMT-0500) [rv180][Kernel][KERNEL] [81117.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:22 2013(GMT-0500) [rv180][Kernel][KERNEL] [81117.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:27 2013(GMT-0500) [rv180][Kernel][KERNEL] [81122.550000] __ratelimit: 93 callbacks suppressed
Wed Dec 4 20:03:27 2013(GMT-0500) [rv180][Kernel][KERNEL] [81122.550000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:27 2013(GMT-0500) [rv180][Kernel][KERNEL] [81122.550000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:27 2013(GMT-0500) [rv180][Kernel][KERNEL] [81122.550000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:27 2013(GMT-0500) [rv180][Kernel][KERNEL] [81122.550000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:27 2013(GMT-0500) [rv180][Kernel][KERNEL] [81122.550000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:27 2013(GMT-0500) [rv180][Kernel][KERNEL] [81122.550000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:27 2013(GMT-0500) [rv180][Kernel][KERNEL] [81122.550000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:27 2013(GMT-0500) [rv180][Kernel][KERNEL] [81122.550000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:27 2013(GMT-0500) [rv180][Kernel][KERNEL] [81122.550000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:27 2013(GMT-0500) [rv180][Kernel][KERNEL] [81122.550000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:32 2013(GMT-0500) [rv180][Kernel][KERNEL] [81127.560000] __ratelimit: 101 callbacks suppressed
Wed Dec 4 20:03:32 2013(GMT-0500) [rv180][Kernel][KERNEL] [81127.560000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:32 2013(GMT-0500) [rv180][Kernel][KERNEL] [81127.570000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:32 2013(GMT-0500) [rv180][Kernel][KERNEL] [81127.600000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:32 2013(GMT-0500) [rv180][Kernel][KERNEL] [81127.690000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:32 2013(GMT-0500) [rv180][Kernel][KERNEL] [81127.750000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:32 2013(GMT-0500) [rv180][Kernel][KERNEL] [81127.790000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:32 2013(GMT-0500) [rv180][Kernel][KERNEL] [81127.830000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:32 2013(GMT-0500) [rv180][Kernel][KERNEL] [81127.830000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:32 2013(GMT-0500) [rv180][Kernel][KERNEL] [81127.840000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:33 2013(GMT-0500) [rv180][Kernel][KERNEL] [81127.840000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:38 2013(GMT-0500) [rv180][Kernel][KERNEL] [81133.140000] __ratelimit: 110 callbacks suppressed
Wed Dec 4 20:03:38 2013(GMT-0500) [rv180][Kernel][KERNEL] [81133.140000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:38 2013(GMT-0500) [rv180][Kernel][KERNEL] [81133.140000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:38 2013(GMT-0500) [rv180][Kernel][KERNEL] [81133.260000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:38 2013(GMT-0500) [rv180][Kernel][KERNEL] [81133.300000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:38 2013(GMT-0500) [rv180][Kernel][KERNEL] [81133.560000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:38 2013(GMT-0500) [rv180][Kernel][KERNEL] [81133.560000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:38 2013(GMT-0500) [rv180][Kernel][KERNEL] [81133.560000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:38 2013(GMT-0500) [rv180][Kernel][KERNEL] [81133.560000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:38 2013(GMT-0500) [rv180][Kernel][KERNEL] [81133.560000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:38 2013(GMT-0500) [rv180][Kernel][KERNEL] [81133.560000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:43 2013(GMT-0500) [rv180][Kernel][KERNEL] [81138.290000] __ratelimit: 84 callbacks suppressed
Wed Dec 4 20:03:43 2013(GMT-0500) [rv180][Kernel][KERNEL] [81138.290000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:43 2013(GMT-0500) [rv180][Kernel][KERNEL] [81138.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:43 2013(GMT-0500) [rv180][Kernel][KERNEL] [81138.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:43 2013(GMT-0500) [rv180][Kernel][KERNEL] [81138.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:43 2013(GMT-0500) [rv180][Kernel][KERNEL] [81138.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:43 2013(GMT-0500) [rv180][Kernel][KERNEL] [81138.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:43 2013(GMT-0500) [rv180][Kernel][KERNEL] [81138.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:43 2013(GMT-0500) [rv180][Kernel][KERNEL] [81138.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:43 2013(GMT-0500) [rv180][Kernel][KERNEL] [81138.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:43 2013(GMT-0500) [rv180][Kernel][KERNEL] [81138.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:49 2013(GMT-0500) [rv180][Kernel][KERNEL] [81143.710000] __ratelimit: 126 callbacks suppressed
Wed Dec 4 20:03:49 2013(GMT-0500) [rv180][Kernel][KERNEL] [81143.710000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:49 2013(GMT-0500) [rv180][Kernel][KERNEL] [81144.570000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:49 2013(GMT-0500) [rv180][Kernel][KERNEL] [81144.570000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:49 2013(GMT-0500) [rv180][Kernel][KERNEL] [81144.570000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:49 2013(GMT-0500) [rv180][Kernel][KERNEL] [81144.570000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:49 2013(GMT-0500) [rv180][Kernel][KERNEL] [81144.570000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:49 2013(GMT-0500) [rv180][Kernel][KERNEL] [81144.570000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:49 2013(GMT-0500) [rv180][Kernel][KERNEL] [81144.570000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:49 2013(GMT-0500) [rv180][Kernel][KERNEL] [81144.570000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:49 2013(GMT-0500) [rv180][Kernel][KERNEL] [81144.570000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:54 2013(GMT-0500) [rv180][Kernel][KERNEL] [81149.580000] __ratelimit: 67 callbacks suppressed
Wed Dec 4 20:03:54 2013(GMT-0500) [rv180][Kernel][KERNEL] [81149.580000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:54 2013(GMT-0500) [rv180][Kernel][KERNEL] [81149.720000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:54 2013(GMT-0500) [rv180][Kernel][KERNEL] [81149.740000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:54 2013(GMT-0500) [rv180][Kernel][KERNEL] [81150.280000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:54 2013(GMT-0500) [rv180][Kernel][KERNEL] [81150.330000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:54 2013(GMT-0500) [rv180][Kernel][KERNEL] [81150.440000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:54 2013(GMT-0500) [rv180][Kernel][KERNEL] [81150.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:54 2013(GMT-0500) [rv180][Kernel][KERNEL] [81150.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:54 2013(GMT-0500) [rv180][Kernel][KERNEL] [81150.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:54 2013(GMT-0500) [rv180][Kernel][KERNEL] [81150.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:59 2013(GMT-0500) [rv180][Kernel][KERNEL] [81154.870000] __ratelimit: 85 callbacks suppressed
Wed Dec 4 20:03:59 2013(GMT-0500) [rv180][Kernel][KERNEL] [81154.870000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:59 2013(GMT-0500) [rv180][Kernel][KERNEL] [81155.030000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:00 2013(GMT-0500) [rv180][Kernel][KERNEL] [81155.030000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:00 2013(GMT-0500) [rv180][Kernel][KERNEL] [81155.210000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:00 2013(GMT-0500) [rv180][Kernel][KERNEL] [81155.210000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:00 2013(GMT-0500) [rv180][Kernel][KERNEL] [81155.210000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:00 2013(GMT-0500) [rv180][Kernel][KERNEL] [81155.210000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:00 2013(GMT-0500) [rv180][Kernel][KERNEL] [81155.210000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:00 2013(GMT-0500) [rv180][Kernel][KERNEL] [81155.280000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:00 2013(GMT-0500) [rv180][Kernel][KERNEL] [81155.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:05 2013(GMT-0500) [rv180][Kernel][KERNEL] [81160.100000] __ratelimit: 114 callbacks suppressed
Wed Dec 4 20:04:05 2013(GMT-0500) [rv180][Kernel][KERNEL] [81160.100000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:05 2013(GMT-0500) [rv180][Kernel][KERNEL] [81160.100000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:05 2013(GMT-0500) [rv180][Kernel][KERNEL] [81160.270000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:05 2013(GMT-0500) [rv180][Kernel][KERNEL] [81160.330000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:05 2013(GMT-0500) [rv180][Kernel][KERNEL] [81160.340000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:05 2013(GMT-0500) [rv180][Kernel][KERNEL] [81160.350000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:05 2013(GMT-0500) [rv180][Kernel][KERNEL] [81160.350000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:05 2013(GMT-0500) [rv180][Kernel][KERNEL] [81160.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:05 2013(GMT-0500) [rv180][Kernel][KERNEL] [81160.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:05 2013(GMT-0500) [rv180][Kernel][KERNEL] [81160.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:02 2013(GMT-0500) [rv180][Kernel][KERNEL] [81097.390000] nf_conntrack: table full, dropping packet.
Sat Jan 01 00:00:13 2011 (GMT +0000): [RV180] [IKE] INFO: IKE started

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.

NIC teaming creates packet loss (Windows 2008 R2)?

I'm experiencing some packet loss to all of our VMs that we didn't have before we made some changes to our Hyper-V implementation (Windows 2008 R2). Most of the VMs also run 2008 R2 - with 3 that run Server 2003.
The host server is a Dell R610 with three 4 port NICS - two Intel quad port gigabit and a quad port Broadcom.
We us the individual ports of the Broadcom for host management and live migration - no problems here. We use the Intel cards for both iSCSI and VM networks. Calling the two intel cards “A” and “B”, and the ports P1-4 we've used AP1, AP2, BP1, BP2 (ports
1 & 2 of both Intel NICs) for iSCSI connections, and we've created a NIC Team with AP3, AP4, BP3, and BP4 (ports 3 and 4 of both Intel NICs). The team type is "Virtual Machine Load Balancing". We then created a Hyper-V switch based on this team
for use with all of the VMs created on the host. (as a side note: prior to implementing the NIC team, we just had 4 Hyper-V switches, one associated with each of these 4 ports.)
The 4 ports of the NIC team are connected to two different Cisco SG200 switches - AP3 and BP3 are connected to switch1, and AP4 and BP4 are connected to switch2 (in an attempt to maximize redundancy). The two Cisco SG200s are simply connected to the rest
of our network - each to a different switch within the subnet. There is minimal configuration done to the SG200s (for example NO
link aggregation); spanning tree is enable however.
My question is: can the network cables be connected to different switches (as they currently are) and if so is there some configuration piece (either on the switch or within Windows) that I'm missing?
What are the options here if this configuration is incorrect? The packet loss is in the range of 0.1%, but we've had odd spikes where a VM was essentially unavailable for a brief period (a few minutes) then returned to "normal" (0,1% loss).
Pinging a device (like the SG200 itself) or another physical server (for example our domain controller or the hyper-v host itself) results in essentially 0 loss; maybe one or two packets during the course of a 12 hour ping (this was the “normal” ping
response to VMs before we created the NIC team, so I’m quite sure this has something to do with it).
Thanks in advance!

I believe when utilizing the Virtual Machine Load Balancing the ports must be connected to the same switch, stack, or chassis as the arp for the MAC could move. I believe, although I could be wrong, that the outages you see is when the machine "moves"
between ports and the arp being updated between the two switches.
I believe you are looking for switch fault tolerance teaming which will allow for the failure of adapter, cabling, or switch which will achieve your goal of maximum redundancy. This is achieved via spanning tree on the switches, which you indicated
is already configured.

E4200 - terrible G-only speed, packet loss and throughput variation

Got this router today, was disappointed to see it fail simple performance tests using wireless G on out-of-the-box firmware 1.0.0.1 and after upgrading to 1.0.0.2.
I tried mixed/G/G+B modes, optimal positioning of the router, manual channels 1,5,6,11 and auto channel, security disabled and 5Ghz disabled, rebooting and power cycling - no difference. I also went on to try a total of 3 different laptops again with no difference (they have Atheros, Realtek and Intel chipsets, all 802.11g, no 802.11n)
Uplink and downlink speeds from WLAN to LAN are consistenly poor (tested using Jperf and Qcheck), with uplink to the router being consistently worse. For example, at my favoured location a few metres from the router with very good signal strength, an Orange Livebox 1.2 (or 'Livebox Mini', which is a standard ISP provided router here in the UK) gives rock solid 22Mbps up and down, a humble Sagem 2504N gives rock solid 21Mbps up and down, the E4200 gives about 11Mbps up and 13Mbps down, even though signal strength at this location as reported by Inssider is in fact highest from the E4200. Wherever I try it, like for like, the E4200 throughput underperforms massively for any wireless router let alone a top-of-the-range model. Even right next to the router, I only seem to get an average of about 18Mbps down, not the full 22Mbps I would expect from 802.11g.
I also see great throughput variation on these tests. So, I ran ping tests from the cmd line (from wireless to a wired computer on the E4200), and sure enough there is packet loss. There is no packet loss on any of my other routers. I also put the E4200 into bridge mode and used it as a wireless access point to another router, again there was packet loss and throughput variation. Coming here to post, I saw some other threads about packet loss, I can confirm I am another user seeing the same thing.
Comments/comparisons/ideas for fixes welcome, but I'm sorry to say, this router is obviously going back.

Thanks, but Cisco Connect did not help.
I am using this router as a wireless access point, without connecting a modem to the WAN port. Cisco Connect did not like this one bit and would not proceed because it could not detect an Internet Connection. It then tried to send a report of why installation had failed over the internet
Not that I should have to use Cisco Connect to avoid packet loss and extremely poor speeds anyway! Nothing I have seen in the Linksys documentation or during setup suggests it will alter performance so I don't know how it would help anyway (the router page only warned that configuring manually meant my network could be left unsecured).
I don't know what the speed tests are through Cisco Connect, because I cannot install it and I can't find a user guide to the software, not even on the installation disc. I don't see how these speed tests will change anything though, how can they give meaningful, different results of a simple TCP throughput test, as I performed using Jperf/Iperf and IxChariot.

PAcket loss during gaming

Similar Messages

Maybe you are looking for