Ok, you already posted while I was assembling this novella so please disregard the QOS entry. I will leave it in case others may find some use for it. Is your Virgin cable service new, or are the problems you are experiencing only as result of changing routers? I assume you bought the DIR-655 to be able to do things your former router could not do? Short of your router being defective, in my simple mind I'm thinking there
has to be a way to resolve these issues.
Have you ever run a TCP optimizer to see if 1500 is the optimal setting? Also to check your TCP Receive Window number? Did you change NICs? Each NIC has it's own MTU registry setting. There are QOS settings in the Windows registry that can negatively impact your performance. Is your connection PPP? The passages below have helped me tremendously and enabled me to tweak my setup to get every MBps I'm paying for. There are guys on this forum that might disagree wth some or all of it. There is no shortage of information similar to this in the numerous Broadband websites found by a Google search. Best of luck, Pawl.
This is but one of many TCP optimizers out there. The best thing about them is that they are free.
http://www.speedguide.net/tcpoptimizer.phpExcerpted:
TCP Receive Window (a.k.a. RWIN) - this buffer is the single most important factor in tweaking your TCP/IP parameters. A small RWIN value limits your maximum throughput (the server waits for acknowledgements of received packets), one much larger than needed by your connection can have a negative effect on your connection as well. Here is some history on RWIN, and all the considerations in choosing an "optimal" value:
Originally, when the TCP protocol was developed, there were only 16 bits in the TCP header reserved for the size of this buffer, allowing for a maximum value of 2^16 (65535, if you start counting from 0). With faster high-latency networks this value proved insufficient, and RFC 1323 introduced additional "TCP Options", allowing for larger RWIN values. It is accomplished by bit shifting, or multiplying the original unscaled RWIN value (up to 65535 bytes) in the TCP header by a scale factor, power of 2.
The TCP Optimizer recommends an optimal TCP Window value considering all the following factors:
- Bandwidth * Delay product based on the chosen maximum connection speed and maximum anticipated latency.
- RWIN (both scaled and unscaled) multiple of MSS, for maximum optimization.
- Proper RFC 1323 scaling for RWIN values larger than 65535.
- largest optimal unscaled RWIN (MSS multiple) used for all RWIN values over 65535.
Type/Quality of Service QoS (Quality of Service) and ToS (Type of Service) have to do with support for priority traffic.
QoS is enabled by default in Windows XP, and can limit available bandwidth in order to accommodate high-priority traffic, when present. The Optimizer only changes the QoS value if it is already present in the registry. It is in the Registry only if the QoS Packet Scheduler is installed (can be added from the Network Adapter Properties).
We recommend having the QoS Packet Scheduler uninstalled, or/and setting the QoS: NonBestEffortLimit Optimizer setting to 0%.ToS (Type of Service, RFC 791, RFC 1812) is a field of the IP header, designed to also carry quality of service features, such as prioritized delivery for IP datagrams. It is not widely used, and it has been redefined and superseded by a newer standard called Differentiated Services (DiffServ) and defined in RFC 2474 , RFC 2475, RFC 2597, RFC 2598. DiffServ increases the number of definable priority levels by reallocating bits of an IP packet for priority marking. The TCP Optimizer allows for ToS/DiffServ editing, although it is an advanced setting, probably beyond the scope of regular residential broadband tweaking. If you feel comfortable editing this value, you might also want to note possible conflicts with using some ToS values in a DiffServ environment, as described in RFC 2873.
ToS other than 0 is only available if ToS: DisableUserTOSSetting is present, and set to "0" in the Optimizer. If enabled, the ToS: DefaultTOSValue can be set to a specific number, (which is probably beyond the scope of this help file, but is somewhat explained below - feel free to read the related RFCs referenced above for more info). If we must make a recommendation, here are some good DefaultTOSValue numbers that are valid, and with high precedence in both ToS and DiffServ environments:
DefaultTOSValue = 80 - (010 100 00 binary). This setting should be tried first. It is not very aggressive, but it takes precedence over regular traffic and asks for low delay. For ToS, you get immediate precedence, low delay. For DiffServ, you get AF22 - class 2 traffic, medium drop probability.
DefaultTOSValue = 136 - (100 010 00 binary). This is a moderately aggressive precedence setting. For ToS, you get flash override precedence, high throughput. For DiffServ, you get AF41 - class 4 traffic, low drop probability.
DefaultTOSValue = 184 - (101 110 00 binary). This is a very aggressive setting, that might introduce some packet loss - it is usually only recommended for audio/video applications. For ToS, you get critical precedence, low delay, high throughput. For DiffServ, you get EF - Expedited Forwarding, high priority traffic, but with higher drop probability.
DNS Error Caching Windows has built-in DNS (Domain Name System) caching, which basically caches resolved hostnames for faster access and fewer DNS lookups. This is generally a great feature, with the only downside that failed DNS lookups get cached by default as well... When a DNS lookup fails (due to temporary DNS problems), Windows still caches the unsuccessful DNS query, and in turn fails to connect to a host regardless of the fact that the DNS server might be able to handle your lookup seconds later. One can manually flush failed DNS lookups by typing ipconfig /flushdns in Command prompt... Or you can simply set the 3 values in the Optimizer to "0", and it will set the relevant Registry settings.
Author
Topic: Performance Degrading over time (Read 11521 times)