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

Login with username, password and session length
Advanced search  

News:

Pages: 1 [2]

Author Topic: All-time highest upstream measured speed of 1.86 Mbps TCP throughput: AA tester  (Read 2423 times)

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project

@Burakkucat - Isn’t your downstream sync rate really high just now ? Or am I just forgetting. Looks pretty good anyway.

I currently see a synchronisation speed of 5735 kbps DS & 1019 kbps US and a throughput speed of 4.56 Mbps DS & 0.98 Mbps US.
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick

A long time question : since line #3 upstream is so low compared to the others, will TCP get confused by the varying delay times of packets depending on whether they went up through the fast line #1 or the slow line #3 ?
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project

That is a query for someone who understands the mechanism of line bonding. It's something I can not answer and I would not like to guess.

Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick

I see, a clever transmitter might tweak the times of transmission of the packets in order to be kind to TCP ? Or not. I’m assuming that in the latter case the values of the difference (tcp_tx time - arrival_time) might go up and down as the different lines are used and a TCP implementation observing transit durations in order to control TCP’s behaviour might get confused because one moment it’s seeing a 300kbps link and the next a 500kbps link. And that could muck up TCP’s delay/RTT-related algorithms, Does that seem a reasonable guess?
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project

I'm struggling to formulate a picture (either murky or clear) . . .
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick

Me too. Perhaps someone who is good at deciphering detailed TCP behaviour from a pcap snapshot of traffic taken during an upload could comment? I’ve forgotten - I used to have a good technique for starting a long upload, tried this which got appallingly low results: https://testmy.net - Be aware, must select a UK server as it defaults to US-based ones, stupidly.
« Last Edit: July 02, 2020, 04:44:51 PM by Weaver »
Logged
Pages: 1 [2]
 

anything