1

I use tcping, which pings a TCP port, in order to check the connection of my computer to a certain port. The average response time of a specific address and port is 50ms in normal connection. Now I start a download from another address using IDM, which splits the file and download the files simultaneously. My ping reply time increases to around 1500ms. I am sure that my download increased this reply time because when I pause my download, the reply time goes back to 50ms.

Image of the problem

I want to prevent this increase of reply time on registered addresses and ports.

I don't want to use NetLimitter or NetBalancer.

I have also tried this. I checked Wireshark and I am sure the DSCP is set but my problem is not solved.

Improve this question
10
  • What kind of Internet package do you have from your isp? What kind of router? How is the computer connected to the Internet?
    – Julysfire
    May 28, 2017 at 15:40
  • Can you reduce the number of concurrent connections (simultaneous downloads/threads) or whatever it's called in IDM to below your number of CPUs. Such that there is a free CPU for tcping. Does that help?
    – HelpingHand
    May 28, 2017 at 16:53
  • 2
    You don't want to use the exact tools that will prevent you from saturating your connection and therefore will actually cure your problem? Well, the only alternatives are to get rid of IDM or stop downloading things at all. Unless you tell us why you don't want to use them it is a bit unhelpful to rule them out.
    – Mokubai ♦
    May 28, 2017 at 18:03
  • @Julysfire My router is Linksys X3500 and The computer is connected using Wifi to the router and router is connected to the ISP using telephone line and ADSL2+
    – Matin Lotfaliee
    May 28, 2017 at 18:05
  • @Biswa I want to be able to choose between ports. Some ports are slower and some are faster.
    – Matin Lotfaliee
    May 28, 2017 at 18:06

2 Answers 2

Reset to default
0

If saturating either your upstream or your downstream network bandwidth causes latency to spike, it means some box in your network path (probably your broadband modem or your ISP's CMTS or DSLAM) has a well-known bug called bufferbloat, where excessive buffering on a box increases latency without benefit.

The fix for bufferbloat is to upgrade the queuing algorithm (a.k.a. queue discipline, network scheduler) of the buggy device to a latency-aware smart queueing algorithm such as FQ-CoDel.

If you can't fix the actual box with the problem, you can work around it by setting up a box with FQ-CoDel at the head of your network and tune its traffic shaping to make it a slight bottleneck in both the upstream and downstream directions. That way FQ-CoDel gets to kick in and allow TCP congestion control to work, before bloated buffer queues can build up on the buggy box.

You can do this yourself with open source router firmware distros such as LEDE (formerly OpenWrt), but if you want a turn-key solution, look at IQrouter from evenroute.com. It apparently auto-tunes its bandwidth shaping throughout the day, maximizing throughput while minimizing latency.

Many people who haven't learned about bufferbloat wrongly assume latency spikes are a natural result of saturated network links. Many people also make problematic attempts to work around bufferbloat by tweaking QoS, trying to prioritize some flows over the large flows that are triggering bloat. But solving bufferbloat directly is much better, because it improves all flows, even the big ones that were triggering bloat.

Improve this answer
8
  • Very interesting. I've observed this behavior with prevalence that closes in on ubiquitous. Any explanation for why so many devices are affected by it? Do networking hardware vendors lack an incentive to fix it? Is there a "reason" in their eyes for this behavior to stay? Something else?
    – I say Reinstate Monica
    May 29, 2017 at 1:06
  • @Twisty RAM became cheap so engineers added more frame buffer space so frames would never have to be dropped. Problem is, TCP Congestion Control uses frame drops to detect congestion. So they acccidentally hid the congestion from TCP without realizing it. Now it's an issue of raising awareness to get middlebox makers to adopt CoDel. Google's "BBR" congestion control algorithm treats bufferbloat latency increases (not just packet drops) as a sign of congestion, as an attempt to make the endpoints smarter to work around this middlebox bug.
    – Spiff
    May 29, 2017 at 5:56
  • @Spiff I am not sure you get the CoDel right... Please have a look at Wikipedia: en.wikipedia.org/wiki/CoDel There are two things: 1) with CoDel you are fixing queues under your control, not ISP and 2) the bottleneck is happening when packets from fast network travelling to a slow net, i.e. from the ISP (fast) net to a client link (slow). So CoDel on a broadband modem will not help, unfortunately...
    – Andriy Berestovskyy
    May 29, 2017 at 16:42
  • 1
    @AndriyBerestovskyy The bufferbloat researchers initially developed CoDel on consumer hardware because it was easy and in their control, but they never intended it to just stop there. The goal is to get all middlebox makes and ISPs to employ smart queueing like CoDel or PIE everywhere, including CMTSes, DSLAMs, traffic shapers, etc. Mike "Dave" Taht's CoDel research is sponsored by Comcast, a giant cable ISP in the US. It takes a while to fix all the middleboxes on the Internet, but the process has begun.
    – Spiff
    May 29, 2017 at 17:06
  • @AndriyBerestovskyy Also, the workaround I mentioned (of making an artificial bottleneck on your network and running CoDel on it so ECN or drops happen before bloat can build up on other boxes) really does work, in both directions. Many people have successfully deployed this trick. evenroute.com has even built a commercial product around this trick (IQrouter).
    – Spiff
    May 29, 2017 at 17:09
-1

Each Internet connection has two directions: from user to the Internet and back. Each direction is independent in therms of QoS and route the packet traverse.

Setting a priority on the OUTGOING packets does not change the priority of INCOMING packets. The priority and QoS of INCOMING packets are still under control of your ISP.

If you have an option to prioritize your traffic on the ISP side - you should try this. Otherwise, your only option is to rate limit you incoming "best effort" traffic, so you always have some bandwidth for your pings or other "high priority" traffic.

Unfortunately, that is not a solution, but I hope it will help you to understand the issue.

Improve this answer
2
  • So you are suggesting me to reserve some bandwidth myself. Right?
    – Matin Lotfaliee
    May 28, 2017 at 19:17
  • @MatinLotfaliee that is the only option if 1) you have no control over QoS on the ISP side and 2) the bottleneck is incoming traffic (from your ISP to you). The QoS configurations will help only when the bottleneck is outgoing traffic (from you to ISP).
    – Andriy Berestovskyy
    May 28, 2017 at 19:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .