Emulation and Realtime Scheduler - Revision history

Vedranm: Remove manual links and replace them with wiki links

2013-02-10T16:36:38Z

Remove manual links and replace them with wiki links

← Older revision		Revision as of 16:36, 10 February 2013
Line 31:		Line 31:
	[[Image:Sigcomm08-demo-figure.png]]		[[Image:Sigcomm08-demo-figure.png]]

	There is a HOWTO describing how to set up the virtual machines [~~http://www.nsnam.org/wiki/index.php/HOWTO_use_VMware_to_set_up_virtual_networks_%28Windows%29~~ here]. You can find the sigcomm demo repository [http://code.nsnam.org/ns-3-sigcomm/ here].		There is a HOWTO describing how to set up the virtual machines [[HOWTO use VMware to set up virtual networks (Windows)\|here]]. You can find the sigcomm demo repository [http://code.nsnam.org/ns-3-sigcomm/ here].

	There are two use cases we've defined so far: using ns-3 nodes and stacks but substituting real net devices and real networks in a simulation; and the converse which is using an ns-3 simulated network between real nodes and stacks.		There are two use cases we've defined so far: using ns-3 nodes and stacks but substituting real net devices and real networks in a simulation; and the converse which is using an ns-3 simulated network between real nodes and stacks.

Hippo at 18:15, 2 May 2010

2010-05-02T18:15:32Z

← Older revision		Revision as of 18:15, 2 May 2010
Line 1:		Line 1:
	==Emulation and Realtime Scheduler==		==Emulation and Realtime Scheduler==
	There are two large pieces to the emulation and realtime scheduler project. Not too ~~suprisingly~~ they are the emulation part and the realtime scheduler part.		There are two large pieces to the emulation and realtime scheduler project. Not too surprisingly they are the emulation part and the realtime scheduler part.

	===Realtime Scheduler===		===Realtime Scheduler===
Line 10:		Line 10:
	Using the realtime scheduler you can create an N second simulation that will consume N seconds of real time. This is not a terrifically useful feature by itself. To make it useful you need to connect the simulation to the real world that is proceeding according to that realtime clock. In the case of network emulation, this means connecting ns-3 to a at least one real device.		Using the realtime scheduler you can create an N second simulation that will consume N seconds of real time. This is not a terrifically useful feature by itself. To make it useful you need to connect the simulation to the real world that is proceeding according to that realtime clock. In the case of network emulation, this means connecting ns-3 to a at least one real device.

	We are providing ns-3 net devices that will look like a usual ns-3 simulated device from the top, but will connect to a real physical network underneath using a packet (raw) socket. By itself this presents little challenge, but one are of concern is the requirement that a process be running as suid root in order to read and write the required sockets. The brute force and awkwardness solution is to simply run the simulation as root. Another option is to use chown and chmod the executable to suid root. This doesn't require the root login, but you still have a rather large application running as root. If one is concerned primarily with limiting the amount of code running as root, but not security, we could provide a net-device smaller process that can read and write raw sockets that runs as root, to which the larger simulation connects. ~~THis~~ has the drawback of opening a giant security hole. If you have any opinions or strong requirements in this respect, please let me know.		We are providing ns-3 net devices that will look like a usual ns-3 simulated device from the top, but will connect to a real physical network underneath using a packet (raw) socket. By itself this presents little challenge, but one are of concern is the requirement that a process be running as suid root in order to read and write the required sockets. The brute force and awkwardness solution is to simply run the simulation as root. Another option is to use chown and chmod the executable to suid root. This doesn't require the root login, but you still have a rather large application running as root. If one is concerned primarily with limiting the amount of code running as root, but not security, we could provide a net-device smaller process that can read and write raw sockets that runs as root, to which the larger simulation connects. This has the drawback of opening a giant security hole. If you have any opinions or strong requirements in this respect, please let me know.

	===Emulation plus Realtime Scheduler===		===Emulation plus Realtime Scheduler===
	If you consider how an ns-3 simulation might drive a physical net device, it is straightforward. When you want the physical net device to drive the simulation, you need to be able to allow the net device to schedule events in the simulator. Since the basic model for ~~sockeets~~ is synchronous, we will need to have a thread reading data from a physical net device in real time. We also want to have at least one thread executing the simulation. It seems clear that we are going to have a multithreaded solution. This means we needed to serialize the ~~sheduler~~.		If you consider how an ns-3 simulation might drive a physical net device, it is straightforward. When you want the physical net device to drive the simulation, you need to be able to allow the net device to schedule events in the simulator. Since the basic model for sockets is synchronous, we will need to have a thread reading data from a physical net device in real time. We also want to have at least one thread executing the simulation. It seems clear that we are going to have a multithreaded solution. This means we needed to serialize the scheduler.

	Also. since there is going to be a need for the net device thread to affect the main scheduler thread we are going to have some form of inter-thread communication. Typically, the scheduler will be sleeping waiting to synchronize with real time. IF a net device receives a packet, we need to be able to schedule a new packet reception event and to wake the scheduler and force it to re-evaluate what it needs to do. This will most likely mean the scheduler will have to execute the newly scheduled event (and derived events) and then go back to sleep waiting for the next event time.		Also. since there is going to be a need for the net device thread to affect the main scheduler thread we are going to have some form of inter-thread communication. Typically, the scheduler will be sleeping waiting to synchronize with real time. IF a net device receives a packet, we need to be able to schedule a new packet reception event and to wake the scheduler and force it to re-evaluate what it needs to do. This will most likely mean the scheduler will have to execute the newly scheduled event (and derived events) and then go back to sleep waiting for the next event time.

	A useful OS construct for doing exactly this kind of wait is a timed ~~contitional~~ wait. ''Posix Threads'' (pthreads) implements this functionality as ''pthread_cond_timedwait''. We use the ''condition'' as a request for interruption by a realtime device. If a pthread_cond_timedwait is requested, a sleep-wait is performed for a specified time. If the condition does not become true during that time (a timeout) then the function call will return and we will have accomplished our needed sleep-wait. If an external (to the simulation proper) device sets the condition, then the sleep-wait will return early. The scheduler then wakes up and re-evaluates its next action.		A useful OS construct for doing exactly this kind of wait is a timed conditional wait. ''Posix Threads'' (pthreads) implements this functionality as ''pthread_cond_timedwait''. We use the ''condition'' as a request for interruption by a realtime device. If a pthread_cond_timedwait is requested, a sleep-wait is performed for a specified time. If the condition does not become true during that time (a timeout) then the function call will return and we will have accomplished our needed sleep-wait. If an external (to the simulation proper) device sets the condition, then the sleep-wait will return early. The scheduler then wakes up and re-evaluates its next action.

	Since multiple threads are wandering around in the scheduler, we need to be careful about protecting shared data structures of course.		Since multiple threads are wandering around in the scheduler, we need to be careful about protecting shared data structures of course.

Craigdo at 23:53, 27 March 2009

2009-03-27T23:53:40Z

← Older revision		Revision as of 23:53, 27 March 2009
Line 36:		Line 36:

	----		----
	23:53, 27 March 2009 (UTC)		[[User:Craigdo\|Craigdo]] 23:53, 27 March 2009 (UTC)

Craigdo: /* Current Status */

2009-03-27T23:53:11Z

Current Status

← Older revision		Revision as of 23:53, 27 March 2009
Line 27:		Line 27:

	===Current Status===		===Current Status===
	~~This has been a high priority background task for me. Its continues to be swapped in and out as other things heat up and cool off~~.		The basic project is complete. The realtime simulator was part of the ns-3.2 release. The EmuNetDevice was part of the ns-3.3 release. The TapBridge was part of the ns-3.4 release. We did a demo of the EmuNetDevice at Sigcomm in 2008 with this topology:

	The realtime simulator ~~has been merged and~~ was part of the ns-3.2 release. The ~~emulated net device~~ was ~~demostrated at sigcomm 2008 and is being prepared for a merge into~~ ns-3~~-dev~~. ~~This used an environment in which there~~ was an ns-3 ~~simulation split onto two virtual machines sending packets across~~ a ~~VMWare LAN link using emulated net devices~~:

	[[Image:Sigcomm08-demo-figure.png]]		[[Image:Sigcomm08-demo-figure.png]]
Line 35:		Line 33:
	There is a HOWTO describing how to set up the virtual machines [http://www.nsnam.org/wiki/index.php/HOWTO_use_VMware_to_set_up_virtual_networks_%28Windows%29 here]. You can find the sigcomm demo repository [http://code.nsnam.org/ns-3-sigcomm/ here].		There is a HOWTO describing how to set up the virtual machines [http://www.nsnam.org/wiki/index.php/HOWTO_use_VMware_to_set_up_virtual_networks_%28Windows%29 here]. You can find the sigcomm demo repository [http://code.nsnam.org/ns-3-sigcomm/ here].

	~~Mathieu Lacage independently developed a TAP-based emulated net device for a demo he is doing back at the INRIA. I am going to merge this work together and push it in for an ns-3.3 release.~~		There are two use cases we've defined so far: using ns-3 nodes and stacks but substituting real net devices and real networks in a simulation; and the converse which is using an ns-3 simulated network between real nodes and stacks.

	There are two use cases we've defined so far: using ns-3 nodes and stacks but substituting real net devices and real networks in a simulation; and the converse which is using an ns-3 simulated network between real nodes and stacks. ~~The former case is working now and has been demoed as mentioned above. Using ns-3 to simulate a network is the next phase.~~

	~~You can find my development repo [http://code.nsnam.org/craigdo/ns-3-emu/ here].~~

	~~[[User~~:~~Craigdo\|Craigdo]] 18:44~~, ~~3 October 2008~~ (~~EDT~~)		----
			23:53, 27 March 2009 (UTC)

Craigdo at 22:44, 3 October 2008

2008-10-03T22:44:35Z

← Older revision		Revision as of 22:44, 3 October 2008
Line 31:		Line 31:
	The realtime simulator has been merged and was part of the ns-3.2 release. The emulated net device was demostrated at sigcomm 2008 and is being prepared for a merge into ns-3-dev. This used an environment in which there was an ns-3 simulation split onto two virtual machines sending packets across a VMWare LAN link using emulated net devices:		The realtime simulator has been merged and was part of the ns-3.2 release. The emulated net device was demostrated at sigcomm 2008 and is being prepared for a merge into ns-3-dev. This used an environment in which there was an ns-3 simulation split onto two virtual machines sending packets across a VMWare LAN link using emulated net devices:

	[[Image:Sigcomm08-demo-figure.~~jpg~~]]		[[Image:Sigcomm08-demo-figure.png]]

	There is a HOWTO describing how to set up the virtual machines [http://www.nsnam.org/wiki/index.php/HOWTO_use_VMware_to_set_up_virtual_networks_%28Windows%29 here]. You can find the sigcomm demo repository [http://code.nsnam.org/ns-3-sigcomm/ here].		There is a HOWTO describing how to set up the virtual machines [http://www.nsnam.org/wiki/index.php/HOWTO_use_VMware_to_set_up_virtual_networks_%28Windows%29 here]. You can find the sigcomm demo repository [http://code.nsnam.org/ns-3-sigcomm/ here].
Line 40:		Line 40:

	You can find my development repo [http://code.nsnam.org/craigdo/ns-3-emu/ here].		You can find my development repo [http://code.nsnam.org/craigdo/ns-3-emu/ here].

			[[User:Craigdo\|Craigdo]] 18:44, 3 October 2008 (EDT)

Craigdo: /* Current Status */

2008-10-03T22:42:18Z

Current Status

← Older revision		Revision as of 22:42, 3 October 2008
Line 29:		Line 29:
	This has been a high priority background task for me. Its continues to be swapped in and out as other things heat up and cool off.		This has been a high priority background task for me. Its continues to be swapped in and out as other things heat up and cool off.

	~~We have prepared for the appearance~~ of the ~~emulation work in~~ ns-3~~-dev~~. The ~~required kernel primitives have been added,~~ and ~~the simulator has been broken up~~ into ~~interface and implementation pieces~~.		The realtime simulator has been merged and was part of the ns-3.2 release. The emulated net device was demostrated at sigcomm 2008 and is being prepared for a merge into ns-3-dev. This used an environment in which there was an ns-3 simulation split onto two virtual machines sending packets across a VMWare LAN link using emulated net devices:

	I have a working simulator implementation that is a realtime scheduler which synchronizes the simulation time with wall clock time. The changes are such that it has been made multithread safe (so schedule requests can come in from threads managing "real" emulated net devices) and the simulator has a wall-~~clock "synchronizer" that is used to provide a real timebase and synchronization capability~~.		[[Image:Sigcomm08-demo-figure.jpg]]

	~~I wrote an "abuse the simulator" program that schedules many functions then spins~~ up ~~a worker thread simulating a net-device and runs~~ the ~~simulation~~. ~~The thread tosses in many schedule-now events while~~ the ~~simulation is running~~. ~~The program loops forever looking for problems caused by the multithreading~~. ~~This has successfully run for days at a time~~.		There is a HOWTO describing how to set up the virtual machines [http://www.nsnam.org/wiki/index.php/HOWTO_use_VMware_to_set_up_virtual_networks_%28Windows%29 here]. You can find the sigcomm demo repository [http://code.nsnam.org/ns-3-sigcomm/ here].

	~~I have~~ a ~~pretty~~-~~much working~~ emulated net device ~~running~~. ~~It works pretty much as you may imagine, by implementing the pure virtual methods~~ in ~~net~~-~~device.h but hooking into the sockets API transmit and recieve real packets~~. ~~There is a functional emulation helper that helps you create simulations~~.		Mathieu Lacage independently developed a TAP-based emulated net device for a demo he is doing back at the INRIA. I am going to merge this work together and push it in for an ns-3.3 release.

	~~You can find a couple of examples that~~ use ~~this functionality.~~ ~~THe first is just a udp~~-~~echo example that consumes~~ real ~~time instead of simulating as quickly as possible. In order to enable this behavior, you just have to set~~ the ~~realtime simulator implementation~~ which is ~~the code at the start of the main function in the realtime~~-~~udp-echo~~.~~cc example~~. ~~There is also an example called emu~~-~~sniff.cc that uses the helper~~ to ~~create~~ a ~~node with an emulated net device, and run for ten seconds dumping all of~~ the ~~packets received in hex~~.		There are two use cases we've defined so far: using ns-3 nodes and stacks but substituting real net devices and real networks in a simulation; and the converse which is using an ns-3 simulated network between real nodes and stacks. The former case is working now and has been demoed as mentioned above. Using ns-3 to simulate a network is the next phase.

	~~There are two use cases we've defined so far~~: using ns-3 nodes and stacks but substituting real net devices and real networks in a simulation; and the converse which is using an ns-3 simulated network between real nodes and stacks. I will be working to get something real working with respect to the first scenario working next. ~~Tom Henderson has said he might do some prototyping to enable the second~~.		You can find my development repo [http://code.nsnam.org/craigdo/ns-3-emu/ here].

	~~Feel free to take a look at the~~ ns-3-emu ~~repository and let me know what you think~~.

Craigdo at 01:49, 29 July 2008

2008-07-29T01:49:23Z

← Older revision		Revision as of 01:49, 29 July 2008
Line 10:		Line 10:
	Using the realtime scheduler you can create an N second simulation that will consume N seconds of real time. This is not a terrifically useful feature by itself. To make it useful you need to connect the simulation to the real world that is proceeding according to that realtime clock. In the case of network emulation, this means connecting ns-3 to a at least one real device.		Using the realtime scheduler you can create an N second simulation that will consume N seconds of real time. This is not a terrifically useful feature by itself. To make it useful you need to connect the simulation to the real world that is proceeding according to that realtime clock. In the case of network emulation, this means connecting ns-3 to a at least one real device.

	We are ~~planning on using pcap and packet sockets to create an~~ ns-3 ~~''NetDevice''~~ that will look like a usual ns-3 simulated device from the top, but will connect to a real physical network underneath. By itself this presents little challenge, but the ~~interaction~~ with the ~~simulator scheduler is~~ a ~~bit tricky~~.		We are providing ns-3 net devices that will look like a usual ns-3 simulated device from the top, but will connect to a real physical network underneath using a packet (raw) socket. By itself this presents little challenge, but one are of concern is the requirement that a process be running as suid root in order to read and write the required sockets. The brute force and awkwardness solution is to simply run the simulation as root. Another option is to use chown and chmod the executable to suid root. This doesn't require the root login, but you still have a rather large application running as root. If one is concerned primarily with limiting the amount of code running as root, but not security, we could provide a net-device smaller process that can read and write raw sockets that runs as root, to which the larger simulation connects. THis has the drawback of opening a giant security hole. If you have any opinions or strong requirements in this respect, please let me know.

	===Emulation plus Realtime Scheduler===		===Emulation plus Realtime Scheduler===
	If you consider how an ns-3 simulation might drive a physical net device, it is straightforward. When you want the physical net device to drive the simulation, you need to be able to allow the net device to schedule events in the simulator. Since the basic model for ~~pcap~~ is synchronous, we will need to have a thread reading data from a physical net device in real time. We also want to have at least one thread executing the simulation. It seems clear that we are going to have a multithreaded solution. This means we ~~are going to need~~ to serialize the sheduler.		If you consider how an ns-3 simulation might drive a physical net device, it is straightforward. When you want the physical net device to drive the simulation, you need to be able to allow the net device to schedule events in the simulator. Since the basic model for sockeets is synchronous, we will need to have a thread reading data from a physical net device in real time. We also want to have at least one thread executing the simulation. It seems clear that we are going to have a multithreaded solution. This means we needed to serialize the sheduler.

	Also. since there is going to be a need for the net device thread to affect the main scheduler thread we are going to have some form of inter-thread communication. Typically, the scheduler will be sleeping waiting to synchronize with real time. IF a net device receives a packet, we need to be able to schedule a new packet reception event and to wake the scheduler and force it to re-evaluate what it needs to do. This will most likely mean the scheduler will have to execute the newly scheduled event (and derived events) and then go back to sleep waiting for the next event time.		Also. since there is going to be a need for the net device thread to affect the main scheduler thread we are going to have some form of inter-thread communication. Typically, the scheduler will be sleeping waiting to synchronize with real time. IF a net device receives a packet, we need to be able to schedule a new packet reception event and to wake the scheduler and force it to re-evaluate what it needs to do. This will most likely mean the scheduler will have to execute the newly scheduled event (and derived events) and then go back to sleep waiting for the next event time.
Line 20:		Line 20:

	Since multiple threads are wandering around in the scheduler, we need to be careful about protecting shared data structures of course.		Since multiple threads are wandering around in the scheduler, we need to be careful about protecting shared data structures of course.

			We have added the required kernel thread and synchronization classes to ns-3-dev as of July, 2008.

	===Higher Order Effects===		===Higher Order Effects===
Line 25:		Line 27:

	===Current Status===		===Current Status===
	This has been a high priority background task for me. Its continues to be swapped in and out as other things heat up and cool off. ~~I spent a few days up until May 20~~, ~~2008 abusing~~ the ~~multithreaded~~ simulator ~~code~~ and it is ~~looking pretty solid~~. ~~As of today, May 21, 2008, I'm off working on other things again~~.		This has been a high priority background task for me. Its continues to be swapped in and out as other things heat up and cool off.

			We have prepared for the appearance of the emulation work in ns-3-dev. The required kernel primitives have been added, and the simulator has been broken up into interface and implementation pieces.

			I have a working simulator implementation that is a realtime scheduler which synchronizes the simulation time with wall clock time. The changes are such that it has been made multithread safe (so schedule requests can come in from threads managing "real" emulated net devices) and the simulator has a wall-clock "synchronizer" that is used to provide a real timebase and synchronization capability.

	I ~~have prototyped~~ the ~~synchronizer, which is the part of the realtime scheduler~~ that ~~synchronizes~~ the simulation ~~time with wall clock time~~. ~~I have done this with three different time sources and I believe~~ the ~~basic idea has proved itself~~. The ~~code to implement this prototype has been commented so someone else could pick up this work. See~~ the ~~ns-3-emu/src/simulator directory and grep for synchronizer~~. ~~The simulator~~ has ~~been made multithread safe so schedule requests can come in from threads managing real net devices or sockets to real networks~~.		I wrote an "abuse the simulator" program that schedules many functions then spins up a worker thread simulating a net-device and runs the simulation. The thread tosses in many schedule-now events while the simulation is running. The program loops forever looking for problems caused by the multithreading. This has successfully run for days at a time.

	~~The basic kernel primitives required for the emulator~~ have ~~been coded and fairly extensively tested~~. ~~These include various condition~~, ~~mutual exclusion, thread~~ and ~~critical section classes~~. ~~You can find these in the ns-3-emu/src/core subdirectory~~.		I have a pretty-much working emulated net device running. It works pretty much as you may imagine, by implementing the pure virtual methods in net-device.h but hooking into the sockets API transmit and recieve real packets. There is a functional emulation helper that helps you create simulations.

	~~I wrote an "abuse~~ the simulator~~" program that schedules many functions then spins up a worker thread and runs~~ the ~~simulation~~. ~~The thread tosses in many schedule~~-~~now events while~~ the ~~simulation is running as if it were~~ a net device~~. The program loops forever looking~~ for ~~problems caused by~~ the ~~multithreading. This has successfully run overnight~~.		You can find a couple of examples that use this functionality. THe first is just a udp-echo example that consumes real time instead of simulating as quickly as possible. In order to enable this behavior, you just have to set the realtime simulator implementation which is the code at the start of the main function in the realtime-udp-echo.cc example. There is also an example called emu-sniff.cc that uses the helper to create a node with an emulated net device, and run for ten seconds dumping all of the packets received in hex.

	~~The pcap trace and packet socket functionality was prototyped in another separate place and is basically throw-away code.~~ There are two use cases we've defined so far: using ns-3 nodes and stacks but substituting real net devices and real networks in a simulation; and the converse which is using an ns-3 simulated network between real nodes and stacks. I will be working to get the first scenario working next. Tom Henderson has said he might do some prototyping to enable the second.		There are two use cases we've defined so far: using ns-3 nodes and stacks but substituting real net devices and real networks in a simulation; and the converse which is using an ns-3 simulated network between real nodes and stacks. I will be working to get something real working with respect to the first scenario working next. Tom Henderson has said he might do some prototyping to enable the second.

	Feel free to take a look at the ns-3-emu repository and let me know what you think.		Feel free to take a look at the ns-3-emu repository and let me know what you think.

Craigdo: /* Current Status */

2008-05-21T14:30:01Z

Current Status

← Older revision		Revision as of 14:30, 21 May 2008
Line 25:		Line 25:

	===Current Status===		===Current Status===
	This has been a high priority background task for me. As of ~~April 28~~, 2008 ~~it has been swapped into the foreground --~~ I ~~am actively~~ working on ~~the project~~.		This has been a high priority background task for me. Its continues to be swapped in and out as other things heat up and cool off. I spent a few days up until May 20, 2008 abusing the multithreaded simulator code and it is looking pretty solid. As of today, May 21, 2008, I'm off working on other things again.

	I have prototyped the synchronizer, which is the part of the realtime scheduler that synchronizes the simulation time with wall clock time. I have done this with three different time sources and I believe the basic idea has proved itself. The code to implement this prototype has been commented so someone else could pick up this work. See the src/simulator directory and grep for synchronizer.		I have prototyped the synchronizer, which is the part of the realtime scheduler that synchronizes the simulation time with wall clock time. I have done this with three different time sources and I believe the basic idea has proved itself. The code to implement this prototype has been commented so someone else could pick up this work. See the ns-3-emu/src/simulator directory and grep for synchronizer. The simulator has been made multithread safe so schedule requests can come in from threads managing real net devices or sockets to real networks.

	The basic kernel primitives required for the emulator have been ~~prototyped~~. These include various condition, mutual exclusion, thread and critical section classes. You can find these in the src/core subdirectory.		The basic kernel primitives required for the emulator have been coded and fairly extensively tested. These include various condition, mutual exclusion, thread and critical section classes. You can find these in the ns-3-emu/src/core subdirectory.

	The ~~pcap trace and packet socket functionality was prototyped~~ in ~~another separate place and~~ is ~~basically throw-away code~~.		I wrote an "abuse the simulator" program that schedules many functions then spins up a worker thread and runs the simulation. The thread tosses in many schedule-now events while the simulation is running as if it were a net device. The program loops forever looking for problems caused by the multithreading. This has successfully run overnight.

	I ~~have the beginnings of~~ the ~~multi-threaded simulator done~~. ~~This includes~~ the ~~condition-based sleep-wait code mentioned above~~.		The pcap trace and packet socket functionality was prototyped in another separate place and is basically throw-away code. There are two use cases we've defined so far: using ns-3 nodes and stacks but substituting real net devices and real networks in a simulation; and the converse which is using an ns-3 simulated network between real nodes and stacks. I will be working to get the first scenario working next. Tom Henderson has said he might do some prototyping to enable the second.

	Feel free to take a look at the ns-3-emu repository and let me know what you think.		Feel free to take a look at the ns-3-emu repository and let me know what you think.

Craigdo: /* Current Status */

2008-04-29T00:14:16Z

Current Status

← Older revision		Revision as of 00:14, 29 April 2008
Line 25:		Line 25:

	===Current Status===		===Current Status===
	This has been a high priority background task for me. As of April 28, 2008 it has been swapped into the foreground --- I am actively working on the project.		This has been a high priority background task for me. As of April 28, 2008 it has been swapped into the foreground -- I am actively working on the project.

	I have prototyped the synchronizer, which is the part of the realtime scheduler that synchronizes the simulation time with wall clock time. I have done this with three different time sources and I believe the basic idea has proved itself. The code to implement this prototype has been commented so someone else could pick up this work. See the src/simulator directory and grep for synchronizer.		I have prototyped the synchronizer, which is the part of the realtime scheduler that synchronizes the simulation time with wall clock time. I have done this with three different time sources and I believe the basic idea has proved itself. The code to implement this prototype has been commented so someone else could pick up this work. See the src/simulator directory and grep for synchronizer.
Line 36:		Line 36:

	Feel free to take a look at the ns-3-emu repository and let me know what you think.		Feel free to take a look at the ns-3-emu repository and let me know what you think.


	~~The required kernel-level synchronization primitives~~

Craigdo at 00:13, 29 April 2008

2008-04-29T00:13:44Z

← Older revision		Revision as of 00:13, 29 April 2008
Line 24:		Line 24:
	Since we are attempting to run our simulations at realtime, and have already committed to a multithreaded environment, we have plenty of need and new opportunity for performance optimizations. Others (Mahrenholz et al.) have considered the kinds of optimizations that can be done so I won't duplicate this here, but at this stage of the game we consider them higher order effects that we'll worry about when the time comes.		Since we are attempting to run our simulations at realtime, and have already committed to a multithreaded environment, we have plenty of need and new opportunity for performance optimizations. Others (Mahrenholz et al.) have considered the kinds of optimizations that can be done so I won't duplicate this here, but at this stage of the game we consider them higher order effects that we'll worry about when the time comes.

	==Current Status===		===Current Status===
	This has been a high priority background task for me. As of April 28, 2008 it has been swapped into the foreground --- I am actively working on the project.		This has been a high priority background task for me. As of April 28, 2008 it has been swapped into the foreground --- I am actively working on the project.