[Ns-developers] [ns3] socket API

[Sam Jansen]

On 21/04/2008, Gustavo Carneiro <gjcarneiro at gmail.com> wrote:
>
> On 21/04/2008, George Riley <riley at ece.gatech.edu> wrote:
> >
> >
> >
> >
> >
> > The larger issue here seems to be what will be the prevailing model for
> >
> > applications that we will use as examples of how to do things in ns-3?
> I'm
> >
> > not sure that many people have looked closely at Mathieu's ns-3-simu but
> > one
> >
> > possibility would be that the process code (see examples/process.cc)
> would
> >
> > be the most widely used API,
> >
> >
> >
> > See, this is what I was afraid of.  You are opening the door for any and
> > every simulation model to use simulated processes, yet the performance
> > implications of this approach have not been studied.  We have already
> seen
> > that the only portable implementation of simulated processes is through
> > POSIX threads, namely one thread per simulated process.  Now suppose you
> > have 500 nodes, each running 2 routing protocols using synchronous
> socket
> > API.  NS-3 will then create 1000 threads.  And what will the performance
> > of
> > that look like?...
> >
> > HI Gustavo,
> > I don't think Tom is suggesting that we would drop the so-called
> > asynchronous
> > API; rather he thinks the process-based one might be more popular.
> >  Whether
> > or not this is comes about does not seem significant at the moment.  I'm
> > very
> > much with you, that performance will suffer if a user models 10,000
> > peer-to-peer
> > applications, each with a separate thread and private stack.  Anyway,
> rest
> > assured the async approach is and will remain an integral part of ns-3,
> > and
> > in my opinion the method of choice for most users.
> >
>
>
> Yes, of course.  I would consider simulated processes and blocking sockets
> a
> feature that does not perform well but acceptable as means of rapid
> prototyping some model.  It would be on par with Python, in that respect.
>
> But unlike Python models, in which it is clear that the performance is
> going
> to be poor when compared to C++, with blocking sockets it is not at all
> apparent the performance penalty a user is incurring.
>
> 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.


--
> Gustavo J. A. M. Carneiro
> INESC Porto, Telecommunications and Multimedia Unit
> "The universe is always one step beyond logic." -- Frank Herbert
>