Skip to first unread message

IA Ob.

unread,
Aug 24, 2014, 4:58:52 PM8/24/14
to ns-3-...@googlegroups.com
Hi all,
im working in application layer between two nodes WiFi (infrastructure) UDP/ QoS support
i need to send portion of packets all at the same time to the mac queue from the application
and then let mac handle sending of those packets as soon as the channel is gained (since all will be available in the queue)

using the following statement did not work without using Simulator::Schedule to schedule the next sending packet time :

while (true)
{
socket->Send (packet);
..
if (condition )
break;
...
..}

consider the mac queue size can take all those packets.
is it possible to that ?? and how????

Best Regards.

Tommaso Pecorella

unread,
Aug 24, 2014, 6:22:42 PM8/24/14
to ns-3-...@googlegroups.com
Hi,

nothing is really urgent, trust me. The sun will keep moving no matter how much urgent the thing is, so... relax and think. The need to find a solution is often the father of very bad choices.

Now, about your question. You didn't say what is the problem and why what you was trying "did not work".
My best guess is that it did work. It just didn't work as you was expecting.

The statement will work, it will load the MAC queue with packets. The problem may be that it will do it once, and it will not do it again.
Also, my best guess is that your "condition" is something related to the queue / channel status, and that you wanted to resume the MAC buffer filling when this condition reverts to false.
Let's say... you want to fill the queue up to the 80% of its size, and resume the generation once it is at 40% fill.

Let's also skip the part where I severely question the usefulness of such an idea. it's your idea and I'll not demolish it... for now.

Finally, let's avoid to point out that telling a bit more about the problem would have saved a lot of hypothesis. You may think that not telling everything may protect the idea, but it isn't for real.

Anyway, enough talking. How to do it. You need a backpressure system. Unfortunately NetDevices doesn't have such a thing.
Solution A: you schedule a periodic event (quite frequent) to check if the condition is changed. In case, resume the data generation.
Solution B: you hook a TraceSource (e.g., a Tx trace) and you check the condition when a packet has been dequeued and transmitted.
Solution C: you modify the wifi module and you add the backpressure you need.

Of course, this is true if all the hypothesis I did are true. But I'm quite confident that they are.

Cheers,

T.

PS: unless you're using a variable bit rate video codec (and also in that case it's not true), the source can not stop generating data according to a MAC level condition. No matter how hard you push, nine women can to deliver a baby in one month.
What can happen is that the Application level can use a buffer to smooth (or tune) the data forwarded to the MAC. However, the buffer is just moved from one place (the MAC) to another one (the App).
I.e., you need a far more complex application model.
Message has been deleted

IA Ob.

unread,
Aug 24, 2014, 7:50:50 PM8/24/14
to ns-3-...@googlegroups.com
Hi T, 

first of all thanks for your help,
and to be honest when you're working in a project for several months and you left with less than a month to finish the whole work and you're lets say half way --i would call that urgent.

and about the saving Ideas Thing -- if i really want top do that i would've search in the group for whose been working on such related ideas or anyone who always help try to help in this group and send then in a private email and hope to get some answers, again i am following the "Don't Let Me read an article - just tell me the problem" thing, and in my opinion this is the right way to do it.

anyway most of your speculation were correct 
OK the idea is that i am trying to send a video, a video that is consisted of several frames (Depending on the encoding you're using ) and send each frame packets to the buffer; lets say the image will take 5.000 packet and i have a buffer that is enough for twice of this amount ) - so buffer wont be the problem

all previous info were setup and i try this in my application

while (true )
{
if (packet count > packets_#of_frame)
{
select_next_frame(); // this function will bring you back here after choosing frame
break;
}
socket->send (packet);
packet count++;
....
..
...
}

what this resulted as i extract the output to a file 
that all the packets were sent and by tracking time i get:
At second 4 packet 1 was sent
At second 4 packet 2 was sent
.
.
..
and so for all the other packets
see time is not changing at all in the sender

and this way the sink received only 4 packets of total all
by the way the timer when to call the send function again is calculated accurately enough to send the whole packets before starting the sending (or filling the buffer) again furthermore i try on one frame and did not work.

the only way to this is to use Simulator::Schedule (second (pksize *8)/app.rate) ------->>>> as most application do such as on-off application // echo client server .... 
and that not what i need.

so any ideas ?
and thanks again :)

Tommaso Pecorella

unread,
Aug 25, 2014, 2:39:43 AM8/25/14
to ns-3-...@googlegroups.com
Hi,

I guess there's a need for a clarification about events, time and so on. Feel free to skip ahead if I am pedantic.

ns-3 is an Event-Driven simulator. Each "Event" has a time associated with it: its execution time (let's think about it like "when the Event happened (or will happen)".
In order to work, events are generated and scheduled to be processed at a given time in the "future" (as we can't change the past).
The time in an Event-Driven simulator is set to be the one of the event currently being processed, and the simulation stops when there are no more events to process.

This is all nice and fancy, but what is an Event ? It's nothing more than a deferred [member] function execution.

Now, if you want to have the time going ahead, you *need* to call Simulator::Schedule and to end the current event processing. Either the time will not advance.

Translated: you can not have a while(true) without a stop condition [i.e., no while(true) at all].
The while(true) is a remnant of a real OS programming, but there you have blocking sockets and multiprocessing. Quite different stuff.

So, your while should look like:

void ThrowPacketsInTheNetDevice (void)
{
 
while (packet count <= packets_num_of_frame)
 
{

    socket
->send (packet);
    packet count
++;
   
....
 
}

  delta
= select_next_frame_delay();  // this function will choose the next frame and will calculate the time difference between Now() and when the selected frame will happen.
 
Simulator::Schedule (delta, &ThrowPacketsInTheNetDevice, this); // this will bring you back to the wihile loop after a proper time.
}


By the way, it's drycoding, so typos and such are guaranteed.

Cheers,

T.

PS: good luck with the project.

IA Ob.

unread,
Aug 25, 2014, 11:01:46 AM8/25/14
to ns-3-...@googlegroups.com
Thanks T, Appreciate it.
Reply all
Reply to author
Forward
0 new messages