Intel Software Network articles feed

Highly Reliable Linux HPC Clusters: Self-Awareness Approach

Fri, 03 Oct 2008 12:24:30 -0700

Introduction

by Chokchai Leangsuksun, Tong Liu, Yudan Liu, Stephen L. Scott, Richard Libby, and Ibrahim Haddad

Current solutions for fault-tolerance in HPC systems focus on dealing with the result of a failure. However, most are unable to handle runtime system configuration changes caused by transient failures and require a complete restart of the entire machine. The recently released HA-OSCAR software stack is one such effort making inroads here. This paper discusses detailed solutions for the high-availability and serviceability enhancement of clusters by HAOSCAR via multi-head-node failover and a service level fault tolerance mechanism.

Our solution employs self-configuration and introduces Adaptive Self Healing (ASH) techniques. HA-OSCAR availability improvement analysis was also conducted with various sensitivity factors. Finally, the paper also entails the details of the system layering strategy, dependability modeling, and analysis of an actual experimental system by a Petri net-based model, Stochastic Reword Net (SRN).

View entire article (PDF)

Intel® Threading Building Blocks - Product Features

Fri, 19 Sep 2008 00:00:00 -0700

Intel® Threading Building Blocks is a runtime library providing a parallel programming model for C++ code using threads. It comprises a template-based collection of components designed to simplify the process of multi-core programming. Use Intel Threading Building Blocks to write scalable applications that:

focus on independent or semi-dependent tasks instead of thread management
emphasize generic data parallel programming
take advantage of concurrent collections and parallel algorithms

The major features of Intel® Threading Building Blocks include:

Task scheduler that interoperates with native threads and OpenMP.
Generic parallel algorithms: parallel for, reduce, scan (prefix), do, pipeline, sort.
Generic, concurrent, thread-safe containers: hash table, vector, queue.
Type-Safe Atomic Operations: read, write, fetch-and-store, fetch-and-add, compare-and-swap
Exception-Safe Locks: spin lock, reader-writer mutex, queuing mutex, OS-wrappers
Cross-Thread Timers
Supports Windows*, Linux*, and Mac OS*
Supports 32-bit applications on IA-32 and Intel® 64 technology platforms, and 64-bit applications on Itanium® 2 and Intel® 64 platforms
Supports Intel, Microsoft* and GNU Compilers

WSC Linux* Reference Implementation

Wed, 13 Aug 2008 11:38:33 -0700

Your Information: Company Name and Division or Group.

Information on your company is optional and not required for the download; however we appreciate your help providing this information for our records.

Download
WSC Linux* Reference Implementation

Additional Resources
Wi-Fi* Simple Config (WSC) Linux* Reference Implementation article

FAQ: Mobile Platform SDK - An Open Source Project for Windows* and Linux*

Tue, 24 Jun 2008 09:34:46 -0700

1. What’s new in Mobile SDK 1.3?

The Mobile Platform SDK 1.3, open source project is covered by BSD license for both Windows and Linux. In addition, supports Linux Ubuntu version 7.10 for notebooks, and support for Moblin UME on UMPC and Atom-based devices.

2. What is the Mobile Platform Software Development Kit (Mobile Platform SDK) version 1.3?

Intel Corporation is providing the Mobile Platform SDK 1.3 as a free, open source project to give the developer community an innovative solution for cross platform and cross OS development of mobile-aware applications. The powerful feature set of the Mobile Platform SDK 1.3 enables developers to create efficient, reliable software that adapts to fluid mobile computing environments.

The Mobile Platform SDK 1.3 for Windows enables mobile features for applications running on notebook and tablet personal computers, smart phones, personal digital assistant (PDA), and Ultra Mobile Devices platforms. The Mobile Platform SDK 1.3 for Linux enables mobile features for applications running on notebooks, and supports Moblin UME on UMPC and Atom-based devices.

3. Why should I care?

The Mobile Platform SDK enables you to develop software with features for mobile computing anywhere, at anytime. With the Mobile Platform SDK 1.3 open source version, you can optimize your offering by creating dynamic context-aware applications that can:

Manage connectivity transparently
Effectively balance power and performance
Work across multiple platforms
Use available memory and disk space for local data storage and synchronization
Adapt to different display types
Manage network bandwidth

All of these advantages can help expand your customer base and lower engineering costs.

For more detailed information please visit: Intel Mobile Platform SDK

