Very High Ping/Latency

Good Evening,
For 4-5 weeks, I have been getting very high pings (>1500ms) this occurs randomly throughout the day and night.
I have reported a fault and have been told this is normal for peak times.... however they will request a switch over to Fast Path from Interleave.
Now I'm no Rocket scientist but >1500ms ping in an area with only 200 houses on my exchange IS NOT normal, nor is it even remotely acceptable that i'm told it is!!
Having browsed the web with this IP (my 1st hop) "217.47.106.122", I find many others with EXACTLY the same issue.
Please can someone confirm there is an issue with the above address..
My Area Code is 01851 (Isle of Lewis).
I am aware there is ongoing work to install infinity on Lewis this summer, yet I haven't been informed of any dissruptions.
If I was a betting man I'd say many user's have been rerouted and now as a result is being overloaded.. an oversight no doubt.
Please either confirm this is or at the very least "may" be the case..
Regards
Dan

Looking good!
Tracing route to bbc.co.uk [212.58.246.103]
over a maximum of 30 hops:
1 1 ms 1 ms <1 ms BTHomeHub.home [192.168.1.254]
2 1385 ms 1426 ms 1419 ms 217.47.106.122
3 783 ms 796 ms 847 ms 217.47.106.193
4 1024 ms 1004 ms 1069 ms 213.1.69.78
5 1162 ms 1212 ms 1255 ms 31.55.165.102
6 1356 ms 1359 ms 973 ms 31.55.165.75
7 834 ms 847 ms 906 ms 31.55.165.107
8 1001 ms 1029 ms 1077 ms 109.159.250.52
9 1218 ms 1278 ms 1222 ms core1-te0-13-0-17.ealing.ukcore.bt.net [109.159.250.42]
10 1092 ms 703 ms 626 ms peer2-xe0-0-0.telehouse.ukcore.bt.net [109.159.254.102]
11 644 ms 738 ms 708 ms 194.74.65.42
12 * * * Request timed out.
13 1204 ms 1183 ms 1291 ms ae0.er01.cwwtf.bbc.co.uk [132.185.254.93]
14 1228 ms * 690 ms 132.185.255.165
15 888 ms 904 ms 909 ms fmt-vip132.cwwtf.bbc.co.uk [212.58.246.103]
Trace complete.

Similar Messages

Very High DPC Latency

