Severe packet loss through tinet

Hi,
i've just spent the evening trying to track down somone at BT tech support who would/could discuss routing/packet loss problems but with no luck.
Essentially i'm trying to contact 206.127.158.1 and suffering very heavy packetloss, this seems to be consistent and not just a 6-8pm thing.
The route has been fine for the past 2 years but began acting up in the last month. The service at the other end is now pretty much unusable (it's a game, GuildWars2/gw2).
I'd very much like to know why/if the routing has changed and if there's anything BT can do to fix it. Other BB providers don't appear to route through the ti-net nodes and don't exhit the problem.
help?
0/ 25 = 0% |
7 25ms 0/ 25 = 0% 0/ 25 = 0% acc2-10GigE-9-2-0.mr.21cn-ipp.bt.net [109.159.250.228]
0/ 25 = 0% |
8 37ms 2/ 25 = 8% 2/ 25 = 8% core1-te0-3-0-13.ilford.ukcore.bt.net [109.159.250.152]
0/ 25 = 0% |
9 31ms 0/ 25 = 0% 0/ 25 = 0% 109.159.252.61
1/ 25 = 4% |
10 37ms 4/ 25 = 16% 3/ 25 = 12% 166-49-211-196.eu.bt.net [166.49.211.196]
0/ 25 = 0% |
11 27ms 1/ 25 = 4% 0/ 25 = 0% 166-49-211-38.eu.bt.net [166.49.211.38]
3/ 25 = 12% |
12 49ms 4/ 25 = 16% 0/ 25 = 0% xe-4-0-1.fra23.ip4.tinet.net [89.149.181.157]
1/ 25 = 4% |
13 42ms 20/ 25 = 80% 15/ 25 = 60% 89.149.164.42
0/ 25 = 0% |
14 --- 25/ 25 =100% 20/ 25 = 80% 206-127-157-86.plaync.com [206.127.157.86]
0/ 25 = 0% |
15 44ms 5/ 25 = 20% 0/ 25 = 0% p4-23-c0-ncdc-pub.plaync.net [206.127.158.1]
Trace complete.

same problem here BT please read this and do something about tinet. I would phone your customer service but it is so awfull I could not bear it
2 35ms 0/ 25 = 0% 0/ 25 = 0% 217.47.106.250
0/ 25 = 0% |
3 --- 25/ 25 =100% 25/ 25 =100% 217.47.105.161
0/ 25 = 0% |
4 42ms 0/ 25 = 0% 0/ 25 = 0% 213.1.69.162
0/ 25 = 0% |
5 --- 25/ 25 =100% 25/ 25 =100% 31.55.165.181
0/ 25 = 0% |
6 41ms 2/ 25 = 8% 2/ 25 = 8% 31.55.165.107
0/ 25 = 0% |
7 102ms 5/ 25 = 20% 5/ 25 = 20% 109.159.250.48
0/ 25 = 0% |
8 109ms 5/ 25 = 20% 5/ 25 = 20% core2-te0-13-0-14.ilford.ukcore.bt.net [109.159.250.46]
0/ 25 = 0% |
9 50ms 0/ 25 = 0% 0/ 25 = 0% peer2-xe3-1-1.telehouse.ukcore.bt.net [109.159.254.233]
2/ 25 = 8% |
10 52ms 3/ 25 = 12% 1/ 25 = 4% t2c3-xe-0-1-2-0.uk-lon1.eu.bt.net [166.49.211.166]
0/ 25 = 0% |
11 50ms 5/ 25 = 20% 3/ 25 = 12% 166-49-211-38.eu.bt.net [166.49.211.38]
0/ 25 = 0% |
12 70ms 2/ 25 = 8% 0/ 25 = 0% xe-4-0-1.fra23.ip4.tinet.net [89.149.181.157]
0/ 25 = 0% |
13 77ms 20/ 25 = 80% 18/ 25 = 72% 89.149.164.42
0/ 25 = 0% |
14 --- 25/ 25 =100% 23/ 25 = 92% 206-127-157-86.plaync.com [206.127.157.86]
0/ 25 = 0% |
15 71ms 2/ 25 = 8% 0/ 25 = 0% p4-23-c0-ncdc-pub.plaync.net [206.127.158.1]

Similar Messages

Change VPN peer according to packet loss

Hi,
We have two vpn peers for redundant. Sometimes one link encounters severe packet loss but is still up. I wonder if there's any method that the vpn peer will swap automatically according to packet loss. I have tried to use ip sla to reroute. However,there's no detailed guide about the ip sla according to packet loss? Thanks

I can change the peer address in the IPSec rule, but is this all that is needed?
- No, tunnel group name must match peer address.
Do I have to add a new tunnel group using the new peer address for the name?
- Yes.
Is it better to make the changes using the CLI?
- I would always recommend it, but if you don't know it you have no option.
Add new tunnel-group with group name as new peer address, same key etc. Add new peer address to peer settings under edit ipsec rule. Then you should be able to remove the old tunnel group. Hope this helps you, been a while since I did it this way.

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.

Help resolving 20-30% packet loss to many sites inc. google and youtube

I've been having issues with pages stop loading, youtube and netflix are not watchable. Netflix will buffer freeze and stop responding. Youtube will load for several seconds then stop buffering. If I refresh the page it will buffer a bit more then stop. Usually to watch a video all the way through you will have to refresh the page 4-5 times per minute of video buffered. Reading forums is also tedious as you have to constantly hit refresh to get pages to finish loading. I’ve been through the standard modem and router reboots, nothing as made a difference.
Sample ping test:
>ping -n 100 google.com
Ping statistics for 74.125.113.105:
Packets: Sent = 100, Received = 76, Lost = 24 (24% loss),
Approximate round trip times in milli-seconds:
Minimum = 48ms, Maximum = 159ms, Average = 55ms
>ping -n 100 verizon.net
Ping statistics for 206.46.232.39:
Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 75ms, Maximum = 110ms, Average = 77ms
>ping -n 100 youtube.com
Ping statistics for 72.14.204.136:
Packets: Sent = 100, Received = 71, Lost = 29 (29% loss),
Approximate round trip times in milli-seconds:
Minimum = 39ms, Maximum = 229ms, Average = 45ms
Speed tests usually report the line around 2MBit. If I connect to the VPN where I work, I do not get packet loss. The fact that the same pings through my VPN do not have the issue leads me to believe its some type of routing issue upstream from my DSLs CO.
Also is there any way I can open an online support ticket that is assigned to a Verizon resource with some chain of accountability. I'm frustrated listening to 10 minutes of automated prompts telling me to reboot the modems to get to a resource that did not understand what I meant by packet loss, then somehow disconnected to start the whole process over again.
Any assistance would be greatly appreciated. Thanks.

#1 Please post the Transceiver Status from your modem.
#2 If you don't know how to get that info:
a) What is the brand and model of your modem?
b) If you have a seperate router: What is the brand and model of it?
#3 Visit http://www.giganews.com/line_info.html and post up the Traceroute the page shows, if you wish. Be aware that the final hop (bottom-most line of the trace) will contain a hop with your IP address in it. Remove that line. What I'm looking for is a line that mentions "ERX" in it's name towards the end. If for some reason the trace does not complete (two lines full of Stars), keep the trace route intact.
If you are the original poster (OP) and your issue is solved, please remember to click the "Solution?" button so that others can more easily find it. If anyone has been helpful to you, please show your appreciation by clicking the "Kudos" button.