4. What are the benefits?

High-level API that unifies and abstracts the following platform Contexts:
- Connectivity
- Bandwidth
- Power
- Storage
- Display
Added Efficiencies
- Supports events on all properties of device contexts, and includes pre-defined events (Thresholds)
- Common event programming model and single internal polling/notification mechanism
Multi-Language/Runtime Support (C++/.NET/Java*)
Multi-Platform/Multi-OS support – single API across many operating systems:
- Microsoft Windows Vista*, Business and Ultimate Editions
- Microsoft Windows XP* Professional with Service Pack 2
- Microsoft Windows XP* Tablet PC Edition 2005
- Windows Mobile 2003 for Pocket PC and Smart Phone
- Windows Mobile® 5.0 for Pocket PC and Smart Phone
- Linux Ubuntu 7.10
- Moblin UME on UMPC and Atom-based devices

5. Why did Intel Corporation open source the Mobile Platform SDK 1.3

Based on customer and industry feedback, Intel has moved the Mobile Platform SDK to an open source distribution model to make the software easily available for the Windows and Linux open source developer community. Availability is a key factor in driving the next generation of mobility software, accelerating application development, and inducing business growth.

6. What is the open source licensing model?

The Mobile Platform SDK 1.3 open source license is BSD.

7. What are the differences between the Intel Mobile Platform SDK 1.1 version and the Mobile Platform SDK 1.3 open source version?

The Mobile Platform SDK 1.3 is a free, open source project which includes the following new key features:

RFID interface
Development support for Visual Studio* 2005 and .NET* Framework 2.0
The Mobile Platform Provider Development Kit (Mobile Platform PDK) enables developers to create plug-in modules that support 3rd party devices.
Intel® Virtualization Technology (Intel® VT) detection
Intel® Centrino® mobile technology detection
Enhanced C++ API uses StringObject rather than wchar_t and uses VectorObject rather than vector
The Mobile Platform SDK version 1.3 adds support for the following operating systems:
- Microsoft Windows Vista*, Business and Ultimate Editions
- Microsoft Windows XP* Tablet PC Edition 2005
- Windows Mobile® 5.0 for Pocket PC and Smart Phone
- Linux Ubuntu 7.10 for notebooks
Windows Mobile® 2003 was tested and supported in MPSDK v1.1. For this Open Source release the software was tested on Windows Mobile® 5.0 not tested on the 2003 version. If you intend to target 2003, give it a try and let us know if you have questions.
Due to licensing restrictions, support for the following devices have been removed from the Mobile Platform SDK 1.3:
- Removal of IVT* Bluetooth device implementation
- Removal of Sierra* CDMA/GPRS device implementation
- Removal of Symbol* Network device implementation
- Removal of Windows* 2000 support

8. Are applications developed with Intel® Mobile Platform SDK 1.1 for Windows compatible with the Mobile Platform SDK 1.3?

Yes. Any mobile application developed with the Intel® Mobile Platform SDK 1.1 is compatible with the Mobile Platform SDK 1.3 open source version for Windows.

9. How do I get the Mobile Platform SDK 1.3 open source version for Windows or Linux or Moblin?

The Mobile Platform SDK 1.3 open source package is available on the following sites:

Intel ISN Intel Mobile Platform SDK
SourceForge.org http://sourceforge.net/projects/mpsdk

10. How do I contribute code to the open source version?

Information on open source contributions, licensing, and distribution can be found at: Intel Mobile Platform SDK

11. What is the development environment for the Mobile Platform SDK 1.3 open source version?

You need the .NET Framework* 1.1 or 2.0 to write and run .NET applications
Microsoft Virtual Studio* .NET* 2003/2005
Microsoft Embedded Virtual C++ 4.0 (SP4) for Windows Mobile* development
Sun Microsystems JDK* 1.4.2 or higher needed when writing and running Java* applications
Linux gcc/g++ 4.1.2 or above

12. What platform devices are supported?

Device support includes:

Processor
Battery
Network, including:
- Wired (802.3)
- Radio (802.11)
- Bluetooth
- GPRS/CDMA
Platform
Display Adapter
Physical Disk
Logical Disk
Memory
RFID Reader.

Context support includes:

Connectivity
Bandwidth
Power
Display
Storage

13. What type of customer support is available?

The Mobile Platform SDK 1.3 open source project provides email, forum, and bug report support. Go to: Intel Mobile Platform SDK

