Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

VOIP Degradation on Wireless Network

2 views
Skip to first unread message

warner_...@hotmail.com

unread,
Nov 7, 2006, 4:50:29 AM11/7/06
to
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.

NetSteady

unread,
Nov 7, 2006, 9:56:14 AM11/7/06
to
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

John Navas

unread,
Nov 7, 2006, 11:45:46 AM11/7/06
to
On 7 Nov 2006 01:50:29 -0800, warner_...@hotmail.com wrote in
<1162893029.5...@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>

Jeff Liebermann

unread,
Nov 7, 2006, 12:39:52 PM11/7/06
to
warner_...@hotmail.com hath wroth:

>I am using a VOIP softphone.

Maker and model number of softphone?
Maker and model number of the wireless router you're using?

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.

--
Jeff Liebermann je...@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

Jeff Liebermann

unread,
Nov 7, 2006, 12:52:55 PM11/7/06
to
"NetSteady" <cmh...@gmail.com> hath wroth:

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.

Àngel Català

unread,
Nov 7, 2006, 1:28:11 PM11/7/06
to
Hi,

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_...@hotmail.com escribió:

John Navas

unread,
Nov 7, 2006, 1:50:23 PM11/7/06
to
On Tue, 07 Nov 2006 09:52:55 -0800, Jeff Liebermann
<je...@comix.santa-cruz.ca.us> wrote in
<09h1l2t5i3lmq0cmp...@4ax.com>:

>"NetSteady" <cmh...@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).

John Navas

unread,
Nov 7, 2006, 1:57:04 PM11/7/06
to
On Tue, 07 Nov 2006 09:39:52 -0800, Jeff Liebermann
<je...@comix.santa-cruz.ca.us> wrote in
<8jg1l2d5dq3flgt4b...@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.

warner_...@hotmail.com

unread,
Nov 7, 2006, 2:05:46 PM11/7/06
to
> Maker and model number of softphone?

Cisco IP communicator 2.0.2.0

> 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 je...@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?

Jeff Liebermann

unread,
Nov 7, 2006, 4:40:47 PM11/7/06
to

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.

--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831-336-2558 je...@comix.santa-cruz.ca.us
# http://802.11junk.com je...@cruzio.com
# http://www.LearnByDestroying.com AE6KS

Jeff Liebermann

unread,
Nov 7, 2006, 4:44:39 PM11/7/06
to
On Tue, 07 Nov 2006 18:57:04 GMT, John Navas
<spamf...@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.

Jeff Liebermann

unread,
Nov 7, 2006, 4:58:00 PM11/7/06
to
On 7 Nov 2006 11:05:46 -0800, warner_...@hotmail.com wrote:

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

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.

John Navas

unread,
Nov 7, 2006, 5:23:23 PM11/7/06
to
On Tue, 07 Nov 2006 21:40:47 GMT, Jeff Liebermann
<je...@comix.santa-cruz.ca.us> wrote in
<buu1l21gbmnjq7p92...@4ax.com>:

>On Tue, 07 Nov 2006 18:50:23 GMT, John Navas
><spamf...@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.

warner_...@hotmail.com

unread,
Nov 9, 2006, 5:12:30 AM11/9/06
to

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.

cheers
Patrick.

John Navas

unread,
Nov 9, 2006, 10:31:55 AM11/9/06
to
On 9 Nov 2006 02:12:30 -0800, warner_...@hotmail.com wrote in
<1163067150....@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.

Jeff Liebermann

unread,
Nov 9, 2006, 11:01:45 AM11/9/06
to
warner_...@hotmail.com hath wroth:

>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:

fping 192.168.1.50 -t 250 -c

Fast pinger version 2.16
(c) Wouter Dhondt (http://www.kwakkelflap.com)

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.

Also try it with encryption temporarily disabled.

John Navas

unread,
Nov 9, 2006, 11:35:13 AM11/9/06
to
On Thu, 09 Nov 2006 08:01:45 -0800, Jeff Liebermann
<je...@comix.santa-cruz.ca.us> wrote in
<7ii6l29iisat2ooku...@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?

warner_...@hotmail.com

unread,
Nov 9, 2006, 12:06:09 PM11/9/06
to
>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.
>
>

I tried this now and also with WEP - no change.

thanks
Patrick.

Jeff Liebermann

unread,
Nov 9, 2006, 12:00:18 PM11/9/06
to
John Navas <spamf...@navasgroup.com> hath wroth:

>On Thu, 09 Nov 2006 08:01:45 -0800, Jeff Liebermann
><je...@comix.santa-cruz.ca.us> wrote in
><7ii6l29iisat2ooku...@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).