E4200 Why huge packet loss at Gig but not 100Mbps?

Vista 64 Intel Pro 1000 with latest driver Here is a shot of the lagometer in COD Black Ops when all is good. I used to see this with my old WRT54GS and connected at 100Mbps Full Duplex or Half Duplex and I currently see this when connected through the E4200 at 100Mbps full or half duplex AND when connected via Gigabit via one of the 4 ports on the back of my cable modem, a Motorola SBG6580 [img]http://photos.smugmug.com/1590700194_rFrtpkV-O-LB.jpg[/img] This next screen capture is what happens when I try to connect via Gigabit thru the E4200. It either starts out like this right away or within 30 seconds to a minute this will start to occur. I believe the red spikes indicate packet loss. [img]http://photos.smugmug.com/1590700217_SWKtMP3-O-LB.jpg[/img] .
Solved!
Go to Solution.

It shows the IP address assigned by the ISP that I'm used to seeing.... 24:207:n:n:n:n:n:n .... under the IPv4 info.
I also have IPv6 enabled and I notice under those listings just.... 0:0:0:0:0:0:0:0 ....which is what I'd expect if IPv6 is not yet in use by by ISP.
I've been running a lot of other tests here with various configurations including substituting my old WRT54GS for the E4200. I currently have several devices off an 8 port Gig unmanaged switch and all is fine as long as I have my Intel Pro 1000 NIC set to 100Mbps full or half duplex moe. If I set it to 1000Mbps and connect it via the 8 port hub or the ports off the back of the E4200, soon after the E4200 starts to go wierd for all systems connected. Running Speedtest.org shows a huge increse in ping if I'm lucky enough to get the page to load that far. It does not seem to make any difference that my laptop connects reliably via Gig, just the PC with the Intel card. I've gone out and bought a new Intel Pro 1000 and will stick that in later this evening.
Thanks for your replies btw.

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.

