Print

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

[MDA]

Pinging 192.168.1.1 with 32 bytes of data:
Reply from 192.168.1.1: bytes=32 time=5ms TTL=64
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=4ms 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=7ms 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

Ping statistics for 192.168.1.1:
    Packets: Sent = 9, Received = 9, Lost = 0 (0% loss)

Where i'd have <1ms for every ping to my WRT300-N, with the DIR-636L its different as shown above.
I understand that routing is more time consuming than simply switching, but this is to and from my desktop gaming PC.

I also know that the 700mhz cpu found in the DIR-636L should be much faster at LAN routing than the cpu found in my old router. When I directly connect to my Arris TM722g cable modem, using ookla's pingtest website I get 19ms and 1ms jitter (from MN to IL).

With the DIR-636L connected, I get a 25ms ping and 6ms jitter to the same location. I understand that is all internet routing and pinging the router is only LAN, but it seems that the router is not only affecting LAN, but also WAN routing. This router has a HW nat accelerator! How can this be?





EDIT: I have switched my D-link DIR-636l with my DIR-632 I had as an access point and every ping is under 1ms as well as WAN ping is just like direct connecting to my modem. I am not ruling out D-link as a future buy for the reason that my older one worked, but I will now be requesting to test every new router I buy in store if possible to prevent this defect.

I know enterprise-grade routers are configured to drop or delay packets like this sort of behavior, but this DIR-636L was making the LAN and WAN connections more delayed than necessary. I even tried downgrading firmware and the 30-30-30 reset trick, but nothing would fix my issue.

[FurryNutz]

Any status on this? 

[network1027]

Just tried pinging my DIR-626L from a wired-directly-attached LAN host. Got :
1ms/4ms/9ms/4ms
3ms/2ms/3ms/<1ms

Never tried checking small ping times before ( except in case of obviously serious network troubles, that may send obviously too-long ping times ( >1000 ms )  

What applications may suffer from a 10ms ping time / jitter ? Online Gaming ? VoIP ?

[FurryNutz]

You can try this test:
http://forums.dlink.com/index.php?topic=57919.msg227456#msg227456

[MDA]

Any status on this? 

Well I apologize for it taking this long to respond, but in the meantime I had the chance to test dir-826l and ping the gateway.

Same results as the dir-636l and 626l (I'm pretty sure all of these use the same mediatek ralink mips chip so unless firmware is coincidentally to blame, then the cpu [hardware Nat acceleration] is probably the cause).

It causes at least 5ms of jitter on WAN and LAN side of the router, making gaming and anything latency-dependant a challenge. Am using the DIR-632 with DD-WRT and its great although it doesn't have working ipv6 support which my isp provides. Stock firmware also had broken ipv6 support.

If this were to be fixed, I'd gladly use my newly inherited 826l since its dual band, but this jitter issue makes it unusable for my needs.

[FurryNutz]

What happens if you disable True Gigabit Route Connectivity on the 826L?

• Link>What Firmware version is currently loaded on both routers? Found on the routers web page under status.

Internet Service Provider and Modem Configurations

• What ISP Service do you have? Cable or DSL?
• What ISP Modem Mfr. and model # do you have?
• Is ISP Modem/Service using Dynamic or Static WAN IP addressing?
• What ISP Modem service link speeds UP and Down do you have?

Well I apologize for it taking this long to respond, but in the meantime I had the chance to test dir-826l and ping the gateway.

Same results as the dir-636l and 626l (I'm pretty sure all of these use the same mediatek ralink mips chip so unless firmware is coincidentally to blame, then the cpu [hardware Nat acceleration] is probably the cause).

It causes at least 5ms of jitter on WAN and LAN side of the router, making gaming and anything latency-dependant a challenge. Am using the DIR-632 with DD-WRT and its great although it doesn't have working ipv6 support which my isp provides. Stock firmware also had broken ipv6 support.

If this were to be fixed, I'd gladly use my newly inherited 826l since its dual band, but this jitter issue makes it unusable for my needs.

[MDA]

Same thing. Did that on the DIR-636l before too and the gateway jitter still persists.

Like I said, since all three of these routers use the same processor, it is likely the culprit. Using any firmware version...

I saw your review on the 826l, Furry. Did you/could you try pinging it's ip address?

[FurryNutz]

What current version of the FW is loaded at this time?

It was mentioned that there was a ping issue in a early version of FW however should have been corrected in a later version I believe.

[FurryNutz]

DIR-826L A1 v1.05
Before Factory reset:
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time=4ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time=7ms TTL=64
Reply from 192.168.0.1: bytes=32 time=4ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=6ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=7ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=9ms TTL=64
Reply from 192.168.0.1: bytes=32 time=5ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time=8ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=7ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time=9ms TTL=64
Reply from 192.168.0.1: bytes=32 time=5ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Ping statistics for 192.168.0.1:
    Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 9ms, Average = 3ms

After Factory reset with out changing anything:
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=8ms TTL=64
Reply from 192.168.0.1: bytes=32 time=5ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=4ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=6ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=4ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=9ms TTL=64
Reply from 192.168.0.1: bytes=32 time=5ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=8ms TTL=64
Reply from 192.168.0.1: bytes=32 time=4ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=6ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time=8ms TTL=64
Reply from 192.168.0.1: bytes=32 time=4ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=6ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time=8ms TTL=64
Reply from 192.168.0.1: bytes=32 time=4ms TTL=64

Ping statistics for 192.168.0.1:
    Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 9ms, Average = 4ms   

Asked D-Link to review this. Shouldn't be seeing such fluctuations on wired connections.

[FurryNutz]

Looks like the following routers don't see this issue:
DIR-868L A1 v1.08
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.0.1:
    Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms
   
DIR-810L A1 v1.02
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.0.1:
    Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 6ms, Average = 0ms

A non-D-Link Mfr Router online with ISP modem and other devices.
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.0.1:
    Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

[FurryNutz]

Link to the DIR-826L board:
http://forums.dlink.com/index.php?topic=51005.0

[MDA]

A little update since,

I fortunately have a T-mobile cellphone subscription and got one of their new Cellspot routers (essentially an Asus RT-AC68U) for 0$.

I know if this problem wasn't occuring in the first place, I would have stuck with the DIR-636L because otherwise, it had all the features I needed. Knowing it may have a possibility to get fixed, I might use the DIR-636L and 826L at other relatives and friends' places that need them.

This problem though, seems like a queueing issue because the bandwidth when file transferring or streaming is really stable with these routers, but the latency/jitter made the gaming a challenge.

[FurryNutz]

Thanks for the feed back. It's under review with D-Link at this time. I presume it will get fixed in the next FW update. We hope.

It only seems to be effecting the 636L and 826L and 836L models at this time. Not sure if the 626L or similar models are effected...I testing my 868L and 810L and they don't exhibit this issue.

Please be patient.

[MDA]

No problem, furry.

Thank you for verifying this issue 

[FurryNutz]

I'll post again if I get any info...if not, then will look for a fix in next release.