Assumption, the mother of all screwups.

Jeff Liebermann

unread,
Nov 9, 2006, 12:02:06 PM11/9/06
to
Jeff Liebermann <je...@comix.santa-cruz.ca.us> hath wroth:

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

Oops. I mean't the time duration of the noise hits, not the time
between them.

Jeff Liebermann

unread,
Nov 9, 2006, 12:51:19 PM11/9/06
to
warner_...@hotmail.com hath wroth:

>> fping 192.168.1.50 -t 250 -c

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

warner_...@hotmail.com

unread,
Nov 10, 2006, 1:47:38 AM11/10/06
to

Jeff Liebermann wrote:

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

thanks
Patrick.

warner_...@hotmail.com

unread,
Nov 10, 2006, 2:01:14 AM11/10/06
to

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.

Jeff Liebermann

unread,
Nov 10, 2006, 12:37:35 PM11/10/06
to
warner_...@hotmail.com hath wroth:

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

>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?

Yes. I think I previously mentioned a few. It's any service or
background application that regularly checks for network connectivity.
Skype and all VoIP applications do that. Any network monitoring
programs that use ping or SNMP. However, I really doubt that these
are the problem due to the long duration of the interference. 1 full
second is an awful long time for a software application to hog the
CPU. If it had been a momentary (<250msec) glitch, then you might
consider chasing the software possibility, but I don't know of any
such software that will stop the network for a full second.

Well, maybe one. I use several weather service plug-ins for Firefox.
They take a while to scrape the data off the Accuweather web site. The
inteval isn't adjustable and seems to be about once per minute.
However, that only runs while Firefox is on the screen, so I really
doubt that it's the culprit. Do you have any weather monitoring
software installed (WeatherBug, weather.com, etc)?

Incidentally, instead of MSCONFIG and it's non-resizeable window, I
suggest something more useful such as Startup Monitor for Windoze:
http://www.WindowsStartup.com
It's free.

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

Yes, something like that. Basically all 802.11 wireless is
half-duplex. In a wireless network, only one transmitter can be
transmitting at a time. Everyone can receive all the time, but only
one transmission 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?

No. That might happen if the transmitter were stuck on the air, but
there are required safeguards to prevent that. Note that the SSID
beacon interval is 100msec, meaning that at least the access point is
transmitting something 10 times per second. You would definitely see
that if something else were hogging airtime.

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

Good test assuming the transmissions are coming from your equipment.
If it's coming from the neighbors, it might be a problem.

>I'm a bit stumped now, but local software now seems to be the most
>likely culprit?

No, I don't think so. I think it's time to do a bit of isolation
testing in order to reduce the number of possibilities. Disconnect
your BT wireless router and go find a location where little chance of
RF interference. I suggest a basement, neighbors house, dungeon, or
similar isolation chamber. You won't need internet connectivity for
this test. Take your laptop with you. Run the fping 250msec test and
see if you get the same 1 minute interval, 1 second outage. If it
travelled with you, then it's something either inside the BT router or
the laptop. If you left your interference problems at home, then it's
something at or near your location and most likely a source of RF
interference.

>Sorry for the misleading information before - it must have been too
>late at night last time I checked the home PC :-)

Well, actually the most important information that was missing was the
available hardware and topology (method of connecting to the network).

Some questions:
1. Is your home PC connected via wireless?
2. Can you see any neighbors wireless networks on the laptop with the
"View available networks" or other tool (Wi-Fi Hopper, Netstumbler)?
3. Have you tried taking the laptop yet a different location such as
a wireless hot spot and tried the Cisco VoIP?
4. Got any friends with 2.4GHz spectrum analyzers?

Jeff Liebermann

unread,
Nov 10, 2006, 12:59:01 PM11/10/06
to
warner_...@hotmail.com hath wroth:

>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'll assume it's not coming from your house. That leaves the
neighbors and the neighborhood.

It's possible that the 1 minute interval, 1 second burst, is wide band
noise from something that's arcing. It should be possible to hear it
on other radio equipment. If you have a portable AM/FM/TV device, try
wandering around and see if you can hear or see something while
listening to an empty channel.

Incidentally, one of the local hams was trying to locate the source of
a similar RF interference pattern that was ruining his HF (short wave)
communications. It was eventually traced down to some manner of pump
controller for the apartment building. I think it was the swimming
pool pump but may have been something else. The noise came from an
arcing thermostat. The pattern you observed seems similar. Got any
mechanical thermostats driving high current loads?