7613 Router - Packet-loss on a LAN link between 6704 and ES 2T

Hi
After connecting two ends of a 10 Gig LAN Link from a 6704 on one 7613 to a ES 2T on another 7613 , then we have packet loss on that link beyond a specific traffic limit !
Please note that after changing both boards to ES 2T we have no problem and LAN/WAN mode is also checked .

Ash wrote:
It's dropping pings, you can see that clearly from the above. It's intermittent. Whilst a drop in pings isn't the definitive sign of packetloss, the way in which it's doing it is.
If it was going to drop it through flooding it simply wouldn't respond at all after the first few. It it was configured to not respond, it simply wouldn't.
Pings to any external source - (not to the device itself) are also failing intermittently. This indicates that a device along the traffic path is having issues.
I can screenshot a nice disconnection plug in games, but there's no real need.
The evidence is there if you know how to interpret it. This needs to be investigated.
A question for you then!
What happens when your router gets repeated pings from the same source?
Does it not block them as a possible DDOS attack?
The more gamers try this tactic the worse their traces will get & it will more than likely also affect other gamers interested in low latency through these same nodes!
Check the timings between the true source & destination by all means but please do not
unnecessarily stress individual points on the main ISP network backbones!
"I have this awful feeling someone is watching every move I make (one of my pet hates is router location tagging)." Marvin (A paranoid Android)

Packet Loss When Extending Network?

Hi there, everyone.
I just purchased the Airport Extreme AC after upgrading to 802.11AC devices in the home. On its own, the Extreme AC performs flawlessly - consistent connections, max speed my ISP provides, no-lag, no studdering, no packet loss. I was dissapointed with the range of the device at the far ends of my home, so I set up my previous generation Airport Extreme to extend the network.
It extends the network fine, speeds are about half of what I get at the source, but the issue is that when it is part of the network, I experience packet loss, anywhere from 3% to 8%. I've tested this multiple times, unplugging, testing, replugging, testing. It happens both wirelessly and through ethernet. The issue is no question caused by the previous gen Airport extending the network.
Any help here would be great!
Setup:
- Motorla Surfboard SB6141
- WAN into Airport Extreme AC
- Previous generation Airport Extreme to extend the network, no special settings.
Don't be afraid to use techincal terminology to help me. I can follow and understand the majority of it, as I'm pretty into all of this.

I'm not aware of anything that has changed in the 802.11ac version of the AirPort base stations that would induce the packet loss that you are seeing with an extended network over using an earlier generation. I am assuming, of course, that you are extending another Apple wireless router ... correct?
Typically I would recommend that you would review the placement of the extending base station to be sure that it is in the optimal spot to reproduce the signal with the greatest amount of bandwidth possible. (Ref: This AirPort User Tip)

Packet loss when flood pinging a Mac

I had some trouble transferring large files between my iMac and my MBP the other day and so started a bit of investigation. Mistake really - here is what I found:
All mac targets are running up-to-date Leopard and use intel processors.
The home network has a linksys wireless router - all devices connected by copper.
flood ping tests with command 'sudo ping -f <target>:
from iMac to MBP shows 30% packet loss
from MBP tp iMac shows 33% packet loss
from iMac to windows laptop 0% packet loss
from iMac to linksys router 0% packet loss
from iMac to Freecom NAS box 0% packet loss
from MBP to windows laptop 0% packet loss
from MBP to linksys router 0% packet loss
from MBP to Freecom NAS box 0% packet loss
I took the macbook to work and picked targets on another site, several busy switch hops away.
from MBP to windows desktop 0% packet loss
from MBP to another iMac 26% packet loss
from MBP to mac mini 28% packet loss
from MBP to linux server 0% packet loss
from linux server to MBP 32% packet loss
The firewall is off on all the targets.
Seem clear enough - Mac machines can't handle high ping loads. It is no good telling me they don't have to. If they can answer a ping at all, they should be able to handle the load. It is a perfectly acceptable way of stress testing the link. File transfers are generally not an issue but now I want to know...
Why can't the macs handle the ping floods?
Is this indicative of any other weakness in the IP stack?
Pete

