tcp-ip@ucbvax.ARPA (06/28/85)
From: mills@dcn6.arpa Folks, A few minutes ago (about 18Z on Thursday afternoon), I collected the following delay data on the path between DCN-GATEWAY (10.0.0.111) and UCL-GATEWAY (4.0.0.60), each on opposite sides of SATNET, using ICMP Echo/Echo Reply messages. Of the 808 ICMP Echo messages sent, all but 66 had come back as ICMP Echo Reply messages within ten seconds. In my simple experiment it was not possible to determine if any of these 66 messages did in fact wander back after more than ten seconds. Of those that came back, the minimum delay was 1539 milliseconds and the mean 2175 milliseconds. For calibration purposes, the mean delay on the path between DCN-GATEWAY and the nearest SATNET gateway ranges between about 78 and 379 milliseconds with a mean of 91 milliseconds. The delays between the namesolver host, name-server host and their respective gateways are not included, nor are the delays intrinsic to the host operating systems. The total of these delays could easily contribute another few hundred milliseconds to the total. Following is a crude histogram showing the (normalized) delay distribution. Value Count ----------------+ 1200 0 | 1400 4 |**** 1600 39 |*************************************** 1800 95 |************************************************************ 2000 67 |************************************************************ 2200 18 |****************** 2400 5 |***** 2600 1 |* 2800 0 | 3000 1 |* 3200 0 | 3400 0 | 3600 2 |** 3800 0 | 4000 0 | 4200 0 | 4400 0 | 4600 0 | 4800 0 | 5000 0 | 5200 1 |* 5400 0 | The performance shown above is typically of SATNET under light loading conditions. The mean roundtrip delay somewhat less than I am used to from other measurements suggests that, at the moment, one of the non-reservation modes is in effect, possibly FTDMA. These data should be instructive to those designing namesolver retransmission strategies, not to mention those configuring TCPs to work over such paths. Dave -------