High Performance Logging System for Embedded UNIX and GNU/Linux Applications
|
|
- Christopher Pope
- 8 years ago
- Views:
Transcription
1 High Performance Logging for Embedded UNIX and GNU/Linux lications Jaein Jeong Cisco s San Jose, California 95134, USA jajeong@cisco.com Abstract We present a high performance logging system for embedded UNIX and GNU/Linux applications. Compared to the standard UNIX and GNU/Linux logging method, syslog, our method has two orders of magnitude lower latency and an order of magnitude higher message throughput. This speed-up is mainly due to the use of a memory-mapped file as the means of interprocess communication, fewer memory copies and the batching of output messages in the logging daemon. In addition, our logging system also accepts syslog messages, providing compatibility with existing applications. Our logging system is in production use in the Cisco UCS Virtual Interface Card. I. INTRODUCTION Logging is a helpful tool for analyzing the behavior of computer systems and applications. By analyzing a sequence of events in a log, one can see whether computer systems or applications behave properly. In production environments logs are even more important and may be the only way to analyze system problems. In this paper, we focus on logging systems for embedded UNIX applications (we will use UNIX to refer to all UNIX-like systems including GNU/Linux). Traditional UNIX applications log messages by writing them over a socket to a system daemon which then writes the messages to log files and/or forwards them to peers running on remote hosts. The system daemon is and the application library interface is syslog. There are two performance problems with this design. The first is the time it takes for an application to transmit a message to. The second is the inefficiency of writing messages to a file one at a time using unbuffered writes. These unbuffered writes are not a big problem on a conventional file system using a hard disk (the file system buffer cache reduces disk I/O and hard drives are fast compared to flash memory), but are very slow when writing to flash memory using a flash memory file system. The first of these problems increases application response times when there are many messages to log. The second reduces the number of messages that can be logged per second by at least an order of magnitude, and also increases the application response time as no new messages may be transmitted to while it is writing the previous message. In order to address these performance problems, we developed a logging method that uses shared memory to transfer messages to the system logging daemon and briefly buffers received messages before writing them to permanent storage. In our logging method, application processes create log messages by writing into a shared memory segment. A write lock is used to ensure applications don t conflict with one another as they write into the shared memory. A logging daemon retrieves messages from the shared memory segment and dispatches them to one or more destinations, such as permanent local storage, a remote daemon, or a dynamically connectable network client. We note that our logging method drops incoming messages when the shared memory becomes full due to a burst of incoming messages. This trade-off was made to meet real-time requirements for applications. After a message is written to the shared memory, the logging daemon must be notified. This is done by writing to a pipe. The logging daemon waits on the receiving end of the pipe and wakes up when data (i.e. a message notification) is available. Event-driven applications may defer notification until their event handler completes. This has two positive effects, the most important of which is reducing the notification overhead from once per message to once per handler invocation. It also defers the cost of notification until the handler has completed its work. Finally, when the logging daemon is running it sets a flag in the shared memory area indicating that (since it s already running) it doesn t need to be notified. As the logging daemon processes each message, those that go to a network destination (either a remote or a dynamic log viewer) are sent to the destination immediately. Those to be stored locally are formatted into their final text representation and written via a pipe to a buffering process, flashlogger. After the first message that arrives when its buffer is empty, flashlogger waits for up to.5 seconds for additional messages. After the wait period or sooner if its buffer fills up, flashlogger writes its buffered messages to flash and resumes waiting for additional messages. This buffering reduces the number of writes to local storage and enables a much higher overall throughput than obtained by writing each message to storage individually. In addition to forwarding to remote processes, the logging daemon also accepts syslog messages from local (only) applications. This provides full compatibility for existing applications. Messages received via the syslog interface are dispatched the same way (i.e. according to their priority and possibly source) as messages received via the shared memory segment. In our embedded environment with flash storage, our log-
2 2 ging system is almost two orders of magnitude faster for an application than syslog. This is because logging a message only involves user-space memory copying without a context switch. The maximum message throughput (how many can be saved per second before having to drop or throttle messages) with the buffering is over an order of magnitude greater. The rest of this paper is organized as follows. In Sections II and III, we review previous work and the evolution of logging systems on which our work is based. We describe the design principles and the implementation details for our logging method in Sections IV and V. We evaluate the performance in Section VI, describe a further optimization in Section VII and conclude this paper in Section VIII. II. RELATED WORK Introduced in BSD in the early 198 s, syslog [1], [2] is still the most notable logging method for UNIX applications due to its simplicity, flexibility and public availability. This is exemplified by a number applications that use or extend it [3] [9]. In order to provide more features, a number of extensions of syslog have been implemented. Syslog-ng [1] and rsyslog [11] are two of the most popular ones [12] [14]. Syslog-ng is an extension of syslog that was created to support the original BSD syslog protocol [1] from another syslog extension, n [15]. Its goals are to provide additional features such as reliable transport, encryption, and richer set of information and filtering. Over time, it has evolved to support the latest syslog protocol [2] and is used by several UNIX distributions. Rsyslog [11] is another wellknown extension of syslog and is being used in many of latest Linux distributions. Rsyslog extends syslog not only in features but also in performance with a multi-threaded implementation. By using threads it avoids the problem of blocking the acceptance of new messages while writing previously received messages. However, these existing systems are not designed for embedded/flash logging and they use the same fundamental design in their message handling and thus have the same limitations when used for embedded flash logging as mentioned in Section I: (i) slow message passing due to message copying over the kernel to user space boundary, and (ii) unbuffered writes of messages to output devices. In the next section, we describe our shared-memory logging methodology and shows how it addresses the performance problems of existing logging systems. III. CISCO UCS VIRTUAL INTERFACE CARD AND EVOLUTION OF LOGGING SYSTEM In this section, we introduce the Cisco UCS Virtual Interface Card and explain how its logging system evolved based on design requirements and experience using it. A. Cisco UCS Virtual Interface Card Cisco Unified Computing (UCS) [16] is a datacenter server system that enables large deployments of virtualized servers with scalable performance through hardwareaccelerated I/O virtualization. Cisco UCS mainly consists of the following components: servers, virtualization interface cards and switches. A UCS server provides computation capability, and it can be used for a computation-intensive single server or a number of virtualized servers. A UCS virtual interface card [17], or VIC, is a high-speed network interface card for a UCS server, and one of its key features is support of virtual network interfaces (VNICs). To the server, a VNIC is seen as a separate device with a unique PCI bus ID and separate resources. To the network, it is seen as a network frame with a special tag, called VN-Tag. Thus, it is treated by a server in the same way as other PCI devices and does not cause any overhead for translation. A VIC is implemented by an ASIC that consists of a management processor, two fiberchannel processors, VNIC resources and resource mappings. The management processor, which the firmware runs on and is the target of our logging system, has a 5MHz MIPS 24Kc processor core and runs Linux kernel rc5. B. Evolution of VIC Logging logd - A Simple Logging Daemon: We initially wrote logd, a simple logging daemon that accepts messages with different severity levels from multiple processes through IPC calls, formats the message and writes the formatted output message to flash storage using stdio functions. Although it is very simple, logd achieved its goals with reasonable performance. Since writes through stdio functions are buffered, logd was able to write messages reasonably quickly most of the time. Unbuffered : logd served its purpose well enough at first, but there came a need to support forwarding serious errors to on the UCS switches. Instead of extending logd with such a feature, we decided to use, which of course already has the feature. Using achieved the immediate goal but its write performance was much worse because writes log messages without buffering them. Buffered : In order to address the write performance problem of we introduced a buffering process, called flashlogger, between and the flash storage. flashlogger has an adjustable wait time (currently half a second) to collect messages before it writes out what it has collected. However, if its buffer fills up before the wait time has passed, it goes ahead and writes out the buffer immediately. This combination of and flashlogger was used for the logging system for VIC until we developed the new logging system that is introduced in this paper. A. Faster Message Transfer IV. DESIGN REQUIREMENTS A representation of is shown in Figure 1(a). The round-trip time between a user application process and the process is typically around 7us on average and has been observed as high as 13,us under heavy load. This is not a small number for a modern computing system. The reason why accessing takes a long time is because
3 3 Switch Switch Switch Switch log log log syslog Flash Logger Flash JFFS2 log mqlogd log dequeue log enqueue Memory Mapped File Flash Logger Flash JFFS2 USER USER KERNEL Buffer Named pipe KERNEL Named pipe (a) Typical UNIX Logging (b) Shared Memory Logging Fig. 1. Data Flow of Log Messages it requires passing data between user and kernel spaces and context switches between the application and. In order to address the long round-trip problem of, we designed a logging scheme that does not require message transfer between user and kernel spaces in its critical data path, as illustrated in Figure 1(b). With this scheme, an application or system process uses the same logging API to log a message. The message is copied to shared memory by the log functions and forwarded to the flash memory or a remote host by a message collector mqlogd. Since the shared memory is allocated in user space, message transfer can be very fast once the shared memory section is initialized. Thus, a user or system application is finished logging right after it writes a message to the shared memory instead of waiting for the reply from the message collector, and this improves latency. The faster message transfer of the shared memory logging is also attributable to the number of times a message is copied in memory, which is a significant factor for message transfer time. With, a message is copied four times in memory: first, it is formatted into a user buffer; second, it is written from the user buffer to a kernel socket; third, it is read from the kernel socket to a user buffer; and fourth, it is written from the user buffer to a file. With the shared memory logging, the number reduces to two. A process that logs a message formats the message into the shared memory. Since the logging daemon accesses the shared memory, the first three message copies in are reduced to a single message copy. B. Compatibility with Existing Logging lications VIC applications use the following logging macros: log_info, log_debug, log_warn, and log_error. These macros format input strings and previously made syslog calls. lications that use these logging macros were converted to shared-memory-based logging without modification of application code by changing the syslog calls to message copies to the shared memory. However, there are some applications that directly call syslog without using the logging macros. Therefore the logging daemon of our logging system also accepts messages intended for. This allows existing applications that use to be used with our logging system without modifications. One such application is klogd. C. Output Flash File The program for VIC used the flashlogger program to buffer messages, and our logging system takes the same approach. D. Support of Destination-Aware Message Formatting One of the advantages of is that it allows log messages to be sent to multiple destinations of different types, where a destination may be a simple file, a named pipe or a socket on a remote host. However, there is a drawback. uses the same data representation shown in Figure 2 for all destinations. This representation has two problems. The first problem is inefficiency. The string representation of date and time requires more space than a binary or simpler text representation. In addition, the host name is redundant for flash logs because all of the events that are stored in the flash memory are local and are from the same host. The second problem is loss of precision. The message format specifies the time of a log message at a granularity of seconds, while the system supports timing in milliseconds. Logging data is more useful with more precise timings. Our logging system formats messages differently depending on the destination. For remote forwarding, it outputs log messages in the same way as the current Cisco version of does for compatibility. For writing to flashlogger, it changes the message format to use a higher precision timestamp while omitting the hostname.
4 4 Format: DateStr TimeStr Host app.module[pid] : Message Example: Mar 9 15:53:23 simserv1 log.logtest[16665]: This is a message Fig. 2. Message format for logperf log mq CLIENT Client Utility (an example) Receives API call Data Transfer Shared Memory Management Queue Management Memory Mapped File Outputs Log mqlogd Data Transfer SERVER mq logger CLIENT Client Utility (an example) syslog() system call UDP Unix Socket Shared Memory Management Queue Management Message Formatting Named Pipe UDP IP Socket TCP IP Socket OUTPUT UTILITY Flash logger OUTPUT UTILITY Local Logging Remote netcat Forwarding OUTPUT UTILITY Dynamic Remote Forwarding Header Entry (48B in size) Flag (1B) Unused Head Tail (3B) (4B) (4B) Data Entry (48B in size) Log Lvl (2B) Msg Length (2B) PID (4B) Timestamp (8B) Reader Mutex PID (2B) (4B) Prog Name (16B) Data Entry only with Msg String (48B in size) Msg String (48B) Unused Logging ID (16B) Fig. 3. Program Modules for the mqlogd Logging Service Queue Memory Layout Offset A. Platform V. IMPLEMENTATION While our logging method can be used for any UNIX system that does logging, it is especially designed for the embedded firmware for the Cisco UCS Virtual Interface Card [17] where low-latency logging is desirable and the storage medium log files are written to is slow. Header Entry (48B) Non-Header Entry (48B) Non-Header Entry (48B) Non-Header Entry (48B) 1 * BlockSize 2 * BlockSize (N-1) * BlockSize B. Modular Description Our logging method consists of a core library, server modules, client modules and output utilities as illustrated in Figure 3. The module mq, which is in charge of managing the memory-mapped file, the circular queue, and message formatting, is made as a library that can be used by both a logging daemon and clients. The logging daemon, mqlogd, accepts logging messages either through the shared memory or a UDP UNIX socket, and it outputs messages through the named pipe or a UDP IP socket. The client modules receive logging requests in a printf-like format and insert them into the shared memory. As for the client utilities, we consider two different kinds depending on how they submit logging requests: one uses shared memory and the other uses the syslog library call and UDP UNIX socket. Output utilities are connected to the server through a named pipe, a UDP IP socket, or a TCP IP socket. The named pipe interface is for a program such as flashlogger that stores logging messages locally. The UDP IP socket interface is to forward messages to the process on the switch. The server also supports dynamic remote forwarding through a TCP IP socket interface. This interface is different from the UDP IP socket interface in that it dynamically maintains forwarding destinations to a client such as netcat on a remote host. Fig. 4. Memory Layout of the Circular Queue C. Shared Memory and Circular Queue Management 1) Data Representation: The shared memory is used as an array of fixed-sized blocks that are managed as a circular queue as illustrated in Figure 4. The first block in the memorymapped file is used as the header entry, which contains all the bookkeeping information for the circular queue and the logging service. The rest of the blocks are data entries, which contain the information for each logging message. Just after each message header, the message uses as many blocks as it needs for the message string. The length of the message string is specified in the message length field in the first data entry. Since data entries are consecutive, we can handle multiple segments of message string fields like a single field by pointing to the starting address of the first message string field. However, there is an exception to this. When a sequence of data entries roll around the end of the memory-mapped file, we cannot treat the message string as consecutive memory. In that case, the message string must be handled as two pieces: the first one is from the beginning of the message string and to the end of the memory-mapped file, the second one is from the beginning of the memory-mapped file and the location where
5 5 the last data entry ends. Thus, a message string can be handled as one or two consecutive byte arrays. 2) Notification Mechanism: The queue management module notifies the logging daemon when a client writes a logging message in the queue or when the queue is full. It implements two different methods for client-to-server notification: one using write-and- (the default) and the other with a signal. Each time a client writes a logging message to the memorymapped file, it checks whether it should notify the logging daemon. If the daemon sets the notify flag in the header entry, the client does not send a notification. If the daemon clears the notify flag, the client sends a data-available command, which makes the daemon retrieve all the logging messages in the queue. This notification batching mechanism suppresses redundant notifications and helps improve the latency and throughput for message passing and dispatch. The client also sends a queue-full notice when it detects that the queue is full. It then drops the message. This makes the daemon output a queue-full message to the destinations in order to mark that there was a drop. 3) Locking Mechanism: The queue management module uses a locking mechanism in order to maintain the consistency of the circular queue. It implements two different mechanisms: semaphore lock and pthread mutex lock. The semaphore lock is a set of lock functions based on the Linux semaphore API. While it is not really fast due to a kernel access for each lock or unlock operation, it is widely supported. The pthread mutex lock uses the Linux pthread API. While it is faster than the semaphore lock, it is unreliable for inter-process use in our current version of Linux. Thus, the deployed queue management module uses the semaphore lock. D. Client Logging Interface Client applications in the original logging system first initialized application-wide logging objects before they called one of the logging macros (log_info, log_debug, log_warn, and log_error). This two-step approach fits well to the shared memory based logging and allowed existing applications to be converted to the new logging without modification of application code. In order to handle syslog messages the logging daemon waits on the UNIX socket at /dev/log, adding received messages to the circular queue. This functionality provides the same application interface as syslog, allowing clients for syslog to be used with the shared memory logging without any modification. E. Server Output Interface After receiving each logging message, the logging daemon formats it and outputs the formatted message to the internal flash storage logger. For a logging message with a high priority level (i.e. error or warn), the logging daemon also outputs the formatted message to a UDP socket on remote hosts. By default, the daemon sends the formatted message string to UDP port 514 of the two switches to which a UCS Virtual Interface Card is attached. Since UDP port 514 is a designated port for, this makes the syglogd processes on the switches receive the message. In order to support dynamic remote forwarding, the logging daemon listens to a TCP port. When a client on a remote host makes a TCP connection to this port, the daemon adds the file descriptor of the TCP connection to a pool of active TCP connections. For each incoming logging message, the daemon formats the message and sends it to clients in the pool. When a remote client disconnects the TCP connection, any attempt to send a message to the client generates a file error. The daemon detects this as an inactive TCP connection and removes the file descriptor from the pool. The dynamic remote forwarding may look similar to the UDP port forwarding, but these two methods are designed for different purposes. The UDP port forwarding sends high-priority messages to the switches and is always enabled. The TCP dynamic remote forwarding, which is designed for easy debugging, sends messages of all priority levels and is enabled only on explicit requests to avoid unnecessary overhead. A. Experiment Set-up VI. EVALUATION 1) Metrics: For evaluation, we measured the performance of our shared memory-based service (mqlogd) and for two metrics request latency and drop rate: Request Latency: We measured statistics (average, minimum, and maximum) for the request latency by repeating a logging message multiple times for each set of parameters. Among these statistics, average and maximum request time are more interesting because they show the expected and worst-case service times. Request Drop Rate: We also measured the request drop rate. has a zero drop rate at the sacrifice of latency, which is an order of magnitude higher. In contrast, the mqlogd logging service drops requests under high load. By measuring the request drop rate for various sets of parameters, we will show the conditions where the mqlogd logging service achieves lower request latency while achieving a zero or acceptably low drop rate. 2) Parameters: For performance comparison of mqlogd and, we varied the number of clients and number of iterations for both logging services: Number of clients - 1 and 2: Changing the number of clients gives the lower bound for performance (a single client) and shows system performance as contention increases (two clients). No more than 2 clients were measured because most of the time, there is only one client logging messages. Number of iterations - 1, 1, 5, 1, and 5: Currently, the queue size of the system is set to 124 items. In this test, we see how our logging service module behaves with different numbers of requests. For all of the measured configurations, five iterations were run.
6 6 For evaluating the most suitable design out of a few design variations, we measured the performance while varying the following parameters locking mechanism and notification mechanism: Locking Mechanism - semaphore lock and pthread mutex lock: The purpose of this test is to see how the semaphore lock performs compared to the pthread mutex lock and how it performs when we change various parameters. Notification Mechanism - signal vs. write-and-: While both signals and write-and- are legitimate ways of notifying the server, signals may have side effects when used with the VIC library code. Thus, the purpose of this test is to see how write-and- performs relative to signal, which has a smaller latency. B. Performance Results As for the average request latency, mqlogd showed more than 1-times speed-up for all configurations compared to. 1) Effects of Notification and Lock Mechanisms: For notification mechanisms, the measurements showed little difference between the implementation with write-and- and the one with signal. In addition, signals cause problems with VIC library. This made us use write-and-. For lock mechanisms, the implementation with the pthread mutex lock was about 4% faster than the one with the semaphore lock. This implies that we can easily get an additional 4% improvement by replacing calls to the semaphore lock with the pthread mutex lock when a working version is available. As for minimum request latency, mqlogd showed more than 2-times speed-up for all its configurations: 25- times speed-up for semaphore lock implementations and 4- times speed-up for pthread mutex lock implementations compared to. As for maximum request latency, mqlogd showed more than a 2x speed-up for all its configurations: by a factor of 2.3 for semaphore lock implementations and 4. for pthread mutex lock implementations compared to. 2) Effects of Queue Size: While did not drop requests, mqlogd dropped logging messages for a burst longer than or equal to 1 (the queue size), and this became more severe as there were more requests. We can see that we need to have the queue size larger than the maximum expected size of a burst to avoid drops. 3) Effects of Multiple Clients: We measured the request latency and the request drop rate for both one and two clients. As for the average request latency, we have observed that having two clients makes about a factor of two increase. This ratio gets higher when the number of requests is larger than the size of queue as in the case of 5 iterations. This shows that setting the queue size is important to have the performance bounded unsurprisingly. We notice that with two clients the request starts to drop with with smaller number of iterations than the case with a single client. Latency (us) Average Request Latency 1 Client mqlogd (, mqlogd (, mqlogd(signal, # - Iterations mqlogd (, mqlogd (, Speed-up over mqlogd (, mqlogd (, Fig Average Request Latency for a Single Client 4) Effects of Client Interface Type: We evaluated the performance of our logging system using the UNIX socket interface and compared it with the performance with shared memory. For reference, we compared this with the performance of. The experiment results are shown in Figure 11. We find that the average latency with the UNIX socket is more than an order of magnitude longer on average than that with the shared memory and about the same level as that of. While we provided the UNIX socket interface for compatibility reasons, the use of the UNIX socket interface (e.g., syslog) should be minimized to achieve the best performance. VII. OPTIMIZATION We have shown that mqlogd provides a logging service that is at least 1 times faster than by using user-space
7 7 Latency (us) Minimum Request Latency 1 Client mqlogd (, mqlogd (, mqlogd(signal, Latency (us) 4.5 x Maximum Request Latency 1 Client mqlogd (, mqlogd (, mqlogd(signal, # - Iterations mqlogd (, mqlogd (, Speed-up over mqlogd (, mqlogd (, Fig Minimum Request Latency for a Single Client # - Iterations mqlogd (, mqlogd (, Speed-up over mqlogd (, mqlogd (, Fig Maximum Request Latency for a Single Client shared memory as the means of inter-process communication. In this section, we discuss a notification mechanism that can improve this speed-up even further. A. Deferred Notification Mechanism In order to improve the processing time of logging requests, we introduce the deferred notification mechanism. With deferred notification, a logging client sends one notification for a batch of messages rather than sending a separate notification for each message. Deferred notification is expected to give a smaller latency than per-message notification, but it has a restriction in that it requires an application to determine an appropriate time to send notifications. This is easy for most applications in VIC because they are event driven and the completion of an event handler is a very suitable time to send a notification. B. Host-Side Round-Trip Time Measurement In this section, we compare the performance of the deferred notification mechanism by measuring the round-trip time from the host. To make this measurement, we execute a program called devcmd on the host. The devcmd program sends queries to the main firmware application, which may produce logging messages, and measures the total latency from the perspective of the host. Using devcmd is useful because the latency on the host side is the latency a user of VIC (i.e., a network driver) will experience. The devcmd program allows a user to specify a command to issue, and each command results in a different action in
8 Request Drop Rate 1 Client mqlogd (, mqlogd (, mqlogd(signal, Average Request Latency 1 and 2 Clients (1 client) (2 clients) mqlogd (, 1 client) mqlogd (, 2 clients) 7 14 Percent # - Iterations mqlogd (,.%.%.% 21.2% 8.%.%.%.% 27.7% 83.1% mqlogd (,.%.%.% 35.% 86.7%.%.%.% 39.3% 87.6% Fig. 8. Request Drop Rate for a Single Client firmware. Firmware processes the received command and logs messages when the minimum threshold for logging is set to the debug level. When the minimum threshold is set to the info level, firmware processes a received command without logging messages. The difference in the round-trip time between the two modes is the logging time for the specified command. The parameters we considered are summarized as follows: Notification mechanisms: write-and-, deferred and Commands: macaddr (gets the MAC address) and capability (checks availability of a given command) Minimum threshold for logging: info and debug Figure 12 shows the latency for the capability command. Figure 12(a) is the graph for total latency for all combinations of notification mechanisms and minimum threshold levels. As expected, the total latencies for the three notification mechanisms are very close when there is no logging. For total latencies with a minimum logging threshold of debug, we see differences among the notification mechanisms. Since the difference in latency between the debug level and the info level is the time to process logging messages, we can quantify the cost of each notification mechanism. Figure 12(b) shows that mqlogd with the deferred notification mechanism achieves more than 2x speed-up compared to the one with write-and-. Figure 13 shows the latency for the macaddr command. Latency (us) # - Iterations ( client) ( clients) mqlogd (, client) mqlogd (, clients) mqlogd (signal client) mqlogd (signal 2 clients) Speed-up over client mqlogd () mqlogd (signal) Fig. 9. Average Request Latency for Two Clients We see that the ratio among each notification mechanism is similar to that Figure 12; mqlogd with the deferred notification mechanism achieves about 2x speed-up compared to the one with write-and-. The difference is that absolute values of latency for macaddr are smaller than those for capability because macaddr is a trivial command it s essentially retrieving 4 bytes. VIII. CONCLUSION We presented a logging system for embedded UNIX applications that provides faster logging times than, while providing application-level interface compatibility. It achieves almost two orders of magnitude speed-up in latency and an order of magnitude improvement in message throughput. This
9 9 Time (us) Total Latency for capability Command Average (us) deferred deferred Time (us) Logging Latency for capability Command Logging Time (us) deferred (a) Total Latency (b) Logging Latency Fig. 12. Latency for the Capability Command 1 Total Latency for macaddr Command Average (us) 1 Logging Latency for macaddr Command Logging Time (us) Time (us) 5 Time (us) 5 deferred deferred deferred (a) Total Latency (b) Logging Latency Fig. 13. Latency for the Macaddr Command Request Drop Rate 1 and 2 Clients mqlogd (, 1 client) mqlogd (, 2 clients) as. ACKNOWLEDGMENTS I would like to thank my colleagues at Cisco, Jim Orosz, Brad Smith, Puneet Shenoy and James Dong for having fruitful discussions and helping edit and proofread this paper. Percent # - Iterations mqlogd (,.%.%.% 21.2% 8.% 1 client) mqlogd (,.%.% 1.% 45.7% 91.9% 2 clients) Fig. 1. Request Drop Rate for Two Clients speed-up is attributed to the use of user-level shared memory as the means of inter-process message communication. It also supports the syslog interface, allowing system applications that use syslog to be interoperable without additional modifications while achieving about the same level of performance REFERENCES [1] C. Lonvick, The BSD Syslog Protocol, rfc3164. [2] R. Gerhards, The Syslog Protocol, rfc5424. [3] T. Qiu, Z. Ge, D. Pei, J. Wang, and J. Xu, What happened in my network: mining network events from router syslogs, in Proceedings of the 1th ACM SIGCOMM conference on Internet measurement (IMC 1), ACM, November 21. [4] K. Slavicek, J. Ledvinka, M. Javornik, and O. Dostal, Mathematical processing of syslog messages from routers and switches, in Proceedings of the 4th International Conference on Information and Automation for Sustainability (ICIAFS 28), IEEE, December 28. [5] M. Bing and C. Erickson, Extending unix system logging with sharp, in Proceedings of the 14th s Administration Conference (LISA 2), USENIX, December 2. [6] M. Hutter, A. Szekely, and J. Wolkerstorfer, Embedded system management using wbem, in IFIP/IEEE International Symposium on Integrated Network Management, 29 (IM 9), IEEE, June 29. [7] T. Park and I. Ra, Design and evaluation of a network forensic logging system, in Convergence and Hybrid Information Technology, 28. ICCIT 8. Third International Conference on, vol. 2, pp , IEEE, 28. [8] M. Roesch et al., Snort-lightweight intrusion detection for networks, in Proceedings of the 13th USENIX conference on administration, pp , Seattle, Washington, [9] M. Schütte, Implementation of ietf syslog protocols in the netbsd, 29. [1] B. Scheidler, syslog-ng. syslog-ng. [11] R. Gerhards, rsyslog.
10 Average Request Latency 1 Client mqlogd (, mqlogd (Unix socket) Latency (us) # - Iterations mqlogd (, mqlogd (UNIX socket) Speed-up over mqlogd (, mqlogd (UNIX socket) Fig. 11. Average Request Latency for a Single Client with Different Client Interfaces [12] A. Tomono, M. Uehara, M. Murakami, and M. Yamagiwa, A log management system for internal control, in Network-Based Information s, 29. NBIS 9. International Conference on, pp , IEEE, 29. [13] F. Nikolaidis, L. Brarda, J.-C. Garnier, and Nikifeld, A universal logging system for lhcb online, International Conference on Computing in High Energy and Nuclear Physics (CHEP 21), October 21. [14] J. Garnier, Lhcb online log analysis and maintenance system, in Proceedings of the 13th International Conference on Accelerator and Large Experimental Physics Control s, October 211. [15] D. Reed, n. avalon/nsyslog.html. [16] S. Gai, T. Salli, and R. Andersson, Project California: a Data Center Virtualization Server UCS (Unified Computing ). lulu.com, March 29. [17] Cisco s, Cisco UCS M81KR Virtual Interface Card Data Sheet. data sheet c html.
Network Attached Storage. Jinfeng Yang Oct/19/2015
Network Attached Storage Jinfeng Yang Oct/19/2015 Outline Part A 1. What is the Network Attached Storage (NAS)? 2. What are the applications of NAS? 3. The benefits of NAS. 4. NAS s performance (Reliability
More informationThe Lagopus SDN Software Switch. 3.1 SDN and OpenFlow. 3. Cloud Computing Technology
3. The Lagopus SDN Software Switch Here we explain the capabilities of the new Lagopus software switch in detail, starting with the basics of SDN and OpenFlow. 3.1 SDN and OpenFlow Those engaged in network-related
More informationLog Management with Open-Source Tools. Risto Vaarandi SEB Estonia
Log Management with Open-Source Tools Risto Vaarandi SEB Estonia Outline Why use open source tools for log management? Widely used logging protocols and recently introduced new standards Open-source syslog
More informationKiwi SyslogGen. A Freeware Syslog message generator for Windows. by SolarWinds, Inc.
Kiwi SyslogGen A Freeware Syslog message generator for Windows by SolarWinds, Inc. Kiwi SyslogGen is a free Windows Syslog message generator which sends Unix type Syslog messages to any PC or Unix Syslog
More informationEUROPEAN ORGANIZATION FOR NUCLEAR RESEARCH CERN ACCELERATORS AND TECHNOLOGY SECTOR A REMOTE TRACING FACILITY FOR DISTRIBUTED SYSTEMS
EUROPEAN ORGANIZATION FOR NUCLEAR RESEARCH CERN ACCELERATORS AND TECHNOLOGY SECTOR CERN-ATS-2011-200 A REMOTE TRACING FACILITY FOR DISTRIBUTED SYSTEMS F. Ehm, A. Dworak, CERN, Geneva, Switzerland Abstract
More informationLog Management with Open-Source Tools. Risto Vaarandi rvaarandi 4T Y4H00 D0T C0M
Log Management with Open-Source Tools Risto Vaarandi rvaarandi 4T Y4H00 D0T C0M Outline Why do we need log collection and management? Why use open source tools? Widely used logging protocols and recently
More informationUsing Debug Commands
Using Debug Commands This chapter explains how you use debug commands to diagnose and resolve internetworking problems. Specifically, it covers the following topics: Entering debug commands Using the debug?
More informationUsing Debug Commands
C H A P T E R 1 Using Debug Commands This chapter explains how you can use debug commands to diagnose and resolve internetworking problems. Specifically, it covers the following topics: Entering debug
More informationCommunication Protocol
Analysis of the NXT Bluetooth Communication Protocol By Sivan Toledo September 2006 The NXT supports Bluetooth communication between a program running on the NXT and a program running on some other Bluetooth
More informationConfiguring Syslog Server on Cisco Routers with Cisco SDM
Configuring Syslog Server on Cisco Routers with Cisco SDM Syslog is a standard for forwarding log messages in an Internet Protocol (IP) computer network. It allows separation of the software that generates
More informationA Comparative Study on Vega-HTTP & Popular Open-source Web-servers
A Comparative Study on Vega-HTTP & Popular Open-source Web-servers Happiest People. Happiest Customers Contents Abstract... 3 Introduction... 3 Performance Comparison... 4 Architecture... 5 Diagram...
More informationUsing Debug Commands
CHAPTER 1 Using Debug Commands This chapter explains how you use debug commands to diagnose and resolve internetworking problems. Specifically, it covers the following topics: Entering debug commands Using
More informationWhite Paper. Real-time Capabilities for Linux SGI REACT Real-Time for Linux
White Paper Real-time Capabilities for Linux SGI REACT Real-Time for Linux Abstract This white paper describes the real-time capabilities provided by SGI REACT Real-Time for Linux. software. REACT enables
More informationPerformance Guideline for syslog-ng Premium Edition 5 LTS
Performance Guideline for syslog-ng Premium Edition 5 LTS May 08, 2015 Abstract Performance analysis of syslog-ng Premium Edition Copyright 1996-2015 BalaBit S.a.r.l. Table of Contents 1. Preface... 3
More informationReporting Guide for Novell Sentinel
www.novell.com/documentation Reporting Guide for Novell Sentinel Identity Manager 4.0.2 November 2012 Legal Notices Novell, Inc., makes no representations or warranties with respect to the contents or
More informationAn Active Packet can be classified as
Mobile Agents for Active Network Management By Rumeel Kazi and Patricia Morreale Stevens Institute of Technology Contact: rkazi,pat@ati.stevens-tech.edu Abstract-Traditionally, network management systems
More informationCS 377: Operating Systems. Outline. A review of what you ve learned, and how it applies to a real operating system. Lecture 25 - Linux Case Study
CS 377: Operating Systems Lecture 25 - Linux Case Study Guest Lecturer: Tim Wood Outline Linux History Design Principles System Overview Process Scheduling Memory Management File Systems A review of what
More informationConfiguring System Message Logging
CHAPTER 25 This chapter describes how to configure system message logging on the Catalyst 2960 switch. Note For complete syntax and usage information for the commands used in this chapter, see the Cisco
More informationNetFlow Aggregation. Feature Overview. Aggregation Cache Schemes
NetFlow Aggregation This document describes the Cisco IOS NetFlow Aggregation feature, which allows Cisco NetFlow users to summarize NetFlow export data on an IOS router before the data is exported to
More informationNetwork Defense Tools
Network Defense Tools Prepared by Vanjara Ravikant Thakkarbhai Engineering College, Godhra-Tuwa +91-94291-77234 www.cebirds.in, www.facebook.com/cebirds ravikantvanjara@gmail.com What is Firewall? A firewall
More informationRed Condor Syslog Server Configurations
Red Condor Syslog Server Configurations May 2008 2 Red Condor Syslog Server Configurations This application note describes the configuration and setup of a syslog server for use with the Red Condor mail
More informationEight Ways to Increase GPIB System Performance
Application Note 133 Eight Ways to Increase GPIB System Performance Amar Patel Introduction When building an automated measurement system, you can never have too much performance. Increasing performance
More informationHave both hardware and software. Want to hide the details from the programmer (user).
Input/Output Devices Chapter 5 of Tanenbaum. Have both hardware and software. Want to hide the details from the programmer (user). Ideally have the same interface to all devices (device independence).
More informationNAT TCP SIP ALG Support
The feature allows embedded messages of the Session Initiation Protocol (SIP) passing through a device that is configured with Network Address Translation (NAT) to be translated and encoded back to the
More informationSimple Network Management Protocol
CHAPTER 4 This chapter gives an overview of (SNMP). It contains the following sections: Overview, page 4-1 SNMP Versioning, page 4-2 SNMP and Cisco Unified CM Basics, page 4-3 SNMP Basic Commands, page
More informationChapter 11 I/O Management and Disk Scheduling
Operating Systems: Internals and Design Principles, 6/E William Stallings Chapter 11 I/O Management and Disk Scheduling Dave Bremer Otago Polytechnic, NZ 2008, Prentice Hall I/O Devices Roadmap Organization
More informationOperating Systems Design 16. Networking: Sockets
Operating Systems Design 16. Networking: Sockets Paul Krzyzanowski pxk@cs.rutgers.edu 1 Sockets IP lets us send data between machines TCP & UDP are transport layer protocols Contain port number to identify
More informationGlobus Striped GridFTP Framework and Server. Raj Kettimuthu, ANL and U. Chicago
Globus Striped GridFTP Framework and Server Raj Kettimuthu, ANL and U. Chicago Outline Introduction Features Motivation Architecture Globus XIO Experimental Results 3 August 2005 The Ohio State University
More informationAutonomous NetFlow Probe
Autonomous Ladislav Lhotka lhotka@cesnet.cz Martin Žádník xzadni00@stud.fit.vutbr.cz TF-CSIRT meeting, September 15, 2005 Outline 1 2 Specification Hardware Firmware Software 3 4 Short-term fixes Test
More informationDatacenter Operating Systems
Datacenter Operating Systems CSE451 Simon Peter With thanks to Timothy Roscoe (ETH Zurich) Autumn 2015 This Lecture What s a datacenter Why datacenters Types of datacenters Hyperscale datacenters Major
More informationSCUOLA SUPERIORE SANT ANNA 2007/2008
Master degree report Implementation of System and Network Monitoring Solution Netx2.0 By Kanchanna RAMASAMY BALRAJ In fulfillment of INTERNATIONAL MASTER ON INFORMATION TECHNOLOGY SCUOLA SUPERIORE SANT
More informationEmerald. Network Collector Version 4.0. Emerald Management Suite IEA Software, Inc.
Emerald Network Collector Version 4.0 Emerald Management Suite IEA Software, Inc. Table Of Contents Purpose... 3 Overview... 3 Modules... 3 Installation... 3 Configuration... 3 Filter Definitions... 4
More informationConfiguring System Message Logging
CHAPTER 1 This chapter describes how to configure system message logging on the Cisco 4700 Series Application Control Engine (ACE) appliance. Each ACE contains a number of log files that retain records
More informationIP SLAs Overview. Finding Feature Information. Information About IP SLAs. IP SLAs Technology Overview
This module describes IP Service Level Agreements (SLAs). IP SLAs allows Cisco customers to analyze IP service levels for IP applications and services, to increase productivity, to lower operational costs,
More informationConfiguring Logging. Information About Logging CHAPTER
52 CHAPTER This chapter describes how to configure and manage logs for the ASASM/ASASM and includes the following sections: Information About Logging, page 52-1 Licensing Requirements for Logging, page
More informationPANDORA FMS NETWORK DEVICE MONITORING
NETWORK DEVICE MONITORING pag. 2 INTRODUCTION This document aims to explain how Pandora FMS is able to monitor all network devices available on the marke such as Routers, Switches, Modems, Access points,
More informationTop 10 Tips for z/os Network Performance Monitoring with OMEGAMON. Ernie Gilman IBM. August 10, 2011: 1:30 PM-2:30 PM.
Top 10 Tips for z/os Network Performance Monitoring with OMEGAMON Ernie Gilman IBM August 10, 2011: 1:30 PM-2:30 PM Session 9917 Agenda Overview of OMEGAMON for Mainframe Networks FP3 and z/os 1.12 1.
More informationSIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP)
1 SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) Mohammad S. Hasan Agenda 2 Looking at Today What is a management protocol and why is it needed Addressing a variable within SNMP Differing versions Ad-hoc Network
More informationIntroducing the Microsoft IIS deployment guide
Deployment Guide Deploying Microsoft Internet Information Services with the BIG-IP System Introducing the Microsoft IIS deployment guide F5 s BIG-IP system can increase the existing benefits of deploying
More informationImproving the Database Logging Performance of the Snort Network Intrusion Detection Sensor
-0- Improving the Database Logging Performance of the Snort Network Intrusion Detection Sensor Lambert Schaelicke, Matthew R. Geiger, Curt J. Freeland Department of Computer Science and Engineering University
More informationMonitoring PostgreSQL database with Verax NMS
Monitoring PostgreSQL database with Verax NMS Table of contents Abstract... 3 1. Adding PostgreSQL database to device inventory... 4 2. Adding sensors for PostgreSQL database... 7 3. Adding performance
More informationAn Introduction to Syslog. Rainer Gerhards Adiscon
An Introduction to Syslog Rainer Gerhards Adiscon What is Syslog? The heterogeneous network logging workhorse a system to emit/store/process meaningful log messages both a communications protocol as well
More informationµtasker Document FTP Client
Embedding it better... µtasker Document FTP Client utaskerftp_client.doc/1.01 Copyright 2012 M.J.Butcher Consulting Table of Contents 1. Introduction...3 2. FTP Log-In...4 3. FTP Operation Modes...4 4.
More informationSiteCelerate white paper
SiteCelerate white paper Arahe Solutions SITECELERATE OVERVIEW As enterprises increases their investment in Web applications, Portal and websites and as usage of these applications increase, performance
More informationLast Class: OS and Computer Architecture. Last Class: OS and Computer Architecture
Last Class: OS and Computer Architecture System bus Network card CPU, memory, I/O devices, network card, system bus Lecture 3, page 1 Last Class: OS and Computer Architecture OS Service Protection Interrupts
More informationLab 5.5 Configuring Logging
Lab 5.5 Configuring Logging Learning Objectives Configure a router to log to a Syslog server Use Kiwi Syslog Daemon as a Syslog server Configure local buffering on a router Topology Diagram Scenario In
More informationConfiguring SNMP. 2012 Cisco and/or its affiliates. All rights reserved. 1
Configuring SNMP 2012 Cisco and/or its affiliates. All rights reserved. 1 The Simple Network Management Protocol (SNMP) is part of TCP/IP as defined by the IETF. It is used by network management systems
More informationMicrosoft SQL Server 2012 on Cisco UCS with iscsi-based Storage Access in VMware ESX Virtualization Environment: Performance Study
White Paper Microsoft SQL Server 2012 on Cisco UCS with iscsi-based Storage Access in VMware ESX Virtualization Environment: Performance Study 2012 Cisco and/or its affiliates. All rights reserved. This
More informationSystem Message Logging
System Message Logging This module describes how to configure system message logging on your wireless device in the following sections: Understanding System Message Logging, page 1 Configuring System Message
More informationChapter 11 I/O Management and Disk Scheduling
Operatin g Systems: Internals and Design Principle s Chapter 11 I/O Management and Disk Scheduling Seventh Edition By William Stallings Operating Systems: Internals and Design Principles An artifact can
More informationSAN Conceptual and Design Basics
TECHNICAL NOTE VMware Infrastructure 3 SAN Conceptual and Design Basics VMware ESX Server can be used in conjunction with a SAN (storage area network), a specialized high speed network that connects computer
More informationUnless otherwise noted, all references to STRM refer to STRM, STRM Log Manager, and STRM Network Anomaly Detection.
TECHNICAL NOTE FORWARDING LOGS USING TAIL2SYSLOG MARCH 2013 The Tail2Syslog support script provides a method for monitoring and forwarding events to STRM using syslog for real-time correlation. Tail2Syslog
More informationInternet Firewall CSIS 4222. Packet Filtering. Internet Firewall. Examples. Spring 2011 CSIS 4222. net15 1. Routers can implement packet filtering
Internet Firewall CSIS 4222 A combination of hardware and software that isolates an organization s internal network from the Internet at large Ch 27: Internet Routing Ch 30: Packet filtering & firewalls
More informationThe virtualization of SAP environments to accommodate standardization and easier management is gaining momentum in data centers.
White Paper Virtualized SAP: Optimize Performance with Cisco Data Center Virtual Machine Fabric Extender and Red Hat Enterprise Linux and Kernel-Based Virtual Machine What You Will Learn The virtualization
More informationEnterprise Manager. Version 6.2. Administrator s Guide
Enterprise Manager Version 6.2 Administrator s Guide Enterprise Manager 6.2 Administrator s Guide Document Number 680-017-017 Revision Date Description A August 2012 Initial release to support version
More informationImplementing Network Attached Storage. Ken Fallon Bill Bullers Impactdata
Implementing Network Attached Storage Ken Fallon Bill Bullers Impactdata Abstract The Network Peripheral Adapter (NPA) is an intelligent controller and optimized file server that enables network-attached
More informationOracle Enterprise Manager
Oracle Enterprise Manager System Monitoring Plug-in for Oracle TimesTen In-Memory Database Installation Guide Release 11.2.1 E13081-02 June 2009 This document was first written and published in November
More informationRemoving The Linux Routing Cache
Removing The Red Hat Inc. Columbia University, New York, 2012 Removing The 1 Linux Maintainership 2 3 4 5 Removing The My Background Started working on the kernel 18+ years ago. First project: helping
More informationA Transport Protocol for Multimedia Wireless Sensor Networks
A Transport Protocol for Multimedia Wireless Sensor Networks Duarte Meneses, António Grilo, Paulo Rogério Pereira 1 NGI'2011: A Transport Protocol for Multimedia Wireless Sensor Networks Introduction Wireless
More informationIBM TSM DISASTER RECOVERY BEST PRACTICES WITH EMC DATA DOMAIN DEDUPLICATION STORAGE
White Paper IBM TSM DISASTER RECOVERY BEST PRACTICES WITH EMC DATA DOMAIN DEDUPLICATION STORAGE Abstract This white paper focuses on recovery of an IBM Tivoli Storage Manager (TSM) server and explores
More informationEnhance Service Delivery and Accelerate Financial Applications with Consolidated Market Data
White Paper Enhance Service Delivery and Accelerate Financial Applications with Consolidated Market Data What You Will Learn Financial market technology is advancing at a rapid pace. The integration of
More informationApplication Note. Windows 2000/XP TCP Tuning for High Bandwidth Networks. mguard smart mguard PCI mguard blade
Application Note Windows 2000/XP TCP Tuning for High Bandwidth Networks mguard smart mguard PCI mguard blade mguard industrial mguard delta Innominate Security Technologies AG Albert-Einstein-Str. 14 12489
More informationApplication Monitoring in the Grid with GRM and PROVE *
Application Monitoring in the Grid with GRM and PROVE * Zoltán Balaton, Péter Kacsuk and Norbert Podhorszki MTA SZTAKI H-1111 Kende u. 13-17. Budapest, Hungary {balaton, kacsuk, pnorbert}@sztaki.hu Abstract.
More informationThe syslog-ng Premium Edition 5LTS
The syslog-ng Premium Edition 5LTS PRODUCT DESCRIPTION Copyright 2000-2013 BalaBit IT Security All rights reserved. www.balabit.com Introduction The syslog-ng Premium Edition enables enterprises to collect,
More informationNetFlow v9 Export Format
NetFlow v9 Export Format With this release, NetFlow can export data in NetFlow v9 (version 9) export format. This format is flexible and extensible, which provides the versatility needed to support new
More informationSockets vs. RDMA Interface over 10-Gigabit Networks: An In-depth Analysis of the Memory Traffic Bottleneck
Sockets vs. RDMA Interface over 1-Gigabit Networks: An In-depth Analysis of the Memory Traffic Bottleneck Pavan Balaji Hemal V. Shah D. K. Panda Network Based Computing Lab Computer Science and Engineering
More informationMEASURING WIRELESS NETWORK CONNECTION QUALITY
Technical Disclosure Commons Defensive Publications Series January 27, 2016 MEASURING WIRELESS NETWORK CONNECTION QUALITY Mike Mu Avery Pennarun Follow this and additional works at: http://www.tdcommons.org/dpubs_series
More informationResource Utilization of Middleware Components in Embedded Systems
Resource Utilization of Middleware Components in Embedded Systems 3 Introduction System memory, CPU, and network resources are critical to the operation and performance of any software system. These system
More informationD1.2 Network Load Balancing
D1. Network Load Balancing Ronald van der Pol, Freek Dijkstra, Igor Idziejczak, and Mark Meijerink SARA Computing and Networking Services, Science Park 11, 9 XG Amsterdam, The Netherlands June ronald.vanderpol@sara.nl,freek.dijkstra@sara.nl,
More informationTivoli IBM Tivoli Web Response Monitor and IBM Tivoli Web Segment Analyzer
Tivoli IBM Tivoli Web Response Monitor and IBM Tivoli Web Segment Analyzer Version 2.0.0 Notes for Fixpack 1.2.0-TIV-W3_Analyzer-IF0003 Tivoli IBM Tivoli Web Response Monitor and IBM Tivoli Web Segment
More informationAnalysis of Open Source Drivers for IEEE 802.11 WLANs
Preprint of an article that appeared in IEEE conference proceeding of ICWCSC 2010 Analysis of Open Source Drivers for IEEE 802.11 WLANs Vipin M AU-KBC Research Centre MIT campus of Anna University Chennai,
More informationPutting it on the NIC: A Case Study on application offloading to a Network Interface Card (NIC)
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE CCNC 2006 proceedings. Putting it on the NIC: A Case Study on application
More informationQuantifying the Performance Degradation of IPv6 for TCP in Windows and Linux Networking
Quantifying the Performance Degradation of IPv6 for TCP in Windows and Linux Networking Burjiz Soorty School of Computing and Mathematical Sciences Auckland University of Technology Auckland, New Zealand
More informationIP - The Internet Protocol
Orientation IP - The Internet Protocol IP (Internet Protocol) is a Network Layer Protocol. IP s current version is Version 4 (IPv4). It is specified in RFC 891. TCP UDP Transport Layer ICMP IP IGMP Network
More informationCCNA R&S: Introduction to Networks. Chapter 5: Ethernet
CCNA R&S: Introduction to Networks Chapter 5: Ethernet 5.0.1.1 Introduction The OSI physical layer provides the means to transport the bits that make up a data link layer frame across the network media.
More informationRepeat Success, Not Mistakes; Use DDS Best Practices to Design Your Complex Distributed Systems
WHITEPAPER Repeat Success, Not Mistakes; Use DDS Best Practices to Design Your Complex Distributed Systems Abstract RTI Connext DDS (Data Distribution Service) is a powerful tool that lets you efficiently
More informationPANDORA FMS NETWORK DEVICES MONITORING
NETWORK DEVICES MONITORING pag. 2 INTRODUCTION This document aims to explain how Pandora FMS can monitor all the network devices available in the market, like Routers, Switches, Modems, Access points,
More informationICOM 5026-090: Computer Networks Chapter 6: The Transport Layer. By Dr Yi Qian Department of Electronic and Computer Engineering Fall 2006 UPRM
ICOM 5026-090: Computer Networks Chapter 6: The Transport Layer By Dr Yi Qian Department of Electronic and Computer Engineering Fall 2006 Outline The transport service Elements of transport protocols A
More information1 Organization of Operating Systems
COMP 730 (242) Class Notes Section 10: Organization of Operating Systems 1 Organization of Operating Systems We have studied in detail the organization of Xinu. Naturally, this organization is far from
More informationConsiderations In Developing Firewall Selection Criteria. Adeptech Systems, Inc.
Considerations In Developing Firewall Selection Criteria Adeptech Systems, Inc. Table of Contents Introduction... 1 Firewall s Function...1 Firewall Selection Considerations... 1 Firewall Types... 2 Packet
More informationA Universal Logging System for LHCb Online
A Universal Logging System for LHCb Online Fotis Nikolaidis 1, Loic Brarda 2, Jean-Christophe Garnier 3 and Niko Neufeld 4 1 2 3 4 European Organization for Nuclear Research (CERN), CH-1211 Geneva 23 Switzerland
More informationManagement of VMware ESXi. on HP ProLiant Servers
Management of VMware ESXi on W H I T E P A P E R Table of Contents Introduction................................................................ 3 HP Systems Insight Manager.................................................
More informationCisco Setting Up PIX Syslog
Table of Contents Setting Up PIX Syslog...1 Introduction...1 Before You Begin...1 Conventions...1 Prerequisites...1 Components Used...1 How Syslog Works...2 Logging Facility...2 Levels...2 Configuring
More informationThe syslog-ng Premium Edition 5F2
The syslog-ng Premium Edition 5F2 PRODUCT DESCRIPTION Copyright 2000-2014 BalaBit IT Security All rights reserved. www.balabit.com Introduction The syslog-ng Premium Edition enables enterprises to collect,
More informationComparative Analysis of Open-Source Log Management Solutions for Security Monitoring and Network Forensics
Comparative Analysis of Open-Source Log Management Solutions for Security Monitoring and Network Forensics Risto Vaarandi, Paweł Niziski NATO Cooperative Cyber Defence Centre of Excellence, Tallinn, Estonia
More informationNetwork Monitoring & Management Log Management
Network Monitoring & Management Log Management Network Startup Resource Center www.nsrc.org These materials are licensed under the Creative Commons Attribution-NonCommercial 4.0 International license (http://creativecommons.org/licenses/by-nc/4.0/)
More informationDynamic Thread Pool based Service Tracking Manager
Dynamic Thread Pool based Service Tracking Manager D.V.Lavanya, V.K.Govindan Department of Computer Science & Engineering National Institute of Technology Calicut Calicut, India e-mail: lavanya.vijaysri@gmail.com,
More informationNetwork Licensing. White Paper 0-15Apr014ks(WP02_Network) Network Licensing with the CRYPTO-BOX. White Paper
WP2 Subject: with the CRYPTO-BOX Version: Smarx OS PPK 5.90 and higher 0-15Apr014ks(WP02_Network).odt Last Update: 28 April 2014 Target Operating Systems: Windows 8/7/Vista (32 & 64 bit), XP, Linux, OS
More informationQuality of Service (QoS) on Netgear switches
Quality of Service (QoS) on Netgear switches Section 1 Principles and Practice of QoS on IP networks Introduction to QoS Why? In a typical modern IT environment, a wide variety of devices are connected
More informationIPV6 流 量 分 析 探 讨 北 京 大 学 计 算 中 心 周 昌 令
IPV6 流 量 分 析 探 讨 北 京 大 学 计 算 中 心 周 昌 令 1 内 容 流 量 分 析 简 介 IPv6 下 的 新 问 题 和 挑 战 协 议 格 式 变 更 用 户 行 为 特 征 变 更 安 全 问 题 演 化 流 量 导 出 手 段 变 化 设 备 参 考 配 置 流 量 工 具 总 结 2 流 量 分 析 简 介 流 量 分 析 目 标 who, what, where,
More informationPerformance Evaluation of Linux Bridge
Performance Evaluation of Linux Bridge James T. Yu School of Computer Science, Telecommunications, and Information System (CTI) DePaul University ABSTRACT This paper studies a unique network feature, Ethernet
More informationCisco Integrated Services Routers Performance Overview
Integrated Services Routers Performance Overview What You Will Learn The Integrated Services Routers Generation 2 (ISR G2) provide a robust platform for delivering WAN services, unified communications,
More informationHow Solace Message Routers Reduce the Cost of IT Infrastructure
How Message Routers Reduce the Cost of IT Infrastructure This paper explains how s innovative solution can significantly reduce the total cost of ownership of your messaging middleware platform and IT
More informationA Dell Technical White Paper Dell PowerConnect Team
Flow Control and Network Performance A Dell Technical White Paper Dell PowerConnect Team THIS WHITE PAPER IS FOR INFORMATIONAL PURPOSES ONLY, AND MAY CONTAIN TYPOGRAPHICAL ERRORS AND TECHNICAL INACCURACIES.
More informationDistributed syslog architectures with syslog-ng Premium Edition
Distributed syslog architectures with syslog-ng Premium Edition May 12, 2011 The advantages of using syslog-ng Premium Edition to create distributed system logging architectures. Copyright 1996-2011 BalaBit
More informationJ-Flow on J Series Services Routers and Branch SRX Series Services Gateways
APPLICATION NOTE Juniper Flow Monitoring J-Flow on J Series Services Routers and Branch SRX Series Services Gateways Copyright 2011, Juniper Networks, Inc. 1 APPLICATION NOTE - Juniper Flow Monitoring
More informationSecurity Overview of the Integrity Virtual Machines Architecture
Security Overview of the Integrity Virtual Machines Architecture Introduction... 2 Integrity Virtual Machines Architecture... 2 Virtual Machine Host System... 2 Virtual Machine Control... 2 Scheduling
More informationIntel DPDK Boosts Server Appliance Performance White Paper
Intel DPDK Boosts Server Appliance Performance Intel DPDK Boosts Server Appliance Performance Introduction As network speeds increase to 40G and above, both in the enterprise and data center, the bottlenecks
More informationPerformance measurements of syslog-ng Premium Edition 4 F1
Performance measurements of syslog-ng Premium Edition 4 F1 October 13, 2011 Abstract Performance analysis of syslog-ng Premium Edition Copyright 1996-2011 BalaBit IT Security Ltd. Table of Contents 1.
More information