>The motion detectors have
>wires that disappear into the walls, so they are not wireless.

Smoke alarm? Mine has a battery saver circuit that samples at about 1
minute intervals. It probably takes 1 second to make a measurement.
Hmmmm....

>I don't know what a Zigbee is so I couldn't comment on that.

I'll make it easy. Are you next to a university or industrial plant?
They use Zigbee radios for mesh wireless sensor networks.

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

I would't expect them to be identical. I think you're hearing someone
elses RF transmissions. Exactly what and from where, I don't know.
Since changing the channel doesn't work, I suspect a frequency hopper
and not an 802.11 direct sequence radio.

It might also be one of the neighbor un-friendly MIMO or turbo
devices, but the inteference pattern doesn't fit to well. Well,
actually it might fit under an unusual case. If the neighbor has one
of these devices, but is not using it for moving any traffic, the
access point will switch to a "sampling" mode spending the bulk of
it's time doing 802.11g, and ocassionally listening for turbo or MIMO
transmissions. I'm only familiar with the transmission patterns from
a few of these (Airgo based systems) and have noted that it changes
with firmware, model, manufacturer, and technology. I'll do some
digging and see if I can find a pattern of what it looks like at idle.
I don't think this is the cause because at the level of interference
that it seems to produce, you should have been complaining about much
longer duration interference when the MIMO system was in use. Still,
it's worth persuing.

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

Ok, that eliminates the BT router as a possible culprit. Just for
fun, turn off the cable or DSL modem. You don't need it for the ping
test.

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

That seems to show that it's RF interference. This is going to be
difficult to identify without test equipment or doing something
drastic like powering down the entire house. Might as well. Power
the access point from a UPS and turn off the entire house.

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

Well, ask the neighbors if they have anything on the list of possible
interfence sources. Bring your laptop when you visit to see if it
gets worse or better at the neighbors. My guess(tm) is that 30m in
any direction is as far as you need to go.

>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 find this kind of troubleshooting to be better than any mystery
novel. Good luck.

Patrick

unread,
Nov 10, 2006, 1:22:37 PM11/10/06
to
>
> 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.
>


Unless there is more than one issue, and one is internal one external.
Thanks for your usual very thorough reply - I have some family commitments
this weekend so I probably won't be able to action the rest of it until
Monday or so - but I will review all that for sure.

cheers
Patrick.


warner_...@hotmail.com

unread,
Nov 10, 2006, 3:21:15 PM11/10/06
to
OK - I did have a bit more time to investigate this evening:

> Some questions:
> 1. Is your home PC connected via wireless?

Yes.


> 2. Can you see any neighbors wireless networks on the laptop with the
> "View available networks" or other tool (Wi-Fi Hopper, Netstumbler)?

No

> 3. Have you tried taking the laptop yet a different location such as
> a wireless hot spot and tried the Cisco VoIP?


No, but that's a very good idea and I may try to do that soon. That
will probably be the final most effective test to see if it's something
in the laptop or something external in the area of the housr.

> 4. Got any friends with 2.4GHz spectrum analyzers?

Un, I'm not even sure if I have any friends who would know what a
2.4GHz spectrum analyzer is. Are they cheap to buy? Before I go down
that route I want to totally disprove that it's not something on the PC
causing it.

Lastly, some new evidence which I'm not sure if it's cause or effect -
I just realised that there is a very clear spike in CPU usage on the
laptop that corresponds to the network outages - it's not a spike to
100% - it's a spike from 1% to about 12%, but it clearly is happening
bang on every time the fping outage occurs. This spike only occurs
when wireless networking connection is active. It does not occur if
there is no network at all, and it does not occur if there is a wired
connection. It is not caused by FPING as it happens even when fping is
not running if the wireless network is active. Is it normal to see a
CPU spike when there is an RF interference incident on the wireless
network?

cheers

decaturtxcowboy

unread,
Nov 10, 2006, 5:11:24 PM11/10/06
to
warner_...@hotmail.com wrote:
> Un, I'm not even sure if I have any friends who would know what a
> 2.4GHz spectrum analyzer is. Are they cheap to buy?

MetaGeek Wi-Spy 2.4 GHz Spectrum Analyzer $100
Bumblebee $3,000 (depends on model) and you need an iPaq
Cognito and Airmagnet PCMIA cards $3,000 - $4,000
Stand alone units $10,000+

