Member Avatar for silvercats

Let's say connection 1's speed is 1.5Mb/ps and its latency is 100ms,connection 2 is 1.5Mb/ps and latency is 200. what is the direct connection of latency to speed? if we download something using both connections ,speed is same and gaming (counter strike for example) is impossible with higer latency. but speed is not affected. WHY
thanks

  • 3 Contributors
  • 2 Replies
  • 282 Views
  • 2 Months Discussion Span
  • Latest Post Latest Post by goatnetworking

Dani AI

Generated

Short answer: the reason your downloads can reach the same megabits/sec while gaming still feels terrible is the bandwidth-delay product (BDP) and how interactive packets are handled. Building on and , BDP tells you how many bytes must be "in flight" to keep a given bandwidth saturated; if the transport (TCP windows, multiple streams) can hold that many bytes, a long file transfer will fill the pipe even with higher RTT.

BDP = bandwidth * RTT

1.5 Mb/s * 0.1 s = 0.15 Mb = 150000 bits = 18750 bytes (~18.75 KB)
1.5 Mb/s * 0.2 s = 0.30 Mb = 300000 bits = 37500 bytes (~37.5 KB)

If the sender and receiver (or browser with parallel connections) can buffer that many bytes, throughput is not limited by RTT. Games, however, exchange small, time‑sensitive packets (often over UDP) where each action depends on the RTT and on low jitter. Small packets and per-event round trips cannot be hidden by windowing or parallel streams, so higher RTT directly increases perceived lag.

Practical checks and fixes: measure ping and jitter to the game server and run traceroute to spot routing problems; test throughput and loss with iperf; avoid saturating your upstream (even downloads can cause uplink ACKs to queue) — cap uploads at ~70-90% of upstream or enable QoS/traffic shaping; prefer wired Ethernet; enable router AQM (fq_codel or cake) to reduce bufferbloat; and prioritize game ports/UDP in QoS. VPNs usually add RTT, so avoid them while gaming.

For : the numbers show why throughput can stay the same while interactivity degrades. pointed out the interactive cost of RTT, and ’s window/bus idea links directly to BDP — together they explain the behavior you observed.

Recommended Answers

All 2 Replies

Member Avatar for skatamatic

Latency is the amount of time it physically takes your data to arrive at your destination - it's based mostly on distance, optimum routing and hardware that must be passed through. The speed is based off of your bandwidth - basically how much your ISP is lending you and can also be limited by hardware (slower NICs for example). Once you establish a connection, assuming there is low packet loss, the other end knows what it needs to send you and starts sending a stream of data. At this point the data is continous and latency only affects when it begins arriving, after that it is your bandwidth (download) and theirs (upload) that determines how fast you can accept it.

In a game you are constantly sending commands and receiving game states - and since these aren't predetermined latency comes into effect. The time between when you send the command and receive the game state is your latency. It doesn't matter how fast your internet is, if it takes a long time between when you send a command and the server receives it this will cause the frustrating lag that you are talking about. You might take 300ms to send a keystroke then receive the new gamestate, leaving you 300ms behind the actual game.

Edited by skatamatic
Member Avatar for goatnetworking

skatamatic is correct. Here is another way to think of it.

Latency is how fast it takes to load up a bus full of people.
Bandwidth is how many people fit into the bus.

Keep in mind that there is a window size in TCP/IP. A group of packets are sent, then waits for the other end to ACK those packets. While waiting for the ACK, the sender may be doing nothing for those 100-200ms.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.