D-Link Forums

The Graveyard - Products No Longer Supported => Routers / COVR => DIR-655 => Topic started by: JaLooNz on March 26, 2008, 08:29:19 PM

Title: Downstream optimisation
Post by: JaLooNz on March 26, 2008, 08:29:19 PM
Hi,

1) Is there any settings which will help prevent saturation of the downstream connection by delaying the ACK packets? Currently when I download at the line capacity via HTTP, browsing will stop and pages won't load. Other connections also start to timeout. My old WRT54G with DDWRT doesn't do this, but I also cannot live without the Gbit LAN port.

2) Is there any way to remove the rebooting after saving settings? I believe this was present in 1.04 but it seems to removed.
Title: Re: Downstream optimisation
Post by: camattin on March 27, 2008, 06:47:14 AM
Number 1 is what I was hoping to get with this router since it advertises QoS.  It's a bit misleading that they say it has QoS when it's not fully (properly?) implemented.
Title: Re: Downstream optimisation
Post by: fgl30 on March 27, 2008, 10:30:11 AM
As far as I know D-Link (Ubicom) QoS engine do not affect downstream... it only improve upstream... ???
Title: Re: Downstream optimisation
Post by: Lycan on March 27, 2008, 04:30:22 PM
Let me see if I can clarify, downstream is kinda silly in a home environment, since the routers LAN runs at 10/100/1000 and your pipe is usually around 5-15mbps down and less then 10mbps up, then the data would already be at the router and the router could handle ti faster then the pipe could feed it.
Does that help?
Title: Re: Downstream optimisation
Post by: JaLooNz on March 27, 2008, 07:39:13 PM
It is precisely that the down pipe is limited that the heavy download requests should be throttled such that the normal browsing packets can go first. The router can handle lots of packets, but if the important packets are such delayed such that it timeouts due to the saturated downstream, things will start going way wrong.
Title: Re: Downstream optimisation
Post by: Lycan on March 31, 2008, 11:43:03 AM
LOL, if the packet has already hit the WAN of the router, the router can NAT 800+mbps, are you telling me that you believe that the router could possibly create a bottleneck there?
Once the packet is already at therouter the ISP has offered it to you as fast as then can. (respectively)If the packets are at the router, then the router can offer them to you faster then the ISP can get it to the router.

(ISP = 10-15mbps < Router = 800+mpbs.)

So now the issue is when the router is pulling from more then 1 source, (e.g. a UDP video stream [youtube] and a data source [FTP download]) how does it negotiate with both sources?  Well the issue is still the same.
(ISP = 10-15mbps < Router = 800+mpbs.)

So for downstream QoS the router would have to negotiate with the ISPs hardware to request the packets in the desired order. We ALL know thats not going to happen.
Title: Re: Downstream optimisation
Post by: JaLooNz on March 31, 2008, 04:56:34 PM
Yes, the router will not cause a bottleneck, but the downstream packets will. I know that we cannot control the ISP's router, but we can possibly delay the ACK packets such that the request packets for the download traffic are not sent till the browsing traffic is sent and recieved.

A connection to a IP with hundreds of packets per second and a long connection time vs a connection to a IP with only a few packets per second, it is more likely that the latter is the browsing traffic, while the other is a download stream. The router can temporarily hold up the request packets for the download stream while allowing the browsing traffic to go...

Is this not possible?
Title: Re: Downstream optimisation
Post by: MitchSchaft on April 01, 2008, 11:17:22 AM
Quote
the router will not cause a bottleneck, but the downstream packets will

That sounds like a contradiction to me.
Title: Re: Downstream optimisation
Post by: Lycan on April 01, 2008, 11:23:03 AM
LOL, where is it going to hold the packet at? At the ISPs hardware? That would require the our router to issue insturction sets to the ISPs hardware. Thats  not going to happen. EVER.