diff --git a/Thumbs.db b/Thumbs.db index 558d266..45536dc 100644 Binary files a/Thumbs.db and b/Thumbs.db differ diff --git a/TracingPaper.aux b/TracingPaper.aux index 644f585..0c2da03 100644 --- a/TracingPaper.aux +++ b/TracingPaper.aux @@ -85,9 +85,6 @@ \bibcite{Orosz2013}{5} \bibcite{Dabir2008}{6} \bibcite{Narayan2010}{7} -\bibcite{Skopko2012}{8} -\bibcite{MS-CIFS}{9} -\bibcite{MS-SMB}{10} \@writefile{toc}{\contentsline {subsection}{\numberline {4.5}Locating Performance Bottlenecks}{6}} \newlabel{Locating Performance Bottlenecks}{{4.5}{6}} \@writefile{toc}{\contentsline {section}{\numberline {5}Intuition Confirm/Change}{6}} @@ -96,6 +93,9 @@ \newlabel{Characterizations of Different Packet Types}{{5.1}{6}} \@writefile{toc}{\contentsline {section}{\numberline {6}Conclusion}{6}} \newlabel{Conclusion}{{6}{6}} +\bibcite{Skopko2012}{8} +\bibcite{MS-CIFS}{9} +\bibcite{MS-SMB}{10} \bibcite{MS-SMB2}{11} \bibcite{Roselli2000}{12} \bibcite{Vogels1999}{13} diff --git a/TracingPaper.log b/TracingPaper.log new file mode 100644 index 0000000..9d90b21 --- /dev/null +++ b/TracingPaper.log @@ -0,0 +1,234 @@ +This is pdfTeX, Version 3.1415926-2.3-1.40.12 (MiKTeX 2.9 64-bit) (preloaded format=pdflatex 2012.11.13) 18 FEB 2015 09:42 +entering extended mode +**C:/Users/rundeMT/Documents/UConn/TracingPaper/TracingPaper.tex +(C:/Users/rundeMT/Documents/UConn/TracingPaper/TracingPaper.tex +LaTeX2e <2009/09/24> +Babel and hyphenation patterns for english, afrikaans, ancientgreek, ar +abic, armenian, assamese, basque, bengali, bokmal, bulgarian, catalan, coptic, +croatian, czech, danish, dutch, esperanto, estonian, farsi, finnish, french, ga +lician, german, german-x-2009-06-19, greek, gujarati, hindi, hungarian, iceland +ic, indonesian, interlingua, irish, italian, kannada, kurmanji, lao, latin, lat +vian, lithuanian, malayalam, marathi, mongolian, mongolianlmc, monogreek, ngerm +an, ngerman-x-2009-06-19, nynorsk, oriya, panjabi, pinyin, polish, portuguese, +romanian, russian, sanskrit, serbian, slovak, slovenian, spanish, swedish, swis +sgerman, tamil, telugu, turkish, turkmen, ukenglish, ukrainian, uppersorbian, u +senglishmax, welsh, loaded. +(C:\Users\rundeMT\Documents\UConn\TracingPaper\usetex-v1.cls +Document Class: usetex-v1 2002/10/31 v1.2 usetex Usenix article class +("C:\Program Files\MiKTeX 2.9\tex\latex\base\article.cls" +Document Class: article 2007/10/19 v1.4h Standard LaTeX document class +("C:\Program Files\MiKTeX 2.9\tex\latex\base\size10.clo" +File: size10.clo 2007/10/19 v1.4h Standard LaTeX file (size option) +) +\c@part=\count79 +\c@section=\count80 +\c@subsection=\count81 +\c@subsubsection=\count82 +\c@paragraph=\count83 +\c@subparagraph=\count84 +\c@figure=\count85 +\c@table=\count86 +\abovecaptionskip=\skip41 +\belowcaptionskip=\skip42 +\bibindent=\dimen102 +) +("C:\Program Files\MiKTeX 2.9\tex\latex\endnotes\endnotes.sty" +\c@endnote=\count87 +\endnotesep=\dimen103 +\@enotes=\write3 +) +\@discard=\box26 + +("C:\Program Files\MiKTeX 2.9\tex\latex\psnfss\times.sty" +Package: times 2005/04/12 PSNFSS-v9.2a (SPQR) +) +Warning: endnotes support is deprecated (see documentation for details) +\@sectionaboveskip=\skip43 +\@sectionbelowskip=\skip44 +\@subsectionaboveskip=\skip45 +) ("C:\Program Files\MiKTeX 2.9\tex\latex\graphics\epsfig.sty" +Package: epsfig 1999/02/16 v1.7a (e)psfig emulation (SPQR) + +("C:\Program Files\MiKTeX 2.9\tex\latex\graphics\graphicx.sty" +Package: graphicx 1999/02/16 v1.0f Enhanced LaTeX Graphics (DPC,SPQR) + +("C:\Program Files\MiKTeX 2.9\tex\latex\graphics\keyval.sty" +Package: keyval 1999/03/16 v1.13 key=value parser (DPC) +\KV@toks@=\toks14 +) +("C:\Program Files\MiKTeX 2.9\tex\latex\graphics\graphics.sty" +Package: graphics 2009/02/05 v1.0o Standard LaTeX Graphics (DPC,SPQR) + +("C:\Program Files\MiKTeX 2.9\tex\latex\graphics\trig.sty" +Package: trig 1999/03/16 v1.09 sin cos tan (DPC) +) +("C:\Program Files\MiKTeX 2.9\tex\latex\00miktex\graphics.cfg" +File: graphics.cfg 2007/01/18 v1.5 graphics configuration of teTeX/TeXLive +) +Package graphics Info: Driver file: pdftex.def on input line 91. + +("C:\Program Files\MiKTeX 2.9\tex\latex\pdftex-def\pdftex.def" +File: pdftex.def 2011/05/27 v0.06d Graphics/color for pdfTeX + +("C:\Program Files\MiKTeX 2.9\tex\generic\oberdiek\infwarerr.sty" +Package: infwarerr 2010/04/08 v1.3 Providing info/warning/error messages (HO) +) +("C:\Program Files\MiKTeX 2.9\tex\generic\oberdiek\ltxcmds.sty" +Package: ltxcmds 2011/11/09 v1.22 LaTeX kernel commands for general use (HO) +) +\Gread@gobject=\count88 +)) +\Gin@req@height=\dimen104 +\Gin@req@width=\dimen105 +) +\epsfxsize=\dimen106 +\epsfysize=\dimen107 +) +("C:\Program Files\MiKTeX 2.9\tex\latex\ltxmisc\url.sty" +\Urlmuskip=\muskip10 +Package: url 2006/04/12 ver 3.3 Verb mode for urls, etc. +) + +LaTeX Warning: Unused global option(s): + [XXX]. + +(C:\Users\rundeMT\Documents\UConn\TracingPaper\TracingPaper.aux) +LaTeX Font Info: Checking defaults for OML/cmm/m/it on input line 54. +LaTeX Font Info: ... okay on input line 54. +LaTeX Font Info: Checking defaults for T1/cmr/m/n on input line 54. +LaTeX Font Info: ... okay on input line 54. +LaTeX Font Info: Checking defaults for OT1/cmr/m/n on input line 54. +LaTeX Font Info: ... okay on input line 54. +LaTeX Font Info: Checking defaults for OMS/cmsy/m/n on input line 54. +LaTeX Font Info: ... okay on input line 54. +LaTeX Font Info: Checking defaults for OMX/cmex/m/n on input line 54. +LaTeX Font Info: ... okay on input line 54. +LaTeX Font Info: Checking defaults for U/cmr/m/n on input line 54. +LaTeX Font Info: ... okay on input line 54. +LaTeX Font Info: Try loading font information for OT1+ptm on input line 54. + +("C:\Program Files\MiKTeX 2.9\tex\latex\psnfss\ot1ptm.fd" +File: ot1ptm.fd 2001/06/04 font definitions for OT1/ptm. +) +("C:\Program Files\MiKTeX 2.9\tex\context\base\supp-pdf.mkii" +[Loading MPS to PDF converter (version 2006.09.02).] +\scratchcounter=\count89 +\scratchdimen=\dimen108 +\scratchbox=\box27 +\nofMPsegments=\count90 +\nofMParguments=\count91 +\everyMPshowfont=\toks15 +\MPscratchCnt=\count92 +\MPscratchDim=\dimen109 +\MPnumerator=\count93 +\makeMPintoPDFobject=\count94 +\everyMPtoPDFconversion=\toks16 +) +LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <14.4> not available +(Font) Font shape `OT1/ptm/b/n' tried instead on input line 76. +LaTeX Font Info: External font `cmex10' loaded for size +(Font) <12> on input line 76. +LaTeX Font Info: External font `cmex10' loaded for size +(Font) <8> on input line 76. +LaTeX Font Info: External font `cmex10' loaded for size +(Font) <6> on input line 76. +LaTeX Font Info: Try loading font information for OT1+pcr on input line 76. + ("C:\Program Files\MiKTeX 2.9\tex\latex\psnfss\ot1pcr.fd" +File: ot1pcr.fd 2001/06/04 font definitions for OT1/pcr. +) +LaTeX Font Info: External font `cmex10' loaded for size +(Font) <7> on input line 76. +LaTeX Font Info: External font `cmex10' loaded for size +(Font) <5> on input line 76. +LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <12> not available +(Font) Font shape `OT1/ptm/b/n' tried instead on input line 78. +Missing character: There is no in font ptmr7t! +Missing character: There is no in font ptmr7t! +Missing character: There is no in font ptmr7t! +Missing character: There is no in font ptmr7t! +Missing character: There is no in font ptmr7t! +Missing character: There is no in font ptmr7t! +LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <10> not available +(Font) Font shape `OT1/ptm/b/n' tried instead on input line 94. + [1{C:/ProgramData/MiKTeX/2.9/pdftex/config/pdftex.map} + + +] +Underfull \hbox (badness 10000) in paragraph at lines 96--97 +[]\OT1/ptm/m/n/10 [CLOSING SEN-TENCES?]While per-form-ing a + [] + + +Underfull \hbox (badness 1596) in paragraph at lines 96--97 +\OT1/ptm/m/n/10 ma-chines com-mu-ni-cat-ing with each other, and the + [] + + +Underfull \hbox (badness 2269) in paragraph at lines 102--103 +\OT1/ptm/m/n/10 no pa-per an re-ally see the whole scope of trac- + [] + +[2] [3] +LaTeX Font Info: Font shape `OT1/ptm/bx/it' in size <10> not available +(Font) Font shape `OT1/ptm/b/it' tried instead on input line 157. + [4] +Underfull \hbox (badness 10000) in paragraph at lines 194--195 + + [] + +LaTeX Font Info: Try loading font information for OMS+ptm on input line 201. + +("C:\Program Files\MiKTeX 2.9\tex\latex\psnfss\omsptm.fd" +File: omsptm.fd +) +LaTeX Font Info: Font shape `OMS/ptm/m/n' in size <10> not available +(Font) Font shape `OMS/cmsy/m/n' tried instead on input line 201. + [5] +Underfull \hbox (badness 1077) in paragraph at lines 366--367 +\OT1/ptm/m/n/10 not only pull out in-for-ma-tion per-ta-nent to the + [] + +[6] +Underfull \hbox (badness 10000) in paragraph at lines 400--401 +[]\OT1/ptm/m/it/10 Common In-ter-net File Sys-tem (CIFS) Pro- + [] + + +Underfull \hbox (badness 10000) in paragraph at lines 400--401 +\OT1/ptm/m/it/10 to-col\OT1/ptm/m/n/10 , urlhttp://msdn.microsoft.com/en- + [] + + +Underfull \hbox (badness 10000) in paragraph at lines 402--403 +[]\OT1/ptm/m/it/10 Server Mes-sage Block (SMB) Pro-to- + [] + + +Underfull \hbox (badness 10000) in paragraph at lines 402--403 +\OT1/ptm/m/it/10 col\OT1/ptm/m/n/10 , urlhttp://msdn.microsoft.com/en- + [] + +[7 + +] (C:\Users\rundeMT\Documents\UConn\TracingPaper\TracingPaper.aux) ) +Here is how much of TeX's memory you used: + 1476 strings out of 494049 + 19894 string characters out of 3146058 + 78677 words of memory out of 3000000 + 4768 multiletter control sequences out of 15000+200000 + 20443 words of font info for 42 fonts, out of 3000000 for 9000 + 715 hyphenation exceptions out of 8191 + 34i,8n,21p,2182b,435s stack positions out of 5000i,500n,10000p,200000b,50000s +{C:/Program + Files/MiKTeX 2.9/fonts/enc/dvips/fontname/8r.enc} +Output written on TracingPaper.pdf (7 pages, 109988 bytes). +PDF statistics: + 51 PDF objects out of 1000 (max. 8388607) + 0 named destinations out of 1000 (max. 500000) + 1 words of extra memory for PDF output out of 10000 (max. 10000000) + diff --git a/TracingPaper.pdf b/TracingPaper.pdf new file mode 100644 index 0000000..31988c1 Binary files /dev/null and b/TracingPaper.pdf differ diff --git a/TracingPaper.synctex.gz b/TracingPaper.synctex.gz new file mode 100644 index 0000000..3368b66 Binary files /dev/null and b/TracingPaper.synctex.gz differ diff --git a/TracingPaper.tex b/TracingPaper.tex index 84dc486..bba5111 100644 --- a/TracingPaper.tex +++ b/TracingPaper.tex @@ -160,7 +160,7 @@ Server Message Block (SMB) is the modern dialect of Common Internet File System \label{ID Tracking} All comands sent over the network are coupled to an identifying MID/PID/TID/UID tuple. Since the only commands being examined are read or write commands, the identifying characteristic distinguishing a request command packet from a reponse command packet is the addition of an FID field with the sent packet. It is examination of the packets for this FID field that allows the analysis code to distinguish between request \& response command pakets. The pairing is done by examining the identifying tuple and assuming that each tuple-identified system will only send one command at a time (awaiting a response before sending the next command of that same type). \\Following these process IDs is as a way to check for intercommunication between two or more processes. In particular, we examine the compute time \& I/O (input/output) time (i.e. time spent in communication; between information arrivals). This is done by examining the inter-arrival times (IAT) between the server \& the client. This is interesting because this information will give us a realistic sense of the data transit time of the network connections being used (e.g. ethernet, firewire, fibre, etc.). Other pertinent information would be how often the client makes requests \& how often this event occurs per client process ID, identifiable by their PID/MID tuple. One could also track the amount of sharing that is occurring between users. The PID is the process identifier and the MID is the multiplex identifier, which is set by the client and is to be used for identifying groups of commands belonging to the same logical thread of operation on the client node. -\\The per client process ID can be used to map the activity of given programs, thus allowing for finer granularity in the produced benchmark (e.g. control down to process types ran by individual client levels). Other features of interest are the time between an open \& close, or how many opens/closes occurred in a window (e.g. a period of time). This information could be used as a gauge of current day trends in filesystem usage \& its consequent taxation on the surrounding network. It would also allow for greater insight on the r/w habits of users on a network along with a rough comparison between other registered events that occur on the network. Lastly, though no less important, it would allow us to look at how many occurrences there are of shared files between different users, though one must note that there is some issue (though hopefully rare) of resource locking (e.g. shared files) that needs to be taken into account. This is initially addressed by monitoring any oplock flags that are sent for read \& writes. This information also helps provide a preliminary mapping of how the network is used and what sort of traffic populates the communication. +\\The per client process ID can be used to map the activity of given programs, thus allowing for finer granularity in the produced benchmark (e.g. control down to process types ran by individual client levels). Other features of interest are the time between an open \& close, or how many opens/closes occurred in a window (e.g. a period of time). This information could be used as a gauge of current day trends in filesystem usage \& its consequent taxation on the surrounding network. It would also allow for greater insight on the r/w habits of users on a network along with a rough comparison between other registered events that occur on the network. Lastly, though no less important, it would allow us to look at how many occurrences there are of shared files between different users. One must note that the type of sharing may differ and there can be an issue of resource locking (e.g. shared files) that needs to be taken into account. This is preliminarily addressed by monitoring any oplock flags that are sent for read \& writes. This information also helps provide a preliminary mapping of how the network is used and what sort of traffic populates the communication. %\subsection{Other (e.g. HTML)} %\label{Other (e.g. HTML)} @@ -189,23 +189,23 @@ All comands sent over the network are coupled to an identifying MID/PID/TID/UID \subsection{System Information and Predictions} \label{System Information and Predictions} -The following is an explination the UITS system from which trace1 pulls it's packet information along with predicitions of how the data will look. +The following is an explination the UITS system from which trace1 pulls it's packet traffic information along with predicitions of how the data will look along with the reasoning behind the shape of the information. -The UITS system consisnts of five Microsoft file server cluster nodes. These blade servers are used to host home directories for all UConn users within the list of 88 departments. These home directories are used to provide personal drive share space to facultiy, staff and students, along with at lest one small group of users. Each server is capable of handling 1Gb of traffic in each direction (e.g. outbound and inbound traffic). All together the five blade server system can in theory handle 10Gb of recieving and tranmitting data. Some of these blade servers have local storage but the majority do not have any. To the understanding of this paper, the blade servers are purposed purely for dealing with incoming traffic to the SAN storage that sits beihnd them. This system does not currently implement load balancing, instead the servers are set up to spead the traffic load among four of the active cluster nodes while the fifth node is passive and purposed to take over in the case that any of the other nodes goes down. \\ +The UITS system consisnts of five Microsoft file server cluster nodes. These blade servers are used to host home directories for all UConn users within a list of 88 departments. These home directories are used to provide personal drive share space to facultiy, staff and students, along with at lest one small group of users. Each server is capable of handling 1Gb/s of traffic in each direction (e.g. outbound and inbound traffic). All together the five blade server system can in theory handle 10Gb/s of recieving and tranmitting data. Some of these blade servers have local storage but the majority do not have any. To the understanding of this paper, the blade servers are purposed purely for dealing with incoming traffic to the SAN storage nodes that sit behind them. This system does not currently implement load balancing, instead the servers are set up to spread the traffic load among four of the active cluster nodes while the fifth node is passive and purposed to take over in the case that any of the other nodes go down (e.g. become inoperable or crash). \\ -The following are my predictions about what the data will tell me about the system. First are the predictions based on what was learned from talking to people within UITS, after that are my general predictions. +From the information at hand I theorized the following behaviors and attributes that would be seen in the system. First are the predictions based on what was learned from talking to people within UITS, after that are my general predictions. -From this paper's understanding of the file server system there are spikes of traffic that tend to happen during the night time. The assumption is that the majority of this traffic will occur between 2am and 6am because this is when backups occur to the SAN system. The point of note is that, however, it is not expected that we would see any of this traffic as the protocol used is not the SMB/CIFS protocol that is being analyzed by this paper. The reasoning for this is that this traffic would be encrypted, therefore this traffic would appear as some other protocol. Further more, any traffic that does occur during the duration of "day time hours" (i.e. 9am to 5pm) would be soley due to the actions taken by the users of this system (e.g facutly, staff, students). \\ +From conversations with UITS, the understanding of the file server system behavior is that there are spikes of traffic that tend to happen during the night time. Our assumption is that the majority of this traffic will occur between 2am and 6am because this is when backups occur to the SAN system. It is important to note that, however, it is not expected that we would see any of this traffic as the protocol used is not the SMB/CIFS protocol that is being analyzed by this paper. The reasoning for this is that this traffic would be encrypted, therefore this traffic would appear as some other protocol. Further more, any traffic that does occur during the duration of "day time hours" (i.e. 9am to 5pm) would be soley due to the actions taken by the users of this system (e.g facutly, staff, students). If there is an automatic backup manager we would expect to see traffic caused by it pulling cached information from the machine of users across the network. \\ Assumptions: \begin{itemize} -\item Some backup traffic will be seen because traffic will be generated as the data being stored using this "oneline storage" is backed up to the SAN system. Note: Any traffic past moving the data to the SAN system will \textbf{not} be seen. +\item Some backup traffic will be seen because traffic will be generated as the data being stored using this "oneline storage" is backed up to the SAN system. Note: Any traffic past moving the data to the SAN system will \textbf{not} be seen. This would be because the traffic would show up as an other protocol. \item All backup will be performed late night/early morning (e.g. 11pm-5am) -\item One general assumption is that these blade servers are "rock solid" and therefore should \textbf{not} ever go down. If this is the case then the expectation is that we should see at most a transfer rate of 8Gb since the fifth server will not be in operation. If we do find that there is a greater rate of transfer of data, then this means that the fifth server is actually helping with the traffic, not just acting as a backup in the case that any other blade server crashes or "goes down". +\item One general assumption is that these blade servers are "rock solid" and therefore should \textbf{not} ever go down. If this is the case then the expectation is that we should see at most a transfer rate of 8Gb/s since the fifth server will not be in operation. If we do find that there is a greater rate of transfer of data, then this means that the fifth server is actually helping with the traffic, not just acting as a backup in the case that one of the other blade servers crashes or "goes down". \end{itemize} \subsection{Run Patterns} \label{Run Patterns} -Interpreting the data collected is done by producing three separate graphs showing three important areas of interest for being able to understand the traffic being examined. These areas are: \textbf{1)} the total number of read/write IO events, \textbf{2)} the occurrrences of different file sizes being read/written, \textbf{3)} the total number of bytes (combined read \& write) that are communicated over the traffic captured by this paper's tracing system. The reason for needing these three areas of information is that combined together one is able to better interpret all the collected and dissected information. By comparing the byte traffic to the IO information this is how we are able to tell not only when the times of greatest times of traffic are but which types of IO interactions dominate these periods. It should be noted that unfortunately the analysis program does not include a granularity to allow knowledge on whether the read, or write, events are responsible for the most data transfer (via communication) but that is one of the many future additions to this work. The file size information allows for interpretation of the size of the information that is being passed between the UITS servers and clients. Although the granualrity for this information is far corser (24 hours versus the 15 minute time window) it still shows which variations of file length were most encountered over the period of the given day. This information coupled with the byte and IO information reflects a priliminary protrait of how the UITS file server system is used, which can be compared to the internal network information that the UITS department keeps for their own maintenance and troubleshooting purposes. +Interpreting the data collected is done by producing three separate graphs showing three important areas of interest for being able to understand the traffic being examined. These areas are: \textbf{1)} the total number of read/write IO events, \textbf{2)} the occurrrences of different file sizes being read/written, \textbf{3)} the total number of bytes (combined read \& write) that are communicated over the traffic captured by the trace1 system. The reason for needing these three areas of information is that combined together one is able to better interpret all the collected and dissected information. By comparing the byte traffic to the IO information this is how we are able to tell not only when the times of greatest times of traffic are but which types of IO interactions dominate these periods. It should be noted that unfortunately the analysis program does not include a granularity to allow knowledge on whether the read, or write, events are responsible for the most data transfer (via communication) but that is one of the many future additions to this work. From early examinations the data leads us to interpret that the majority of reads are due to client exploring the shared drives \& queries about directories and directory contents, along with users copying large directories of data (most likely for their own purposes). The file size information allows for interpretation of the size of the information that is being passed between the UITS servers and clients (e.g. buffer sizes). Although the granualrity for this information is far corser (24 hours versus the 15 minute time window) it still shows which variations of data lengths were most encountered over the period of the given day. This information coupled with the byte and IO information reflects a priliminary protrait of how the UITS file server system is used, which can be compared to the internal network information that the UITS department keeps for their own maintenance and troubleshooting purposes. The hope is to essentially replicate the data that UITS keeps for their own records. \subsection{Locating Performance Bottlenecks} \label{Locating Performance Bottlenecks} @@ -357,8 +357,8 @@ Interpreting the data collected is done by producing three separate graphs showi \section{Conclusion} \label{Conclusion} \textit{Do the results show a continuation in the trend of traditional computer science workloads?} -On the outset of this work it was believed that the data collected and analyzed would follow similar behavior patterns seen in previous papers \textit{Cite?}. Our initial results were confusing and most definitely did not meet expections. One of these oddities was that during the day one would see a greater increase in writes instead of reads. The frist assumption was that this is due to the system and how users interact with everything. -I belive that the greater number of writes comes from students doing intro work for different classes in which students are constantly saving their work while reading instructions from a single source. One must also recall that this data itself has limited interpretation because only a small three week windows of infomration is being examined. A better, and far more complete, image can be constructed using data captured from the following months, or more ideally, from an entire year's worth of data. An other limitation of the results is the scope of the analysis is curbed and does not yet fully dissect all of the fields being passed in network communication. +On the outset of this work it was believed that the data collected and analyzed would follow similar behavior patterns seen in previous papers \textit{Cite?}. One of these oddities was that during the day one would see a greater increase in writes instead of reads. The first assumption was that this is due to the system and how users interact with everything. +I belive that the greater number of writes comes from students doing intro work for different classes in which students are constantly saving their work while reading instructions from a single source. The early traffic is most likely due to professors preparing for classes. One must also recall that this data itself has limited interpretation because only a small three week windows of infomration is being examined. A better, and far more complete, image can be constructed using data captured from the following months, or more ideally, from an entire year's worth of data. An other limitation of the results is the scope of the analysis is curbed and does not yet fully dissect all of the fields being passed in network communication. The future work of this project would be to \begin{itemize} \item 1. Complete the dissection analysis to include all captured fields from the originating pcap files.