I've been searching for months, i haven't found a solution. I have a dell 14r, and i've got very high dpc latency, i've disabled Intel speed step, i don't know if it was the cause, but helped a little, but a still have some high DPC.
here's the DPC Conclusion
CONCLUSION
Your system seems to have difficulty handling real-time audio and other tasks. You may experience drop outs, clicks or pops due to buffer underruns. One problem may be related to power management, disable CPU throttling settings in Control Panel and BIOS setup.
Check for BIOS updates.
LatencyMon has been analyzing your system for 0:00:50 (h:mm:ss) on all processors.
SYSTEM INFORMATION
Computer name: ALEF
OS version: Windows 8 , 6.2, build: 9200 (x64)
Hardware: Inspiron 5437, Dell Inc., 01PN4H
CPU: GenuineIntel Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz
Logical processors: 4
Processor groups: 1
RAM: 6048 MB total
CPU SPEED
Reported CPU speed: 1596,0 MHz
Measured CPU speed: 180,0 MHz (approx.)
Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.
WARNING: the CPU speed that was measured is only a fraction of the CPU speed reported. Your CPUs may be throttled back due to variable speed settings and thermal issues. It is suggested that you run a utility which reports your actual CPU frequency and temperature.
MEASURED INTERRUPT TO USER PROCESS LATENCIES
The interrupt to process latency reflects the measured interval that a usermode process needed to respond to a hardware request from the moment the interrupt service routine started execution. This includes the scheduling and execution of a DPC routine, the
signaling of an event and the waking up of a usermode thread from an idle wait state in response to that event.
Highest measured interrupt to process latency (µs): 1572,913052
Average measured interrupt to process latency (µs): 22,366048
Highest measured interrupt to DPC latency (µs): 1565,856753
Average measured interrupt to DPC latency (µs): 11,824275
REPORTED ISRs
Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal.
Highest ISR routine execution time (µs): 364,749373
Driver with highest ISR routine execution time: ndis.sys - NDIS (Especificação de Interface de Driver de Rede), Microsoft Corporation
Highest reported total ISR routine time (%): 0,106754
Driver with highest ISR total time: ndis.sys - NDIS (Especificação de Interface de Driver de Rede), Microsoft Corporation
Total time spent in ISRs (%) 0,133510
ISR count (execution time <250 µs): 21131
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-999 µs): 3
ISR count (execution time 1000-1999 µs): 0
ISR count (execution time 2000-3999 µs): 0
ISR count (execution time >=4000 µs): 0
REPORTED DPCs
DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.
Highest DPC routine execution time (µs): 747,735589
Driver with highest DPC routine execution time: ndis.sys - NDIS (Especificação de Interface de Driver de Rede), Microsoft Corporation
Highest reported total DPC routine time (%): 0,297310
Driver with highest DPC total execution time: ndis.sys - NDIS (Especificação de Interface de Driver de Rede), Microsoft Corporation
Total time spent in DPCs (%) 0,652473
DPC count (execution time <250 µs): 263660
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-999 µs): 253
DPC count (execution time 1000-1999 µs): 0
DPC count (execution time 2000-3999 µs): 0
DPC count (execution time >=4000 µs): 0
REPORTED HARD PAGEFAULTS
Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted
and blocked from execution.
NOTE: some processes were hit by hard pagefaults. If these were programs producing audio, they are likely to interrupt the audio stream resulting in dropouts, clicks and pops. Check the Processes tab to see which programs were hit.
Process with highest pagefault count: explorer.exe
Total number of hard pagefaults 1115
Hard pagefault count of hardest hit process: 493
Highest hard pagefault resolution time (µs): 12225544,827694
Total time spent in hard pagefaults (%): 247,355044
Number of processes hit: 22
PER CPU DATA
CPU 0 Interrupt cycle time (s): 0,761402
CPU 0 ISR highest execution time (µs): 331,166667
CPU 0 ISR total execution time (s): 0,090588
CPU 0 ISR count: 7756
CPU 0 DPC highest execution time (µs): 678,561404
CPU 0 DPC total execution time (s): 0,432507
CPU 0 DPC count: 129558
CPU 1 Interrupt cycle time (s): 1,093584
CPU 1 ISR highest execution time (µs): 364,749373
CPU 1 ISR total execution time (s): 0,177768
CPU 1 ISR count: 13378
CPU 1 DPC highest execution time (µs): 650,636591
CPU 1 DPC total execution time (s): 0,566066
CPU 1 DPC count: 21399
CPU 2 Interrupt cycle time (s): 1,091097
CPU 2 ISR highest execution time (µs): 0,0
CPU 2 ISR total execution time (s): 0,0
CPU 2 ISR count: 0
CPU 2 DPC highest execution time (µs): 747,735589
CPU 2 DPC total execution time (s): 0,292306
CPU 2 DPC count: 112231
CPU 3 Interrupt cycle time (s): 0,461547
CPU 3 ISR highest execution time (µs): 0,0
CPU 3 ISR total execution time (s): 0,0
CPU 3 ISR count: 0
CPU 3 DPC highest execution time (µs): 338,436090
CPU 3 DPC total execution time (s): 0,020591
CPU 3 DPC count: 725

Hi,
Please refer to the article below:
http://blog.tune-up.com/windows-insights/title-poor-jerky-performance-fixing-unacceptably-high-dpc-latency-issues/
Andy Altmann
TechNet Community Support

Internet is back to very high ping + lag again!

So, I posted one similar yesterday and it appeared to have just gone away, however I get on today and the internet is at the laggiest it's been! I really need some help to get rid of this. Any advice please!
Line state:
Connected
Connection time:
0 days, 19:47:15
Downstream:
6.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):
4.9 dB / 23.0 dB
Line attenuation (Down/Up):
43.4 dB / 25.0 dB
Output power (Down/Up):
19.9 dBm / 12.1 dBm
FEC Events (Down/Up):
0 / 6
CRC Events (Down/Up):
2760 / 17
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):
7254 / 1
Error Seconds (Local/Remote):
1766 / 19
bttester
Download - 1.78
upload - 0.05
ping - 200.88

so the problem appears to be with the wifi connection and not the internet as ethernet works ok
you can try downloading inssider3 (istumbler if MAC) and then run it. This will show the broadcasting networks round about you and their channels including your own. If you then enter your router and change your wireless channel to a free or less congested channel.
you can also change hub from b/g/n to just b/g unless all devices have 'n' wifi cards. you can also check to make sure your driver is up to date for wifi cards - check manufacturer's website and not rely on windows update
If you like a post, or want to say thanks for a helpful answer, please click on the Ratings star on the left-hand side of the post.
If someone answers your question correctly please let other members know by clicking on ’Mark as Accepted Solution’.

Very high DPC Latency on W520

Did anyone else noticed any problems with DPC latency on their W520? Using DPC Latency Checker from http://www.thesycon.de/deu/latency_check.shtml I can see huge spikes that happen on average about 2-3 times a minute (sometimes a lot more often), usually reaching over 90000 µs. The threshold that's considered acceptable is 1000 µs. This makes listening to music completely unenjoyable.
I tried killing every non-system process and service but it made no difference, which makes me think that it is driver related. I noticed that the only way to help it is to disable the wifi and unplug the network cable. Obviously, that's not really a solution...
I made sure that both wireless and ethernet drivers are up-to-date but it made no difference.

