[sim-wg] TOSSIM and the 2.1 Release

[Philip Levis]

On Sep 20, 2007, at 9:56 AM, Chad Metcalf wrote:

> Phil, do you have a more firm target for the 2.1 release? End of 2007?
> So several months maybe 4, 5, or 6?
>
>> Life is going to be very busy for me for the next few weeks (NSDI is
>> approaching), but I might be able to take a look today. Having a
>> serial forwarder would require either multithreading in Python or
>> polling the SF, right? Or did you write it as C/C++?
>
> It's written in C and is in large part just the C SF embedded in
> TOSSIM. To avoid multithreading and make it available in C and Python
> the user is required to call the processing loop.
>
>    38  while(t->time() < 600 * t->ticksPerSecond()) {
>    39    throttle.checkThrottle();
>    40    sf.process();
>    41    t->runNextEvent();
>    42  }
>
>    46 for i in range(0, 20):
>    47   throttle.checkThrottle()
>    48   sf.process()
>    49   t.runNextEvent()
>
> This was the simplest way I thought to handle it. The SF forwards all
> serial traffic out, setting the source. All serial traffic in is
> delivered to the specified destination (broadcast not implemented).
> Ignore the calls to the throttle, thats the other half of the TOSSIM
> Live extensions.
>

Right -- I did a performance analysis way back when for T1 and found  
that optimistic concurrency control (read: mutexes) was more  
efficient than polling. The original idea behind TOSSIM in T2 was to  
bring it up to Python as quickly as possible, so that things like  
serial forwarders could be incorporated as scripts, which then users  
could choose to include/not include. E.g., there's no reason that  
your Python driver can't do something like

for i in range(0, 100000):
   t.runNextEvent()
   processSFPackets()


The one downside of pushing this into the scripting world is it makes  
transitioning between C++ and Python harder.

>> It would be great to incorporate this into the main tree. My one
>> major concern is radio simulation: if there's power information,
>> people will latch onto it as an evaluation mechanism, which means
>> that the radio simulation needs to be reasonable (or at least
>> pessimistic).
>
> I agree. Venkatesh can you pitch in some information as to how your
> packet level simulation is going and where you think it will be in the
> next couple of months?
>
>> Tal and I have been working on this. At the very least, I am going to
>> incorporate a log-shadowing model to add some short-term temporal
>> variation to RSSI. Tal's been looking at how to model longer-term
>> swings.
>
> Great, so this is targeted to the 2.1 release?

Yes. Tal has been finding that the current RSSI simulation has a  
bunch of issues due to quantization and the sharp SNR/PRR curve.

Phil