slides.tex

柯老师网站上找到的

\begin{comment}
\item vertical slice through code.
\end{comment}

\foilhead{\indigo Multicast Transport: Other types}
\begin{itemize}
\item Structured hierarchy mechanisms
  \begin{sublist}\footnotesize
  \item Exists Multicast and Network Dynamics
  \item Exists Some of the possible timer mechanisms
  \item Exists Different loss models
  \item Requires building different modules for request/repair
  \item Requires defining the hierarchy and mechanisms
  \item Expect mostly work in OTcl
  \end{sublist}
\item Route Support
  \begin{sublist}\footnotesize
  \item Pointers to files for various models of implementation
  \item Exists Multicast and Dynamics
  \item Exists Loss Models
  \item Requires modifying some network layer code
  \item Expect Some minor work in C++, Lots of ``plumbing'' in OTcl
  \end{sublist}
\item Multicast Congestion Control
\end{itemize}

\begin{comment}
\item hints
\item throw open the floow
\end{comment}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\foilhead{\indigo Current NS Scaling}
NS is currently \emph{memory limited} for large simulations.

To scale, we're taking two approaches:
\begin{itemize}
\item tuning/monitoring detailed simulations (to reduce memory usage)
\item abstract simulations (to remove ``unimportant'' details)
\end{itemize}
\keyword{Scaling Considerations}

\begin{comment}
\item Acknowledge John, Polly
\item tradeoff of extensibility vs scaling
\item memory bottleneck for the types of simulations we are interested in.
\item Other types may be CPU bound, such as packet level tracing via OTcl.Not yet reached this limit
\end{comment}

\foilhead{\indigo Detailed Simulations: Limits}
Some large topology configurations are in the distribution:

{\renewcommand{\arraystretch}{1.1}
\begin{tabularx}{\linewidth}{cX}
\multicolumn{2}{l}{\nsf{tcl/ex/newmcast/cmcast-150.tcl}} \\
150 nodes, 2200 links & Centralised multicast simulation; Uses
        $\approx$ 53MB \\[2ex]
2420 nodes, 2465 links & static unicast routing; path computation
        algorithms; Uses $\approx$ 800MB \\[2ex]
500 nodes, 815 links & sparse multicast group of 80 members; studying
        scalable session messsages \\[2ex]
\end{tabularx}
}

\begin{comment}
\item the large scale topologies are output from the GT-ITM 
  topology generation code
\end{comment}

\foilhead{\indigo Detailed Simulations: Object Sizes}
Rough estimates of memory per object
\begin{center}
\begin{tabular}{lr}
Simulator      & 268\makebox[0in][l]{KB} \\
Node            & 2 \\
Multicast Capable Node       & 6 \\
duplex-link     & 9 \\
duplex-link w. interfaces & 14 \\
\end{tabular}
\end{center}


\begin{comment}
\item Simulator is O(1) per simulation, not TclObject, only in OTcl
\item Big because of the number of instance procedures etc.
\item Estimates can be used to gather ballpark estimate
        of memory reqd. per simulation. 
\end{comment}

\foilhead{\indigo Hints to reduce memory usage}
\begin{itemize}
\item avoid trace-all
\item use arrays [\$a(1), \$a(2)\ldots] instead of vars [\$a1, \$a2]
\item other hints at
  \url{http://www-mash.cs.berkeley.edu/ns/ns-debugging.html}
\end{itemize}

\begin{comment}
\item trace-all enables tracing on all links.
\item each link`requires 3 objects for tracing, maybe more
\end{comment}

\foilhead{\indigo Further Memory Debugging}
\begin{itemize}
\item purify
  \begin{sublist}
  \item Use purify~3.2 if possible
  \item purify~4.0.2 may cause \ns\ to crash.

    Try using flags: -staticchecking=false -force-rebuild
  \item Typical call syntax for purify is:
    \begin{program}
      purify -staticchecking=false -force-reuild -collector=\tup{ld} g++ -o ns \ldots
    \end{program}
  \end{sublist}
\item Gray Watson \tup{[e-mail]}'s dmalloc library

  At \iurl{http://www.letters.com/dmalloc}
  \begin{sublist}
  \item Link into \ns, and analyse memory usage
  \end{sublist}
\end{itemize}

\begin{comment}
\item purify, paid software, lots of nice features,
\item lots of traps for various events
\item dmalloc free software...worth the money you paid for it
\item good statistical summary, but requires post processing
\end{comment}

\foilhead{\indigo Sample Dmalloc Summary}
Sample summary:
{\footnotesize
\begin{verbatim}
      size      count      gross function
               172114    6358277 total
        84      16510    1386840 ra=0x8064846
  subtotal      42634    1000426 TclObject::bind(char const *, int *) 
        18         12        216 "
        19        522       9918 "
    ...
        32      30263     968416 StringCreate 
  subtotal      30158     742472 NewVar 
        24      30077     721848 "
        27          1         27 "
    ...
\end{verbatim}
}

\begin{comment}
\item top line is total memory used
\item next line ra=0x is function in shared library
\item next line us TclObject::bind-allocated-memory
\item next line are subtotals for different sizes
\item StringCreate only has one size of allocation => no subtotals
\end{comment}

\foilhead{\violet Additional Debugging Hints}
Instructions are at:
\url{http://www-mash.cs.berkeley.edu/ns/ns-debugging.html}

None of this impacts order of magnitude improvements

Beyond this, Session Level Simulations\ldots

\begin{comment}
\item emphaise order or magnitude scaling is problematic
\end{comment}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\foilhead{\blue Abstract or Session-level Simulations}
\begin{itemize}
\item Why Session-level Packet Distribution? \hfil --- Scaling
\begin{program}\small
        before - 150  nodes, 2180 links, ~53 MB
        after  - 2000 nodes, 8108 links, ~40 MB
\end{program}
\item When to use Session-level Packet Distribution?
  \begin{sublist}
  \item multicast simulations
  \item low source rate (lower than the bottlenect link)
  \item little cross-traffic
  \item \eg, SRM sessions
  \end{sublist}
\item \emph{\textbf{Caveat:  Work in Progress}}
\end{itemize}
\keyword{Session}

\begin{comment}
\item WORK IN PROGRESS
\item cost of just creating the topology
\item ensure no queueing,
\end{comment}


\foilhead{\indigo Tradeoff: Accuracy}
\begin{itemize}
\item   ignores queuing delay within the routers
\end{itemize}

\begin{comment}
\item Abstracts out the topology, hence avoids processing delays as well
\end{comment}

\foilhead{\indigo Abstractions}
\begin{itemize}
\item Nodes are compacted, only store node id and port id

  \ie, no classifiers, replicators, route tables, \etc

\item Links only store bw/delay attributes

  \ie, no queues, delay elements, tracing, classifiers, \etc

\item Links get translated into a virtual end-to-end mesh\ldots sorta
\end{itemize}

\begin{comment}
\item node only stores unicast address, no additoinal instance variables
\item link delays and b/w are othe only attributes
\item configuration is identical to normal detail simulation
\end{comment}

\foilhead{\indigo Configuration}
\begin{program}\small
  set ns [new \textbf{SessionSim}]  \; note difference in simulator;

  # {\cf{}configuration of topology and multicast as usual}
  
  # {\cf{}configuration source agent as usual}
  set srcAgent [new Agent/CBR]
  $srcAgent set dst_ \tup{dst}
  $ns attach-agent $node $srcAgent

  set sessionHelper [$ns \textbf{create-session} $node $srcAgent]
\end{program}

\begin{comment}
\item note very similar configuration mechanisms
\item create-session because no explicit forwarding in node
\end{comment}

\foilhead{\red Internal Realisation of a Session}
\placefig{sessionArch}

\begin{comment}
\item notice direct e2e transfer
\item virtual link processing makes this possible
\item creating loss through lossModules
\end{comment}

\foilhead{\indigo Realising Loss}
\begin{program}\small
  $node join-group $receiver $group
  
  $sessionHelper \textbf{insert-loss} $lossModule $receiver
  $sessionHelper \textbf{insert-depended-loss} $receiver $srcAgent $group
\end{program}

\placefig{deploss}

\begin{itemize}
\item Location of loss impacts translation into virtual mesh
\end{itemize}

\begin{comment}
\item Loss modules are created from the loss models separately
\item Loss modules would be attached to the link.
\item translating them to virtual topology is done, but implementation
  is not in yet.
\end{comment}

\foilhead{\red Realisation and Comparisons}
Comparison of Multicast trees

\begin{minipage}{0.5\linewidth}
\placefig{regularTree}
\end{minipage}
\begin{minipage}{0.5\linewidth}
\placefig{sessionTree}
\end{minipage}

\begin{comment}
\item 4 node topology, 1 source 3 receivers
\end{comment}

\foilhead{\indigo Abstract Simulation Summary}
\begin{itemize}
\item Almost identical configuration
\item Lots of Work still in progress
  \begin{sublist}
  \item Loss Dependency
  \item Queueing approximation models
  \item Calibrating Error
  \item Mixed simulations
  \end{sublist}
\item Completed but not yet checked in:
  \begin{sublist}
  \item Early versions of Loss Dependency completed
  \end{sublist}
\end{itemize}

\begin{comment}
\item two new commands, subclass of Simulator
\item API fpr loss dependency
\end{comment}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\foilhead{\blue  Debugging in \ns: Overview}
\begin{itemize}
\item Correctness

--- tcldebugger

--- gdb

\item Coexistence of gdb and tcldebugger

\item Support in the Simulator
\end{itemize}
\keyword{Debugging}             % 6

\begin{comment}
\item debugging tips
\item Discusses space debugging earlier
\item Not run nto time scaling yet
\item correctness analysis
\item hard in dual environment, or is it?
\end{comment}

\foilhead{\violet Tcl debugger}
\begin{itemize}
\item Don Libes \tup{[e-mail]}'s Tcl debugger, written in Tcl
\item At \iurl{http://expect.nist.gov/tcl-debug/}
\item single stepping through lines of code 
\item supports break points based on procedures, or with arbitrary
  regular expressions
\end{itemize}

\begin{comment}
\item debugger written in Tcl and is a Tcl parser
\item can be used to add/modify code or data
\item breakpoints by routine or even by reg. exp matching on 
      code execution
\end{comment}

\foilhead{\violet Tcl debugger}
\begin{itemize}
\item Can also trap to debugger from the script, place \code{debug 1} 
  at the appropriate location
\item works with in user's simulation scripts
\item works even through (or in) embeddedTcl code
\item examine and set data or code using Tcl-ish commands
\end{itemize}

\begin{comment}
\item useful to track Tcl level problems. 
\item hard to correlate to C++ code though...
\end{comment}

\foilhead[-3.2ex]{\indigo Co-existence Semi-seamless Debugging}
        \begin{program}
      (gdb) run
      Starting program: /nfs/prot/kannan/PhD/simulators/ns/ns-2/ns 
      \ldots
      ^C
      Program received signal SIGINT, Interrupt.
      0x102218 in write ()
      (gdb) {\bfseries{}call Tcl::instance().eval("debug 1")}
      15: lappend auto_path $dbg_library
      dbg15.3> w
      *0: application
       15: lappend auto_path /usr/local/lib/dbg
      dbg15.4> Simulator info instances
      _o1
      dbg15.5> _o1 now
      0
      dbg15.6> # and other fun stuff
      dbg15.7> {\bfseries{}c}
      (gdb) where
      #0  0x102218 in write ()
      #1  0xda684 in FileOutputProc ()
      \ldots
      (gdb) {\bfseries{}c}
        \end{program}

\begin{comment}
\item power at your finger tips
\item can be used for other things as well, such as 
    Scheduler::instance().clock()
\end{comment}

\foilhead[-2ex]{\violet \textdollar{}ns gen-map output}
\begin{program}
% {\bfseries{}$ns gen-map}
Node _o6(id 0)
                classifier__o7(Classifier/Addr)
                dmux_(NULL_OBJECT)

        Link _o11, fromNode_ _o6(id 0) -> toNode_ _o8(id 1)
        Components (in order) head first
                _o10    Queue/DropTail
                _o12    DelayLink
                _o14    TTLChecker
---
Node _o8(id 1)
                classifier__o9(Classifier/Addr)
                dmux_(NULL_OBJECT)

        Link _o16, fromNode_ _o8(id 1) -> toNode_ _o6(id 0)
        Components (in order) head first
                _o15    Queue/DropTail
                _o17    DelayLink
                _o19    TTLChecker
---
%
\end{program}

\begin{comment}
\item simple topology of two nodes and one link to illustrate
\end{comment}
\end{document}