14. How can I add devices?

The Mobile Platform SDK 1.3 open source version includes the Mobile Platform Provider Development Kit (Mobile Platform PDK) for Windows* XP/Vista. The Mobile Platform PDK enables the ISV Provider, such as the Device vendor, to integrate their devices into the Mobile Platform SDK runtime dynamically. Examples of these devices are an RFID reader and a network adapter.

15. What are the future plans to support additional Linux distributions?

Currently the Mobile Platform SDK 1.3 for Linux supports Ubuntu 7.10 for notebooks, and now supports Moblin UME on UMPC and Atom-based devices.

16. Why was the license changed from Apache to BSD?

The BSD license covers both Windows and Linux.

17. Where can I get more technical details about Mobile Platform SDK 1.3 open source?

For more detailed information, visit Intel Mobile Platform SDK

Windows* client CIFS behavior can slow Linux* NAS performance

Wed, 26 Sep 2007 16:25:56 -0700

Figure 1: Filesystem choice significantly influences performance

Summary

We have compared the performance of Windows* and Linux*-based CIFS* (Samba*) servers for digital media applications and found that the ext3*-based Linux server’s throughput was up to 53% lower than the Windows server’s--although both used identical hardware (Figure 1). An XFS*-based Linux server had roughly the same performance as the Windows server. Our investigation shows that the difference lies in the filesystem allocation and handling of sparse files. In particular, the Windows client makes an assumption that the CIFS fileserver uses NTFS*, a filesystem that assumes files will be data-full (not sparse). This contradicts a fundamental assumption of ext3--that files are sparse--and leads to fragmentation of files and degraded performance on ext3. Further, we’ve seen this behavior manifested for a broad range of media applications including iTunes*.

Observed Behavior

The test system consists of two PCs directly connected over gigabit ethernet. A client PC running Windows XP SP2* connects to a server PC running either Windows XP SP2 or Openfiler* 2.2 (Linux 2.6, based on rPath Linux). The client maps a dedicated data disk on the server as a network drive using CIFS and generates repeatable media playback and record of high definition video streams. Our internally developed workload generator allows us to run the media streams unbounded: we record or replay the media as fast as the client is able and are not limited to the original media framerate. This allows us to stress the server with an aggressive workload. High definition video streams offer well-understood behavior: they are largely sequential, transfer large blocks of data, and are read-only (playback) or write-only (record).

Playback of these HD streams differs significantly depending on the server OS and filesystem. Playing back single or multiple simultaneous HD videos results in up to 53% lower data throughput when the server uses Openfiler/ext3 rather than Windows/NTFS. We have captured network traces, filesystem traces, and SATA traces to deeply characterize this performance difference. As would be expected, the network traces show little difference in the client-generated requests: the client is identical in both cases and it will generate the same requests regardless of the server. Server side traces of the filesystem and SATA interface reveal a significant difference in the operation of the two filesystems. In particular, Openfiler/ext3 exhibits a broad range of transfer sizes (Figure 2) and a significantly longer tail of service times than Windows/NTFS (Figure 3). These two observed trends point towards some kind of fragmentation on the Openfiler/ext3 disk (varied transfer sizes and long disk seeks) while the Windows/NTFS disk is largely contiguous and unfragmented (few transfer sizes and short, cached disk operations).

Figure 2: Openfiler uses a broad range of SATA sizes

Figure 3: WinXP frequently hits the SATA drive cache

Observing the recording of the HD streams sheds some light on why the Openfiler/ext3 disk becomes fragmented and the Windows/NTFS disk does not. On the Windows client network interface, we can observe a number of small (one-byte) writes to high offsets within the file at a long stride (128K bytes). These writes are generated by the client filesystem: they do not show up in application traces but do show up in network traces. These small writes to increasingly large offsets turn out to be bogus data which are used to provide hints to the server to pre-allocate data blocks on the disk. The data at these locations are eventually overwritten by large data writes of the actual HD recording. The behavior is illustrated conceptually in Figure 4 where the initial red blocks represent the pre-allocate writes and the later blue blocks represent the actual data written to the media file. If the server OS uses a filesystem like NTFS, these pre-allocate writes are used to allocate contiguous blocks on the disk. NTFS assumes that all files will be filled with data, so the small write to a high offset forces the filesystem to allocate a set of contiguous blocks up to that offset. When the valid data is written to NTFS, the blocks are already allocated, simplifying and speeding the data writes.

