Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[zambarossa]

I am streaming an mkv file from my WD MyBook and I am having issues with hiccups or sudden pauses every few minutes when using my DWA-160. This happens in both 2.4GHz and 5GHz bands and both N and A/G modes. No issues with the built in intel wireless adapter in both A and G modes.

DWA-160 rev A1
Acer 5920G laptop
vista x32 premium home w/SP1
Driver version 3.1.0.104
Utility Version: V1.40

Connected to a DIR-825 running A+N in 5GHz band and G+N in 2.4 GHz band.

I tried all combination of disabling mixed mode, disabling one radio and leaving the other running, changing channels, disabling WMM, etc. with no luck. Anyone else have such problems or any suggestions on what to try next? Do I need to exchange this for a rev B part or it doesn't make a difference?

Thanks in advance for any response.

[zambarossa]

P.S. I noticed my router (DIR-825) is reporting many RX dropped packets with the DWA-160 but none with the Intel PRO/wireless 3945ABG built in adapter. Any way to get more detailed stats regarding those dropped packets?

[arod]

Try to uninstall the D-Link wirerless utility along with the drivers and reinstall just the drivers and use windows zero config utility to connect to your SSID.

[zambarossa]

Try to uninstall the D-Link wirerless utility along with the drivers and reinstall just the drivers and use windows zero config utility to connect to your SSID.

No luck with that  , any other suggestions? Thanks.

[zambarossa]

It is definitely the adapter, not sure if it is a firmware, driver, or hardware issue though. I tested it against a DIR-625 in G and N modes with same bad results. I ran a ping while streaming video and every time a hiccup happens it seemed there is a > 2 second  delay in the ping reply:


Reply from 192.168.0.199: bytes=32 time=1ms TTL=64
Reply from 192.168.0.199: bytes=32 time=2ms TTL=64
Reply from 192.168.0.199: bytes=32 time=1ms TTL=64
Reply from 192.168.0.199: bytes=32 time=2ms TTL=64
Reply from 192.168.0.199: bytes=32 time=2ms TTL=64
Reply from 192.168.0.199: bytes=32 time=10ms TTL=64
Reply from 192.168.0.199: bytes=32 time=1ms TTL=64
Reply from 192.168.0.199: bytes=32 time=1ms TTL=64
Reply from 192.168.0.199: bytes=32 time=1ms TTL=64
Reply from 192.168.0.199: bytes=32 time=3ms TTL=64
Reply from 192.168.0.199: bytes=32 time=2ms TTL=64
Reply from 192.168.0.199: bytes=32 time=1ms TTL=64
Reply from 192.168.0.199: bytes=32 time=1ms TTL=64
Reply from 192.168.0.199: bytes=32 time=1ms TTL=64
Reply from 192.168.0.199: bytes=32 time=2776ms TTL=64
Reply from 192.168.0.199: bytes=32 time=10ms TTL=64
Reply from 192.168.0.199: bytes=32 time=1ms TTL=64
Reply from 192.168.0.199: bytes=32 time=2ms TTL=64
Reply from 192.168.0.199: bytes=32 time=1ms TTL=64

^C
C:\Windows\system32>ping 192.168.0.199 -t

Reply from 192.168.0.199: bytes=32 time=1ms TTL=64
Reply from 192.168.0.199: bytes=32 time=2ms TTL=64
Reply from 192.168.0.199: bytes=32 time=6ms TTL=64
Reply from 192.168.0.199: bytes=32 time=2ms TTL=64
Reply from 192.168.0.199: bytes=32 time=1ms TTL=64
Reply from 192.168.0.199: bytes=32 time=1ms TTL=64
Reply from 192.168.0.199: bytes=32 time=2ms TTL=64
Reply from 192.168.0.199: bytes=32 time=1ms TTL=64
Reply from 192.168.0.199: bytes=32 time=2171ms TTL=64
Reply from 192.168.0.199: bytes=32 time=4ms TTL=64
Reply from 192.168.0.199: bytes=32 time=3ms TTL=64
Reply from 192.168.0.199: bytes=32 time=3ms TTL=64

Ping statistics for 192.168.0.199:
    Packets: Sent = 42, Received = 42, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 2171ms, Average = 54ms
Control-C
^C
C:\Windows\system32>
C:\Windows\system32>

C:\Windows\system32>ping 192.168.0.199 -t


Reply from 192.168.0.199: bytes=32 time=2ms TTL=64
Reply from 192.168.0.199: bytes=32 time=1ms TTL=64
Reply from 192.168.0.199: bytes=32 time=20ms TTL=64
Reply from 192.168.0.199: bytes=32 time=1ms TTL=64
Reply from 192.168.0.199: bytes=32 time=2ms TTL=64
Reply from 192.168.0.199: bytes=32 time=2ms TTL=64
Reply from 192.168.0.199: bytes=32 time=2529ms TTL=64
Reply from 192.168.0.199: bytes=32 time=2ms TTL=64
Reply from 192.168.0.199: bytes=32 time=2ms TTL=64
Reply from 192.168.0.199: bytes=32 time=1ms TTL=64
Reply from 192.168.0.199: bytes=32 time=1ms TTL=64
Reply from 192.168.0.199: bytes=32 time=2ms TTL=64
Reply from 192.168.0.199: bytes=32 time=3ms TTL=64
Reply from 192.168.0.199: bytes=32 time=1ms TTL=64

Ping statistics for 192.168.0.199:
    Packets: Sent = 97, Received = 97, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 2529ms, Average = 50ms
Control-C
^C
C:\Windows\system32>


Reran the same test against the DIR-825 in N mode while pinging the router interface this time, and same 2+ second delay when hiccup occurs:

Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2487ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=12ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64

