diff --git a/TracingPaper.aux b/TracingPaper.aux index 5774299..63c559c 100644 --- a/TracingPaper.aux +++ b/TracingPaper.aux @@ -67,58 +67,11 @@ \newlabel{SMB}{{4.1}{5}} \@writefile{toc}{\contentsline {subsection}{\numberline {4.2}ID Tracking}{5}} \newlabel{ID Tracking}{{4.2}{5}} -\citation{Anderson2004} -\citation{Anderson2004} -\citation{Anderson2004} -\@writefile{toc}{\contentsline {subsection}{\numberline {4.3}Run Patterns}{6}} -\newlabel{Run Patterns}{{4.3}{6}} -\@writefile{toc}{\contentsline {subsection}{\numberline {4.4}Locating Performance Bottlenecks}{6}} -\newlabel{Locating Performance Bottlenecks}{{4.4}{6}} -\@writefile{toc}{\contentsline {subsection}{\numberline {4.5}Other (e.g. HTML)}{6}} -\newlabel{Other (e.g. HTML)}{{4.5}{6}} -\@writefile{toc}{\contentsline {subsection}{\numberline {4.6}Process ID Tracking}{6}} -\newlabel{Process ID Tracking}{{4.6}{6}} -\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces \relax \fontsize {9}{11}\selectfont \abovedisplayskip 8.5\p@ plus3\p@ minus4\p@ \abovedisplayshortskip \z@ plus2\p@ \belowdisplayshortskip 4\p@ plus2\p@ minus2\p@ \def \leftmargin \leftmargini \topsep 4\p@ plus2\p@ minus2\p@ \parsep 2\p@ plus\p@ minus\p@ \itemsep \parsep {\leftmargin \leftmargini \topsep 4\p@ plus2\p@ minus2\p@ \parsep 2\p@ plus\p@ minus\p@ \itemsep \parsep }\belowdisplayskip \abovedisplayskip \itshape Rough Sketch of Communication}}{6}} -\newlabel{fig-communication}{{1}{6}} -\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.6.1}event\_data Structure Tracking}{6}} -\newlabel{event_data Structure Tracking}{{4.6.1}{6}} -\@writefile{toc}{\contentsline {subsection}{\numberline {4.7}Run Patterns}{6}} -\newlabel{Run Patterns}{{4.7}{6}} -\@writefile{toc}{\contentsline {subsection}{\numberline {4.8}Locating Performance Bottlenecks}{6}} -\newlabel{Locating Performance Bottlenecks}{{4.8}{6}} -\@writefile{toc}{\contentsline {section}{\numberline {5}Intuition Confirm/Change}{6}} -\newlabel{Intuition Confirm/Change}{{5}{6}} -\@writefile{toc}{\contentsline {subsection}{\numberline {5.1}Characterizations of Different Packet Types}{6}} -\newlabel{Characterizations of Different Packet Types}{{5.1}{6}} -\@writefile{toc}{\contentsline {section}{\numberline {6}Related Work}{6}} -\newlabel{Related Work}{{6}{6}} -\@writefile{toc}{\contentsline {subsection}{\numberline {6.1}Anderson 2004 Paper}{6}} -\newlabel{Anderson 2004 Paper}{{6.1}{6}} -\citation{EllardLedlie2003} -\citation{EllardLedlie2003} -\citation{EllardLedlie2003} -\@writefile{toc}{\contentsline {subsection}{\numberline {6.2}Ellard Ledlie 2003}{7}} -\newlabel{Ellard Ledlie 2003}{{6.2}{7}} -\citation{Ellard2003} -\@writefile{toc}{\contentsline {subsection}{\numberline {6.3}Ellard 2003}{8}} -\newlabel{Ellard 2003}{{6.3}{8}} -\@writefile{toc}{\contentsline {subsection}{\numberline {6.4}Leung 2008 Paper}{8}} -\newlabel{Leung 2008 Paper}{{6.4}{8}} -\@writefile{toc}{\contentsline {subsection}{\numberline {6.5}Orosz 2013 Paper}{8}} -\newlabel{Orosz 2013 Paper}{{6.5}{8}} \bibcite{Leung2008}{1} \bibcite{Ellard2003}{2} \bibcite{EllardLedlie2003}{3} \bibcite{Anderson2004}{4} \bibcite{Orosz2013}{5} -\@writefile{toc}{\contentsline {subsection}{\numberline {6.6}Dabir 2008 Paper}{9}} -\newlabel{Dabir 2008 Paper}{{6.6}{9}} -\@writefile{toc}{\contentsline {subsection}{\numberline {6.7}Narayan 2010 Paper}{9}} -\newlabel{Narayan 2010 Paper}{{6.7}{9}} -\@writefile{toc}{\contentsline {subsection}{\numberline {6.8}Skopko 2012 Paper}{9}} -\newlabel{Skopko 2012 Paper}{{6.8}{9}} -\@writefile{toc}{\contentsline {section}{\numberline {7}Conclusion}{9}} -\newlabel{Conclusion}{{7}{9}} \bibcite{Dabir2008}{6} \bibcite{Narayan2010}{7} \bibcite{Skopko2012}{8} @@ -129,3 +82,17 @@ \bibcite{Vogels1999}{13} \bibcite{Meyer2012}{14} \bibcite{PFRING}{15} +\@writefile{toc}{\contentsline {subsection}{\numberline {4.3}Run Patterns}{6}} +\newlabel{Run Patterns}{{4.3}{6}} +\@writefile{toc}{\contentsline {subsection}{\numberline {4.4}Locating Performance Bottlenecks}{6}} +\newlabel{Locating Performance Bottlenecks}{{4.4}{6}} +\@writefile{toc}{\contentsline {subsection}{\numberline {4.5}Run Patterns}{6}} +\newlabel{Run Patterns}{{4.5}{6}} +\@writefile{toc}{\contentsline {subsection}{\numberline {4.6}Locating Performance Bottlenecks}{6}} +\newlabel{Locating Performance Bottlenecks}{{4.6}{6}} +\@writefile{toc}{\contentsline {section}{\numberline {5}Intuition Confirm/Change}{6}} +\newlabel{Intuition Confirm/Change}{{5}{6}} +\@writefile{toc}{\contentsline {subsection}{\numberline {5.1}Characterizations of Different Packet Types}{6}} +\newlabel{Characterizations of Different Packet Types}{{5.1}{6}} +\@writefile{toc}{\contentsline {section}{\numberline {6}Conclusion}{6}} +\newlabel{Conclusion}{{6}{6}} diff --git a/TracingPaper.log b/TracingPaper.log index 2cc0e6e..0744e0e 100644 --- a/TracingPaper.log +++ b/TracingPaper.log @@ -1,4 +1,4 @@ -This is pdfTeX, Version 3.1415926-2.5-1.40.14 (MiKTeX 2.9 64-bit) (preloaded format=pdflatex 2014.12.20) 21 DEC 2014 17:53 +This is pdfTeX, Version 3.1415926-2.5-1.40.14 (MiKTeX 2.9 64-bit) (preloaded format=pdflatex 2014.12.20) 21 DEC 2014 21:35 entering extended mode **TracingPaper.tex (C:\UConn\TracingPaper\TracingPaper.tex @@ -180,65 +180,9 @@ Underfull \vbox (badness 10000) has occurred while \output is active [] 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 185. - -File: communications_sketch.png Graphic file (type png) - - -Package pdftex.def Info: communications_sketch.png used on input line 207. -(pdftex.def) Requested size: 180.67499pt x 180.89331pt. - Underfull \vbox (badness 10000) has occurred while \output is active [] [5] -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! -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! -Missing character: There is no â in font ptmr7t! -Missing character: There is no € in font ptmr7t! -Missing character: There is no ™ in font ptmr7t! - -[6 ] -Underfull \vbox (badness 10000) has occurred while \output is active [] - - -Underfull \vbox (badness 1484) has occurred while \output is active [] - - [7] -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! -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! -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! - -[8] -Underfull \hbox (badness 1215) in paragraph at lines 371--372 -[]\OT1/ptm/m/n/10 4. Dump-cap has op-tion called \OT1/ptm/m/it/10 snaplength \O -T1/ptm/m/n/10 to - [] - -[9] Underfull \hbox (badness 10000) in paragraph at lines 408--409 []\OT1/ptm/m/it/10 Common In-ter-net File Sys-tem (CIFS) Pro- [] @@ -258,19 +202,17 @@ Underfull \hbox (badness 10000) in paragraph at lines 410--411 \OT1/ptm/m/it/10 col\OT1/ptm/m/n/10 , urlhttp://msdn.microsoft.com/en- [] -[10 - -] (C:\UConn\TracingPaper\TracingPaper.aux) +[6] (C:\UConn\TracingPaper\TracingPaper.aux) LaTeX Warning: There were multiply-defined labels. ) Here is how much of TeX's memory you used: - 1494 strings out of 493705 - 19998 string characters out of 3144575 - 81983 words of memory out of 3000000 - 4818 multiletter control sequences out of 15000+200000 - 22634 words of font info for 45 fonts, out of 3000000 for 9000 + 1481 strings out of 493705 + 19740 string characters out of 3144575 + 80973 words of memory out of 3000000 + 4808 multiletter control sequences out of 15000+200000 + 20443 words of font info for 42 fonts, out of 3000000 for 9000 1025 hyphenation exceptions out of 8191 34i,8n,21p,1884b,437s 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 (10 pages, 4041247 bytes). +Output written on TracingPaper.pdf (6 pages, 104879 bytes). PDF statistics: - 63 PDF objects out of 1000 (max. 8388607) + 46 PDF objects out of 1000 (max. 8388607) 0 named destinations out of 1000 (max. 500000) - 6 words of extra memory for PDF output out of 10000 (max. 10000000) + 1 words of extra memory for PDF output out of 10000 (max. 10000000) diff --git a/TracingPaper.pdf b/TracingPaper.pdf index 3b63463..eb4d764 100644 Binary files a/TracingPaper.pdf and b/TracingPaper.pdf differ diff --git a/TracingPaper.synctex.gz b/TracingPaper.synctex.gz index 9eb855b..109377b 100644 Binary files a/TracingPaper.synctex.gz and b/TracingPaper.synctex.gz differ diff --git a/TracingPaper.tex b/TracingPaper.tex index 6c5e9d7..acd4cb1 100644 --- a/TracingPaper.tex +++ b/TracingPaper.tex @@ -196,30 +196,30 @@ All comands sent over the network are coupled to an identifying MID/PID/TID/UID \subsection{Locating Performance Bottlenecks} \label{Locating Performance Bottlenecks} -\subsection{Other (e.g. HTML)} -\label{Other (e.g. HTML)} - -\subsection{Process ID Tracking} -\label{Process ID Tracking} - -\begin{figure}[htbp] -\begin{centering} -\epsfig{file=communications_sketch, width=2.50in} -\small\itshape -\caption{\small\itshape Rough Sketch of Communication} -\label{fig-communication} -\end{centering} -\end{figure} - -Figure~\ref{fig-communication} shows a rough sketch of communication between a client \& server. The general order that constitutes a full tracking is as follows: (client) computation [process to filesystem], (client) communication [SMB protocol used to send data client→server], (server) timestamping + service [server gets data, logs it, performs service], (server) communication [SMB data send server→client], (client) next computation. - -Currently the focus of process ID tracking is to see the number of reads, writes and events that occur due to the actions of clients on the network. This is done by using a tuple of the PID \& MID fields which allows for the identification of client. Since these values are unique and \textbf{MUST} be sent with each packet, this tuple is used as the key for the unordered map that is used to track this information. The structure is as follows: the tuple functions as the key for the pairing of the identifying tuple \& corresponding event\_data structure; which is used to house pertinent information about reads/writes/events. The information stored in the structure is the last time a read/write/event occurred, the total IAT of the observed read/write/events, and the total number of reads/writes/events that have occurred for the identified tuple. The purpose for tracking this information is to profile the read/write “habits” of the users on the network as well as comparing this information against the general events’ inter-arrival times, thus allowing one to see if the read \& write events are being processed differently (e.g. longer or shorter IATs) than the rest of the events occurring on the network. - -One should note that there are separate purposes to the PID/MID tuple from the PID/MID/TID/UID tuple. The first tuple (2-tuple) is used to uniquely identify groups of commands belonging to the same logical thread of operation on the client node, while the latter tuple (4-tuple) allows for unique identification for request \& responses that are part of the same transaction. While the PID/MID tuple is mainly what we are interested in, since this allows the following of a single logical thread, there is some interest in making use of the TID/UID tuple because this would allow us to count the number of transactions that occur in a single logical thread. This information could provide interesting information on how the computer systems on the network may be deciding to handle/send commands over the network; e.g. sending multiple commands per transaction, multiple packet commands per transaction, etc. - -\subsubsection{event\_data Structure Tracking} -\label{event_data Structure Tracking} -The purpose of the event\_data structure is to maintain a list of the interesting information associated with each PID/MID/TID/UID tuple seen on the network. It is through this structure that the read \& write times, IATs, and even number of occurances are tracked, along with the request/response IAT pairings. In this manner each tuple has the following information tracked, and both the packet processing is performed and the meaningful data is output from the AnalysisModule code. \textit{\textbf{ADD LIST OF event\_data INFORMATION HERE}}. Although there is a large number of aspects that can be examined when dealing with all of this network information, the current focus of this paper is to examine the possible read/write commands that can occur in via SMB protcols and the IAT times of the request and response packets for these commands. \textit{\textbf{Note:}} Eventually the addition of resource locks WILL be included because it is through this information that we can gain any sort of idea as to the interaction between users/other programs with the resources on the network. +%\subsection{Other (e.g. HTML)} +%\label{Other (e.g. HTML)} +% +%\subsection{Process ID Tracking} +%\label{Process ID Tracking} +% +%\begin{figure}[htbp] +%\begin{centering} +%\epsfig{file=communications_sketch, width=2.50in} +%\small\itshape +%\caption{\small\itshape Rough Sketch of Communication} +%\label{fig-communication} +%\end{centering} +%\end{figure} +% +%Figure~\ref{fig-communication} shows a rough sketch of communication between a client \& server. The general order that constitutes a full tracking is as follows: (client) computation [process to filesystem], (client) communication [SMB protocol used to send data client→server], (server) timestamping + service [server gets data, logs it, performs service], (server) communication [SMB data send server→client], (client) next computation. +% +%Currently the focus of process ID tracking is to see the number of reads, writes and events that occur due to the actions of clients on the network. This is done by using a tuple of the PID \& MID fields which allows for the identification of client. Since these values are unique and \textbf{MUST} be sent with each packet, this tuple is used as the key for the unordered map that is used to track this information. The structure is as follows: the tuple functions as the key for the pairing of the identifying tuple \& corresponding event\_data structure; which is used to house pertinent information about reads/writes/events. The information stored in the structure is the last time a read/write/event occurred, the total IAT of the observed read/write/events, and the total number of reads/writes/events that have occurred for the identified tuple. The purpose for tracking this information is to profile the read/write “habits” of the users on the network as well as comparing this information against the general events’ inter-arrival times, thus allowing one to see if the read \& write events are being processed differently (e.g. longer or shorter IATs) than the rest of the events occurring on the network. +% +%One should note that there are separate purposes to the PID/MID tuple from the PID/MID/TID/UID tuple. The first tuple (2-tuple) is used to uniquely identify groups of commands belonging to the same logical thread of operation on the client node, while the latter tuple (4-tuple) allows for unique identification for request \& responses that are part of the same transaction. While the PID/MID tuple is mainly what we are interested in, since this allows the following of a single logical thread, there is some interest in making use of the TID/UID tuple because this would allow us to count the number of transactions that occur in a single logical thread. This information could provide interesting information on how the computer systems on the network may be deciding to handle/send commands over the network; e.g. sending multiple commands per transaction, multiple packet commands per transaction, etc. +% +%\subsubsection{event\_data Structure Tracking} +%\label{event_data Structure Tracking} +%The purpose of the event\_data structure is to maintain a list of the interesting information associated with each PID/MID/TID/UID tuple seen on the network. It is through this structure that the read \& write times, IATs, and even number of occurances are tracked, along with the request/response IAT pairings. In this manner each tuple has the following information tracked, and both the packet processing is performed and the meaningful data is output from the AnalysisModule code. \textit{\textbf{ADD LIST OF event\_data INFORMATION HERE}}. Although there is a large number of aspects that can be examined when dealing with all of this network information, the current focus of this paper is to examine the possible read/write commands that can occur in via SMB protcols and the IAT times of the request and response packets for these commands. \textit{\textbf{Note:}} Eventually the addition of resource locks WILL be included because it is through this information that we can gain any sort of idea as to the interaction between users/other programs with the resources on the network. \subsection{Run Patterns} \label{Run Patterns} @@ -233,143 +233,143 @@ The purpose of the event\_data structure is to maintain a list of the interestin \subsection{Characterizations of Different Packet Types} \label{Characterizations of Different Packet Types} -\section{Related Work} -\label{Related Work} - -\subsection{Anderson 2004 Paper} -\label{Anderson 2004 Paper} -This paper tackles the temporal inaccuracy of current day benchmarks \& the impact and errors produced due to these naive benchmarking tools. Timing accuracy (issuing I/Os at the desired time) at high I/O rates is difficult to achieve on stock operating systems ~\cite{Anderson2004}. Due to this inaccuracy, these may be introduction of substantial errors into observed system metrics when benchmarking I/O systems; including the use of these inaccurate tools for replaying traces or for producing synthetic workloads with known inter-arrival times ~\cite{Anderson2004}. Anderson \textit{et al.} demonstrates the need for timing accuracy for I/O benchmarking in the context of replaying I/O traces. Anderson \textit{et al.} showed that the error in perceived I/O response times can be as much as +350\% or -15\% by using naive benchmarking tools that have timing inaccuracies ~\cite{Anderson2004}. Anderson \textit{et al.}'s measurements indicated that the accuracy achieved by using standard system calls is not adequate and that errors in issuing I/Os can lead to substantial errors in measurements of I/O statistics such as mean latency and number of outstanding I/Os. -\begin{itemize} - \item 1. Timing in accuracy of benchmakrs can lead to error of +350\% or -15\% in perceived I/O response times. Accuracy achieved using standard system calls \textbf{not} adequate and error in issuing I/Os leads to substantial I/O statistics errors - \item 2. "We currently lack tools to easily and accurately generate complex I/O workloads on modern storage systems". \textit{\textbf{Result}}: May introduce substantial errors in observed system metrics when benchmark I/O systems use inaccurate tools - \item 3. I/O benchmarking widespread practice in storage industry and serves as basis for purchasing decisions, performance tuning studies and marketing campains. "how does a given storage system perform for my workload?" Benchmarking done by comparing I/O systems by subjecting them to known workloads - \item 4. Three general approaches based on trade-off between experimental complexity and resemblence to application - \begin{itemize} - \item 1. Connect system to production/test environment, run application, measure application metrics - \item 2. Collect traces from running application and replay them (after possible modification) back on test I/O system - \item 3. Generate sythetic workload and measure system performance - \end{itemize} - \item 5. Most studies assume issue accuracy using standard system calls adequate. Measures indicate not the case and errorsin issuing I/O can lead to substantial errors in issuing I/O can lead to substantial errors in I/O statistic measurements (e.g. mean latency and number of outstanding I/Os - \item 6. Inaccuracies in scheduling I/Os may result in as much as a factor of 3.5 difference in measured response time and factor of 26 in measured queue sizes; Differences too large to ignore - \item 7. Timing accuracy and high through-put involves three challenges - \begin{itemize} - \item 1. Designing for peak performance requirements - \item 2. Coping with OS timing inaccuracy - \item 3. Working around unpredictable OS behavior - \begin{itemize} - \item 1. Standard OS mechanisms to keep time and issue I/Os; accuracy determined by scheduling granularity of underlying OS - \item 2. Accuracy of I/O scheduling contingent upon thread being scheduled at right time by OS scheduling boundaries \textit{or} flatten bursts - \end{itemize} - \item 4. Unpredictable performance effects due to interrupts; locking, resource contention, kernel scheduling intracacies - \item 5. Examples of performance effects - \begin{itemize} - \item 1. \textit{gettimeofday}() function (SMP) from multiple threads may cause locking to preserve clock invarience - \item 2. Thread moving from one CPU to another difficulty keeping track of wall clock time - \end{itemize} - \item 6. In higher load case the kernel gets more opportunities to schedule threads and hence more I/O issuing threads get scheduled at right time - \end{itemize} -\end{itemize} - -\subsection{Ellard Ledlie 2003} -\label{Ellard Ledlie 2003} -This paper examines two workloads (research and email) to see if they resemble previously studied workloads, as well as performs several new analyses on the NFS protocol. Trace-based analyses have guided and motivated contemporary file system design for the past two decades; where the original analysis of the 4.2BSD file system motivated many of the design decisions of the log-structured file system (LFS)~\cite{EllardLedlie2003}. This paper also takes the stance that since the use of technology has expanded and evolved, this fundamental change in workloads needs to be traced to observe and understand the behavior. "We believe that as the community of computer users has expanded and evolved there has been a fundamental change in the workloads seen by file servers, and that the research community must find ways to observe and measure these new workloads."~\cite{EllardLedlie2003} Some of the contributions of this paper include new techniques for analyzing NFS traces along with tools to gather new anonymized NFS traces. Leung \textit{et al.} (as well as Ellard \textit{et. al.}) also observed that much of the variance of load characterization statistics over time can be explained by high-level changes in the workload over time; despite, this correlation having been observed in many trace studies, its effects are usually ignored~\cite{EllardLedlie2003}. The most noticeable change in their traces was the difference between peak and off-peak hours of operation. This finding conveyed that time is a strong predictor of operation counts, amount of data transferred, and the read-write ratios for their CAMPUS (e.g. email) workload. - -\subsection{Ellard 2003} -\label{Ellard 2003} -This paper shows that the technology being actively researched gains improvement faster and that the technology that is not improved will end up being the bottleneck of the system. Ellard and Seltzer give the example of how file system performance is steadily losing ground relative to CPU, memory, and even network performance. Even though Ellard and Seltzer began their efforts to accurately measure the impact of changes to their system, they also discovered several other phenomena that interacted with the performance of the disk and file system in ways that had far more impact on the overall performance of the system than their improvements~\cite{Ellard2003}. This paper loosely groups all benchmarks into two categories: micro benchmarks and macro/workload benchmarks, the difference between these two being that micro benchmarks measure specific low-level aspects of system performance while workload benchmarks estimate the performance of the system running a particular workload. - -\subsection{Leung 2008 Paper} -\label{Leung 2008 Paper} -Comparison of file access patterns (RO, WO, RW) -\begin{itemize} - \item 1. Workloads more write-heavy than previously seen - \item 2. RW access patterns much more frequent - \item 3. Bytes transferred in much longer sequential runs - \item 4. Bytes transferred from much larger files - \item 5. Files live order of magnitude longer - \item 6. Most files not reopened once closed; If file re-opened, temporally related to previous closing of file -\end{itemize} -Files are infrequently shared by more than one client; over 76\% files never opened by more than one client. -File sharing rarely concurrent and usually read-only; 5\% of files opened by multiple client are concurrent and 90\% of sharing is read only -\textit{Compared to Previous Studies} -\begin{itemize} - \item 1. Both of our workloads are more write-oriented. Read to write byte ratios have significantly decreased. - \item 2. Read-write access patterns have increased 30-fold relative to read-only and write-only access patterns. - \item 3. Most bytes are transferred in longer sequential runs. These runs are an order of magnitude larger. - \item 4. Most bytes transferred are from larger files. File sizes are up to an order of magnitude larger. - \item 5. Files live an order of magnitude longer. Fewer than 50\% are deleted within a day of creation. -\end{itemize} -\textit{New Observations} -\begin{itemize} - \item 6. Files are rarely re-opened. Over 66\% are re-opened once and 95\% fewer than five times. - \item 7. Files re-opens are temporally related. Over 60\% of re-opens occur within a minute of the first. - \item 8. A small fraction of clients account for a large fraction of file activity. Fewer than 1\% of clients account for 50\% of file requests. - \item 9. Files are infrequently shared by more than one client. Over 76\% of files are never opened by more than one client. - \item 10. File sharing is rarely concurrent and sharing is usually read-only. Only 5\% of files opened by multiple clients are concurrent and 90\% of sharing is read-only. -\end{itemize} -\textit{List of interesting data points (comes from 'Table 3: Summary of trace statistics')} -\begin{itemize} - \item Clients, Days, Data Read (GB), Data Written (GB), R:W I/O Ratio, R:W Byte Ratio, Total Operations - \item Operation Names: Session Create, Open, Close, Read, Write, Flush, Lock, Delete, File Stat, Set Attribute, Directory Read, Rename, Pipe Transactions -\end{itemize} -\textit{Table 4: Comparison of file access patterns - This figure gives good show of Read-Only, Write-Only \& Read-Write} -\\\textit{Observations:} -\begin{itemize} - \item 1) “Both of our workloads are more write-heavy than workloads studied previously” - \item 2) “Read-write access patterns are much more frequent compared to past studies” - \item 3) “Bytes are transferred in much longer sequential runs than in previous studies” - \item 4) Bytes are transferred from much larger files than in previous studies - \item 5) Files live an order of magnitude longer than in previous studies - \item 6) Most files are not re-opened once they are closed - \item 7) If a file is re-opened, it is temporally related to the previous close -\end{itemize} - -\subsection{Orosz 2013 Paper} -\label{Orosz 2013 Paper} -\begin{itemize} - \item 1. Primary bottleneck in current timestamp resolution provided by Kernel is large deviation of deneration (timestamp generation) overhead decreases timestamp precision - \item 2. Simplifying the work of the kernel (i.e. time stamping process) will lead to lower packet loss - \item 3. "In network measurement, the precision of timestamping is a criterion more important than the low clock offset, especially for measuring packet inter-arrival times and round-trip delays at one single point of the network (e.g., active probing)" -\end{itemize} - -\subsection{Dabir 2008 Paper} -\label{Dabir 2008 Paper} -\begin{itemize} - \item 1. "Since Dumpcap is a single threaded application, it was suspected that while it is busy writing to disk, because it is blocked by the I/O call, it is unable to handle newly arriving packets due to the small size of the kernel buffer which quickly fills up." - \item 2. Increasing amount of kernel level buffer associated with capture socket could lead to better capture speeds with Dumpcap -\end{itemize} -\textit{Note}: While (item 1) could be a source of packet loss, until this is tested on a trace system do not assume this is a key limiting factor. It could be that by having Dumpcap write to RAM would alieviate this problem. If this is the case, Dabir \& Matrawy attempted to overcome this limitation by having synchronization between two threads (using two semaphores) where \textbf{one} thread would store/buffer incoming packets and the \textbf{second} thread would write the packet information to disk - -\subsection{Narayan 2010 Paper} -\label{Narayan 2010 Paper} -\begin{itemize} - \item 1. Striping Data in parallel file system can bottleneck if file distribution parameters do not fit access patterns of applications - \item 2. Parallel application have five major models of I/O - \begin{itemize} - \item 1. Single output file shared by multiple nodes by ranges - \item 2. Large sequential read by single node at beginning of computation and large sequential write by single node at end of computation - \item 3. Checkpointing of state - \item 4. Metadata and read intensive - small data I/O, frequent directory lookups for reads - \item 5. Each node outputs to its own file - \end{itemize} - \item 3. Distributing I/O across more nodes not decrease IATs because files striped across all nodes which causes any Read or Write to access all nodes - \item 4. From Figure 5: As we see in the graphs and data provided, as the number of I/O nodes increases (as well as the number of processors/servers) the IATs decrease along with the number of I/O operations increase. This leads to a larger \% of IATs occuring at lower times (e.g. < 1ms) - \item 5. From study on IATs, most parallel applications doing significant I/O increase the I/O frequency as the number of compute nodes increases. \textbf{However}, scaling I/O nodes alone causes issue because increased I/O load is transferred to each I/O storage node - \item 6. "I/O access models that assume independence or randomness between requests are not valid" -\end{itemize} - -\subsection{Skopko 2012 Paper} -\label{Skopko 2012 Paper} -\begin{itemize} - \item 1. Software based capture solutions heavily rely on OS's packet processing mechanism - \item 2. "Dumpcap itself uses relatively small system resources, however it is executed on a general purpose system that shares its resources between the running processes" - \item 3. Drivers typically operate in two different modes: interrupt mode and polling mode; importance of modes is dual - \begin{itemize} - \item 1. timestamps generated at enqueueing process reflect that tiem instead of moment of arrival at physical layer - \item 2. polling causes bursty packet forwarding, thus need for appropriate sized buffers to handle them - \end{itemize} - \item 4. Dumpcap has option called \textit{snaplength} to do truncation; compared to original measurement, smaller snaplength = fewer lost packets by Dumpcap -\end{itemize} +%\section{Related Work} +%\label{Related Work} +% +%\subsection{Anderson 2004 Paper} +%\label{Anderson 2004 Paper} +%This paper tackles the temporal inaccuracy of current day benchmarks \& the impact and errors produced due to these naive benchmarking tools. Timing accuracy (issuing I/Os at the desired time) at high I/O rates is difficult to achieve on stock operating systems ~\cite{Anderson2004}. Due to this inaccuracy, these may be introduction of substantial errors into observed system metrics when benchmarking I/O systems; including the use of these inaccurate tools for replaying traces or for producing synthetic workloads with known inter-arrival times ~\cite{Anderson2004}. Anderson \textit{et al.} demonstrates the need for timing accuracy for I/O benchmarking in the context of replaying I/O traces. Anderson \textit{et al.} showed that the error in perceived I/O response times can be as much as +350\% or -15\% by using naive benchmarking tools that have timing inaccuracies ~\cite{Anderson2004}. Anderson \textit{et al.}'s measurements indicated that the accuracy achieved by using standard system calls is not adequate and that errors in issuing I/Os can lead to substantial errors in measurements of I/O statistics such as mean latency and number of outstanding I/Os. +%\begin{itemize} +% \item 1. Timing in accuracy of benchmakrs can lead to error of +350\% or -15\% in perceived I/O response times. Accuracy achieved using standard system calls \textbf{not} adequate and error in issuing I/Os leads to substantial I/O statistics errors +% \item 2. "We currently lack tools to easily and accurately generate complex I/O workloads on modern storage systems". \textit{\textbf{Result}}: May introduce substantial errors in observed system metrics when benchmark I/O systems use inaccurate tools +% \item 3. I/O benchmarking widespread practice in storage industry and serves as basis for purchasing decisions, performance tuning studies and marketing campains. "how does a given storage system perform for my workload?" Benchmarking done by comparing I/O systems by subjecting them to known workloads +% \item 4. Three general approaches based on trade-off between experimental complexity and resemblence to application +% \begin{itemize} +% \item 1. Connect system to production/test environment, run application, measure application metrics +% \item 2. Collect traces from running application and replay them (after possible modification) back on test I/O system +% \item 3. Generate sythetic workload and measure system performance +% \end{itemize} +% \item 5. Most studies assume issue accuracy using standard system calls adequate. Measures indicate not the case and errorsin issuing I/O can lead to substantial errors in issuing I/O can lead to substantial errors in I/O statistic measurements (e.g. mean latency and number of outstanding I/Os +% \item 6. Inaccuracies in scheduling I/Os may result in as much as a factor of 3.5 difference in measured response time and factor of 26 in measured queue sizes; Differences too large to ignore +% \item 7. Timing accuracy and high through-put involves three challenges +% \begin{itemize} +% \item 1. Designing for peak performance requirements +% \item 2. Coping with OS timing inaccuracy +% \item 3. Working around unpredictable OS behavior +% \begin{itemize} +% \item 1. Standard OS mechanisms to keep time and issue I/Os; accuracy determined by scheduling granularity of underlying OS +% \item 2. Accuracy of I/O scheduling contingent upon thread being scheduled at right time by OS scheduling boundaries \textit{or} flatten bursts +% \end{itemize} +% \item 4. Unpredictable performance effects due to interrupts; locking, resource contention, kernel scheduling intracacies +% \item 5. Examples of performance effects +% \begin{itemize} +% \item 1. \textit{gettimeofday}() function (SMP) from multiple threads may cause locking to preserve clock invarience +% \item 2. Thread moving from one CPU to another difficulty keeping track of wall clock time +% \end{itemize} +% \item 6. In higher load case the kernel gets more opportunities to schedule threads and hence more I/O issuing threads get scheduled at right time +% \end{itemize} +%\end{itemize} +% +%\subsection{Ellard Ledlie 2003} +%\label{Ellard Ledlie 2003} +%This paper examines two workloads (research and email) to see if they resemble previously studied workloads, as well as performs several new analyses on the NFS protocol. Trace-based analyses have guided and motivated contemporary file system design for the past two decades; where the original analysis of the 4.2BSD file system motivated many of the design decisions of the log-structured file system (LFS)~\cite{EllardLedlie2003}. This paper also takes the stance that since the use of technology has expanded and evolved, this fundamental change in workloads needs to be traced to observe and understand the behavior. "We believe that as the community of computer users has expanded and evolved there has been a fundamental change in the workloads seen by file servers, and that the research community must find ways to observe and measure these new workloads."~\cite{EllardLedlie2003} Some of the contributions of this paper include new techniques for analyzing NFS traces along with tools to gather new anonymized NFS traces. Leung \textit{et al.} (as well as Ellard \textit{et. al.}) also observed that much of the variance of load characterization statistics over time can be explained by high-level changes in the workload over time; despite, this correlation having been observed in many trace studies, its effects are usually ignored~\cite{EllardLedlie2003}. The most noticeable change in their traces was the difference between peak and off-peak hours of operation. This finding conveyed that time is a strong predictor of operation counts, amount of data transferred, and the read-write ratios for their CAMPUS (e.g. email) workload. +% +%\subsection{Ellard 2003} +%\label{Ellard 2003} +%This paper shows that the technology being actively researched gains improvement faster and that the technology that is not improved will end up being the bottleneck of the system. Ellard and Seltzer give the example of how file system performance is steadily losing ground relative to CPU, memory, and even network performance. Even though Ellard and Seltzer began their efforts to accurately measure the impact of changes to their system, they also discovered several other phenomena that interacted with the performance of the disk and file system in ways that had far more impact on the overall performance of the system than their improvements~\cite{Ellard2003}. This paper loosely groups all benchmarks into two categories: micro benchmarks and macro/workload benchmarks, the difference between these two being that micro benchmarks measure specific low-level aspects of system performance while workload benchmarks estimate the performance of the system running a particular workload. +% +%\subsection{Leung 2008 Paper} +%\label{Leung 2008 Paper} +%Comparison of file access patterns (RO, WO, RW) +%\begin{itemize} +% \item 1. Workloads more write-heavy than previously seen +% \item 2. RW access patterns much more frequent +% \item 3. Bytes transferred in much longer sequential runs +% \item 4. Bytes transferred from much larger files +% \item 5. Files live order of magnitude longer +% \item 6. Most files not reopened once closed; If file re-opened, temporally related to previous closing of file +%\end{itemize} +%Files are infrequently shared by more than one client; over 76\% files never opened by more than one client. +%File sharing rarely concurrent and usually read-only; 5\% of files opened by multiple client are concurrent and 90\% of sharing is read only +%\textit{Compared to Previous Studies} +%\begin{itemize} +% \item 1. Both of our workloads are more write-oriented. Read to write byte ratios have significantly decreased. +% \item 2. Read-write access patterns have increased 30-fold relative to read-only and write-only access patterns. +% \item 3. Most bytes are transferred in longer sequential runs. These runs are an order of magnitude larger. +% \item 4. Most bytes transferred are from larger files. File sizes are up to an order of magnitude larger. +% \item 5. Files live an order of magnitude longer. Fewer than 50\% are deleted within a day of creation. +%\end{itemize} +%\textit{New Observations} +%\begin{itemize} +% \item 6. Files are rarely re-opened. Over 66\% are re-opened once and 95\% fewer than five times. +% \item 7. Files re-opens are temporally related. Over 60\% of re-opens occur within a minute of the first. +% \item 8. A small fraction of clients account for a large fraction of file activity. Fewer than 1\% of clients account for 50\% of file requests. +% \item 9. Files are infrequently shared by more than one client. Over 76\% of files are never opened by more than one client. +% \item 10. File sharing is rarely concurrent and sharing is usually read-only. Only 5\% of files opened by multiple clients are concurrent and 90\% of sharing is read-only. +%\end{itemize} +%\textit{List of interesting data points (comes from 'Table 3: Summary of trace statistics')} +%\begin{itemize} +% \item Clients, Days, Data Read (GB), Data Written (GB), R:W I/O Ratio, R:W Byte Ratio, Total Operations +% \item Operation Names: Session Create, Open, Close, Read, Write, Flush, Lock, Delete, File Stat, Set Attribute, Directory Read, Rename, Pipe Transactions +%\end{itemize} +%\textit{Table 4: Comparison of file access patterns - This figure gives good show of Read-Only, Write-Only \& Read-Write} +%\\\textit{Observations:} +%\begin{itemize} +% \item 1) “Both of our workloads are more write-heavy than workloads studied previously” +% \item 2) “Read-write access patterns are much more frequent compared to past studies” +% \item 3) “Bytes are transferred in much longer sequential runs than in previous studies” +% \item 4) Bytes are transferred from much larger files than in previous studies +% \item 5) Files live an order of magnitude longer than in previous studies +% \item 6) Most files are not re-opened once they are closed +% \item 7) If a file is re-opened, it is temporally related to the previous close +%\end{itemize} +% +%\subsection{Orosz 2013 Paper} +%\label{Orosz 2013 Paper} +%\begin{itemize} +% \item 1. Primary bottleneck in current timestamp resolution provided by Kernel is large deviation of deneration (timestamp generation) overhead decreases timestamp precision +% \item 2. Simplifying the work of the kernel (i.e. time stamping process) will lead to lower packet loss +% \item 3. "In network measurement, the precision of timestamping is a criterion more important than the low clock offset, especially for measuring packet inter-arrival times and round-trip delays at one single point of the network (e.g., active probing)" +%\end{itemize} +% +%\subsection{Dabir 2008 Paper} +%\label{Dabir 2008 Paper} +%\begin{itemize} +% \item 1. "Since Dumpcap is a single threaded application, it was suspected that while it is busy writing to disk, because it is blocked by the I/O call, it is unable to handle newly arriving packets due to the small size of the kernel buffer which quickly fills up." +% \item 2. Increasing amount of kernel level buffer associated with capture socket could lead to better capture speeds with Dumpcap +%\end{itemize} +%\textit{Note}: While (item 1) could be a source of packet loss, until this is tested on a trace system do not assume this is a key limiting factor. It could be that by having Dumpcap write to RAM would alieviate this problem. If this is the case, Dabir \& Matrawy attempted to overcome this limitation by having synchronization between two threads (using two semaphores) where \textbf{one} thread would store/buffer incoming packets and the \textbf{second} thread would write the packet information to disk +% +%\subsection{Narayan 2010 Paper} +%\label{Narayan 2010 Paper} +%\begin{itemize} +% \item 1. Striping Data in parallel file system can bottleneck if file distribution parameters do not fit access patterns of applications +% \item 2. Parallel application have five major models of I/O +% \begin{itemize} +% \item 1. Single output file shared by multiple nodes by ranges +% \item 2. Large sequential read by single node at beginning of computation and large sequential write by single node at end of computation +% \item 3. Checkpointing of state +% \item 4. Metadata and read intensive - small data I/O, frequent directory lookups for reads +% \item 5. Each node outputs to its own file +% \end{itemize} +% \item 3. Distributing I/O across more nodes not decrease IATs because files striped across all nodes which causes any Read or Write to access all nodes +% \item 4. From Figure 5: As we see in the graphs and data provided, as the number of I/O nodes increases (as well as the number of processors/servers) the IATs decrease along with the number of I/O operations increase. This leads to a larger \% of IATs occuring at lower times (e.g. < 1ms) +% \item 5. From study on IATs, most parallel applications doing significant I/O increase the I/O frequency as the number of compute nodes increases. \textbf{However}, scaling I/O nodes alone causes issue because increased I/O load is transferred to each I/O storage node +% \item 6. "I/O access models that assume independence or randomness between requests are not valid" +%\end{itemize} +% +%\subsection{Skopko 2012 Paper} +%\label{Skopko 2012 Paper} +%\begin{itemize} +% \item 1. Software based capture solutions heavily rely on OS's packet processing mechanism +% \item 2. "Dumpcap itself uses relatively small system resources, however it is executed on a general purpose system that shares its resources between the running processes" +% \item 3. Drivers typically operate in two different modes: interrupt mode and polling mode; importance of modes is dual +% \begin{itemize} +% \item 1. timestamps generated at enqueueing process reflect that tiem instead of moment of arrival at physical layer +% \item 2. polling causes bursty packet forwarding, thus need for appropriate sized buffers to handle them +% \end{itemize} +% \item 4. Dumpcap has option called \textit{snaplength} to do truncation; compared to original measurement, smaller snaplength = fewer lost packets by Dumpcap +%\end{itemize} \section{Conclusion} \label{Conclusion}