🚀 go-pugleaf

In article <7201@transfer.stratus.com>, cme@ellisun.sw.stratus.com (Carl Ellison) writes:
|> The bad point is that while the callee is doing its thing *and* while that
|> call is being transmitted *and* while the reply is coming back, the caller
|> is twiddling its thumbs -- either literally spinning or doing a task
|> switch.  As processors get faster, the time for the callee to do its thing
|> goes down -- but the communication time doesn't (since the speed of light
|> doesn't change).  So the number of instructions wasted in the caller goes
|> up, if the caller spins.  This forces the caller to task-switch or waste
|> time.

Let me disagree. Don't forget that the speed of light is not the only source of
network communications bottleneck. In my understanding, a very little portion
of latency is due to the light speed limit. On a local network with a physical
range of say 10 miles, the light would make a roundtrip in about 0.1 msec 
(10 * 2 / 186000 ) wich is quite acceptable. 

The real delays which are in the range of 5-100 msec come
in my understanding from routers, gateways, packet switcher, network overload, ...

If I remember correctly, the theoretical speed limit of a network packet 
is something around 0.8 * c (eighty percent speed of light).

So, as processors become faster, so do the routers and gateways. We are also going
to have networks with much higher capasity which will increase the size of
packets and reduce the number of packets required.

It is my understanding that in the nearest future (10-15 years) the processors 
(and not the networks) will be the bottleneck in the RPC or any client-server
scenario.

-- 
Alex Berlin                     
berlin@is.morgan.com