Experiments on the delay shows that the actual delay by the line and router should be close to 72 uSec

Infrastructure here

madrid$ ping -U -c 12 -s requestSize 192.168.2.2

Experiments Raw data:

For a postscript version of this picture: here its gnuplot script here, the stat is here

We can use the line passing point(256,248.3) and point(1408,640.9) to approximate this line.
RTT = a * Request_Size + b

so
248.3 = a*256 + b
640.9 = a*1408 + b

Solve the above equations, we can get  a = 0.3408 , b = 161.0556

Theoretically, 

RTT/2  = delay + 2*(Packet_Size/Rate)

            (Packet_Size = Request_size + ICMP header(8) + IP header (20) + Ethernet Wrapper(26)  )

RTT = 2*delay + 4*( (Request_Size+8+20+26)/Rate )   
RTT = Request_Size * ( 4/Rate ) + ( 2*delay + 216/Rate )

Where Rate = 100Mb/sec = 12.5MB/Sec = 12.5 B/uSec

4/Rate = 4/12.5 = 0.32   which is very close to the data calculated from the experiment 0.3408

b = 2*delay + 216/Rate = 161.0566

So delay = (161.0556 - 216/12.5)/2 = 71.8878 (uSec)=72 uSec

Why the result is far from the one we got in previous experiment (145 uSec )??

Possible Reason.

1. In previous calculation, the time used to copy data  from kernel to device (or from  device to kernel)  is actually Sending/Receiving time. And the cable length is only 3 meters, cable delay is 3/(3*10**8)=0.01uSec. The Sending/Receiving time is 1526*8/(100*10**6)=122.08 uSec. So before the sending machine ends sending the packet, the receiving machines has already started receiving the same packet.  i,e. There is overhead between sending and receiving time.

2. When we say the delay time of a specific infrastructure, this delay time should be a constant.  In ideal case, the delay should be the time that a single bit travels from the source host to the destination host. It should not depend on the packet length. So the previous calculation using the time used to copy data  from kernel to device (or from  device to kernel) is not right.