Jeff Liebermann

unread,
Nov 10, 2006, 10:11:40 PM11/10/06
to
On 10 Nov 2006 12:21:15 -0800, warner_...@hotmail.com wrote:

>> 4. Got any friends with 2.4GHz spectrum analyzers?
>
>Un, I'm not even sure if I have any friends who would know what a
>2.4GHz spectrum analyzer is. Are they cheap to buy? Before I go down
>that route I want to totally disprove that it's not something on the PC
>causing it.

As Mr. Decaturtxcowboy mentioned, Wi-Spy for $100 is a bargain. The
problem is that it's not very sensitive and not at all directional. I
sorta solved the directional problem with a salad bowl antenna:
| http://802.11junk.com/jeffl/antennas/Salad-Dish/index.html
| http://www.metageek.net/forum/viewtopic.php?t=27
There are other forms of kitchen reflectors:
| http://www.usbwifi.orcon.net.nz

If you've never used a spectrum analyzer before, it will be difficult
to know what to look for. There are sample capture files on the
Wi-Spy web pile:
| http://www.metageek.net
I suspect you're looking for something fairly weak and obscure which
may be difficult to recognize. Probably the best approach would be to
convince the company IT department that it really needs to buy one,
and then borrow it. However, wait for the new version that has an SMA
connector for an external antenna. The salad bowl is really a bad way
to play direction finder.

There are plenty of others available at exponentially increasing
prices and complexity.

>Lastly, some new evidence which I'm not sure if it's cause or effect -
>I just realised that there is a very clear spike in CPU usage on the
>laptop that corresponds to the network outages - it's not a spike to
>100% - it's a spike from 1% to about 12%, but it clearly is happening
>bang on every time the fping outage occurs. This spike only occurs
>when wireless networking connection is active. It does not occur if
>there is no network at all, and it does not occur if there is a wired
>connection. It is not caused by FPING as it happens even when fping is
>not running if the wireless network is active. Is it normal to see a
>CPU spike when there is an RF interference incident on the wireless
>network?

Hmmm... Good observation. No, it's not normal. Wi-Fi network
interrupt overhead is minimal (unless you have a seriously
underpowered laptop). Is there anything that might make the CPU work
harder such as lack of adequate RAM or very slow CPU?

If the outages really do correspond to the CPU usage spikes, then the
problem is in the laptop. However, if it's in the laptop, it would
also have appeared at the office as well as home. I think you can
identify the culprit program or service using the Task Manager.
Instead of the Performance Graph, select "Processes". Click on the
top of the "CPU" column once or twice to get it to sort on CPU usage.
The process that eats the most CPU cycles will appear at the top of
the list.

You might also want to add "CPU Time" to the display:
Task Manager -> View -> Select Columns

Drivel: Try the same test for interference with the laptop battery
charger disconnected. It just might be junk from the Li-Ion battery
charger circuit. If you use a different power supply at work, I would
definately look into this one.

Jeff Liebermann

unread,
Nov 11, 2006, 2:15:31 AM11/11/06
to
decaturtxcowboy <nope_...@nowayspam.com> hath wroth:

Avcom $2700.
| http://www.avcomofva.com/products/default.asp?page=psa1727b

Bantam Instruments $2950.
| http://www.bantaminstruments.com

Using an MMDS downconverter, a much cheapter 500Mhz or 1GHz spectrum
analyzer can be used.

There are also the Proxim FHSS 7400 RangeLAN2 based spectrum analyzer
cards for about $20. They sorta work but not for intermittent sources
of interference. The sweep rate is just too slow:
| http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=140051480091

If you don't mind used, there are quite a few good spectrum analyzers
on eBay:

HP 8569B for $2700.
| http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=150053582953
Drool and slobber... I want it, I want it, I want it. Argh.

Patrick

unread,
Nov 11, 2006, 2:52:36 AM11/11/06
to

">
>>Lastly, some new evidence which I'm not sure if it's cause or effect -
>>I just realised that there is a very clear spike in CPU usage on the
>>laptop that corresponds to the network outages - it's not a spike to
>>100% - it's a spike from 1% to about 12%, but it clearly is happening
>>bang on every time the fping outage occurs. This spike only occurs
>>when wireless networking connection is active. It does not occur if
>>there is no network at all, and it does not occur if there is a wired
>>connection. It is not caused by FPING as it happens even when fping is
>>not running if the wireless network is active. Is it normal to see a
>>CPU spike when there is an RF interference incident on the wireless
>>network?
>
> Hmmm... Good observation. No, it's not normal. Wi-Fi network
> interrupt overhead is minimal (unless you have a seriously
> underpowered laptop). Is there anything that might make the CPU work
> harder such as lack of adequate RAM or very slow CPU?