RikoOnWeb wrote:
rc87 wrote:
I ran that on mine, specs in sign. Average around 160 uS, max 503 uS, so mine is fine
Can you please check the driver versions of your wifi and ethernet drivers?
tried only on wifi, system manager says I have driver 14.1.1.3 just don't remember if I installed from lenovo or through windows update, because I did a clean install from a W7 dvd.
I have the 6205 intel card.
Ethernet driver is 11.12.38.2001, I think this too was from windows update?
W520 on win8.1/linux | X220 | and some older stuff 760 onwards

Slow download, high ping

Hi
I'm seeing very slow download speeds and very high ping numbers recently. Mostly evenings. This evening is bad. For example 0.12 mbits download and 2012ms ping. Does anyone have any ideas? I had similar a couple of years ago and it was my profile. But profile is at 7 figure on current Bt wholesale speed tests.

Thanks, yes results below:
Download speedachieved during the test was - 0.99 Mbps
For your connection, the acceptable range of speeds is 0.6 Mbps-7.15 Mbps.
Additional Information:
Your DSL Connection Rate :8.13 Mbps(DOWN-STREAM), 0.45 Mbps(UP-STREAM)
IP Profile for your line is - 7.15 Mbps
ROUTER DATA&colon;
Basic Status
Device Information
Firmware Version:0.9.1 0.1 v0041.0 Build 140905 Rel.30877n
Hardware Version:Archer D9 v1 00000000
System Up Time:0 day(s) 02:08:26
DSL
Line Status:Connected
DSL Modulation Type:ADSL_G.dmt
Annex Type:Annex A/L
Upstream DownstreamCurrent Rate (Kbps)Max Rate (Kbps)SNR Margin (dB)Line Attenuation (dB)Errors (Pkts)
448
8128
1140
11184
24
15
3
3
0
0

High Pings, slow performance. Good line stats. P...

Hi
I am suffering from very high ping times and variable download speeds. I normally get about 15ms ping and 12-15Mb download. I am currently getting 200-500ms ping times and 1Mb-6Mb download and significant packet loss. Ping test gives me a server in holland as fastest server!
My line stats look fine - problem doesn't seem to be the local loop.
I swapped the ECI modem for a Hauwei from eBay in case that was causing an issue (and so I could access the stats) but it didn't improve things. Any clue? Do you know how to get to someone in BT that I can have a sensible conversation with? I am preparing myself for the usual long drawn out fight with the helpdesk and hours on the phone.
1) Exchange and cabinet details
BT BROADBAND AVAILABILITY CHECKER
Telephone Number *********** on Exchange HARPENDEN is served by Cabinet 49
Featured ProductsDownstream Line Rate(Mbps)Upstream Line Rate(Mbps)Downstream Range(Mbps)Availability Date High Low High Low
FTTC Range A (Clean)
17
10.6
1.3
0.8
Available
FTTC Range B (Impacted)
13.4
5.3
1.2
0.5
Available
WBC ADSL 2+
Up to 2.5
1 to 4
Available
ADSL Max
Up to 2
1 to 3.5
Available
WBC Fixed Rate
1
Available
Fixed Rate
1
Available
Other Offerings
FTTP on Demand
330
30
Available
Fibre Multicast
Available
Copper Multicast
Available
2) DSL Modem Details
Device
Help
Product type
EchoLife HG612
Device ID
10C61F-21530315408K25030366
Hardware version
VER.B
Software version
V100R001C01B030SP08
Firmware version
A2pv6C038m.d24j
Batch number
BC1P6.030.A2pv6C038m.d24j
System up time
0 days 1 hours 18 minutes 15 seconds
3) DSL Line Stats
Connection Status
Help
Mode
VDSL2
Traffic type
PTM
DSL synchronization status
Up
DSL up time
0
Line Status
Help
Downstream
Upstream
Attainable rate (kbit/s)
15524
1134
SNR margin (dB)
30.9
0
Line attenuation (dB)
10.1
10.5
Output power (dBmV)
10.1
10.5
Statistics
Help
Path 0
Path 1
Downstream
Upstream
Downstream
Upstream
Line rate (kbit/s)
14999
1077
0
0
CRC errors
222
138
18
18
FEC errors
0
3
4
0
HEC errors
90
58
32
32
Thanks for your help!

