[sim-wg] TOSSIM and the 2.1 Release

[Philip Levis]

On Sep 20, 2007, at 10:24 AM, Chad Metcalf wrote:

>> 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()
>
> Right now will this implementation you don't have to use SF in either
> the C++ or Python versions. You get an instance of the SF object and
> then you use it other wise you don't. So I'm not sure I understand
> what you mean or rather what is different. (See the included full
> Python example). SF is just an object that lives with the TOSSIM,
> radio, and mac objects.
>

The difference is whether it is

   t.processSFPackets()

or

   processSFPackets()

That is, whether the SF code is *in* TOSSIM, or is just Python code  
included in the Python driver script. Don't forget, there's a TOSSIM  
command that lets you inject packets to nodes. It currently only  
works for radio packets, but adding the serial one would be trivial.  
So you could just write Python code that processes SF packets and  
calls inject() on TOSSIM. Or is that what you're doing?

>> The one downside of pushing this into the scripting world is it makes
>> transitioning between C++ and Python harder.
>
> So is the thought going forward then that TOSSIM won't be supporting
> C++ based simulation drivers?

No -- just that moving back and forth between Python and C++ might be  
a bit trickier.

Phil