Not that I'm aware of and the CPU was flat at 0% for all the intervening
time. It's a Dell Latitude D600 - not state of the art, but it should cope
with a few networking tasks fine.


> If the outages really do correspond to the CPU usage spikes, then the
> problem is in the laptop. However, if it's in the laptop, it would
> also have appeared at the office as well as home. I think you can
> identify the culprit program or service using the Task Manager.
> Instead of the Performance Graph, select "Processes". Click on the
> top of the "CPU" column once or twice to get it to sort on CPU usage.
> The process that eats the most CPU cycles will appear at the top of
> the list.
>
> You might also want to add "CPU Time" to the display:
> Task Manager -> View -> Select Columns
>

I already tried that, but I didn't add CPU time in - I tried just sorting by
CPU to see if any programs were spiking on CPU usage at that moment but I
couldn't identify any. I also tried closing down the programs starting with
the busiest, until I ran into accidently stopping an essential process and
the machine shut down. I couldn't identify a culprit yet in this way. I'll
try it with CPU time also. Of course, if the culprit is actually the
wireless network drivers or configuration utility then I'm stuffed - to
check for that I will need to try a different network card - actually I just
rememered I think I have a spare PCMCIA wireless card around somewhere so I
might try that.

In the office I connect wired not wireless. I am going to our US office
next month where there is wireless, so I can see what happens then, or as
you said I could also take it to a hotspot. But again it's interesting that
these CPU spikes don't happen when I'm connected wired, only wireless. I am
pretty confident about this because I sat and watched through a 5 minute
period each with wireless/wired/no network. With wireless, there is a clear
CPU spike that corresponds to when I get the network dropouts. (at this
point many others are probably thinking I should get a life instead of
spending Friday evenings watching the task manager, but there you go).

> Drivel: Try the same test for interference with the laptop battery
> charger disconnected. It just might be junk from the Li-Ion battery
> charger circuit. If you use a different power supply at work, I would
> definately look into this one.

I'll try that too.


Jeff Liebermann

unread,
Nov 11, 2006, 12:41:23 PM11/11/06
to
"Patrick" <nob...@nowhere.com> hath wroth:

>I already tried that, but I didn't add CPU time in - I tried just sorting by
>CPU to see if any programs were spiking on CPU usage at that moment but I
>couldn't identify any.

Try increasing the sample rate in Task Manager.
View -> Update Speed -> High

>Of course, if the culprit is actually the
>wireless network drivers or configuration utility then I'm stuffed - to
>check for that I will need to try a different network card - actually I just
>rememered I think I have a spare PCMCIA wireless card around somewhere so I
>might try that.

The Dell D600 usually arrives with a Truemobile 1300 MiniPCI card
using BCM4301 chipset. Is that what you have? It's a generally
acceptable card with no unusual problems that I could find.

Duh... Try turning off the wireless using the Fn key method and the
right click on the System tray icon, and see if the 1 minute glitches
go away. If it goes away, the glitches are definately coming from the
wireless card or driver.

>But again it's interesting that
>these CPU spikes don't happen when I'm connected wired, only wireless. I am
>pretty confident about this because I sat and watched through a 5 minute
>period each with wireless/wired/no network. With wireless, there is a clear
>CPU spike that corresponds to when I get the network dropouts.

The MiniPCI wireless cards are rather dumb. Much of the wireless
dirty work is done by the main CPU. I have customers with Dell D600
or D610 laptops and can check if they have the same one minute busy
cycles. It's possible that it would be a common trait as it would
only cause a problem with realtime applications like VoIP.

Anyone else have a Dell D600 handy that can check?

>(at this
>point many others are probably thinking I should get a life instead of
>spending Friday evenings watching the task manager, but there you go).

Ask yourself "What did I do on Friday evenings before discovering
computers"? If you can't remember, you have a problem.

Jeff Liebermann

unread,
Nov 11, 2006, 3:19:39 PM11/11/06
to
Jeff Liebermann <je...@comix.santa-cruz.ca.us> hath wroth:

>"Patrick" <nob...@nowhere.com> hath wroth:


