Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Algorithms / techniques to determine available bandwidth


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 Angus Hollands   Members   -  Reputation: 722

Like
0Likes
Like

Posted 10 December 2013 - 03:33 PM

Hi everyone,

As the question states, I was wondering how best to determine the available bandwidth of a connection. I intend to determine the update frequency of a networked entity based upon its network priority and the available bandwidth.

Any ideas?

Thanks,

Angus.



Sponsor:

#2 Nikopol_AU   Members   -  Reputation: 468

Like
0Likes
Like

Posted 10 December 2013 - 07:14 PM

The problem is that connection quality can change over time.

In both directions.

 

Start sending updates at certain pre-defined rate.

When connection quality decreases (more and more packets get dropped), you respond by decreasing your update rate.

When connection quality has been good for certain time, you can start to increase your update rate.



#3 hplus0603   Moderators   -  Reputation: 5692

Like
2Likes
Like

Posted 10 December 2013 - 07:18 PM

The short answer is that you can't, and if utilizing bandwidth efficiently is your goal, you should use TCP.

 

The long answer is that you can use packet loss as a proxy for bandwidth, and slowly increase the bandwidth until you get a dropped packet, and then quickly throttle back. Where "slowly" means "linearly add some constant to your estimate of bandwidth" and "quickly" means "halve the estimated throughput," you will behave like traditional TCP stacks. (Main improvements in later years: quick-start, path memory, window scaling mechanisms.)

 

It's important that you behave like this (quick scale-back, slow growth) to avoid overwhelming some local choke point, or getting into extreme oscillation, when other sources of traffic are also sharing the connection.

 

If you use TCP, then set a buffer size that you're willing to live with, and keep sending on the socket. When the send blocks and/or doesn't transfer all the data, you know that the buffer is full, and thus the other end is behind compared to the speed you have been sending at.

 

Note that, when your girlfriend starts watching Netflix, or your ISP is doing router maintenance, the available bandwidth for an existing connection may quickly change!


enum Bool { True, False, FileNotFound };

#4 Angus Hollands   Members   -  Reputation: 722

Like
0Likes
Like

Posted 11 December 2013 - 09:10 AM

And what sort of tolerance should I use for dropped packets (so that a batch of five successive packets that may be dropped don't lead to a reduction of 0.5^5
Would you advise having a safe window of the rtt + x to ensure that we only see new feedback?

#5 hplus0603   Moderators   -  Reputation: 5692

Like
0Likes
Like

Posted 11 December 2013 - 03:20 PM

Five packets dropped in a row does mean that you have a significant network congestion event, and should drastically scale back your estimate.
Perhaps you could say that each successive dropped packet after the first dropped packet after a successful packet back down by 0.8 instead of 0.5, but you'd still need to back off significantly if you get a significant amount of packet drop.

Feel free to keep a "minimum accepted" level, and either not drop below that, or kick the user off if it cannot be maintained (with proper user messaging so the user knows what the problem is.)
enum Bool { True, False, FileNotFound };




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS