busy-wait during simulation

[Dorice Diane Ngueguia]

Hi,

I have a server application that receives packets, process them before sending replies packets to clients. In the real application, the packet processing function is written in java, and very complex, using cryptography. I would like to simulate packet processing during my simulation in a simple manner, without adding all the details. So, I have evaluated the mean processing time in the real application. Let's assume that, that processing time is X nanoseconds. How can I perform a kind of busy-wait(X) in my simulation, so as to respect the real application execution time ?

I read the Real-time scheduler section of the ns3 manual, but it is not very clear to a beginner like me.

Please could some one help ?

tank you

[Antti Mäkelä]

On Jan 12, 1:09 pm, Dorice Diane Ngueguia <doricedi...@gmail.com>
wrote:

> simulation in a simple manner, without adding all the details. So, I have
> evaluated the mean processing time in the real application. Let's assume
> that, that processing time is X nanoseconds. How can I perform a kind of
> busy-wait(X) in my simulation, so as to respect the real application
> execution time ?

Create an event and have it fire when the processingperiod is over,
like so:

EventId ProcessingCompleteEvent;
ProcessingCompleteEvent = Simulator::Schedule(Seconds(processtime),
&Myapplication::SendResponse, this);

(Assuming that your application is running as an instantiated object).
You naturally need a Myapplication::SendResponse() method somewhere.

[Dorice Diane Ngueguia]

Tank you for your interest,

I have already tried that method. The problem is that, when I schedule the event to fire in processtime seconds, the server is able to continue, performing other operations (for example dealing with other requests), what is precisely what I don't want, because I am testing the ability of my application to support a great number of request. I want the "processor" of my server node to be busy, so that it can perform any other operation only at the end of the specified delay (processtime).

My english is not good. I hope it is clearer.

So, ?

--
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To post to this group, send email to ns-3-...@googlegroups.com.
To unsubscribe from this group, send email to ns-3-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ns-3-users?hl=en.

[Antti Mäkelä]

On Jan 12, 3:51 pm, Dorice Diane Ngueguia <doricedi...@gmail.com>
wrote:

> Tank you for your interest,
>
> I have already tried that method. The problem is that, when I schedule the
> event to fire in processtime seconds, the server is able to continue,
> performing other operations (for example dealing with other requests), what
> is precisely what I don't want, because I am testing the ability of my

Can't you simply set a

bool serverbusy = true;

when starting processing,

setting it back to false after process is done, and if additional
requests come in just do a if (serverbusy) return; // Exit without
doing anything

[cra...@ee.washington.edu]

If you just want to consume real cycles on a real machine, you can do so in a for-loop.

 

  Ptr<RealtimeSimulatorImpl> impl = DynamicCast<RealtimeSimulatorImpl> (Simulator::GetImplementation ());

  for (;;)

    {

      if (impl->RealtimeNow () > tEnd)

        {

          Break;

        }

    }

 

This is easy.  The effect of doing something like that is a little harder to understand, and it’s hard to know exactly unless you get more specific about how your code is put together.  It probably won’t do what you want at all.

 

If you are using the realtime simulator only (no emulated or tap devices), then the for-loop has the effect of making the system appear slow for a short time.  If the simulator is running in the default mode, it will notice that the simulation is beginning to lag realtime and will attempt to speed things up by delaying less between events.  The simulation will proceed to catch up if it is not fully consuming the CPU and your for-loop will have little effect in the big picture..

 

If you have the realtime simulator running in hard real time mode and you delay for long enough, you may simply hit the hard limit and the realtime simulator will stop with a fatal error.

 

If you are using the realtime simulator with emulation or tap devices running, then there are multiple threads running in the system.  While your server is looping the main simulator thread can still be swapped out by the OS and other threads can run.  In this case, even though you think you are consuming “system” cycles, an emulated net device can receive packets.  This is like a machine getting network interrupts and queuing packets even though the CPU is completely loaded.  These packets will be scheduled by the devices to run at the current real time.  Eventually, the server thread will stop spinning and the simulation will resume.  The packets received during the server “busy wait” will execute as soon as possible following the server, but their execution time will be their reception and schedule time, which is a real time during the server wait.  The simulator will notice it is behind and start speeding up and eventually compensate for your server busy wait.

 

If you think about it, the scenario you are presenting is no different than, as often happens, the ns-3 process being swapped out while your system does something else.  The realtime simulator was designed to compensate for this.  So when you see difficulties trying to notice a busy-wait loop in your server, it is evidence of the realtime simulator working as designed. 

 

Another complication is that if you have scheduled events for some time in the future, their execution times will not be magically changed if you do a “busy-wait” in your server code.  They will still run on time (assuming the scheduler can catch up).

 

As you may infer, ns-3 does not model the execution time of events – events are assumed to run instantaneously.  When you start wanting to have the server event consume real time, you start fighting against the basic design of ns-3.  You can use the realtime clock to find out how long your code is taking to execute and if you are careful, you can watch real time progress in your events and do realtime scheduling.  This means it is possible to defeat all of the hoops the simulator jumps through to produce a best-effort version of realtime, but it is going to mean some work for you.  You will also find that some models in the system make assumptions about time not progressing in events so if you start playing these games, be prepared for grief.

 

If you are using emulated and tap devices, you can to write code to set some flag when the server event is actually running in real time and queue inbound packets in emulated devices while this is happening.  When your server is done it can schedule an event which schedules the packet handler.  Of course, you are talking about realtime multithreaded programming here, it won’t be easy and you’ll end up hacking on the device code.  Another way is to go into the devices and add some offset to the real time (i.e., schedule packet reception for some time in the future, not the current real time).

 

There are some simple things you can do, especially using the real time clock to profile your server code.  If you want to do anything much more complicated than that, you may be in for a difficult time.

 

-- Craig

[Michael]

Maybe you could just shut down the server interface while the
processing is going on (schedule a SetDown()) and then turn the
interface back on when the processing is complete (schedule a SetUp
())? Or did you want to store received packets in a buffer?

Michael

> <mailto:ns-3-users%2Bunsu...@googlegroups.com> .

[Dorice Diane Ngueguia]

My goal is not just to consume real cycles on the real machine. As you said, I would in deed like my server to operate "like a machine getting network interrupts and queuing packets even though the CPU is completely loaded".  I have decided to use a buffer to store the received packet. So my packet processing function takes the packets from the buffer. I also have a boolean flag 'idle' that is set to true when the packet processing function find no packet in the buffer. This help me to recall the processing function when the next packet will be received.

My simulator is not running in realtime mode. I observed that my server can not receive a packet and buffer it while processing another. When it start processing packet, it do so until the buffer is empty, and then it receive a burst of packets and then restart processing. You talked about realtime mode, using emulated and tap devices. I am not using  it because my simulation does not have to send/receive packet to/from external destinations/sources. Is the no other mean to have the behavior I want ?

[Sakshi]

Dorice Diane Ngueguia,

I want to implement the similar stuff. Is there any solution that you have come up with? Please post it. It would be great help for me.

Thanks,

Rgds,
Sakshi

[Tommaso Pecorella]

This thread is from 2010. THREE years ago.

You already asked a similar question in other threads. Please avoid this, as it will not lead to anything useful.

Thanks.

T.

[sakshi chourasia]

Ok.

--
You received this message because you are subscribed to a topic in the Google Groups "ns-3-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ns-3-users/ixUXoeAkLp0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ns-3-users+...@googlegroups.com.

To post to this group, send email to ns-3-...@googlegroups.com.

Visit this group at http://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.