Page History

...

• This is for a single TCP stream
  
  • Use of multi-stream TCP to achieve high throughput is fairly common today
• Based on TCP Reno implementation. 
  • Today's standard for Linux is based on CUBIC (see https://www.noction.com/blog/tcp-transmission-control-protocol-congestion-control)
• Fails for no packet loss
  • Assuming no loss, in a day PingER will send 480 packets from an MA to a target, or a loss rate of < 0.2%. In a 30 day month it sends 14,400 packet and no loss is a loss rate of < 0.007% and in a year 172,800 packets or loss < 0.00058%.
  • No loss in a month is commonly observed for targets with excellent network connectivity (e.g. Singapore).  
    • When calculating annual throughputs, we filter out months with no loss.
    •  
      no loss in month  is a loss rate of < 0.007%  and in a year no loss in 172,800 packets or loss < 0.00058%
  •  Bit error rates in fibre are typically between 10^-9 and 10^-12 (e.g. https://www.rp-photonics.com/bit_error_rate.htm). For packet sizes of 1460 Bytes this translates to 0.0012% and 0.00001%
  • Possible accomodations:
    • Increase the number of pings per measurement:
      • Decrease the inter ping interval from 1/second to 5/second (200msec is the minimum interval for a non super user in Linux) and send 5 times as many pings per measurement.
      • Increase the number of pings sent per measurement but do not reduce the interval. Each measurement will now take extra time (e.g. if increase number of pings by 5 then a successful measurement with no losses will take 5 times as long. One may be able to compensate for this by increasing the number of threads. Currently the number of threads is 25 and it takes the SLAC MA between 1300 and 1750 seconds to measure about 1000 targets. Increasing the number of threads could lead to troubles (e.g. see https://stackoverflow.com/questions/344203/maximum-number-of-threads-per-process-in-linux) so would need to be done carefully and monitored. 
      • One could decide which targets have good connectivity (e.g. all targets in certain regions such as North America, Europe, East Asia, Australasia, and some special cases such as Singapore)  and just increase the number of pings for them in the configuration database. This could be person power intensive or would need some extra automation to be developed.

No separate estimates of upload and download speeds

...