Figure 4: Pre-allocate writes are later overwritten with real data

Most Linux filesystems make the opposite assumption that files are sparsely populated with data. This results in poor behavior in response to the pre-allocate writes. The filesystem must assume that the data within the pre-allocate writes is valid: there is nothing in these writes to differentiate them from valid data. The filesystem (ext3) will therefore allocate blocks as they are written, in this case one byte at a time at 128KB stride. In practice, we have observed pre-allocate writes to offsets 15 MB into the file before a single valid data write occurs. When the application on the client begins writing valid data, the filesystem is already likely to be fragmented because of these pre-allocate writes. This fragmentation turns what should be a best-case workload for most modern hard disks (large, sequential reads) into a mess of low performance disk seeks. Anecdotally, we have observed that one 3.5GB video file used in our testing was fragmented into 49,986 extents. A simple copy to a new location defragmented this file to 28 extents (26 extents is ideal).

This behavior is not limited to our test case: a simple test using iTunes to rip a CD to a music library on a NAS device will show the same one-byte pre-allocate writes. We expect to see this behavior any time a Windows client is appending to a file of unknown length. Additionally, the Windows client behavior does not change in response to the Samba-advertised "fstype" parameter--the client issues pre-allocate writes whether the server announces itself as "NTFS" or "Samba." We have tried to force the linux server to allocate data-full files with the Samba &ldqu o;strict allocate” flag but observed no change in ext3 performance. (UPDATE 9/12/07: newer versions of Samba 3.0.20 or greater zero-fill files when “strict allocate” is set. This has the desired effect of producing NTFS-like behavior that works well with windows clients and improves media serving performance to be on par with XFS.)

Proposed Solutions

We have seen that media files recorded from a Windows client and streamed/appended to an ext3-based Linux file server show lower delivered throughput (when played back unbounded) as compared to media recorded to an NTFS-based Windows file server. We attribute this performance delta to fragmentation within ext3 as a result of pre-allocate writes issued by the Windows client. When using XFS as a base Linux filesystem, we see similar performance to Windows (likely from XFS’ increased allocation size and delayed allocation). Additionally, if we defragment the media files on ext3 by copying them to a new location on the disk, playback performance improves to expected levels.

Ideally, the client would not assume the filesystem behavior on the server and would not issue these pre-allocate writes. This would allow the server to perform optimizations appropriate to the underlying filesystem. Modifying the Windows CIFS client, however, is not realistic. Modifying the server to discard the one-byte writes or delay them until overwritten by the real data may help in file fragmentation, but these solutions create data integrity issues. Another possibility would be to change ext3 so that it assumes data-full files.

More realistically, the server could recognize the small size, high offset writes and use them to implement block pre-allocation on the disk. When the server sees transactions such as those observed here to be pre-allocations, it would translate those into a pre-allocate mechanism specific to the underlying filesystem. If this were implemented at the Samba or VFS layer, the pre-allocate writes could translate into a larger number of smaller stride one-byte writes (for example, striding each 4KB disk block) to allow ext3 to properly allocate contiguous blocks on the disk. If the underlying filesystem has a specific pre-allocation mechanism (as has been proposed for ext4), the one-byte writes could be translated directly into this filesystem-native pre-allocation.

System configurations

Client system:

Intel ® Pentium® 4 processor 3.6 GHz
Intel ® D915GEV desktop board, 800 MHz system bus
Integrated Marvell* Yukon* 1GbE
2x512 MB DDR2-533 4-4-4-12
1x Hitachi* Deskstar* 250 GB, 7200 RPM, SATA (NTFS)
Windows XP SP2

Server system:

Intel ® Pentium® D processor 3.2 GHz 2x1MB L2
Intel ® 955 chipset, 800 MHz system bus
Integrated Intel ® PRO/1000 Gigabit Server Adapter
2x512MB DDR2-667 5-5-5-15
WD* Raptor*, 74GB, 10,000RPM, SATA (OS drive, NTFS or ext3)
Hitachi Deskstar 250GB, 7,200 RPM, SATA (data drive, NTFS, ext3, or XFS)
Windows XP SP2 or Openfiler 2.2 (linux kernel 2.6.19, Samba 3.0.10)

*Other names and brands may be claimed as the property of others.

Company Name:
Division Name: