Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Author Topic: Bandwidth-delay product values  (Read 599 times)

Weaver

  • Kitizen
  • ****
  • Posts: 4004
  • Retd sw dev; A&A; 3 × 7km ADSL2; IPv6; Firebrick
Bandwidth-delay product values
« on: March 07, 2017, 11:05:51 AM »

Can anyone tell me what the bandwidth-delay product values are for their internet connections? Well we can work them out. Will need to know the type of link, protocols, yand the usual basic numbers including latency and some ping times if poss. DSL users: would be interested to know what interleave settings you have.

Btw, does the "latency" often quoted mean round-trip time, or one-way? (Stupid question, I’m sure. I ought to know.) I presume that gamers might care about both.
Logged

roseway

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 38343
  • Penguins CAN fly
    • DSLstats
Re: Bandwidth-delay product values
« Reply #1 on: March 07, 2017, 11:21:17 AM »

The output of a ping request can only be the round trip time. This is of course very dependent on the routing to the remote site, so it's fairly pointless comparing different users' results.
Logged
  Eric

Weaver

  • Kitizen
  • ****
  • Posts: 4004
  • Retd sw dev; A&A; 3 × 7km ADSL2; IPv6; Firebrick
Re: Bandwidth-delay product values
« Reply #2 on: March 07, 2017, 02:13:01 PM »

Agreed about ping. Pings would have to be to the first hop outside your own site, but to your own ISp would be interesting and to some standard point would be interesting. My other question is about people's understanding of the term ‘latency’, how they personally use it.

I'm interested in delay-bandwidth product because I'm wondering about performance tuning and how correct or not operating systems’ setting might be, and about their auto-tuning mechanisms or heuristics. This was sparked off by the earlier thread where we discussed the horrors of WinXp. (What on earth were Microsoft thinking?) I'd really like to get some very rough numbers just to get some idea. I can do my own numbers, but I am pretty odd, so I have no idea about others.

Coming back to WinXp, were they stuck in the days of dialup? Where delay was modest but bandwidth was so low that they thought they could get away with 4 kB, was it, Chyrs said?
Logged

Ignitionnet

  • Reg Member
  • ***
  • Posts: 503
Re: Bandwidth-delay product values
« Reply #3 on: March 15, 2017, 12:15:26 PM »

Can anyone tell me what the bandwidth-delay product values are for their internet connections? Well we can work them out. Will need to know the type of link, protocols, yand the usual basic numbers including latency and some ping times if poss. DSL users: would be interested to know what interleave settings you have.

Btw, does the "latency" often quoted mean round-trip time, or one-way? (Stupid question, I’m sure. I ought to know.) I presume that gamers might care about both.

No, as the latency depends where I'm connecting to. BDP is only really relevant in enterprise environments connecting to a remote site across very high bandwidth, high latency sites.

There's no real tuning to do, most of us use TCP stacks that auto-tune.
Logged

Weaver

  • Kitizen
  • ****
  • Posts: 4004
  • Retd sw dev; A&A; 3 × 7km ADSL2; IPv6; Firebrick
Re: Bandwidth-delay product values
« Reply #4 on: March 15, 2017, 12:57:00 PM »

@ignitionnet - how do you yourself use the word 'latency' ? To mean one-way or round-trip time to some destination?
Logged

Ignitionnet

  • Reg Member
  • ***
  • Posts: 503
Re: Bandwidth-delay product values
« Reply #5 on: March 16, 2017, 10:50:08 AM »

Hi Weaver.

Unless otherwise specified round trip time.

With TCP basically always round trip time as it's connection oriented. BDPs have always in my experience been calculated with round-trip time.

Remember the BDP is how much data can be traversing a connection at one time, and is used to calculate appropriate window size. The latency calculation has to be two way as in order to free up capacity in the transmission window data has to be acknowledged so the operation kinda runs, grossly simplified:

Server: Transmission of data, increment internal transmit window downwards - data considered 'in flight', unknown if received and processed
Client: Receipt of data, decrement receive window - data received, but not processed by TCP stack / application
Client: Transmission of acknowledgement(s), increment receive window per amount acknowledged, advertise window to server - processing complete, able to accept more data into TCP stack
Server: Receipt of acknowledgement(s), increment internal transmit window as appropriate - confirmed data received, no back off necessary, able to send more

Both advertise a window at the start of the connection, then both have internal windows, with server responding to feedback from client, and client's TCP stack using both information from itself and higher up the protocol stack as it tries to drain sockets to individual applications, so if client's TCP stack isn't able to drain properly it won't increment receive window as much, if at all, to invoke congestion control.
Logged

Weaver

  • Kitizen
  • ****
  • Posts: 4004
  • Retd sw dev; A&A; 3 × 7km ADSL2; IPv6; Firebrick
Re: Bandwidth-delay product values
« Reply #6 on: March 17, 2017, 06:08:01 AM »

Understood.

It's difficult because people may not separate out delay times in the two directions. And they also may not separate the delay times that are inherent properties of a link - and which must be measured by one-way transit time when the link is lightly loaded - from the transit time in a particular situation which also includes queuing time depending on traffic conditions, and this latter is not an inherent property if the link at all, but nevertheless is crucial.

I'm wondering how easy it is to get one way times and inherent link delay times. And I'm also wondering if protocols make use of or would benefit from one-way times as opposed to having to live with two-way actual current round-trip times because that is all they can get.
Logged

Ignitionnet

  • Reg Member
  • ***
  • Posts: 503
Re: Bandwidth-delay product values
« Reply #7 on: March 17, 2017, 06:17:28 PM »

The only reliable way to get one-way times is to be in control of both sides of the link and timestamp everything.

Queuing in traffic conditions is supposed to happen. TCP congestion control.

Seriously don't worry about BDPs, especially not with your bandwidth. You're not even close to stressing an untweaked TCP stack, even across satellite-like latencies.
Logged

Weaver

  • Kitizen
  • ****
  • Posts: 4004
  • Retd sw dev; A&A; 3 × 7km ADSL2; IPv6; Firebrick
Re: Bandwidth-delay product values
« Reply #8 on: March 17, 2017, 10:51:53 PM »

I'm not 'worrying' about BDP, nor have any interest in tweaking. But I realised that I simply don't have any idea what the typical numbers are for different networking configurations.

I can see a figure of ~40 ms min 'latency' quoted by AA's CQM (ADSL2, interleave 'on', 2.8 Mbps d/s 0.54 Mbps u/s ) but I don't know if that is one-way or round trip. Round trip? They have not halved a round-trip measurement and displayed that. Also, I don't know how much but I suspect I need to take a certain substantial amount out for the WLAN if I just want the characteristics of the line.

AA's website says 12 ms if interleave off, 28 ms if on, so we assume that is round-trip?


I would be interested to know what the numbers are for very much faster DSL technologies.
« Last Edit: March 17, 2017, 10:55:16 PM by Weaver »
Logged

Weaver

  • Kitizen
  • ****
  • Posts: 4004
  • Retd sw dev; A&A; 3 × 7km ADSL2; IPv6; Firebrick
Re: Bandwidth-delay product values
« Reply #9 on: March 17, 2017, 10:56:59 PM »

One really weird thing, I've just noticed that the minimum latency of line 4 is about half that of the other two lines, looks to be about ~20 ms instead of ~40 ms, very approx. Read off the CQM graphs.

I was poking around in clueless and at the right hand end of the set of controls concerning line setting such as target SNRM, DLM stability preferences and interleave, I saw a green button entitled "Set Interleave On" it appears to me that the upstream interleave might have been turned off somehow. There is a control at the right hand side that shows the two choices Off and On for the current state of upstream interleave. Anyway I hit the button to change the whatever interleave state to "On", and saved the settings, and this change was reflected in the log, although the log doesn't say what this is talking about, upstream or downstream, but the rhs upstream interleave state is showing as "on'.

I wonder if this might be why line 4 was running ~200 kbps d/s sync rate slower than the other two lines, lack of interleave on the upstream? Would only make sense if the errors on upstream and downstream were not considered separately, in isolation.
« Last Edit: March 17, 2017, 11:22:42 PM by Weaver »
Logged

Weaver

  • Kitizen
  • ****
  • Posts: 4004
  • Retd sw dev; A&A; 3 × 7km ADSL2; IPv6; Firebrick
Re: Bandwidth-delay product values
« Reply #10 on: March 17, 2017, 11:25:44 PM »

Slightly better readings from clueless give typical minimum latencies of 37 ms for line 1 and 22 ms for line 4.

Looking at the log again, it shows that an 'order' has been placed with BT automatically to change the state of 'it' (line 4) to interleave-on, so perhaps this did mean downstream as well as upstream. I don't know how that got so screwed up in that case, a cock-up somewhere.

This is straight after I forced a resync:

Quote
BT Test xDSL Status Check:Pass Standalone sub test passed successfully.Pass OK. Circuit In Sync
BRAS=2305kb/s FTR=2278kb/s MSR=2848kb/s ServOpt=1 I/L=A
A SERVICE OPTION CHANGE ORDER IS IN PROGRESS ON THIS LINE
Up Sync=491kb/s LoopLoss=42dB SNR=5.9dB ErrSec=0 HECErr=0 Cells=0
Down Sync=2934kb/s LoopLoss=65.1dB SNR=2.9dB ErrSec=0 HECErr=N/A Cells=0   cwcc@a
Today 23:30:05   
   
Tx rate (adjusted) 2274633 to 2554051

So it seems to have got me the 200k lost speed traight back, and 2934 k downstream sync is definitely as high as I have ever seen.
« Last Edit: March 17, 2017, 11:44:37 PM by Weaver »
Logged

Chrysalis

  • Content Team
  • Kitizen
  • *
  • Posts: 4437
Re: Bandwidth-delay product values
« Reply #11 on: March 18, 2017, 01:12:48 AM »

weaver the delay on your lines contributes to the rtt, but it wont be the entirety of it.

rtt varies depending on the end point.  So e.g. bbc.co.uk will have a much lower rtt than asus.tw.
Logged
Sky Fiber Pro - Billion 8800NL bridge & PFSense BOX running PFSense 2.4 - ECI Cab

Weaver

  • Kitizen
  • ****
  • Posts: 4004
  • Retd sw dev; A&A; 3 × 7km ADSL2; IPv6; Firebrick
Re: Bandwidth-delay product values
« Reply #12 on: March 18, 2017, 02:26:27 AM »

@chrysalis - I fully understand that. :-) I did some new protocol design many years ago where I worked, featuring enormous delays, including an experimental transport over SMS. (That racked up an interesting bill during testing!  ;D  )

But I don't have any idea of what the actual numbers involved are, so I'd be interested if anyone could break things down. Latencies per hop would be nice. Round trip times otherwise. If anyone can measure to their absolute closest possible hop then that would be good.

I saw some crazy numbers from my own LAN, which I mentioned in an earlier thread some while ago. They would pollute my results, so I ought to be only doing wireful tests.
Logged
 

anything