>
>>I already tried that, but I didn't add CPU time in - I tried just sorting by
>>CPU to see if any programs were spiking on CPU usage at that moment but I
>>couldn't identify any.
>
>Try increasing the sample rate in Task Manager.
> View -> Update Speed -> High

It may also help to get a better Task Managerie. See Sysinternals
(now owned by Microsoft) Process Explorer 10.21:
| http://www.microsoft.com/technet/sysinternals/SystemInformation/ProcessExplorer.mspx
It can run at 0.5 sec per sample, which should be sufficient to see a
1 second long hickup. Click the mouse on the CPU column to get the
processes that are active at the top of the screen.

warner_...@hotmail.com

unread,
Nov 13, 2006, 5:02:10 PM11/13/06
to
Right, let's recap where we are:

1) Over the weekend I took the laptop to a hotspot and I found the same
symptoms when logged into the hotspot. That means the problem is
coming from the laptop or from something upon my person - I had already
eliminated my cellphone from enquiries, so the only other electronic
object on my person is my watch - I doubt it's that.

2) Disabling radio on the task manager - I think I already had
effectively tried this in a previous message - last week I looked for
the CPU glitches whilst there was radio disabled and no network cable
connected. The glitches were not there. They only occur when I am
connected to a wireless network. In fact, if radio is enabled, but I
am not connected to a network, they don't occur either - only when I am
actually logged on to a wireless network. Therefore this seems to
indicate that it's something specific to the wireless card drivers or
utility, or at least a conflict between that and something else.

3) My Wireless card is listed as a "Dell Truemobile 1400 Dual Band WLAN
Mini-PCI Card". The manufacturer is Broadcom. I don't know what the
chipset is. I did also notice just now that there are a whole bunch of
settings that can be changed from within the Device manager for the
network card - I never tried changing any of them.

4) I still can't isolate anything using process manager even when set
to high refresh rate, but I will download and try that other process
manager you mentioned.

5) I need to check the Dell website for updated drivers - I checked it
several months ago and there was no update for a couple of years, but
I'll check again.

6) Battery charger, I have tried it without the battery being on charge
and no change. Should I also try it with mains power but no battery in
the PC?

We are getting closer.....

cheers
Patrick.

John Navas

unread,
Nov 13, 2006, 6:28:40 PM11/13/06
to
1. Bluetooth on that laptop? If so, disable it temporarily.

2. Run thorough anti-virus and anti-spyware scans.

3. Use MSCONFIG to temporarily disable background processes.

On 13 Nov 2006 14:02:10 -0800, warner_...@hotmail.com wrote in
<1163455330.0...@h48g2000cwc.googlegroups.com>:

--

Jeff Liebermann

unread,
Nov 13, 2006, 9:45:54 PM11/13/06
to
On 13 Nov 2006 14:02:10 -0800, warner_...@hotmail.com wrote:

>1) Over the weekend I took the laptop to a hotspot and I found the same
>symptoms when logged into the hotspot.

Well, that eliminates interference and the BT access point as possible
culprits. It's something in your laptop or wireless device.

>They only occur when I am
>connected to a wireless network. In fact, if radio is enabled, but I
>am not connected to a network, they don't occur either - only when I am
>actually logged on to a wireless network.

Weird. The only think I can think of in the driver that ocurrs at 1
minute intervals is the "power save" feature. Look for it in the
properties for the wireless device. I suggest you disable the power
save mode.

>Therefore this seems to
>indicate that it's something specific to the wireless card drivers or
>utility, or at least a conflict between that and something else.

It might also be a program or service that's checking for internet
access. If it finds internet access, it monopolizes the processor for
about a second. If it doesn't fine internet access, it doesn't do
anything, which is why it doesn't show up every minute. However,
that's unlikely as it should act the same with wireless and wired
connections. I'm beginning to agree that it's something in the
wireless card or wireless driver.

>3) My Wireless card is listed as a "Dell Truemobile 1400 Dual Band WLAN
>Mini-PCI Card". The manufacturer is Broadcom. I don't know what the
>chipset is. I did also notice just now that there are a whole bunch of
>settings that can be changed from within the Device manager for the
>network card - I never tried changing any of them.

These are the same setting as found in the properties for the wireless
device under "Network settings". Try to remember the default
settings. I don't have any experience with this particular card. The
Truemobile 1300 (2.4GHz only) is a fairly common device, but not the
1400. If you feel like burning a few dollars, you might try a 1300
PCI from eBay for about 37 GBP.

>4) I still can't isolate anything using process manager even when set
>to high refresh rate, but I will download and try that other process
>manager you mentioned.

I'm not sure it will be much better, but it does show quite a bit more
detail and is somewhat faster.

>5) I need to check the Dell website for updated drivers - I checked it
>several months ago and there was no update for a couple of years, but
>I'll check again.

There appear to be some recent Truemobile 1400 drivers. Be sure to
grab the correct version for UK.
| <http://support.dell.com/support/downloads/type.aspx?c=us&cs=19&l=en&s=dhs&SystemID=LAT_PNT_PM_D600&os=WW1&osl=en&deviceid=3355&libid=5>


>6) Battery charger, I have tried it without the battery being on charge
>and no change. Should I also try it with mains power but no battery in
>the PC?

No, don't try it without the battery. The idea was to see if the
battery charger "pulsing" with a fully charged battery was causing the
1 minute glitches. It was a long shot.... oh well.

>We are getting closer.....

I hope so. I like to fix things like this by substitution. If you
can scrounge another wireless card, try it instead. Just make sure
you create a system restore point before attacking so you can put
things back to current condition.

John Navas

unread,
Nov 13, 2006, 10:00:23 PM11/13/06
to
On Tue, 14 Nov 2006 02:45:54 GMT, Jeff Liebermann
<je...@comix.santa-cruz.ca.us> wrote in
<ibail2d4q483f2742...@4ax.com>:

>On 13 Nov 2006 14:02:10 -0800, warner_...@hotmail.com wrote:

>>They only occur when I am
>>connected to a wireless network. In fact, if radio is enabled, but I
>>am not connected to a network, they don't occur either - only when I am
>>actually logged on to a wireless network.
>
>Weird. The only think I can think of in the driver that ocurrs at 1
>minute intervals is the "power save" feature. Look for it in the
>properties for the wireless device. I suggest you disable the power
>save mode.

Worth trying, but I doubt that's the cause. I suspect something else
running in the system, even given those symptoms. I'd personally use
MSCONFIG to disable everything possible, in addition to running malware
scans.

>>Therefore this seems to
>>indicate that it's something specific to the wireless card drivers or
>>utility, or at least a conflict between that and something else.
>
>It might also be a program or service that's checking for internet
>access. If it finds internet access, it monopolizes the processor for
>about a second. If it doesn't fine internet access, it doesn't do
>anything, which is why it doesn't show up every minute.

Yep. Lots of shitty software out there. Processor spin loops are lame
but all too common.

>However,
>that's unlikely as it should act the same with wireless and wired
>connections.

Not necessarily -- it could easily be due to differences between wired
and wireless networks -- as you've noted, wireless cards typically
depend on much more host processing.

warner_...@hotmail.com

unread,
Nov 14, 2006, 6:31:11 AM11/14/06
to

Jeff Liebermann wrote:
> Weird. The only think I can think of in the driver that ocurrs at 1
> minute intervals is the "power save" feature. Look for it in the
> properties for the wireless device. I suggest you disable the power
> save mode.
>

Will try that later.

> I hope so. I like to fix things like this by substitution. If you
> can scrounge another wireless card, try it instead. Just make sure
> you create a system restore point before attacking so you can put
> things back to current condition.
>

OK Jeff - I have loaded up an old US Robotics 5410 PCMCIA wireless card
and disabled the on board card.

Results are quite positive.

Firstly, the one minute glitches have disappeared, so we have isolated
those 1 minute glitches to something to do with the on board wireless
function.

Secondly, the real world voice over IP performance seems much better -
I am geeting a good connection with virtually no interference.

On the minus side, my bandwidth seems to have taken a nosedive with
the US Robotics card - I'm down to about 2Meg compared to 6 Meg with a
wired connection. Also, when I run FPING, I am actually seeing more
dropouts than with the on board card - I am seeing long pings and
timeouts probably every 20 secs or so, but not totally regular.
However as I say this doesn't appear to cause a break in IP
communication. I think maybe the difference is that only one packet is
dropping instead of a continuous issue that lasts for a whole second.

However if I can get good IP telephony I may be happy to go with that,
even if my bandwidth seems to be restricted by this USR card. I seem
to remember someone telling me the USR wireless cards were not very
good? Do you have any knowledge on that?

thanks
Patrick.

Jeff Liebermann

unread,
Nov 14, 2006, 12:36:20 PM11/14/06
to
warner_...@hotmail.com hath wroth:

>OK Jeff - I have loaded up an old US Robotics 5410 PCMCIA wireless card
>and disabled the on board card.