I had a suspicion of packet loss on my internet connection but could not be certain it was the ISP at fault. The fact that I had been having trouble transferring large files between my machines led me to look for possible local problems.
Network fault finding should always examine the hardware first so I wanted to see if there was anything about the cabling or the router which might be causing packet loss.
Actually copying data about the network is a pretty poor way to test things because you have several additional layer of complexity that can colour the results.
When I had narrowed down the flood ping packet loss to the macs, I went hunting on the 'net. There were plenty of people who were reporting various kinds of packet loss. Enough of them that I wondered if there was something more to it. Some of them were talking about similar symptoms to mine. The respondents usually answered a question other than the one asked so I thought I would put up some tests and see if there was actually a problem anywhere.
Now I know it is a 'feature' rather than a fault, I can work around it.
Thanks anyway
Pete

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).

50% Packet Loss on VoIP/Video calls

HI,
When making VoIP or video calls I'm getting up to 50% packet loss. I'm struggling to find out what is causing the problem. When I make a video call I have, at the same time, run speedtest.net and it is still providing adequate bandwidth so I know that is not the cause. The packet loss seems to come and go so it will be fine for a few seconds and then goes up to 50% for a few seconds and then keeps cycling.
-Dave

Ash wrote:
It's dropping pings, you can see that clearly from the above. It's intermittent. Whilst a drop in pings isn't the definitive sign of packetloss, the way in which it's doing it is.
If it was going to drop it through flooding it simply wouldn't respond at all after the first few. It it was configured to not respond, it simply wouldn't.
Pings to any external source - (not to the device itself) are also failing intermittently. This indicates that a device along the traffic path is having issues.
I can screenshot a nice disconnection plug in games, but there's no real need.
The evidence is there if you know how to interpret it. This needs to be investigated.
A question for you then!
What happens when your router gets repeated pings from the same source?
Does it not block them as a possible DDOS attack?
The more gamers try this tactic the worse their traces will get & it will more than likely also affect other gamers interested in low latency through these same nodes!
Check the timings between the true source & destination by all means but please do not
unnecessarily stress individual points on the main ISP network backbones!
"I have this awful feeling someone is watching every move I make (one of my pet hates is router location tagging)." Marvin (A paranoid Android)

Constant Packet Loss

Hello, over the past month I have been recieving terrible quality over ventrilo (a VOIP program), terrible lagging in online games, and even when browsing the internet I often have to refresh a web page several times to get it to show up. At first I thought it was just my internet having an off week so I waited a while, but the problem continued. I'm not too good with routers, modems and internet connections etc, but I talked to some friends and did some googling and was pointed towards packet loss as a possible cause, so I ran some tests and here are the results I got, which seem to indicate a lot of packet loss. www.pingtest.com sometimes reports up to 50%.
http://i54.tinypic.com/2uj4fiu.jpg
http://i55.tinypic.com/zupget.jpg
http://i53.tinypic.com/29d71xw.jpg
http://i55.tinypic.com/30jhhn7.jpg
I'm using a BT home hub (I really don't know what model and I can't find anything in the home hub program or on the physical hub that tells me the model, it's white and a couple of years old though.)
I really have no idea how to find the cause via the info, since as I said I don't really know a lot about it. Would appreciate any help in finding the cause so I can call BT, or even better find a fix I could do myself.

Took several tries to get the speed test to complete, left it running for an hour at one point :
http://i52.tinypic.com/16j1nc3.jpg
The ADSL Line details :
Uptime:
0 days, 8:43:37
Modulation:
G.992.1 annex A
Bandwidth (Up/Down) [kbps/kbps]:
448 / 2,368
Data Transferred (Sent/Received) [MB/MB]:
87.69 / 349.78

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.

VoIP Phones - Testing Latency, Jitter, and Packet Loss