Thanks for the quick response!
BusyBox v1.9.1 (2014-01-21 16:44:38 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
# xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 1134 Kbps, Downstream rate = 15580 Kbps
Bearer: 0, Upstream rate = 1077 Kbps, Downstream rate = 14999 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
Medley Phase (Final) Band Plan
US: (7,32)
DS: (33,859)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 1134 kbps 15580 kbps
Actual Aggregate Tx Power: 10.5 dBm 10.1 dBm
====================================================================================
VDSL Band StatusU0U1U2U3U4D1D2D3
Line Attenuation(dB): 13.4 N/A N/A N/A N/A 28.2 86.8 N/A
Signal Attenuation(dB): 13.4 N/A N/A N/A N/A 44.8 N/A N/A
SNR Margin(dB): 6.8 N/A N/A N/A N/A 6.7 N/A N/A
TX Power(dBm): 10.5 N/A N/A N/A N/A 10.1 N/A N/A

Very high latency on my MBP 3,1 (mid 2007) with airport extreme card 0x168C

Hi
I wanted to let you know that i filled a bug report concerning a problem involving a MacBookPro3,1 and my airport extreme card (AirPort Extreme (0x168C, 0x87) Firmware Version 1.4.16.2)
If you've got any feedback, please feel free to share it with me.
Here's the bug report:
Hello
I'm experiencing very high latency on my MBP when connected using Wi-Fi in my living room and I believe this is a software bug.
This is the trace of my ping test to my router (5m from me):
macbookpro:~ laurent$ ping 192.168.0.254
PING 192.168.0.254 (192.168.0.254): 56 data bytes
64 bytes from 192.168.0.254: icmp_seq=0 ttl=64 time=1536.229 ms
64 bytes from 192.168.0.254: icmp_seq=1 ttl=64 time=536.642 ms
64 bytes from 192.168.0.254: icmp_seq=1 ttl=64 time=3444.466 ms (DUP!)
64 bytes from 192.168.0.254: icmp_seq=2 ttl=64 time=2547.260 ms
64 bytes from 192.168.0.254: icmp_seq=3 ttl=64 time=2671.552 ms
64 bytes from 192.168.0.254: icmp_seq=4 ttl=64 time=1671.272 ms
64 bytes from 192.168.0.254: icmp_seq=5 ttl=64 time=2619.991 ms
64 bytes from 192.168.0.254: icmp_seq=6 ttl=64 time=1619.350 ms
64 bytes from 192.168.0.254: icmp_seq=7 ttl=64 time=2362.474 ms
64 bytes from 192.168.0.254: icmp_seq=8 ttl=64 time=1362.662 ms
64 bytes from 192.168.0.254: icmp_seq=9 ttl=64 time=363.461 ms
64 bytes from 192.168.0.254: icmp_seq=10 ttl=64 time=1407.557 ms
64 bytes from 192.168.0.254: icmp_seq=11 ttl=64 time=1020.437 ms
64 bytes from 192.168.0.254: icmp_seq=12 ttl=64 time=119.570 ms
^C
--- 192.168.0.254 ping statistics ---
14 packets transmitted, 13 packets received, +1 duplicates, 7% packet loss
round-trip min/avg/max/stddev = 119.570/1663.066/3444.466/937.468 ms
These are the details of my network when alt clicking on the network icon:
ca:69:50:37:c7:b2
Channel: 5
RSSI: -54
Transmit Rate: 54
I'm using Channel 5 where my router is the only device available (checked with iStumbler and KissMac).
I compared these results with another computer sitting at the same place:
This is the trace of my ping test to my router using a PC laptop:
C:\Documents and Settings\Laurent>ping -t 192.168.0.254
Envoi d'une requête 'ping' sur 192.168.0.254 avec 32 octets de données :
Réponse de 192.168.0.254 : octets=32 temps=2 ms TTL=64
Réponse de 192.168.0.254 : octets=32 temps=2 ms TTL=64
Réponse de 192.168.0.254 : octets=32 temps=3 ms TTL=64
Réponse de 192.168.0.254 : octets=32 temps=4 ms TTL=64
Réponse de 192.168.0.254 : octets=32 temps=3 ms TTL=64
Réponse de 192.168.0.254 : octets=32 temps=4 ms TTL=64
Réponse de 192.168.0.254 : octets=32 temps=2 ms TTL=64
Réponse de 192.168.0.254 : octets=32 temps=3 ms TTL=64
Réponse de 192.168.0.254 : octets=32 temps=3 ms TTL=64
Réponse de 192.168.0.254 : octets=32 temps=6 ms TTL=64
Réponse de 192.168.0.254 : octets=32 temps=4 ms TTL=64
Réponse de 192.168.0.254 : octets=32 temps=8 ms TTL=64
Réponse de 192.168.0.254 : octets=32 temps=4 ms TTL=64
Réponse de 192.168.0.254 : octets=32 temps=4 ms TTL=64
Réponse de 192.168.0.254 : octets=32 temps=4 ms TTL=64
Réponse de 192.168.0.254 : octets=32 temps=1 ms TTL=64
Statistiques Ping pour 192.168.0.254:
Paquets : envoyés = 16, reçus = 16, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 1ms, Maximum = 8ms, Moyenne = 3ms
(PC: Win XP SP3 with Linksys Wi-Fi card)
Obviously, my Mac has very high latency where my PC works as expected.
I tried resetting the PRAM, but i didn't affect my results.
I tried updating Airport with the latest AirPort Client Update (http://support.apple.com/downloads/AirPortClient_Update_for_MacBook_and_MacBookPro), but my hardware wasn't eligible for that update (Mid 2007 MacBookPro).
I believe this isn't a hardware bug because i get acceptable ping results when next to my router or in other rooms of my flat.
Can you help me with that bug ?
Regards,
Laurent
Hardware Overview:
Model Name: MacBook Pro
Model Identifier: MacBookPro3,1
Processor Name: Intel Core 2 Duo
Processor Speed: 2.2 GHz
Number Of Processors: 1
Total Number Of Cores: 2
L2 Cache: 4 MB
Memory: 2 GB
Bus Speed: 800 MHz
Boot ROM Version: MBP31.0070.B07
SMC Version (system): 1.16f11
Serial Number (system): W874551DX91
Hardware UUID: 00000000-0000-1000-8000-001B63B19195
Sudden Motion Sensor:
State: Enabled
AirPort:
Type: AirPort
Hardware: AirPort
BSD Device Name: en1
IPv4 Addresses: 192.168.0.2
IPv4:
Addresses: 192.168.0.2
Configuration Method: DHCP
Interface Name: en1
NetworkSignature: IPv4.Router=192.168.0.254;IPv4.RouterHardwareAddress=00:07:cb:3e:04:ef
Router: 192.168.0.254
Subnet Masks: 255.255.255.0
DNS:
Server Addresses: 212.27.40.241, 212.27.40.240
DHCP Server Responses:
Domain Name Servers: 212.27.40.241,212.27.40.240
Lease Duration (seconds): 0
DHCP Message Type: 0x05
Routers: 192.168.0.254
Server Identifier: 192.168.0.254
Subnet Mask: 255.255.255.0
Proxies:
Exceptions List: *.local, 169.254/16
FTP Passive Mode: Yes
Ethernet:
MAC Address: 00:1e:52:72:05:2c
Media Options:
Media Subtype: Auto Select
AirPort Card Information:
Wireless Card Type: AirPort Extreme (0x168C, 0x87)
Wireless Card Locale: Worldwide
Wireless Card Firmware Version: 1.4.16.2
Current Wireless Network: kalamar
Wireless Channel: 5

Ok, I must have jinxed myself.
High latency with my Negear WPN824v3. As previously mentioned, the other wireless computers connect fine. Latency remains regardless of the power connected or not.
Please advise.
PING 192.168.0.1 (192.168.0.1): 56 data bytes
64 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=11.607 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=7280.106 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=9209.019 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=8237.475 ms
64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=7262.603 ms
64 bytes from 192.168.0.1: icmp_seq=8 ttl=64 time=4313.763 ms
64 bytes from 192.168.0.1: icmp_seq=9 ttl=64 time=3336.361 ms
64 bytes from 192.168.0.1: icmp_seq=10 ttl=64 time=2339.579 ms
64 bytes from 192.168.0.1: icmp_seq=11 ttl=64 time=1344.110 ms
64 bytes from 192.168.0.1: icmp_seq=12 ttl=64 time=345.132 ms
64 bytes from 192.168.0.1: icmp_seq=13 ttl=64 time=1191.119 ms
64 bytes from 192.168.0.1: icmp_seq=14 ttl=64 time=3969.730 ms
64 bytes from 192.168.0.1: icmp_seq=15 ttl=64 time=3992.111 ms
64 bytes from 192.168.0.1: icmp_seq=16 ttl=64 time=3692.648 ms
64 bytes from 192.168.0.1: icmp_seq=17 ttl=64 time=2927.634 ms
64 bytes from 192.168.0.1: icmp_seq=18 ttl=64 time=2130.216 ms
64 bytes from 192.168.0.1: icmp_seq=19 ttl=64 time=1437.424 ms
64 bytes from 192.168.0.1: icmp_seq=20 ttl=64 time=2385.203 ms
64 bytes from 192.168.0.1: icmp_seq=21 ttl=64 time=1393.622 ms
64 bytes from 192.168.0.1: icmp_seq=22 ttl=64 time=396.783 ms
64 bytes from 192.168.0.1: icmp_seq=23 ttl=64 time=1.295 ms
64 bytes from 192.168.0.1: icmp_seq=24 ttl=64 time=115.793 ms
64 bytes from 192.168.0.1: icmp_seq=25 ttl=64 time=3.137 ms
64 bytes from 192.168.0.1: icmp_seq=26 ttl=64 time=10.240 ms
64 bytes from 192.168.0.1: icmp_seq=27 ttl=64 time=2.709 ms
64 bytes from 192.168.0.1: icmp_seq=28 ttl=64 time=9.958 ms
64 bytes from 192.168.0.1: icmp_seq=29 ttl=64 time=1818.371 ms
64 bytes from 192.168.0.1: icmp_seq=30 ttl=64 time=1470.613 ms
64 bytes from 192.168.0.1: icmp_seq=31 ttl=64 time=472.520 ms
64 bytes from 192.168.0.1: icmp_seq=32 ttl=64 time=2255.417 ms
64 bytes from 192.168.0.1: icmp_seq=33 ttl=64 time=18198.039 ms
64 bytes from 192.168.0.1: icmp_seq=34 ttl=64 time=23288.761 ms
64 bytes from 192.168.0.1: icmp_seq=35 ttl=64 time=25150.840 ms
64 bytes from 192.168.0.1: icmp_seq=36 ttl=64 time=26813.832 ms
^C
--- 192.168.0.1 ping statistics ---
63 packets transmitted, 34 packets received, 46% packet loss
round-trip min/avg/max/stddev = 1.295/4906.111/26813.832/7241.136 ms

Latency is very high when SELECT statements are running for LONG

We are a simple DOWN STREAM streams replication environment ( Archive log is shipped from source , CAPTURE & APPLY are running on destination DB).
Whenever there is a long running SELECT statement on TARGET the latency become very high.
SGA_MAX_SIZE = 8GB
STREAMS_POOL_SIZE=2GB
APPLY parallelism = 4
How can resolve this issue?

Is the log file shipped but not acknowledge? -- NO
Is the log file not shipped? -- It is shipped
Is the log file acknowledged by not applied? -- Yes...But Apply process was not stopped. it may be slow or waiting for something?
It is 10g Environment. I will run AWR.. But what should i look for in AWR?

DPC Latency very high in Games sound and game freezes

5DPC Latency very high in Games sound and game freezes?hello, i am new her. I am german, sry for my Bad englisch. i do my best that you unterstand me...
my problem is very well known in the internet, but i did not find a solution until now...
My Computer:
E6300 @ 3 ghz
Mainboard: Abit Fatalty FP-IN9 with nForce650i-SLI Chipset
4 Gig DDR2 Ram
Win 7 64bit
Soundblaster is a X-fi Titanium PCIe
when i am in windows, look a film on youtube or on my harddisk the DPC Latency is always " green " and i have no freezes in sound or computer
But when i start a Computergame like Starcraft the freezes come, and also the DPC Latency goes red.
http://www.picfront.org/d/7Ngg
I thought the problem is the old Daniel_K 2.0 support pack driver which i installed 6 month ago. I formated my computer todey.
Installed Windows, installed Ati display driver, than installed orginal Creative driver : 2.7.0008 (26. Juli 200). And then i started Starcraft 2 direct but i did not help. Because of that i think i must be a hardware problem...
cya

the Wlan-card was it. How can i solve the problem that i can use my wlan without this freeze problems ?

Very Slow Internet + High Ping

I am on a Sager laptop running Windows 7 and using an Airport Extreme Base Station as my router. I don't know how the router is set up or even how to access the router from my computer. My roommate set up the internet before I moved in. I have already contacted my internet provider and they believe my slow service + extremely high pings when I try to play any online game are a result of my router.
I am just looking for a way to correct my issue. I would also like to know how I can even access my router from my computer. Thanks.

+Is there any way for the owner of the device to limit the amount of bandwidth I am receiving??+
No.
+but I really don't understand why my internet is so crummy.+
Interference from other wireless networks or cordless phones is usually the cause of issues like this. If you have a cordless phone there, turn it off for an hour or so to see if things improve. Unfortunately, there's not much you can do about a neighbor's cordless phone causing problems or another wireless network.
+If I could access the utility what would you suggest I check?+
You can access AirPort Utility by going to the Downloads link on the main forum page. But, you won't be able to access any of the settings on the AirPort Extreme unless you have the device password, which is different than the wireless password. The first thing to do is try different channel settings for the wireless to see if you can find some clear airspace.

0404 USB / CoreAudio Drivers - Latency is very high?

Hello,
I hooked up an 0404 USB to my MacBook Pro. After completing the install, I found that the latency for the 0404 USB using CoreAudio was slightly higher than the latency of the Macbook's integrated sound using CoreAudio. DAW is Ableton Live. 'CoreAudio' was the only device driver option available in Live's Preferences window for the 0404 USB.
As the Emu 0404 USB is a Pro Audio interface designed for recording, I was expecting lower latency than built-in, so I'm wondering if I did something wrong / don't understand. This is my first Mac so I'm in unknown territory in comparison to my extensive background with PC's.
Is this normal? Am I using the correct drivers? Is there an ASIO driver for Mac?
If it's possible for someone from Emu to get back to me on this ASAP, I would really appreciate it, as I'm preparing for an extended period of travel and need to get an interface with low-latency dialed in on my laptop within the next week.
Thanks,
Tom
Message Edited by Tom_D_123 on 03-30-200708:24 AM

Hi,
Please refer to the article below:
http://blog.tune-up.com/windows-insights/title-poor-jerky-performance-fixing-unacceptably-high-dpc-latency-issues/
Andy Altmann
TechNet Community Support

Response times (PING) very high with CAP3602i access point

I have installed an access point CAP3602i in mode HREAP a controller Model 5508 with version 7.4.100.0 but the response times of the connected users are very high.
The less users are connected to the access point is faster surfing the internet and response times are low. But if there are many users connected, increase response times.
I'll be grateful someone comments any experience with this problem.
Thanks

We are talking about 15 users per AP, but that everything is surfing the internet and not so heavy downloads before aps 1141 and had had no such problem response times were normal between 2,3,4 ms
There is performing some function more cap3602i ap causes high response times.
Supposedly CAP3602i I say are better than the 1141, which is why we made the change but we found with surprise that high times.
The SSID was HREAP doubt it has anything to do with the 1141 does not give the issue of high times.

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

Extremely high ping times ( 3000ms) and unusable ...

Hi all,
I am currently at my girlfriends house, trying to do some work but am experiencing absolutely dreadful internet connectivity.
I have just setup a small *nix box plugged directly into the HH4's gigabit ethernet port purely to monitor this abysmal connectivity. Due to the super high latency and low bandwidth for upload / downloads our internet is virtually unusable.
Here are a couple of excerpts from this mornings logged data.
Firstly latency of 4129.204 ms!!!
23/06/15 : 09:09
./speedtest-cli
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from BT (86.165.237.95)...
Selecting best server based on latency...
Hosted by Spectrum Internet (Cardiff) [90.75 km]: 4129.204 ms
Testing download speed........................................
Download: 0.10 Mbit/s
Testing upload speed..................................................
Upload: 0.10 Mbit/s
Secondly ping test to bbc.co.uk again showing very high and varied latency. Avg 1629.844ms high 2361.604ms
PING bbc.co.uk (212.58.244.18) 56(84) bytes of data.
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=1 ttl=50 time=653 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=2 ttl=50 time=730 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=3 ttl=50 time=1188 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=4 ttl=50 time=1529 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=5 ttl=50 time=1464 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=6 ttl=50 time=600 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=7 ttl=50 time=153 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=8 ttl=50 time=491 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=9 ttl=50 time=148 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=10 ttl=50 time=870 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=11 ttl=50 time=1163 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=12 ttl=50 time=1202 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=13 ttl=50 time=1192 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=14 ttl=50 time=1209 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=15 ttl=50 time=1193 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=16 ttl=50 time=644 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=17 ttl=50 time=139 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=18 ttl=50 time=96.6 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=19 ttl=50 time=158 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=20 ttl=50 time=510 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=21 ttl=50 time=653 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=22 ttl=50 time=613 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=23 ttl=50 time=827 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=24 ttl=50 time=829 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=25 ttl=50 time=922 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=26 ttl=50 time=124 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=27 ttl=50 time=94.0 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=28 ttl=50 time=90.9 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=29 ttl=50 time=419 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=30 ttl=50 time=364 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=31 ttl=50 time=358 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=32 ttl=50 time=361 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=33 ttl=50 time=402 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=34 ttl=50 time=382 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=35 ttl=50 time=427 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=36 ttl=50 time=409 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=37 ttl=50 time=443 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=38 ttl=50 time=566 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=39 ttl=50 time=651 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=40 ttl=50 time=580 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=41 ttl=50 time=205 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=42 ttl=50 time=361 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=43 ttl=50 time=372 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=44 ttl=50 time=386 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=45 ttl=50 time=360 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=46 ttl=50 time=381 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=47 ttl=50 time=419 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=48 ttl=50 time=430 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=49 ttl=50 time=408 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=50 ttl=50 time=409 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=51 ttl=50 time=492 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=52 ttl=50 time=709 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=53 ttl=50 time=817 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=54 ttl=50 time=1073 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=55 ttl=50 time=1373 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=56 ttl=50 time=1197 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=57 ttl=50 time=1406 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=58 ttl=50 time=1565 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=59 ttl=50 time=1714 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=60 ttl=50 time=1835 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=61 ttl=50 time=2018 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=62 ttl=50 time=2151 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=63 ttl=50 time=2237 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=64 ttl=50 time=2277 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=65 ttl=50 time=2295 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=66 ttl=50 time=2300 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=67 ttl=50 time=2311 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=68 ttl=50 time=2329 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=69 ttl=50 time=2352 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=70 ttl=50 time=2323 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=71 ttl=50 time=2269 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=72 ttl=50 time=2236 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=73 ttl=50 time=2257 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=74 ttl=50 time=2224 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=75 ttl=50 time=2250 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=76 ttl=50 time=2242 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=77 ttl=50 time=2247 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=78 ttl=50 time=2258 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=79 ttl=50 time=2237 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=80 ttl=50 time=2251 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=81 ttl=50 time=2341 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=82 ttl=50 time=2330 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=83 ttl=50 time=2257 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=84 ttl=50 time=2319 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=85 ttl=50 time=2277 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=86 ttl=50 time=2278 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=87 ttl=50 time=2361 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=88 ttl=50 time=2341 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=89 ttl=50 time=2306 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=90 ttl=50 time=2358 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=91 ttl=50 time=2328 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=92 ttl=50 time=2252 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=93 ttl=50 time=2277 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=94 ttl=50 time=2248 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=95 ttl=50 time=2302 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=96 ttl=50 time=2322 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=97 ttl=50 time=2281 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=98 ttl=50 time=2269 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=99 ttl=50 time=2295 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=100 ttl=50 time=2277 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=101 ttl=50 time=2244 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=102 ttl=50 time=2256 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=103 ttl=50 time=2253 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=104 ttl=50 time=2244 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=105 ttl=50 time=2252 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=106 ttl=50 time=2291 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=107 ttl=50 time=2245 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=108 ttl=50 time=2309 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=109 ttl=50 time=2299 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=110 ttl=50 time=2313 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=111 ttl=50 time=2300 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=112 ttl=50 time=2286 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=113 ttl=50 time=2254 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=114 ttl=50 time=2242 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=115 ttl=50 time=2242 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=116 ttl=50 time=2246 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=117 ttl=50 time=2261 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=118 ttl=50 time=2251 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=119 ttl=50 time=2253 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=120 ttl=50 time=2219 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=121 ttl=50 time=2210 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=122 ttl=50 time=2261 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=123 ttl=50 time=2261 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=124 ttl=50 time=2228 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=125 ttl=50 time=2274 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=126 ttl=50 time=2265 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=127 ttl=50 time=2255 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=128 ttl=50 time=2269 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=129 ttl=50 time=2248 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=130 ttl=50 time=2274 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=131 ttl=50 time=2282 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=132 ttl=50 time=2283 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=133 ttl=50 time=2250 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=134 ttl=50 time=2270 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=135 ttl=50 time=2273 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=136 ttl=50 time=2192 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=137 ttl=50 time=2304 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=138 ttl=50 time=2296 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=139 ttl=50 time=2284 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=140 ttl=50 time=2270 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=141 ttl=50 time=2272 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=142 ttl=50 time=2263 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=143 ttl=50 time=2305 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=144 ttl=50 time=2283 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=145 ttl=50 time=2250 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=146 ttl=50 time=2266 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=147 ttl=50 time=2269 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=148 ttl=50 time=2247 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=149 ttl=50 time=2267 ms
^C
--- bbc.co.uk ping statistics ---
151 packets transmitted, 149 received, 1% packet loss, time 150279ms
rtt min/avg/max/mdev = 90.912/1629.844/2361.604/830.792 ms, pipe 3

Anyone able to advise what to do about this problem?

High Pings and lag in games.

The problem I have is with gaming early in a morning and towards lunch time are usually fine and late a night into the early hours are usually ok aswell but as soon as peak times roll in my online play is impossible due to high pings and very bad lag, any idea what could be causing my problem please?
Steps I have taken to date, contact BT and was passed onto tier 2 tech support who then ran a noise check which last 24 hours on my line, which seems to have left my line with a higher noise value than before.
Tried a different ethernet cable, different micro filter, unplugged everything from the socket except for my Homehub 2, turned off my firewall and virus checker, reset my computer, closed all unused programs. Tried a friends Homehub 2, tried a laptop, all have the same result with high pings and lag in games.
Also BT quote my line speed should be an estimated 17MB.
ADSL line status
Line state
Connected
Connection time
4 days, 22:09:10
Downstream
8,128 Kbps
Upstream
445 Kbps
ADSL settings
VPI/VCI
0/38
Type
PPPoA
Modulation
ITU-T G.992.5
Latency type
Interleaved
Noise margin (Down/Up)
15.6 dB / 30.2 dB
Line attenuation (Down/Up)
24.0 dB / 14.1 dB
Output power (Down/Up)
0.0 dBm / 10.9 dBm
Loss of Framing (Local)
0
Loss of Signal (Local)
0
Loss of Power (Local)
0
FEC Errors (Down/Up)
0 / 0
CRC Errors (Down/Up)
3334 / N/A
HEC Errors (Down/Up)
N/A / 0
Error Seconds (Local)
2211

Test1 comprises of two tests
1. Best Effort Test: -provides background information.
Download Speed
6592 Kbps
0 Kbps
7150 Kbps
Max Achievable Speed
Download speedachieved during the test was - 6592 Kbps
For your connection, the acceptable range of speeds is 2000-7150 Kbps.
Additional Information:
Your DSL Connection Rate :8128 Kbps(DOWN-STREAM), 445 Kbps(UP-STREAM)
IP Profile for your line is - 7170 Kbps
2. Upstream Test: -provides background information.
Upload Speed
363 Kbps
0 Kbps
445 Kbps
Max Achievable Speed
>Upload speed achieved during the test was - 363 Kbps
Additional Information:
Upstream Rate IP profile on your line is - 445 Kbps

Very High Ping/Latency

Similar Messages

Maybe you are looking for