I am using a VOIP softphone. When at my office this works fine, but
when I am working from home I get massive jitter and delay in response.
I am wondering if my home wireless network 802.11G could be the cause.
When I connect to my router directly with an ethernet cable, the IP
Softphone seems to work much better with less jitter.
I don't really understand that as my laptop is only a couple of metres
from the router in clear line of site and I have a solid 54MBPS
connection on wireless.
I am not sure if I could also have a latency issue - I seem to have
ping times of 120ms to the my companies' servers in the US which is
where the IP phone exchange is located.
Is it normal to expect much worse performance on an IP softphone when
going over a local wireless network?
I would say that it's normal to expect worse performance on wireless
altogether. You have to remember, radio waves are susceptible to many
things that wires arent. Honestly, 120ms on VoIP is a lot, and I'm
surprised you're making calls that are decent at all.
On 7 Nov 2006 01:50:29 -0800, warner_patrick@hotmail.com wrote in
<1162893029.579420.237940@k70g2000cwa.googlegroups .com>:
>I am using a VOIP softphone. When at my office this works fine, but
>when I am working from home I get massive jitter and delay in response.
That's probably a result of enough wireless interference to cause lots
of transmission errors.
>I am wondering if my home wireless network 802.11G could be the cause.
>When I connect to my router directly with an ethernet cable, the IP
>Softphone seems to work much better with less jitter.
>
>I don't really understand that as my laptop is only a couple of metres
>from the router in clear line of site and I have a solid 54MBPS
>connection on wireless.
Interference can still be a problem. See types and remedies in the
wikis below.
>I am not sure if I could also have a latency issue - I seem to have
>ping times of 120ms to the my companies' servers in the US which is
>where the IP phone exchange is located.
>
>Is it normal to expect much worse performance on an IP softphone when
>going over a local wireless network?
No. Absent interference, latency of Wi-Fi is quite low.
Try different Wi-Fi channels with minimal overlap: 1, 6, and 11.
--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>
Maker and model number of softphone?
Maker and model number of the wireless router you're using?
>When at my office this works fine, but
>when I am working from home I get massive jitter and delay in response.
>
>I am wondering if my home wireless network 802.11G could be the cause.
>When I connect to my router directly with an ethernet cable, the IP
>Softphone seems to work much better with less jitter.
>
>I don't really understand that as my laptop is only a couple of metres
>from the router in clear line of site and I have a solid 54MBPS
>connection on wireless.
>
>I am not sure if I could also have a latency issue - I seem to have
>ping times of 120ms to the my companies' servers in the US which is
>where the IP phone exchange is located.
>
>Is it normal to expect much worse performance on an IP softphone when
>going over a local wireless network?
Assuming nothing is defective, your home system probably has either a
weak signal, reflection problems, or interference. All of these
result in packet loss (at the MAC layer) which shows up as latency
variations. The few softphones I've tinkered with all have a built in
ping utility. Fire up the utility, and ping your unspecified model
wireless router utility. If your unspecified model (are you getting
the hint?) softphone does not have a ping utility, ping the phones IP
address from another PC on your network that is plugged directly into
your unspecified model wireless router.
You should see *CONSISTENT* ping times with 1 or perhaps 2 msec
latency. However, if you see something like this:
Reply from 192.168.1.50: bytes=32 time=6ms TTL=127
Reply from 192.168.1.50: bytes=32 time=12ms TTL=127
Request timed out.
Reply from 192.168.1.50: bytes=32 time=66ms TTL=127
Reply from 192.168.1.50: bytes=32 time=1ms TTL=127
Reply from 192.168.1.50: bytes=32 time=1ms TTL=127
Reply from 192.168.1.50: bytes=32 time=5ms TTL=127
you have a problem. The normal latency on this wireless link is 1
msec. The other values are packet loss and retransmissions cause in
this case by interference from another nearby network. I can usually
guess the cause by watching the numbers. Do whatever is necessary to
get it to always be 1msec (or less).
If you get fairly consistent ping times, then something else is the
problem. Usually its someone else using your broadband network and
hogging all the outgoing bandwidth. This is why most current routers
have a QoS feature, that will allow prioritization of packets. VoIP
packets come first. File sharing and Peer to Peer networking comes
last. You may also have a worm or trojan horse running on a local PC
that's hogging all the outgoing bandwidth. Try the softphone with all
the other computers in the house turned off and see if that helps.
>I would say that it's normal to expect worse performance on wireless
>altogether. You have to remember, radio waves are susceptible to many
>things that wires arent. Honestly, 120ms on VoIP is a lot, and I'm
>surprised you're making calls that are decent at all.
>
>Chris
>http://www.netsteady.cc
Sorta kinda maybe. 120msec latency is no problem as long as it's a
consistent 120msec latency. For example, I have a customer that uses
Skype and other VoIP phone systems over a DirecWay satellite link.
Latency is typically 800msec. When traffic is minimal and the latency
is consistently 800msec, there's no problem using the satellite link
(except for having to say "over" at the end of each phrase).
Admittedly, that's not very often, but it does work. Similarly, Skype
VoIP works just fine over a dialup connection, which usually has 120
to 200msec latency. The point is that if the latency does not vary,
VoIP will work fine.
In the case of wireless, the minimal latency is basically the
processing time of the devices at each end. Flight time is at the
speed-o-light which is negligible unless you try for long distance
(over 5 mile) links. The effect is the same. Consistent latency will
cause a delay or echo, but not garble the voice. Varying latency will
sound like gargling ball bearing.
802.11 uses a CSMA/CA MAC protocol with a exponential backoff contention
window. So, in case of your wireless channel is shared with other
devices (802.11, bluetooth, home devices like microwave ovens, TV
transmiters, etc.) at the same band, then you are making use of the
backoff contention window and then you are using a random time to access
channel. So your jitter can be cancelled by means of buffers. The
greater the buffer the greater delay. But if the buffer is too short you
con run out of it.
Also if you generate packets at a high rate, you can force yourself to
make use of contention window although your wireless networks is made of
one wireless station.
Maybe a first simple solution be a change in transmission channel.
Best regards.
warner_patrick@hotmail.com escribió:
> Hi all,
>
> I am using a VOIP softphone. When at my office this works fine, but
> when I am working from home I get massive jitter and delay in response.
>
> I am wondering if my home wireless network 802.11G could be the cause.
> When I connect to my router directly with an ethernet cable, the IP
> Softphone seems to work much better with less jitter.
>
> I don't really understand that as my laptop is only a couple of metres
> from the router in clear line of site and I have a solid 54MBPS
> connection on wireless.
>
> I am not sure if I could also have a latency issue - I seem to have
> ping times of 120ms to the my companies' servers in the US which is
> where the IP phone exchange is located.
>
> Is it normal to expect much worse performance on an IP softphone when
> going over a local wireless network?
>
> cheers for any comments on this.
>
On Tue, 07 Nov 2006 09:52:55 -0800, Jeff Liebermann
<jeffl@comix.santa-cruz.ca.us> wrote in
<09h1l2t5i3lmq0cmpl4jm2slp65i0icfrd@4ax.com>:
>"NetSteady" <cmhutch@gmail.com> hath wroth:
>
>>I would say that it's normal to expect worse performance on wireless
>>altogether. You have to remember, radio waves are susceptible to many
>>things that wires arent. Honestly, 120ms on VoIP is a lot, and I'm
>>surprised you're making calls that are decent at all.
>>
>>Chris
>>http://www.netsteady.cc
>
>Sorta kinda maybe. 120msec latency is no problem as long as it's a
>consistent 120msec latency. For example, I have a customer that uses
>Skype and other VoIP phone systems over a DirecWay satellite link.
>Latency is typically 800msec. When traffic is minimal and the latency
>is consistently 800msec, there's no problem using the satellite link
>(except for having to say "over" at the end of each phrase).
>Admittedly, that's not very often, but it does work. Similarly, Skype
>VoIP works just fine over a dialup connection, which usually has 120
>to 200msec latency. The point is that if the latency does not vary,
>VoIP will work fine.
Dialup with a good modem should add less than 120 ms latency. If it
adds more than that, either the modem is crappy, or something else is
wrong (e.g., crappy ISP).
--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>
On Tue, 07 Nov 2006 09:39:52 -0800, Jeff Liebermann
<jeffl@comix.santa-cruz.ca.us> wrote in
<8jg1l2d5dq3flgt4bi5nvo14j05c51l5og@4ax.com>:
>If you get fairly consistent ping times, then something else is the
>problem. Usually its someone else using your broadband network and
>hogging all the outgoing bandwidth. This is why most current routers
>have a QoS feature, that will allow prioritization of packets. VoIP
>packets come first. File sharing and Peer to Peer networking comes
>last. You may also have a worm or trojan horse running on a local PC
>that's hogging all the outgoing bandwidth. Try the softphone with all
>the other computers in the house turned off and see if that helps.
Another likely cause of high/inconsistent latency is saturation of
broadband uplink, which isn't addressed by the QoS in most low-end
routers. No matter what the packet priority, saturation of the uplink
on typical consumer (asymmetric) broadband results in severe downlink
speed degradation and big latency spikes. The only way to resolve that
is with uplink throttling, either in the client computer or in the
router.
--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>
> Maker and model number of the wireless router you're using?
BT Homehub (I am in the UK and this is the router supplied by BT who
are my ISP).
> Assuming nothing is defective, your home system probably has either a
> weak signal, reflection problems, or interference. All of these
> result in packet loss (at the MAC layer) which shows up as latency
> variations. The few softphones I've tinkered with all have a built in
> ping utility. Fire up the utility, and ping your unspecified model
> wireless router utility. If your unspecified model (are you getting
> the hint?) softphone does not have a ping utility, ping the phones IP
> address from another PC on your network that is plugged directly into
> your unspecified model wireless router.
When you say ping the phone's IP address, you mean ping the computer
that the phone is running on?
>
> You should see *CONSISTENT* ping times with 1 or perhaps 2 msec
> latency. However, if you see something like this:
>
> Reply from 192.168.1.50: bytes=32 time=6ms TTL=127
> Reply from 192.168.1.50: bytes=32 time=12ms TTL=127
> Request timed out.
> Reply from 192.168.1.50: bytes=32 time=66ms TTL=127
> Reply from 192.168.1.50: bytes=32 time=1ms TTL=127
> Reply from 192.168.1.50: bytes=32 time=1ms TTL=127
> Reply from 192.168.1.50: bytes=32 time=5ms TTL=127
>
> you have a problem. The normal latency on this wireless link is 1
> msec. The other values are packet loss and retransmissions cause in
> this case by interference from another nearby network. I can usually
> guess the cause by watching the numbers. Do whatever is necessary to
> get it to always be 1msec (or less).
First, I pinged my router from the computer where the softphone is
running 72 times and got 2 long response times out of 72 - the rest
were 1ms.
However a few minutes later I tried again and got the following:
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Reply from 192.168.1.254: bytes=32 time=150ms TTL=64
Reply from 192.168.1.254: bytes=32 time=38ms TTL=64
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Reply from 192.168.1.254: bytes=32 time=2ms TTL=64
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Reply from 192.168.1.254: bytes=32 time=150ms TTL=64
Reply from 192.168.1.254: bytes=32 time=140ms TTL=64
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Reply from 192.168.1.254: bytes=32 time=150ms TTL=64
Reply from 192.168.1.254: bytes=32 time=140ms TTL=64
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Reply from 192.168.1.254: bytes=32 time=150ms TTL=64
Reply from 192.168.1.254: bytes=32 time=33ms TTL=64
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
So it looks like I have an issue but it's intermittent?
When you say you can guess the cause by watching the numbers, do you
mean that there is some pattern in the dropouts that is consistent with
some other device in the area or what?
>
> If you get fairly consistent ping times, then something else is the
> problem. Usually its someone else using your broadband network and
> hogging all the outgoing bandwidth. This is why most current routers
> have a QoS feature, that will allow prioritization of packets. VoIP
> packets come first. File sharing and Peer to Peer networking comes
> last. You may also have a worm or trojan horse running on a local PC
> that's hogging all the outgoing bandwidth. Try the softphone with all
> the other computers in the house turned off and see if that helps.
>
> --
> Jeff Liebermann jeffl@comix.santa-cruz.ca.us
> 150 Felker St #D http://www.LearnByDestroying.com
> Santa Cruz CA 95060 http://802.11junk.com
> Skype: JeffLiebermann AE6KS 831-336-2558
Thanks for you input on that. This QoS feature - if I have it will it
work automatically or do I need to configure it?
On Tue, 07 Nov 2006 18:50:23 GMT, John Navas
<spamfilter0@navasgroup.com> wrote:
>On Tue, 07 Nov 2006 09:52:55 -0800, Jeff Liebermann
><jeffl@comix.santa-cruz.ca.us> wrote in
><09h1l2t5i3lmq0cmpl4jm2slp65i0icfrd@4ax.com>:
>
>>"NetSteady" <cmhutch@gmail.com> hath wroth:
>>
>>>I would say that it's normal to expect worse performance on wireless
>>>altogether. You have to remember, radio waves are susceptible to many
>>>things that wires arent. Honestly, 120ms on VoIP is a lot, and I'm
>>>surprised you're making calls that are decent at all.
>>>
>>>Chris
>>>http://www.netsteady.cc
>>
>>Sorta kinda maybe. 120msec latency is no problem as long as it's a
>>consistent 120msec latency. For example, I have a customer that uses
>>Skype and other VoIP phone systems over a DirecWay satellite link.
>>Latency is typically 800msec. When traffic is minimal and the latency
>>is consistently 800msec, there's no problem using the satellite link
>>(except for having to say "over" at the end of each phrase).
>>Admittedly, that's not very often, but it does work. Similarly, Skype
>>VoIP works just fine over a dialup connection, which usually has 120
>>to 200msec latency. The point is that if the latency does not vary,
>>VoIP will work fine.
>Dialup with a good modem should add less than 120 ms latency. If it
>adds more than that, either the modem is crappy, or something else is
>wrong (e.g., crappy ISP).
I stand corrected. I couldn't remember the latency I was getting for
a dialup modem. Worse, I couldn't find a dilaup modem to even try it.
None of my desktops or laptops have an internal modem. So, I did the
Google thing, found someone expounding on dialup latency, and used
their numbers. Try a Google search for "dialup latency msec" and
notice the rather large numbers it returns.
Looking on the shelf, I see several large boxes full of assorted ISA
and PCI modems. Maybe this is a clue about dialup.
Wow. I also just found a box of Microchannel boards. I wonder what
else is buried behind all the modem boards.
On Tue, 07 Nov 2006 18:57:04 GMT, John Navas
<spamfilter0@navasgroup.com> wrote:
>Another likely cause of high/inconsistent latency is saturation of
>broadband uplink, which isn't addressed by the QoS in most low-end
>routers. No matter what the packet priority, saturation of the uplink
>on typical consumer (asymmetric) broadband results in severe downlink
>speed degradation and big latency spikes. The only way to resolve that
>is with uplink throttling, either in the client computer or in the
>router.
Yep. That what I said in my previous rant.
"You may also have a worm or trojan horse running on a local PC
that's hogging all the outgoing bandwidth. Try the softphone with
all the other computers in the house turned off and see if that
helps."
Incidentally, I did some testing with various VoIP products using
DummyNet to simulate a line imparement problem. http://info.iet.unipi.it/~luigi/ip_dummynet/
I have it loaded on an old desktop using a CF card for boot. Makes a
nice piece of test equipment. As I recall, a consipated uplink had a
horrible effect on downlink latency and thus VoIP quality.
>> Maker and model number of softphone?
>
>Cisco IP communicator 2.0.2.0
Ok, I goofed. I assumed that you mean't a real 802.11 phone, where
the wireless link is built into the phone. That's just VoIP software
running on a PC. Most of what I mumbled still applies, except the
references should be to the wireless connected computer, not to a
Wi-Fi VoIP handset.
>> Maker and model number of the wireless router you're using?
>
>BT Homehub (I am in the UK and this is the router supplied by BT who
>are my ISP).
I couldn't find much on this device on the the internet. Duz it have
QoS features in the firmware?
>When you say ping the phone's IP address, you mean ping the computer
>that the phone is running on?
Correct. However, since you have a PC, it's easy enough to just ping
the wireless router from the PC running the Cisco VoIP software.
>First, I pinged my router from the computer where the softphone is
>running 72 times and got 2 long response times out of 72 - the rest
>were 1ms.
>
>However a few minutes later I tried again and got the following:
>
>
>Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=150ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=38ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=2ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=150ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=140ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=150ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=140ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=150ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=33ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
>Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
>
>So it looks like I have an issue but it's intermittent?
Yep. There's your problem. One hit every 10 seconds.
It's difficult to guess what it might be. Something that periodic and
regular could easily be an application running on the PC that's
hogging enough CPU cycles to slow down the networking. Something like
an early version of Symantec Live Update that checks to see if it's
connected to the internet every few seconds. Programs that poll for
activity and connectivity can also do the same thing. Try disabling
any network applications that you have running in the background.
Another possibility is a local source of RF interference. Anything
that regular is probably an appliance or power supply with a
thermostat or regulator of some sorts that samples exactly 10 seconds.
I don't have a clue what it might be but my guess is that you can also
hear it with an AM or FM portable radio. Try sniffing around the area
and see if you hear anything.
Duh.... some 2.4GHz phones have a system where they check to see if
there are handsets within range. Siemens 2.4GHz phones do this. The
base "probes" for handsets every 10 seconds. If you have a cordless
phone, I would unplug it and see if the problem goes away.
>When you say you can guess the cause by watching the numbers, do you
>mean that there is some pattern in the dropouts that is consistent with
>some other device in the area or what?
Exactly. For example, microwave ovens tend to operate only during
typical eating times. Cordless phones tend to interfere for a few
minutes, followed by hours of few problems (unless owned by a
teenager). Muncipal networks tend to be on all the time but decrease
late at night. Each source has a pattern.
>Thanks for you input on that. This QoS feature - if I have it will it
>work automatically or do I need to configure it?
You need to configure it. I'm not sure if your BT box has it.
However, it won't help this problem. Find the source of the glitches
and your problem will go away. Good luck.
On Tue, 07 Nov 2006 21:40:47 GMT, Jeff Liebermann
<jeffl@comix.santa-cruz.ca.us> wrote in
<buu1l21gbmnjq7p921fn8ajtdc9a1ltl92@4ax.com>:
>On Tue, 07 Nov 2006 18:50:23 GMT, John Navas
><spamfilter0@navasgroup.com> wrote:
>>Dialup with a good modem should add less than 120 ms latency. If it
>>adds more than that, either the modem is crappy, or something else is
>>wrong (e.g., crappy ISP).
>
>I stand corrected. I couldn't remember the latency I was getting for
>a dialup modem. Worse, I couldn't find a dilaup modem to even try it.
>None of my desktops or laptops have an internal modem. So, I did the
>Google thing, found someone expounding on dialup latency, and used
>their numbers. Try a Google search for "dialup latency msec" and
>notice the rather large numbers it returns.
What I Guess(sm):
1. Many of these folks are looking at end-to-end latency, rather than
just the dialup portion.
2. Folks are much more likely to post when they are having problems,
rather than when things are working properly.
3. Many (most?) computers aren't configured properly (e.g., too low port
speed, which increases latency).
4. There's a lot of crap hardware out there.
5. There's a lot of just plain crap info on the Internet.
Data I Know To Be Good(sm):
<http://groups.google.com/group/comp.dcom.modems/msg/017bf8a87e0e1f16?dmode=source>
<http://groups.google.com/group/comp.dcom.modems/msg/794f46d8308fe357?dmode=source>
<http://groups.google.com/group/comp.dcom.modems/msg/61a52e7d7fc43029?dmode=source>
>Looking on the shelf, I see several large boxes full of assorted ISA
>and PCI modems. Maybe this is a clue about dialup.
Maybe. I've personally migrated to wireless cellular, which is much
faster, cheaper (on my data package at least), and far more ubiquitous
than dialup.
--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>
> >
> >Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=150ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=38ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=2ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=150ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=140ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=150ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=140ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=150ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=33ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
> >Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
> >
> >So it looks like I have an issue but it's intermittent?
>
> Yep. There's your problem. One hit every 10 seconds.
>
> It's difficult to guess what it might be. Something that periodic and
> regular could easily be an application running on the PC that's
> hogging enough CPU cycles to slow down the networking. Something like
> an early version of Symantec Live Update that checks to see if it's
> connected to the internet every few seconds. Programs that poll for
> activity and connectivity can also do the same thing. Try disabling
> any network applications that you have running in the background.
>
> Another possibility is a local source of RF interference. Anything
> that regular is probably an appliance or power supply with a
> thermostat or regulator of some sorts that samples exactly 10 seconds.
> I don't have a clue what it might be but my guess is that you can also
> hear it with an AM or FM portable radio. Try sniffing around the area
> and see if you hear anything.
>
> Duh.... some 2.4GHz phones have a system where they check to see if
> there are handsets within range. Siemens 2.4GHz phones do this. The
> base "probes" for handsets every 10 seconds. If you have a cordless
> phone, I would unplug it and see if the problem goes away.
>
> >When you say you can guess the cause by watching the numbers, do you
> >mean that there is some pattern in the dropouts that is consistent with
> >some other device in the area or what?
>
> Exactly. For example, microwave ovens tend to operate only during
> typical eating times. Cordless phones tend to interfere for a few
> minutes, followed by hours of few problems (unless owned by a
> teenager). Muncipal networks tend to be on all the time but decrease
> late at night. Each source has a pattern.
>
OK I have been investigating this further and the mystery deepens.....
The interference I was getting every 10 seconds has gone now - I was
getting it earlier this week in the evening like clockwork. Since then
I have tried switching off a lot of appliances, and I have also changed
the channel on the router to channel 11. I have not seen any
interference cycling at 10 second intervals since Tuesday evening, even
though I have switched pretty much everything back on, so I'm baffled
at that one.
However, I do now see long ping times or time outs on wireless
approximately every 65 to 70 secs, and I have been able to sync these
exactly with periods of poor reception on my softphone, so I have
isolated these as the cause as you suspected.
But I have not been able to find the cause of these dropouts every 65
to 70 seconds so far. I have yet to try disabling services and
programs on my computer so I will try that, but since I am seeing a
similar issue on another computer in the house that has a totally
different configuration I'm not convinced that it's a local PC issue
yet.
One other theory I had - I am using WPA-PSK encryption. Could it be
the recylcing of the encryption key that's causing this? I may try
reverting temporarily to WEP in order to check that. In think that in
some routers you can change the time between recycling of the key, but
in this BT Homehub I can't find an option to do that.
On 9 Nov 2006 02:12:30 -0800, warner_patrick@hotmail.com wrote in
<1163067150.061776.71560@f16g2000cwb.googlegroups. com>:
>One other theory I had - I am using WPA-PSK encryption. Could it be
>the recylcing of the encryption key that's causing this? ...
No.
--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>
>OK I have been investigating this further and the mystery deepens.....
I just hate it when that happens.
>I have not seen any
>interference cycling at 10 second intervals since Tuesday evening, even
>though I have switched pretty much everything back on, so I'm baffled
>at that one.
The problem with intermittants is that they tend to return.
>However, I do now see long ping times or time outs on wireless
>approximately every 65 to 70 secs, and I have been able to sync these
>exactly with periods of poor reception on my softphone, so I have
>isolated these as the cause as you suspected.
For how long do these last? Try pinging at a faster rate to get a
clue as to the length of time between noise hits. Windoze ping will
not allow this, so I suggest you download fping 2.16 from: http://www.kwakkelflap.com/downloads.html
Run it at about 4 pings per second and try to estimate the length of
the outage. For example on my link:
Pinging 192.168.1.50 with 32 bytes of data every 250 ms:
Reply[1] from 192.168.1.50: bytes=32 time=2.8 ms TTL=127
Reply[2] from 192.168.1.50: bytes=32 time=2.4 ms TTL=127
Reply[3] from 192.168.1.50: bytes=32 time=2.5 ms TTL=127
Reply[4] from 192.168.1.50: bytes=32 time=2.3 ms TTL=127
Reply[5] from 192.168.1.50: bytes=32 time=2.3 ms TTL=127
Reply[6] from 192.168.1.50: bytes=32 time=2.4 ms TTL=127
(...etc...)
I have some guesses as to the culprit, but wanna know the length of
time to cut down on the possibilities. There are a huge number of
"once per minute" devices possible, such as anything with a digital
clock inside, remote weather sensors, RF intrusion detectors, printers
with power save options, etc.
>But I have not been able to find the cause of these dropouts every 65
>to 70 seconds so far. I have yet to try disabling services and
>programs on my computer so I will try that, but since I am seeing a
>similar issue on another computer in the house that has a totally
>different configuration I'm not convinced that it's a local PC issue
>yet.
Good plan. If it happens on any computer, then it's probably not
anything running on the PC unless they're running the same software. I
once had a similar problem with periodic glitches and traced it down
to the FreePing program I was using to check if my clients servers
were up or down. http://www.tools4ever.com/products/free/freeping/
Every time it would check, the whole computah would almost stop dead.
I recently repeated the effect by installing the Accuweather watch
plug-in for the Firefox browser. Every time it would check
Accuweather for updates, it would freeze the browser and slow down the
computah. Anyway, look for such programs that periodicially check for
updates.
>One other theory I had - I am using WPA-PSK encryption. Could it be
>the recylcing of the encryption key that's causing this?
Yes, it could. The usual default re-key interval is 3600 seconds or 6
minutes. If it had been lowered to 60 seconds, this might be the
problem. Check the BT HomeHub WPA-PSK settings.
>I may try
>reverting temporarily to WEP in order to check that. In think that in
>some routers you can change the time between recycling of the key, but
>in this BT Homehub I can't find an option to do that.
On Thu, 09 Nov 2006 08:01:45 -0800, Jeff Liebermann
<jeffl@comix.santa-cruz.ca.us> wrote in
<7ii6l29iisat2ookusdqsk6c1sor8g3urv@4ax.com>:
>>One other theory I had - I am using WPA-PSK encryption. Could it be
>>the recylcing of the encryption key that's causing this?
>
>Yes, it could. ...
Not unless it's badly broken. I've personally never seen such a problem
-- have you?
--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>
John Navas <spamfilter0@navasgroup.com> hath wroth:
>On Thu, 09 Nov 2006 08:01:45 -0800, Jeff Liebermann
><jeffl@comix.santa-cruz.ca.us> wrote in
><7ii6l29iisat2ookusdqsk6c1sor8g3urv@4ax.com>:
>
>>>One other theory I had - I am using WPA-PSK encryption. Could it be
>>>the recylcing of the encryption key that's causing this?
>>
>>Yes, it could. ...
>
>Not unless it's badly broken. I've personally never seen such a problem
>-- have you?
No, I haven't and previously noted that it was improbable. However,
I'm open to new and wonderful bugs. Testing is easy enough and more
interesting than the usual broken Windoze problems. I like to test my
assumptions first, to be sure I'm not missing something obvious,
especially if they're easily checked.
I'm betting on a nearby device with a power save feature that's
spewing RFI. I once spent a miserable afternoon in a lab trying to
find the source of periodic 1 second RF bursts. Eventually someone
noticed that it only happened when I was in the room. After the
requisite sick humor, I turned off my pager and the problem went away.
(The pager has a battery saver circuit and we were hearing the local
oscillator going on and off). I have some guesses as to the 1 minute
interval source, but I wanna know the approximate duration first.
When you have eliminated the impossible, whatever remains, however
improbable, is the culprit. When that's been eliminated, we're left
with the ridiculous. (Apologies to Arthur K. Doyle).
>these as the cause as you suspected.
>
> For how long do these last? Try pinging at a faster rate to get a
> clue as to the length of time between noise hits. Windoze ping will
> not allow this, so I suggest you download fping 2.16 from:
> http://www.kwakkelflap.com/downloads.html
> Run it at about 4 pings per second and try to estimate the length of
> the outage. For example on my link:
>
> fping 192.168.1.50 -t 250 -c
>
>
> I have some guesses as to the culprit, but wanna know the length of
> time to cut down on the possibilities. There are a huge number of
> "once per minute" devices possible, such as anything with a digital
> clock inside, remote weather sensors, RF intrusion detectors, printers
> with power save options, etc.
>
Hereby follows 3 sections of output showing the time profile of the
dropouts - each section occurs 60 to 70 seconds apart using the same
parameters you used above:
Reply[326] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[327] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[328] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[329] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[330] from 192.168.1.254: bytes=32 time=2.1 ms TTL=64
Reply[331] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[332] from 192.168.1.254: bytes=32 time=13.2 ms TTL=64
Reply[333] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[334] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[335] from 192.168.1.254: bytes=32 time=180.8 ms TTL=64
Reply[336] from 192.168.1.254: bytes=32 time=88.8 ms TTL=64
Reply[337] from 192.168.1.254: bytes=32 time=191.0 ms TTL=64
Reply[338] from 192.168.1.254: bytes=32 time=191.0 ms TTL=64
Reply[339] from 192.168.1.254: bytes=32 time=2.2 ms TTL=64
Reply[340] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[341] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[342] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[343] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[344] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[345] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[346] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[326] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[327] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[328] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[329] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[330] from 192.168.1.254: bytes=32 time=2.1 ms TTL=64
Reply[331] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[332] from 192.168.1.254: bytes=32 time=13.2 ms TTL=64
Reply[333] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[334] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[335] from 192.168.1.254: bytes=32 time=180.8 ms TTL=64
Reply[336] from 192.168.1.254: bytes=32 time=88.8 ms TTL=64
Reply[337] from 192.168.1.254: bytes=32 time=191.0 ms TTL=64
Reply[338] from 192.168.1.254: bytes=32 time=191.0 ms TTL=64
Reply[339] from 192.168.1.254: bytes=32 time=2.2 ms TTL=64
Reply[340] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[341] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[342] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[343] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[344] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[345] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[346] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[326] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[327] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[328] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[329] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[330] from 192.168.1.254: bytes=32 time=2.1 ms TTL=64
Reply[331] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[332] from 192.168.1.254: bytes=32 time=13.2 ms TTL=64
Reply[333] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[334] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[335] from 192.168.1.254: bytes=32 time=180.8 ms TTL=64
Reply[336] from 192.168.1.254: bytes=32 time=88.8 ms TTL=64
Reply[337] from 192.168.1.254: bytes=32 time=191.0 ms TTL=64
Reply[338] from 192.168.1.254: bytes=32 time=191.0 ms TTL=64
Reply[339] from 192.168.1.254: bytes=32 time=2.2 ms TTL=64
Reply[340] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[341] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[342] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[343] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[344] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[345] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[346] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
I also noticed that using this fping program my ping times are always
at least 1.9 ms and there is more variance - using normal windows ping
it was almost always just 1ms except during the outages - maybe windoes
ping always rounds down?
> Also try it with encryption temporarily disabled.
>
>
>Hereby follows 3 sections of output showing the time profile of the
>dropouts - each section occurs 60 to 70 seconds apart using the same
>parameters you used above:
OK, 250 msec per ping. That means the burst of crud is about 1 second
long.
>Reply[335] from 192.168.1.254: bytes=32 time=180.8 ms TTL=64
>Reply[336] from 192.168.1.254: bytes=32 time=88.8 ms TTL=64
>Reply[337] from 192.168.1.254: bytes=32 time=191.0 ms TTL=64
>Reply[338] from 192.168.1.254: bytes=32 time=191.0 ms TTL=64
(...)
>Reply[335] from 192.168.1.254: bytes=32 time=180.8 ms TTL=64
>Reply[336] from 192.168.1.254: bytes=32 time=88.8 ms TTL=64
>Reply[337] from 192.168.1.254: bytes=32 time=191.0 ms TTL=64
>Reply[338] from 192.168.1.254: bytes=32 time=191.0 ms TTL=64
>Reply[335] from 192.168.1.254: bytes=32 time=180.8 ms TTL=64
It looks fairly repeatable. There'a also a small glitch about 750msec
before the 1 second burst that also seems repeatable. 1 second
duration is a LONG time for a battery saver, so that's out. It's too
fast and too long for radar. Whatever it is seems very periodic.
It sounds roughly like the pattern of a data burst from some
transmitter. My guess would be a wireless weather station, wireless
burglar alarm, or cordless phone system that updates the handsets. It
can also be coming from outside in the form of a SCADA telemetry
transmitter from some utilty service, or data collector. Is anyone
doing any Zigbee work in the area?
Another possibility is a cordless mouse on 2.4GHz. One of these (I
forgot the model) has a feature where if the mouse walks away, an
alarm goes off in the computer. It's necessary to have the mouse
transmit something periodicially, which might be the source.
I know I'm being fairly vague but that's the best I can do from here
without knowning whats in the vicinity. The next step would be to
drag out the spectrum analyzer and directional antenna, which is
probably more than you want to attempt. If you have some amateur
radio operators nearby, you might ask for help.
Try this test. Take a cardboard box and cover it with aluminum foil
on all but one face of the box. Leave the lid functional. Don't
worry too much about sealing the lid edge seams. Put the access point
inside the box and rotate the non-covered side in 45 degree incriments
to obtain a crude impression of the direction of the intereference
source. Don't forget to try up and down direction and moving the
access point around. I don't know if this will really work, but it's
the best I can think of.
If I think of anything else, I'll post it. (I have the feeling I'm
missing something obvious).
>I also noticed that using this fping program my ping times are always
>at least 1.9 ms and there is more variance - using normal windows ping
>it was almost always just 1ms except during the outages - maybe windoes
>ping always rounds down?
Windoze apparently truncates ping times. That's why I like to use
fping. There's additional resolution, more features, and it numbers
the packets so I can see if any disappear. It's fairly difficult to
ruin a simple diagnostic like ping, but Microsoft managed it nicely.
>I tried this now and also with WEP - no change.
Ok, so much for the WPA re-keying theory. If it's not the computer
getting busy (I assume you checked with another machine), what's left
is:
RFI (radio interference)
Broken BT HomeHub
Alien communications from nearby crop circles.
> If I think of anything else, I'll post it. (I have the feeling I'm
> missing something obvious).
>
I may be leading you up the garden path here. There are two PCs in my
house connected to the network - one is a work PC and one is the home
PC and they are running mostly different software. I have focussed
most of this troubleshooting on the work PC because that's the one I
want to use for IP telephony. The other one I checked briefly and got
the impression it had the same issue, but I was too hasty in my checks
late the other night.
Last night I checked again - the other (home) PC has a different
sequence and pattern of latency spikes than the office one. I put them
right next to each other and the pattern which happens ever minute or
so on the office PC does not happen on the home one, at least not at
the same time. The home one actually has more frequent issues - some
of them are characterised by just one long ping or lost packet, and
others are characterised by a pattern just like the one you looked at
yesterday, but not on the same timing - they are more frequent than
once per minute and less regular.
So that seems to indicate that it's something to do with the local PC
and software running on the PC that's causing the issues (?), or
extremely localised RF interference caused within the PC itself (?). I
have tried disabling everything in the startup file using MSConfig but
that didn't make any difference. Are there any services that you have
seen that could be culprits here?
BUT when I connect to the router with an ethernet cable, I get no
latency spikes whatsoever, so if it's something running on the local PC
it is something that only impacts on the wireless networking. If
something was stopping the network or grabbing all the bandwidth whilst
it phones home, I would have thought I would see at least some impact
on wired networking as well.
Thinking whilst I am talking though, I seem to remember reading that on
a wireless network, only one device can actually communicate at a time
in the network layer (?) and the communication can only go one way at a
time. Therefore could it be that the home PC is grabbing all the
network bandwidth every minute and the other one doesn't get a look in?
I don't think so though, because I have also tried tests with the home
PC completely switched off (and everything else in the house switched
off as well) and get the same results.
I'm a bit stumped now, but local software now seems to be the most
likely culprit?
Sorry for the misleading information before - it must have been too
late at night last time I checked the home PC :-)
Jeff Liebermann wrote:
>
> It looks fairly repeatable. There'a also a small glitch about 750msec
> before the 1 second burst that also seems repeatable. 1 second
> duration is a LONG time for a battery saver, so that's out. It's too
> fast and too long for radar. Whatever it is seems very periodic.
>
> It sounds roughly like the pattern of a data burst from some
> transmitter. My guess would be a wireless weather station, wireless
> burglar alarm, or cordless phone system that updates the handsets. It
> can also be coming from outside in the form of a SCADA telemetry
> transmitter from some utilty service, or data collector. Is anyone
> doing any Zigbee work in the area?
>
> Another possibility is a cordless mouse on 2.4GHz. One of these (I
> forgot the model) has a feature where if the mouse walks away, an
> alarm goes off in the computer. It's necessary to have the mouse
> transmit something periodicially, which might be the source.
>
> I know I'm being fairly vague but that's the best I can do from here
> without knowning whats in the vicinity. The next step would be to
> drag out the spectrum analyzer and directional antenna, which is
> probably more than you want to attempt. If you have some amateur
> radio operators nearby, you might ask for help.
>
Everything in the list above that I have in my house has been disabled
- I even took the batteries out of a wireless mouse and keyboard
upstairs. I did not take the batteries out of all the kids toys, but
as far as I can remember they don't have any radio controlled toys. To
my knowledge the burglar alarm is wired not wireless, and I would not
have a clue how to switch it off without triggering a tamper alarm. It
is not the type of alarm that alerts the authorities, so I doubt that
it has radio transmission capabilities. The motion detectors have
wires that disappear into the walls, so they are not wireless.
I don't know what a Zigbee is so I couldn't comment on that.
Also see my other post where I had actually misdiagnosed the other PC
in my house, and the interference patterns are NOT the same on both
PCs.
Other comments:
- I tried using a different router (US Robotics 9106) that I had stored
away and the results on both PCs were the same as with the BT router.
- If I move the office PC which is a laptop around the house, there are
places where I seem to get very similar interference patterns much more
frequently, but even depending on whether there are objects blocking
the way and/or which direction I am facing), but the underlying ding
every 60 to 70 seconds always seems to be there anyway.
- Of course I guess in theory any of the items mentioned above (and any
others on the list of frequent causes of RF interference that was
linked in one of the messages above) could also exist at the neighbours
house - my house is a terrace so it's joined to the neighbours on both
sides.
cheers and thanks for all your help on this. We may not find the issue
but I'm certainly more clued up about wireless networking issues than
before you have been extremely helpful.
>I put them
>right next to each other and the pattern which happens ever minute or
>so on the office PC does not happen on the home one, at least not at
>the same time.
I'll assume that both PC's are connected via wireless. Putting them
next to each other is no guarantee that you'll get identical wireless
performance and interference. However, I've been assuming that the
point of entry of whatever is causeing the interference is the cental
wireless access point, and not the client radios which are usually
less sensitive with inferior antennas. That may be a bad assumption.
>The home one actually has more frequent issues - some
>of them are characterised by just one long ping or lost packet, and
>others are characterised by a pattern just like the one you looked at
>yesterday, but not on the same timing - they are more frequent than
>once per minute and less regular.
Note the extra packet loss at about 750msec before the 1 second long
loss. I suspect that you're watching a transmission between TWO other
wireless devices, a weak one and a strong one. That will make the
actual pattern somewhat variable depending on location.
>So that seems to indicate that it's something to do with the local PC
>and software running on the PC that's causing the issues (?),
That's easy to test. Move the PC around. If it's software, shouldn't
mattery where the PC is located, the level of interference and
interference timing pattern should remain roughly identical in all
locations. If it varies in intensity and possibly pattern, it's
something external. If it stays the same at all locations, it's
something in software.
>or
>extremely localised RF interference caused within the PC itself (?).
Again, easy to test. If it's coming from inside, it will remain the
same no matter where you're located. Run the XP Task Manager
Performance graph and see if the CPU gets very busy or spikes at
corresponding 1 minute intervals.
VOIP Degradation on Wireless Network 