Re: Patch for nanosecond scheduling precision in ns-3-click

Hey,

those patches are meant for ns3, sorry. I posted them here, because
Lalith announce his changes here on this mailing list. I will post
them on the ns3 mailing list.

I will have a look at your changes later on.

Sascha

On 02/17/12 01:54, Eddie Kohler wrote:
> Hi Sascha,
> 
> Both of these patches are for ns, so I can't apply them. Did you
> mean to send them elsewhere?
> 
> I just checked in a change that you should look at...
> 
> Eddie
> 
> 
> On 2/11/12 3:18 PM, Sascha Alexander Jopen wrote:
>> Hey,
>> 
>> finally i've got some time to run simulations with the
>> nanosecond precision changes. Well, they run with nanosecond
>> precision.
>> 
>> However, this does only work, when running the simulator with
>> nanosecond or finer resolution. With lower resolution, the
>> timestamp at which the event is scheduled is rounded down by the
>> NS3 Time class. Because this depends on the resolution of NS3,
>> this has to be fixed in HandleScheduleFromClick to the next
>> matching timestamp. This is essentially the same as we did in
>> click routerthread.cc to fix problems with nano-/microsecond
>> precision. See the attached patch for a quick fix. This has to be
>> applied to ns-3-dev as well, removing the microsecond part of
>> it. Using other resolutions but the default resolution in ns3 has
>> some disadvantages. Some models simply do not work with other
>> resolutions, like the wifi dcf manager, which relies on us
>> slottimes, for example.
>> 
>> By the way, the last patch i submitted, which calls
>> simclick_click_kill leads to segfaults when ns3 terminates with
>> uninitialized click routers. The second patch fixes this (against
>> ns-3-dev)
>> 
>> Sascha
>> 
>> On 01/25/12 21:41, Lalith Suresh wrote:
>>> On Wed, Jan 25, 2012 at 9:40 PM, Eddie
>>> Kohler<[email protected]>  wrote:
>>>> Hi Lalith,
>>>> 
>>>> This is fair enough. But we could add a sim-command that
>>>> returned 0 if the current timestamp is a timespec. On Ns-2
>>>> this command would return -1. Then we could do what's
>>>> appropriate within click.
>>>> 
>>> 
>>> Alright. I'll have an update ready soon.
>>> 
>>>> Eddie
>>>> 
>>>> 
>>>> 
>>>> On 1/9/12 3:33 PM, Lalith Suresh wrote:
>>>>> 
>>>>> Hi Eddy,
>>>>> 
>>>>> On Mon, Jan 9, 2012 at 7:05 PM, Eddie
>>>>> Kohler<[email protected]> wrote:
>>>>>> 
>>>>>> Hi Lalith,
>>>>>> 
>>>>>> This change looks generally good, but surely ns defines
>>>>>> some version variables that we can use to detect whether
>>>>>> "cursimnode->curtime" is a timespec or a timeval. If it
>>>>>> doesn't, then please add one: #define 
>>>>>> NS_CURTIME_IS_TIMESPEC 1. Then Click can be made to work
>>>>>> cleanly with either, for instance:
>>>>>> 
>>>>>> #if NS_CURTIME_IS_TIMESPEC *ts = cursimnode->curtime; 
>>>>>> #else ts->tv_sec = cursimnode->curtime.tv_sec; 
>>>>>> ts->tv_nsec = cursimnode->curtime.tv_usec * 1000; #endif
>>>>>> 
>>>>>> The timer scheduling code in routerthread.cc would also
>>>>>> need a fork: #if CLICK_NS&&   NS_CURTIME_IS_TIMESPEC
>>>>>> /timespec-code/ #elif CLICK_NS /timeval-code/ #endif.
>>>>>> 
>>>>>> Make sense?
>>>>>> 
>>>>> 
>>>>> Nopes (or I'm way too tired). :)
>>>>> 
>>>>> I don't think a #define in ns-3 will help here. ns-3 links
>>>>> with libnsclick.so dynamically, and "cursimnode->curtime"
>>>>> comes from include/click/simclick.h (struct simclick_node).
>>>>> If we are to use the preprocessor to fork the code
>>>>> appropriately, then we'd need to know 
>>>>> NS_CURTIME_IS_TIMESPEC during Click's compile time. Right?
>>>>> 
>>>>>> Sascha, did you end up trying this? Eddie
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 12/31/11 7:46 AM, Lalith Suresh wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> Hello all,
>>>>>>> 
>>>>>>> After Sascha raised this issue on the ns-3-users list
>>>>>>> [1], I tried making a quick patch to make Click's NS
>>>>>>> code use timespec, and make the corresponding changes
>>>>>>> on the ns-3 side as well.
>>>>>>> 
>>>>>>> I've pushed the changes to my ns-3-click [2] and Click
>>>>>>> [3] repositories. Kindly review. I'll push to ns-3-dev
>>>>>>> once the Click side changes are applied. Note that this
>>>>>>> will probably break the ns-2 patches for nsclick.
>>>>>>> 
>>>>>>> 
>>>>>>> [1]
>>>>>>> 
>>>>>>> http://groups.google.com/group/ns-3-users/browse_thread/thread/2be8d60531bd82a8
>>>>>>>
>>>>>>>
>>>>>>> 
[2] http://code.nsnam.org/lalith/ns-3-click-dev
>>>>>>> [3] https://github.com/lalithsuresh/click
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> _______________________________________________ click mailing
>> list [email protected] 
>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click