I am having big problems with my VoIP phone connection and I'll try to lay it out clearly here.
The main telephone system resides at Location A (static IP address - see below - xxx.xxx.206.19), which has a network connection of 50MB down/20MB up (i.e., very fast). The VoIP phone configured for that system resides at Location B, which has a network connection of 10MB down/1MB up (i.e., also fast, or at least fast enough "on paper" for a quality VoIP connection). The LAN at Location A uses an Airport Extreme router, which does not have QOS or EF capability. The LAN at Location B uses a D-Link DIR-655 router which does have QOS that is configured properly to direct all traffic to the VoIP phone's IP address.
The VoIP phone at Location B is having intermittent call quality problems with skipping of words, hollowing out noises, jittery conversations, etc. All the inquiries I've made to the ISPs and phone system manufacturer (ESI) suggest that my base Internet speeds are not the problem.
I'm told, instead, that the problem might be latency, jitter, or packet loss between Location A and Location B. This leads to several questions:
(1)     Is there any Mac software that can test latency, jitter, and packet loss? I've looked at Network Utility and it seems to only measure a few things.
(2)     Does anyone see anything in the following Traceroute and Ping results (done twice from Location B to Location A) that looks problematic to VoIP quality?:
Traceroute:
First run: Traceroute has started…
traceroute to xxx.xxx.206.19 (xxx.xxx.206.19), 64 hops max, 72 byte packets
1 alfirving (192.168.0.1) 0.569 ms 0.363 ms 0.302 ms
2 10.72.28.1 (10.72.28.1) 27.567 ms 18.161 ms 22.288 ms
3 70.125.216.150 (70.125.216.150) 9.841 ms 10.346 ms 9.497 ms
4 24.164.209.116 (24.164.209.116) 11.042 ms 8.298 ms 9.433 ms
5 70.125.216.108 (70.125.216.108) 21.068 ms 20.657 ms 12.045 ms
6 te0-8-0-2.dllatxl3-cr01.texas.rr.com (72.179.205.48) 11.154 ms 11.540 ms 24.495 ms
7 107.14.17.136 (107.14.17.136) 11.994 ms 14.217 ms 15.816 ms
8 ae-3-0.pr0.dfw10.tbone.rr.com (66.109.6.209) 14.566 ms 32.670 ms 15.947 ms
9 ix-0-3-2-0.tcore2.dt8-dallas.as6453.net (209.58.47.105) 11.647 ms 12.260 ms 12.386 ms
10 if-2-2.tcore1.dt8-dallas.as6453.net (66.110.56.5) 10.023 ms 12.285 ms 12.338 ms
11 209.58.47.74 (209.58.47.74) 17.641 ms 16.741 ms 16.372 ms
12 0.ae2.xl3.dfw7.alter.net (152.63.97.57) 11.584 ms 12.315 ms 12.890 ms
13 0.so-6-1-0.dfw01-bb-rtr1.verizon-gni.net (152.63.1.90) 13.812 ms
    0.ge-3-0-0.dfw01-bb-rtr1.verizon-gni.net (152.63.1.17) 18.831 ms
    130.81.23.164 (130.81.23.164) 14.189 ms
14 p14-0-0.dllstx-lcr-05.verizon-gni.net (130.81.27.40) 14.561 ms 13.621 ms 15.544 ms
15 * * *
16 static-xxx.xxx.206.19.dllstx.fios.verizon.net (xxx.xxx.206.19) 23.125 ms 24.136 ms 22.411 ms
Second run: Traceroute has started…
traceroute to xxx.xxx.206.19 (xxx.xxx.206.19), 64 hops max, 72 byte packets
1 alfirving (192.168.0.1) 0.603 ms 0.420 ms 0.324 ms
2 10.72.28.1 (10.72.28.1) 40.494 ms 26.625 ms 14.152 ms
3 70.125.216.150 (70.125.216.150) 9.431 ms 9.660 ms 9.018 ms
4 24.164.209.116 (24.164.209.116) 16.293 ms 12.339 ms 19.252 ms
5 70.125.216.108 (70.125.216.108) 15.801 ms 11.438 ms 12.068 ms
6 te0-8-0-2.dllatxl3-cr01.texas.rr.com (72.179.205.48) 23.221 ms 30.459 ms 17.519 ms
7 107.14.17.136 (107.14.17.136) 14.611 ms 15.696 ms 15.775 ms
8 ae-3-0.pr0.dfw10.tbone.rr.com (66.109.6.209) 17.643 ms 14.812 ms 16.294 ms
9 ix-0-3-2-0.tcore2.dt8-dallas.as6453.net (209.58.47.105) 11.169 ms 12.374 ms 9.849 ms
10 if-2-2.tcore1.dt8-dallas.as6453.net (66.110.56.5) 16.453 ms 12.168 ms 12.384 ms
11 209.58.47.74 (209.58.47.74) 18.015 ms 14.867 ms 16.432 ms
12 0.ae2.xl3.dfw7.alter.net (152.63.97.57) 11.471 ms 11.993 ms 12.395 ms
13 0.ge-6-3-0.dfw01-bb-rtr1.verizon-gni.net (152.63.96.42) 14.077 ms 29.153 ms
    0.ge-3-0-0.dfw01-bb-rtr1.verizon-gni.net (152.63.1.17) 17.962 ms
