Round trip time questions

Wilson SHEK shek at mullian.ee.mu.OZ.AU
Mon Nov 13 10:25:27 AEST 1989


	Recently, I conducted some round trip time measurements on 
UNIX DGRAM sockets in the INET domain and was puzzled by some of the 
results.

	The measurements were done between two SUN 3/50's (4 Mb main memory)
under SunOS 4.0 over a 10Mbit ethernet. The setup of the test was as follows:
one machine (at the sending end) sent an n-byte message using a DGRAM socket 
to the other machine (at the receiving end). As soon as the message arrived
at the receiving end machine, it was sent back. The sending end machine
would not send another message until the previous one was reflected back. This
was repeated until 5000 round trips were completed. The total time required 
was recorded at the sending end machine using gettimeofday(). The following
results were observed for n from 50 to 2000 with 50 byte increments.

Message size 		Round trip time (total time/5000) 
(bytes)			(ms)
50			5.37
.			.   
.			.    RTT increases almost linearly
.			.
500			7.73 <- 
550			6.99 <- an obvious drop at 512 octets
600			7.11
.			.
.			.    RTT increases almost linearly	
.			.
1450			10.21 
1500			13.08 <- 
1550 			11.97 <- another obvious drop at 1536 octets
1600 			12.11

	My questions are:

1. What caused the drops at 512 and 1536?
2. Why didn't the RTT drop significantly at 1024 bytes? (considering
   that the mbuf mechanism supporting the UNIX sockets was optimised for
   a page size of 1024 bytes)
   When the same test was done between two SUN3/60's, significant drop
   of RTT occurred at 1024,2048 (nothing special @ 512 and 1536).

	The tests were done when the network was virtually idle, therefore
network traffic shouldn't have affected the results.

	Any help would be greatly appreciated.

	Thanks in advance.

  Wilson  SHEK                     |  ACSnet   : shek at mullian.mu.oz          
  Department of Elec Engineering   |  internet : shek at mullian.mu.oz.au     
  University of Melbourne          |  uunet    : uunet!munnari!mullian!shek



More information about the Comp.unix.questions mailing list