[Ns-developers] [ns3] socket API

[George Riley]

>
> By the way, I did some performance tests of using threads vs.  
> ucontext. Worst case seems to be about a 20x slowdown when using the  
> threaded implementation; though this varies depending on access  
> pattern. I only compared these approaches in isolation, so I'm not  
> sure how this factors into ns-3 as a whole. It may be that the cost  
> of using the ucontext approach is quite small; but we can't  
> guarantee that is always available, so it seems reasonable to  
> conclude that the approach as a whole is costly.
Yes, the so-called "user-level threads" using getcontext/setcontext  
will usually outperform kernel-level threads, such
as pthreads.  The normal drawback to user level threads is that if a  
single thread blocks, the kernel is not aware
of the other threads and they also block.  This is not the case for  
ns-3, since in our case when a thread "blocks",
it just means that the application waits for a callback from the  
socket, and is not blocked from the perspective
of the kernel.

Both types of threads also of course each need a private stack, and  
the required size of this stack is not always
obvious.  A user will have to balance the need for stack space against  
total available
memory and choose a good value that is "big enough", but not "too big".

George