14 p14-0-0.dllstx-lcr-05.verizon-gni.net (130.81.27.40) 14.629 ms 12.297 ms 12.839 ms
15 * * *
16 static-xxx.xxx.206.19.dllstx.fios.verizon.net (xxx.xxx.206.19) 24.976 ms 22.170 ms 22.376 ms
Ping:
First Run: Ping has started…
PING xxx.xxx.206.19 (xxx.xxx.206.19): 56 data bytes
64 bytes from xxx.xxx.206.19: icmp_seq=0 ttl=242 time=22.814 ms
64 bytes from xxx.xxx.206.19: icmp_seq=1 ttl=242 time=24.621 ms
64 bytes from xxx.xxx.206.19: icmp_seq=2 ttl=242 time=24.711 ms
64 bytes from xxx.xxx.206.19: icmp_seq=3 ttl=242 time=24.109 ms
64 bytes from xxx.xxx.206.19: icmp_seq=4 ttl=242 time=23.336 ms
64 bytes from xxx.xxx.206.19: icmp_seq=5 ttl=242 time=25.644 ms
64 bytes from xxx.xxx.206.19: icmp_seq=6 ttl=242 time=27.755 ms
64 bytes from xxx.xxx.206.19: icmp_seq=7 ttl=242 time=25.135 ms
64 bytes from xxx.xxx.206.19: icmp_seq=8 ttl=242 time=22.443 ms
64 bytes from xxx.xxx.206.19: icmp_seq=9 ttl=242 time=24.635 ms
--- xxx.xxx.206.19 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 22.443/24.520/27.755/1.448 ms
Second Run: Ping has started…
PING xxx.xxx.206.19 (xxx.xxx.206.19): 56 data bytes
64 bytes from xxx.xxx.206.19: icmp_seq=0 ttl=242 time=27.183 ms
64 bytes from xxx.xxx.206.19: icmp_seq=1 ttl=242 time=24.629 ms
64 bytes from xxx.xxx.206.19: icmp_seq=2 ttl=242 time=22.511 ms
64 bytes from xxx.xxx.206.19: icmp_seq=3 ttl=242 time=39.620 ms
64 bytes from xxx.xxx.206.19: icmp_seq=4 ttl=242 time=26.722 ms
64 bytes from xxx.xxx.206.19: icmp_seq=5 ttl=242 time=23.183 ms
64 bytes from xxx.xxx.206.19: icmp_seq=6 ttl=242 time=25.171 ms
64 bytes from xxx.xxx.206.19: icmp_seq=7 ttl=242 time=24.412 ms
64 bytes from xxx.xxx.206.19: icmp_seq=8 ttl=242 time=23.837 ms
64 bytes from xxx.xxx.206.19: icmp_seq=9 ttl=242 time=23.785 ms
--- xxx.xxx.206.19 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 22.511/26.105/39.620/4.713 ms
(3) Any other ideas on what my call quality problem might be, or how I can tweak it? For example, would putting a DIR-655 router at Location A and enabling QOS really make a difference?
Thanks to everyone, and I hope this is not too long or difficult to understand.

Hey thanks for your reply Yeah im only getting 1 ro sometimes 2 bars reception so hopefully the antenna will beef things up but I think it is what it is perhaps.

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.

Severe packet loss through tinet

Similar Messages

Maybe you are looking for