That's an 802.11g card and should work (famous last assumptions). It's
not that old as USR lists it on their web pile.
| http://www.usr.com/products/networking/wireless-product.asp?sku=USR5410

>Firstly, the one minute glitches have disappeared, so we have isolated
>those 1 minute glitches to something to do with the on board wireless
>function.

Agreed. That generally eliminates any programs that are not directly
related to the Dell TrueMobile 1400 card and driver. We still don't
know if it's the card or the driver. That's why I suggested you buy
or borrow a 1300 card. I forgot to check with my customers that might
have a D600 or D610. Sorry.

>Secondly, the real world voice over IP performance seems much better -
>I am geeting a good connection with virtually no interference.

Ah... progress.

>On the minus side, my bandwidth seems to have taken a nosedive with
>the US Robotics card - I'm down to about 2Meg compared to 6 Meg with a
>wired connection. Also, when I run FPING, I am actually seeing more
>dropouts than with the on board card - I am seeing long pings and
>timeouts probably every 20 secs or so, but not totally regular.

That sounds like local interference. The drop in speed could be due
to massive retransmissions. Not good. Are you SURE you have the
internal card turned off? There are usually 3 ways to disarm the
card. One is in the CMOS setup which disables the MiniPCI slot for
reduced power consumption. Not every BIOS has this feature. Another
is <Fn><Something> on the keyboard, which I think (not sure) also
disables the power to the card. Last is in Windoze from the system
tray. This just disables the NDIS5 driver and may not totally turn
off the card. It's easy enough to literally extract the card. If you
suspect that it's still running, try a Wirelessectomy.

>However as I say this doesn't appear to cause a break in IP
>communication. I think maybe the difference is that only one packet is
>dropping instead of a continuous issue that lasts for a whole second.

Possible, but difficult to tell with all that packet loss.

>However if I can get good IP telephony I may be happy to go with that,
>even if my bandwidth seems to be restricted by this USR card. I seem
>to remember someone telling me the USR wireless cards were not very
>good? Do you have any knowledge on that?

No, not me. I have some experience with the ancient Eumitcom based
wireless products from about 1998. I have a few of their access
points from this era sitting in the closet doing nothing. They were
not very good at doing anything, but then neither was the competition
at the time. No experience with their PCMCIA cards.

warner_...@hotmail.com

unread,
Nov 18, 2006, 4:44:59 PM11/18/06
to
>
> That sounds like local interference. The drop in speed could be due
> to massive retransmissions. Not good. Are you SURE you have the
> internal card turned off? There are usually 3 ways to disarm the
> card. One is in the CMOS setup which disables the MiniPCI slot for
> reduced power consumption. Not every BIOS has this feature. Another
> is <Fn><Something> on the keyboard, which I think (not sure) also
> disables the power to the card. Last is in Windoze from the system
> tray. This just disables the NDIS5 driver and may not totally turn
> off the card. It's easy enough to literally extract the card. If you
> suspect that it's still running, try a Wirelessectomy.
>

I'll take another look at that - and see if I can disable wireless in
the CMOS - I disabled it by disabling the wireless device in the device
manager.

cheers
Patrick.

warner_...@hotmail.com

unread,
Nov 24, 2006, 4:14:50 AM11/24/06
to
After some delays I have some more news on this issue and potentially a
solution which I will be sure of later.

> >Secondly, the real world voice over IP performance seems much better -
> >I am geeting a good connection with virtually no interference.
>
> Ah... progress.

I had a lot of success using the USR card with VOIP, but I have not
found the cause of the much lower bandwidth. I did try disabling
miniPCI and wireless in the CMOS, but this didn't seem to fix it.
Strangely, I got very mixed results on different internet speed tests -
the BT speedtest reported my USR card as similar bandwidth to the on
board card. However several other speed tests reported it as much
slower, and as said before I can see quite a lot of packet loss.

BUT - yesterday I went back to the on board network card. I tried to
install the latest drivers from Dell, but the driver claimed that it
was not compatible. Then, I tried one thing that I had not done before
- in the device manager wireless card options I disabled a number of
options that I felt were not needed - e.g. Bluetooth sharing, anything
to do with 802.11b, and automatic wake up support for network card
when in standby(these are options that can only be accessed from device
manager and not from the wireless card program). Eureka - the one
minute timed second long glitches seem to have disappeared. I will try
this out with real world VOIP later on today to confirm.

cheers

0 new messages