[Ns-developers] [ns3] socket API

[Mathieu Lacage]

On Mon, 2008-04-21 at 10:07 -0700, Sam Jansen wrote:

> > So I really have nothing against blocking sockets as long as they are not
> > widespread used.  It would be better if there was a decision, followed by
> > documentation, that writing new simulation models (e.g. new protocols) on
> > top of blocking sockets is to be discouraged.
> 
> 
> This seems like a case where we just need the documentation to make it clear
> that there is a (potentially fairly large?) performance disadvantage to
> using the blocking API.
> 
> 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.

Tom, craig, and, I discussed that on friday: I think that the main issue
is not necessarily cpu usage. It is memory usage: you need to allocate a
bunch of extra objects _and_ the stack for the user application. It is
hard to allocate a stack smaller than 4k per process so, if you factor
that across the number of nodes in your simulation, the memory usage for
process stacks goes quickly up. 

However, I think that, for most applications which use this API, this is
not going to be an issue in practice because most routing applications
are O(n2) (maybe some are O(n.log(n))) with regard to memory usage or
trigger cascading O(n2) messages. In both cases, it is the application
behavior itself which is likely to be a bottleneck way before the
application stack usage becomes one.

regards,
Mathieu