Ping statistics for 192.168.1.1:
    Packets: Sent = 344, Received = 344, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 3031ms, Average = 41ms
Control-C
^C
C:\Windows\system32>


I tried changing the security settings to WPA/TKIP just in case this is an AES performance issue, but that didn't make a difference. 

I contacted DLink support, but their 1st level support didn't add anything insightful, just went over what I already did, agreed that there is nothing else to try and told me to call back again when the 2nd level support are available. 

Not sure if anyone else has seen something similar. I am tempted to walk in to a local Best Buy and pickup another rev A unit to see if it is just my unit that is defective or if it is a rev A issue. If I can find a rev B I will also get one to see if that makes any difference.

As always, any additional insight is appreciated.

[zambarossa]

Just finished talking to DLink's Product Specialist support person and they concurred the part seems defective. I even tried it on my Vista64 desktop with similar results. They have recommended I replace it with a Rev B part if I can get my hands on one. Now I have to deal with the RMA process  .

[Rideau]

I had the same sort of issue with WoW when playing excessive stuttering every so many secs.  Here is what resolved my issue:  Running Vista 64 Ultimate.

Start button / Control panel / Hardware and Sound / Device Manager / Network adapters / D-Link DWA -160 / now right click on D -Link DWA 160 / Properties / Advanced / Multimedia/Gaming Environment => It may say Disabled => Enable it.

That fixed my issue and should fix yours.

[zambarossa]

I had the same sort of issue with WoW when playing excessive stuttering every so many secs.  Here is what resolved my issue:  Running Vista 64 Ultimate.

Start button / Control panel / Hardware and Sound / Device Manager / Network adapters / D-Link DWA -160 / now right click on D -Link DWA 160 / Properties / Advanced / Multimedia/Gaming Environment => It may say Disabled => Enable it.

That fixed my issue and should fix yours.

hmmmm I can't seem to find that option. What hardware and firmware revision and which version of the driver are you running?

[Rideau]

I have the Rev B.  and running the Ralink Drivers: http://www.ralinktech.com/ralink/Home/Support/Windows.html ,  If you have the Rev B. download the RT2870.

[zambarossa]

No unfortunately I have the rev A1 as indicated in my 1st post. For the heck of it I went and got another rev A1 from Best Buy and tried it and had the same exact problem, so it seems a generic problem related to rev A hardware. I could not locate rev B units at any local Best Buy or Future Shop. Where did you buy yours?

I am now leaning towards taking a hit on the shipping and returning it for a full refund and looking for another dual band N adapter from another manufacturer.

[Rideau]

At a BestBuy here in Mass. 

[zambarossa]

Well I went ahead and got a Linksys WUSB600N to try it out and guess what, it exhibited the same symptoms. I thus concluded it is not an issue specific to the DWA-160 and went around looking for reasons. Lo and behold it turned out to be a Windows problem. It seems the WLAN config service on Vista decides to run a scan every so often and that causes the 2-3 second delay. I am suspecting this is exasperated by the fact there are lots of APs around. I also stumbled across the solution to my problem at this link (http://www.wlanbook.com/disable-windows-vista-wireless-zero-configuration/). What I have to do now is run the following command every time after I connect and no lag whatsoever anymore:

netsh wlan set autoconfig enabled=no interface=”Wireless Network Connection 3”

However every time I need to reconnect I have to reenable auto config:

netsh wlan set autoconfig enabled=yes interface=”Wireless Network Connection 3”

The commands need to be run as admin in vista. I created a couple of batch files so I don't have to type the commands over and over.

I am not too surprised that windows is doing something this silly, but I am somewhat surprised that Dlink and Linksys Engineers along with Dlink product support had no clue about this especially that it seemed to be a common problem especially among gamers. What puzzles me still is why my built in Interl/PRO wireless adapter didn't exhibit this problem! Maybe Intel knows something Dlink and Linksys don't.

So afterall, I guess I will keep my DWA-160 and return the Linksys. I did some performance testing and for the most part both adapters perform similarly with the Dlink doing performing slightly better in the 5GHZ and the Linksys performing slightly better in the 2.4GHz band, nothing to swing me one way or another. To be honest I liked the design of the DWA better, esp. the USB cradle :-).

I guess this story has a happy ending afterall. I will report back if I run into any trouble in the future.

[Lycan]

I'll check in to that, it would seem that this type of failure caused by the WZC would be present on ANY vista machine, I wonder why more people aren't having this issue. 

[zambarossa]

I'll check in to that, it would seem that this type of failure caused by the WZC would be present on ANY vista machine, I wonder why more people aren't having this issue. 

I am curious as to whether it is related to being in a wi-fi "busy" area with lots of APs within range, as is it in my case! Just a thought. Also I didn't notice it till I started to play a video file off of a network share (so not exactly buffered streaming as my title maybe suggested). Running ping confirmed the lag.

[Jaska]

I have to give some contribution into this thread as well. I had a similar problem and similar setup with zambarossa (DWA-160 A1, DIR-825, 32-bit Vista Ultimate). No matter how I set up the network (G, N, 2.4 GHz, 5 GHz) there were those strange delays during low rate wireless communication.

For example, when streaming a high bitrate HD movie there were no problems and no network delays according to diagnostic tools. Streaming a low bitrate file instead - e.g. an SD movie - caused the network to pause constantly which made watching videos a jumpy experience and nearly impossible.

As the problems were this specific I thought the problem was in certain file types and so it was _really_ hard to find the solution as it was this general. Thanks to zambarossa for several posts you have made. There is actually an application which you can set to automatically handle those annoying user commands: http://www.martin-majowski.de/wlanoptimizer/

Btw. I tried to repeat the problem with completely similar system without DWA-160 and there were no problems at all. I hope you can get the DWA-160 driver fixed to get rid of extra startup applications.