| تبليغات | X |
|
XGRID تکنولوژی
|
||
|
پیاده سازی سیستم های توزیع شده |
مراحل ایجاد یک برنامه client/server در دلفی
بسمه تعالی
مراحل ایجاد یک برنامه clint/server
توضیح : خیلی از عزیزان برای شبکه کردن indy را توصیه می کنند . درست است INDY برای ارسال پیام در شبکه و ایمیل و ... مناسب است ولی برای بانکهای اطلاعاتی درد سر بسیار دارد . در این ثال از datasnap استفاده شده که کار را بسیار راحت می کند .
الف : برنامه سرور
1-یک پروژه جدید باز کنید و با عنوان سرور ذخیره نمایید
2- به قسمت file / new / other/multitier رفته و بر روی remote data server کلیک نمایید
3- حال یک پنجره با عنوان remote data module wizard ایجاد می شود که در قسمت CoClass Name یک نام برای سرور انتخاب نمایید . و به قسمتهای دیگر کاری نداشته باشید و ok را بزنید .
4- بلافاصله یک datamodule جدید با نام سرور (نامی که در قسمت class name انتخاب نمودید ) ایجاد می شود .
5- حال با استفاده از ado یا bde یا ... به با نک اطلاعاتی وصل شوید . مثلا با adoquery به یک جدول از یک بانک اطلاعاتی sql server وصل شده . حال adoqueryr را فعال سازید تا ارتباط برقرار شود . در پنجره مشخصات adoquery خاصیت active را true نمایید .
6- در قسمت dataacess یک DataSetProvider1 را بر روی datamoule که ایجاد کرده ایم قرار می دهیم و روی dataset در پنجره مشخصات کلیک نموده تا نام ارتباط بانک اطلاعاتی نمایان شود ( adoquer در مثال بالا)
7- پس از اطمینال از اتصال صحیح با نک اطلاعاتی پروژه را ذخیره و یک بار اجرا نمایید تا سرور در شبکه ثبت شود .
8- توجه داشته باشید که برنامه سرور فقط محل نگهداری بانک اطلاعاتی و کنترل اتصالات و کاربران است . پس کار دیگری را انجام نمی دهیم و حال فایل اجرایی برنامه سرور را اجرا می کنم.
ب نوشتن برنامه کلاینت
1- یک پروژه جدید با عنوان کلاینت ایجاد نموده و ذخیره نمایید .
2- در روی فرم از قسمت datasnap یک SocketConnection1 را روی فرم قرار داه . در قسمت adress نام ip کامپیوتر سرور را وارد نمایید.(مثلا ip سرور در برنامه محل کار من 10.20.1.93 است ) . اگر ای پی سرور را نمی دانید می توانید نام کامپیوتر سرور را وارد کنید .حال در قسمت servername نام سروری را که در برنامه سرور ثبت کرده اید را انتخاب نمایید . اگه پیام خطا داده احتمالا در تنظیمات شبکه یا خود شبکه ایراد است . وقتی نام سرور را نتخاب کردید گزینه conecct از مشخصات SocketConnection1 vh را true کنید . اگر true شد یعنی ارتنباط با سرور بر قرا است .
3- حال در قسمت datascess یک ClientDataSet1 بر روی فرم قرار داده و تنظیمات زیر را انجام دهید
A: در قسمت remote server کلیک نمایید تا نام socketConnection1 ظاهر شود .
b: در قسمت provider name کلیک کنید تا نام DataSetProvider1 ظاهر شود
c:حال خاصیت active را true کنید .
4- حال از قسمت dataascess یک datasource1 بر روی فرم قرار دهید و خاصیت datadet آن را با نام clientdataset1ظاهر شود .
5- حال از قسمت data control یک datagrid روی فرم قرار داده و خاصیت datasource آن رو datasource 1 انتخاب کنید . می بینید که اطلاعات سرور نمایش داده می شود .
توضیحات . چون ما از SocketConnection2 استفاده می کنیدم که بر اساس tcp/ip عمل می کنید (پشتیبانی سوکت ها ) باید برنامه فعال سوکت ها فعال شود . برای این کار مرحل زیر را انجام دهید
1- در قسمت run ویندوز دستور cmd را تایپ نمایید .
2- پس از ورود به محیط cmd دستور مقابل را تایپ نمایید scktsrvr - install .
توضیح 2 : فرض بر این است که کلیه خوانندگان عزیز با بانک اطلاعتی و ارتباط با ان آشنایی دارند . اگر می خواهید به نتیجه برسید نامگذاری اشیاعی که بر روی فرم ها و ... می گذارید عین مثال باشد .
امیدوارم مورد استفاده قرار گرفته باشد .
منبع : http://delphi-7.blogfa.com
(thread)و سیستمهای multitasking
در تکنیک چندنخی (multitasking) یک فرایند (process) که برنامهای در حال اجراست , میتواند به بخشها یا نخهایی (بندهایی ) تقسیم شود که میتوانند به صورت همزمان اجراء شوند.
برنامههایی که چند وظیفه مستقل از هم را انجام میدهند میتوانند به صورت چن نخی نوشته شوند. گاهی اوقات به سیستمهای multithreading سیستمهای چند تکلیفی یا چند وظیفه ای (multitasking)هم گفته میشود.
فرآیند (process)یا پردازش اساس یک برنامه در حال اجراست که منابعی از سیستم به آن تخصیص داده شده است (شامل رجیسترها,حافظه,فایلها و دستگاهها).فرآیند میتواند مجموعهای از یک یا چند نخ باشد. به نخ, رشته یا بند هم گفته میشود . کلیه اطلاعات مربوط به هر پروسس , در یکی از جداول سیستم عامل به نام جداول Process Control Block=PCB ذخیره میشود. این جدول یک آرایه یا لیست پیوندی از ساختارهاست که هر عضو آن مربوط به یکی از پروسسهاست که در حال حاضر موجودیت دارد.
اطلاعات موجود در PCB عبارتند از : حالت جاری پردازش ,شماره شناسایی پردازش , اولیت پردازش , نشانی حافظه پردازش , نشانی محل برنامه پردازش بر روی دیسک , نشانی سایر منابع پردازش , محلی برای حفظ ثباتها .
منبع :شبه رشد
The Grid Engine project has announced a new maintenance release (version 6.1 Update 4) of its software. This release fixes some 50+ issues found in earlier versions. In particular, couple of problems causing qmaster crashes have been resolved, and so were several dbwriter and accounting issues. More specifically, if you were wondering why your array job task usage is missing from the accounting file, you should consider installing this release. The new version of the software is available for download here. MPI vs. Compiler
Marlborough, MA, ? April 01, 2008 ? Scali, the leader in higher performance computing software, today announced new benchmark results provided by Scali using the SPEC MPI2007 benchmark suite on the newly released Scali MPI Connect version 5.6.1. As of today?s release, Scali cements its leadership and has the highest SPECmpiM_base2007 score for all systems ranging from 32 to 128 cores. Further, as a courtesy to the industry, Scali has submitted results using different compilers, enabling studies of which cluster components truly provide differential performance benefits. For a 32-node cluster system using 128 cores, the results show the compiler difference to be a modest 6 percent. However, on similarly equipped systems, these new results show that Scali MPI Connect extracts 18 percent more performance than HP-MPI (1).
?It is our top priority to deliver the best performing MPI in the industry and the newly submitted results underscore that commitment. Out of the 13 applications which constitute the SPEC MPI2007 medium suite running on 32 nodes and 128 cores, three of the applications performed within +/- 2 percent as compared to a similar system using HP-MPI. All the other 10 applications perform significant faster with Scali MPI Connect. For example the Quantum Chemistry application Socorro performs 21 percent faster with Scali MPI Connect. Additionally, the result for the POP2 benchmark, a climate modeling test using the Parallel Ocean Program (POP) showed a 336 percent performance advantage over the HP-MPI based system.?, said Hakon Bugge, CTO of Scali. ?We will continue our leadership role in providing the HPC community with the data they need to make important technology decisions. The choice is clear, over all; Scali MPI Connect is the best performing MPI in the market.?
SPEC MPI2007
SPEC MPI2007 is SPEC's benchmark suite for evaluating MPI-parallel, floating point, and compute intensive performance across a wide range of cluster and SMP hardware. MPI2007 continues the SPEC tradition of giving HPC users the most objective and representative benchmark suite for measuring the performance of SMP (shared memory multi-processor) systems. SPEC reviews and publishes submitted results on their website at: http://www.spec.org/mpi2007/results/ . SPEC? and the benchmark name SPEC MPI? are registered trademarks of the Standard Performance Evaluation Corporation. Competitive benchmark results stated above reflect results published on www.spec.org as of April 1, 2008.
About Scali and Scali MPI Connect
Founded in 1997, Scali is the leading developer of a fully integrated message passing interface (MPI) library that enables companies to take advantage of premier interconnect technologies to build high performance clusters. Scali MPI Connect is designed to enable applications to run at maximum performance through its unique, high performance, patent pending technology. Scali MPI Connect supports a wide range of customer environments while lowering the number of binaries required, and delivers superior application performance. Hundreds of companies, including Goodyear, Daimler AG, Lockheed Martin, US Army and Naval Air, Schlumberger and Shell benefit from using Scali?s MPI libraries. The company is headquartered in Marlborough, Massachusetts with research and development in Oslo, Norway and Nagpur, India. Visit http://www.scali.com for more information.
? 2008 Scali, Inc., All rights reserved. Scali and Scali MPI Connect are trademarks of Scali, Inc. All other service marks, trademarks, and registered trademarks are the property of their respective owners.
(1) The two systems labeled ? HP Proliant BL460c blade Cluster Platform 3000BL? and ? LS-1, Scali MPI Connect 5.6.1, Intel 9.1 compilers?, are both using Mellanox based Infiniband DDR HCAs, dual-core Intel Xeon 5160 processors and Intel 9.1 compilers. Using 32 nodes and 128 cores, the HP-MPI based system delivers a SPECmpiM(TM)_base2007 score of 11.9. The Scali MPI Connect based system delivers 14.0 using the same metric, i.e., 18 percent higher score. منبع : http://www.linuxhpc.org/stories.php?story=08/04/10/8378717
An Introduction To Distributed Intrusion Detection Systems
|
What is a dIDS? A distributed IDS (dIDS) consists of multiple Intrusion Detection Systems (IDS) over a large network, all of which communicate with each other, or with a central server that facilitates advanced network monitoring, incident analysis, and instant attack data. By having these co-operative agents distributed across a network, incident analysts, network operations, and security personnel are able to get a broader view of what is occurring on their network as a whole. A dIDS also allows a company to efficiently manage its incident analysis resources by centralizing its attack records and by giving the analyst a quick and easy way to spot new trends and patterns and to identify threats to the network across multiple network segments. This article will discuss distributed intrusion detection systems, including the general setup of a dIDS and a fictional case study to demonstrate the distributed analysis abilities. It will also try to give the reader some insight into the benefits of running a dIDS system, from both incident analyst and corporate views. Overview The Central Analysis Server The central analysis server is really the heart and soul of the operation. This server would ideally consist of a database and Web server. This allows the interactive querying of attack data for analysis as well as a useful Web interface to allow the corporate guys upstairs to see the current attack status of your network. It also allows analysts to perform pre-programmed queries, such as attack aggregation, statistics gathering, to identify attack patterns and to perform rudimentary incident analysis, all from a Web interface. The Co-operative Agent Network The co-operative agent network is one of the most important components of the dIDS. An agent is a piece of software that reports attack information to the central analysis server. The use of multiple agents across a network allows the incident analysis team a broader view of the network than can be achieved with single IDS systems. Ideally these agents will be located on separate network segments, and geographical locations (See diagram below.) The agents can also be distributed across multiple physical locations, allowing for a single incident analysis team to view attack data across multiple corporate locations.
Although any IDS could be used on the agent machines, it is highly suggested that Snort be used. It has been demonstrated, however, that any attack logging system can be incorporated into this agent network. This can range from router attack logs, to ipfw, firewalls, and even Windows personal firewall systems. Attack Aggregation Attack aggregation is another core part of the dIDS system. This part of the system is programming logic based on the central server. Aggregation simply refers to the method in which users group or order the information gathered from the agent network. One example of this would be to aggregate information according to attacker IP, putting all attacks from an attacking IP together with other attacks from the same IP. Another example is the aggregation of attack data according to destination (attacked) port, or even by date and time. Uses for aggregation will be explained later in this paper. Advantages of a dIDS Why a dIDS? Due to the greater view the agent allows the analyst to achieve, the dIDS offers the incident analyst many advantages over other single mode IDS systems. One of these advantages is the ability to detect attack patterns across an entire corporate network, with geographic locations separating segments by time zones or even continents. This could allow for the early detection of a well-planned and coordinated attack against the organization in question, which would allow the security people to ensure that targeted systems are secured and offending IPs are disallowed any access. Another proven advantage is to allow early detection of an Internet worm making its way through a corporate network. This information could then be used to identify and clean systems that have been infected by the worm, and prevent further spread of the worm into the network, therefore lowering any financial losses that would otherwise have been incurred. The second major advantage is that a single analysis team can now do what previously required several incident analysis teams due to physical distance. This obviates the need to pay for distinct incident analysis teams for each separate geographic location of the organization’s offices. Another issue that it addresses is attacks from within the corporations network by angry, upset, or bored employees. By tying the central analysis server in with the companies DHCP or RADIUS servers, the incident analysts can track down people launching attacks from within the company, and track what they have attempted to do, as well as provide evidence against the perpetrators. Incident Analysis With dIDS Incident analysis using the dIDS system is really what it is all about. This is where all the power, potential, flexibility, and strength of the system as a whole lies. It is the reason why the dIDS was first conceptualized, to allow for advanced analysis of attacks occurring over multiple network segments, and at an advanced level. Analysis Using Aggregation Aggregation is the main component used to facilitate this advanced method of analysis across a networks multiple segments. By aggregating similar or related data, the analyst is able to easily see how an attack progressed through the different stages: from active network reconnaissance, to the final attack. It is possible for the incident analyst to see what kind of time frame the attacker was working within and to correlate other attack attempts against the networks to determine if there were multiple co-operative attackers. The most common methods of aggregation are according to attacker IP, destination port, agent ID, date, time, protocol, or attack type.
By utilizing all of these aggregation methods, the analyst is given an unlimited number of different sets of data to correlate against other attacks, detect coordinated distributed attacks, attacks from within their own network, and to detect new exploits and vulnerabilities being deployed by the underground hacking community. The broad view given by the dIDS system also allows the analyst to ensure a minimum of false positives and false negatives by being able to see beyond a single network segment, into the network as a whole. For example, if the analyst saw that one out of five network segments got seven unrequested ICMP Echo packets, it could be a simple issue of false addressing or improper routing somewhere. However, if the analyst were to see that three separate network segments were reporting seven unrequested ICMP Echo packets, it is much more likely that these packets would be malicious in nature. This would cause the analyst to take note of the activity and perhaps check into the incident further or flag it for review at a later date. Analysis Case Study You come into the office early one morning, boot up your PC, and surf to your Central Analysis server to see what has been going on throughout the night. First thing you do is check incident reports aggregated by the attackers IP. You notice that slews of probes were sent to two internal use IIS Web Servers, located at 172.16.2.106, and 172.16.1.98. These segments’ agent Ids are “Main Office.” and “Production” The following shows up on the incident report: Source IP: 206.219.23.16
Now we’ll want to see if any other attacks were attempted on either of these machines. So, we’ll aggregate the attack data by the target IP addresses, which are included in the previous report. Now we get two reports. Target IP: 172.16.106
Target IP: 172.16.1.98
Next we’ll combine these two reports by asking the database to give us all attack data with an attacker IP of 24.26.198.98, and 209.219.23.16, against “Production” and “Main Office.” We’ll also have it sort by date and time: Source IP: 24.26.198.98 OR 206.219.23.16
This basically, gives us a step-by-step view of how the attack was carried out by the two attackers. This example is very simplistic, but there have been several demonstrated highly complex attacks that have been identified using this analysis method. Using these reports, it would be apparent to the analyst that a coordinated attack was attempted against both of these IIS servers. Further analysis can be achieved by viewing the actual IDS logs submitted to the central analysis server, and a decision on network vulnerability to attempted attacks can be performed, as per the GIAC standard for incident analysis reports. It would also be advisable to see the aggregated report on the second attackers IP, to see if any other systems had attack attempts from this system, that were not included in this coordinated attack. It has been demonstrated in the past that this system helps the analyst identify large scale, coordinated attacks against large corporate networks, attacks that might otherwise have gone unnoticed due to communications breakdowns between teams and the inability to correlate all the data involved across multiple network segments without a system like this. Conclusion The dIDS system gives the analyst a quicker, easier, more efficient method to identify coordinated attacks across multiple network segments, and to trace back the activities of the attackers. The system also, ultimately, saves the corporation whose networks it is deployed on money by reducing the number of Incident Analysts needed, as well as the amount of time required to gather logs from the various IDS systems setup in a large corporate network. By having all of these attack records stored in a single place, it allows the analyst much more flexibility in discovering attack patterns, and other attack issues which may have otherwise gone unnoticed. As attackers, and attack methods become increasingly complex, the need for a dIDS system in large corporate, and military networks increases drastically. With the increased complexity of these attacks, analysts are leaving themselves open to the problems of communications breakdowns, where one analyst sees a single attack on his segment, and dismisses it as nothing. While several other segments receiving the same attacks in a coordinated manner, their analysts may be dismissing the seriousness of the attack. However, when all the attack data is viewed together, a dramatically different perspective the attack may emerge. dIDS systems are the next logical level for IDS systems to move to. They are able to be setup with pre-existing architectures and IDS systems, making them even more cost-efficient. It should also be noted that there are currently a few systems in place that fall along the lines of a dIDS. Instead of being based in the corporate environment, focused on in this paper, they are deployed across the entire Internet, which thousands of sensors submitting data to them every day. One such service is SecurityFocus’s ARIS Predictor service, which should be noted due to its large scale demonstration of the use of a dIDS in the reporting of attacks to ISPs, server owners, and their proven ability to identify new worms, and attacks, therefore making the Internet as a whole safer for all. Nathan Einwechter is currently a Senior Research Scientist with Fate Research Labs, aswell as a System Developer/Incident Analyst with myNetWatchman.Com. While working with myNetWatchman, Nathan assisted in the discovery and analysis of the "W32.Leave.Worm" along with SANS, the FBI, and NIPC. The discovery of which was made possible by analysis of data collected by a dIDS system. |
Middleware در يك سيستم محاسباتی توزيع شده به عنوان لايه نرمافزاری تعريف میشود كه بين سيستم عامل و برنامهها قرار میگيرد و اجرای چند فرايند را بر روی يك يا چند ماشين در شبكه امكان پذير میسازد.
Middleware برای انتقال برنامههای mainframe به برنامههای كلاينت / سرور ضروری است. اين تكنولوژی در سالهای 1990 تكامل يافت. تكنولوژیهای Middleware با رشد برنامههای مبتنی بر شبكه اهميت پيدا كردند. از سوی ديگر تعداد سيستمهايی كه از مجموعهای از ديوايسها تشكيل شده بودند افزايش يافت. هر ديوايس عملكردی را انجام میداد كه در شبكه با ساير ديوايسها نظير تلفنهای هوشمند، كامپيوترهای شخصی، PDA تعامل داشت.
عملكردهای Middleware
در هر يك از حالات فوق، برنامهها از نرمافزار ميانجی و پروتكلهای ارتباطی برای انجام عملكردهای زير استفاده میكنند:
پنهانسازی توزيع: توجه به اين واقعيت كه برنامه معمولا از بخشهای به هم پيوستهای تشكيل شده است كه در مكانهای توزيع شده اجرا میشود.
پنهان سازی ناهمگنی اجزای سختافزاری، سيستم عاملها و پروتكلهای ارتباطی مختلف
تهيه رابط استاندارد، يكپارچه و سطح بالا برای توسعهگران برنامهها، به گونهای كه برنامهها به سادگی قابل تهيه و استفاده مجدد باشند.
تهيه مجموعه سرويسهايی برای انجام عملكردهای مختلف همه منظوره.
اين لايههای نرمافزاری ميانجی، Middleware ناميده میشوند.
Middleware با فراهم آوردن محيط برنامهنويسی مشترك، پنهان سازی ناهمگونیها، توزيع سختافزار و سيستم عامل زيربنايی و پنهانسازی جزييات و برنامهنويسی سطح پايين، توسعه برنامهها را آسانتر میسازد.
برخی از انواع Middleware
Middleware بازتابی: اينگونه Middleware از تكنيكهای بازتابی برای رسيدن به انعطافپذيری و انطباق با پلاتفرمها استفاده میكند.
Middleware رويدادگرا: اين Middleware مفاهيم، طراحی، پيادهسازی و سرويسهايی را در بر میگيرد كه از سيستمهای رويدادگرا پشتيبانی میكنند.
Middleware شیگرا: Middleware شیگرا پارادايم برنامهنويسی شیگرا را برای سيستمهای توزيع شده بسط میدهد.
Middleware پيام گرا: اين Middleware در لايههای پايين مدل شبكه OSI به كار گرفته میشود. Middlewareهای مختلف از مدلهای بربرنامهنويسی متفاوت پشتيبانی مینمايند. Middleware شیگرا متداولترين Middleware است كه در آن برنامهها به صورت آبجكتهايی ساخته میشوند. CORBA و COM از جمله اين Middleware هستند. Middleware رويدادگرا برای ساخت برنامههای توزيع شده غيرمتمركز مناسب است. كنترل فرايند، شبكههای خبری اينترنتی از زمره اينگونه Middlewareها هستند.
Middleware پيامگرا برای برنامههايی كه در آنها پيامها به صورت دائمی ذخيره میشوند، مناسب است. برنامههای پيامرسانی و گردش كار نمونههايی از اينگونه Middleware هستند.
طراحی Middleware
Middleware به عنوان واسط بين بخشهای مختلف برنامه يا بين برنامهها عمل میكند. لذا قواعد به كار رفته در معماری نقش اساسی در طراحی Middleware دارند. در اينجا منظور از معماری، معماری كلی سازمانها و الگوهای ارتباطی در زمينه برنامهها و خود Middleware است. هر سيستم Middleware به لايه ارتباطی بستگی دارد. اين لايه امكان عمل بينابينی بخشهای مختلف را فراهم میآورد.
چالشهای فراروی Middleware
هزينهها: هزينه بكارگيری تكنولوژی Middleware در توسعه سيستمها كاملا به سيستم عاملها و پلاتفرمهای مورد نياز بستگی دارد. پيادهسازی Middleware منحصر به فروشنده آن است. لذا به پشتيبانی و نگهداری از جانب فروشنده وابسته است. اين وابستگی تاثير منفی بر انعطافپذيری و قابليت نگهداری سيستم دارد.
پيچيدگی برنامهها: هر چه برنامهها ارتباط درونی بيشتری با هم داشته باشند. تعداد آبجكتها با كاربران و ديوايسها افزايش میيابد. اين امر مديريت آبجكتها و پيچيدگی اداره نمودن سيستم را دشوار میسازد.
مديريت برنامهها: مديريت برنامههای بزرگ، ناهمگون و توزيع شده با مشكلات متعددی از قبيل مسائل امنيتی، نظارتی، وابستگی به چندين زير سيستم، تعريف و پياده سازی خط مشیهای مديريت منابع روبرو خواهد بود.
منبع : http://www.pcworldiran.com
MultiThreading چیست؟
مقدمه -
گاهی اوقات ممکن است که شما بخواهید برنامه شما دو یا چند عمل را به طور همزمان انجام دهد و یا اینکه نیاز به انجام عملیاتی که مدت زمان زیادی به طول می انجامد و یا زمان انجام آن معلوم نیست ، باشد ، بدون اینکه برنامه شما از دسترس کاربر خارج شود و به اصطلاح برنامه شما تا پایان یافتن عملیات قفل کند و همچنین کاربر بتواند عملیات را متوقف/معلق/شروع دوباره نماید . در چنین موقعیتی نیاز به MultiThreading حس میشود . به فرض مثال کد زیر را در نظر بگیرید :
For i As Integer = 0 To 10000000
For i2 As Integer = 0 To 100
'Do Nothing
Next
Next
هنگامی که این عملیات شروع میشود ، کاربر توانایی کار با برنامه تا پایان یافتن آن را نخواهد داشت .
Thread چیست؟
Thread نامی برای جریان اجرای یک عملیات خاص میباشد و هنگامی که برنامه شما دارای چند Thread میباشد بدان معناست که قسمت های مختلفی از کد برنامه شما به طور همزمان در حال اجرا شدن میباشند . در حقیقت کامپیوتر زمان پردازش یک عملیات را به قسمت(slice) های مختلفی تقسیم میکند و هنگامی که شما یک Thread جدید را آغاز میکنید کامپیوتر قسمتی از زمان را به آن اختصاص میدهد . لازم به ذکر است که برنامه شما از ابتدا دارای یک Thread اصلی (Main Thread) برای اجرا کد مربوط به آن میباشد .
کار خود با Thread ها را آغاز مینماییم :
میخواهیم برنامه ای بنویسیم که تا یک عدد معین عملیات شمارش را انجام دهد .
1 – یک پروزه Windows Apploication به نام MutiThreading Sample ایجاد نمایید .
2 – یک Button به نام btnStart و یک TextBox به نام txtMAX به فرم اضافه نمایید .
3 – یک کلاس به نام clsCounter به پروژه اضافه کرده و کد زیر را در داخل آن قرارهید :
Public Class clsCounter
Public MAX As Integer
Public Event CountingFinished(ByVal Number As Integer)
Sub StartCounting()
Dim intTotal As Integer
For i As Integer = 0 To MAX
intTotal += 1
Next
RaiseEvent CountingFinished(intTotal)
End Sub
End Class
توضیحات در مورد کد فوق :
• وظیفه این کلاس شمردن از 1 تا مقدار MAX میباشد .
• رویدادی با نام CountingFinished تعریف کردیم که هنگامی که عملیات شمارش به پایان برسد اتفاق می افتد .
• متد StartCounting از 1 تا مقدار intMax را شماره کرده و در هر بار اجرای حلقه یک واحد به مقدار متغیر intTotal اضافه میشود که در نهایت مساوی با مقدار MAXخواهد بود .
• پس از پایان شمارش رویداد CountingFinished را همراه با پاس کردن متغیر intTotal به آن اجرا مینماییم .
حال ما باید در هنگامی که دکمه کلیک میشود یک Thread جدید ایجاد کرده و سپس متد StartCounting کلاس clsCounter را اجرا کرده و رخدادن رویداد CountingFinished را کنترل نماییم . در زمانی که عملیات شمارش انجام میشود ما میتوانیم رابط کاربری را کنترل کرده و کاربر توانایی کار با برنامه را دارد .
حال کد زیر را به پروژه خود اضافه نمایید :
Sub CountingFinishedEventHandler(ByVal N As Integer)
System.Windows.Forms.MessageBox.Show("Counting Finished!")
End Sub
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnStart.Click
Dim CounterClass As New clsCounter
Dim CountingThread As New Threading.Thread(AddressOf CounterClass.StartCounting)
CounterClass.MAX = Val(txtMax.Text)
AddHandler CounterClass.CountingFinished, AddressOf CountingFinishedEventHandler
CountingThread.Start()
End Sub
توضیحات در مورد کد فوق :
•ابتدا یک پروسیجر برای کتترل رویداد CountingFinished مربوط به کلاس Counter ایجاد مینماییم . هنگامی که رویداد اتفاق بیافتد(عملیات شمارش به پایان برسد) ، پیغامی مبنی بر پایان یافتن عملیات به کاربر نشان داده خواهد شد .
• در رویداد Click شی ء btnStart ، ابتدا یک نمونه از کلاس CounterClass ایجاد مینماییم .
• سپس برای ایجاد شی ء Thread ، آدرس متذ clsCounter.StartCounting را به سازنده کلاس Thread پاس مینماییم به طوری که متد clsCounter.StartCounting را بعد از آوردن کلمه کلیدی addressof ، می آوریم .
• بعد ، توسط کلمه کلیدی Addhandle ، کنترل کننده رویداد که CountingFinishedEventHandler نام دارد را به رویداد clsCounter.CountingFinished متصل مینماییم .
• در آخر نیز توسط متد Start مربوط به شیء CountingThread ، عملیات را آغاز مینماییم .
برخی متدهای دیگر مربوط به شی ء Thread :
Suspend و Resume : در حالی که یک Thread در حال اجراست ، توسط متد Suspend میتوانید آن را معلق کنید که منجر به متوقف شدن آن تا زمانی که متد Resume اجرا شود ، خواهد گردید .
Abort : Thread را متوقف میکند .
Sleep : توسط این متد میتوانید اجرای Thread را برای پاره ای از زمان (برحسب میلی ثانیه) به حالت تعلیق دربیاورید .
اولویت بندی Thread ها :
شما کنترل بیشتری بر روی Threadها دارید و میتوانید مقدار زمانی که هر Thread نسبت به دیگر Thread ها دریافت میکند را از طریق خاصیت Priority تنظیم نمایید . این خاصیت توسط یکی از ثابت های شمارشی زیر که عضوی از ThreadPriority میباشد تنظیم میشود :
ThreadPriority.AboveNormal : اولویت بالاتری به Thread میدهد .
ThreadPriority.LowerPriority : اولویت پایین تری به Thread میدهد .
ThreadPriority.HighestPriority : بالاترین اولویت را به Thread میدهد .
ThreadPriority.LowestPriority : پایین ترین اولویت را به Thread میدهد .
ThreadPriority.Normal : تولویت نرمال را به Thread میدهد .
پیدا کردن وضعیت Thread :
وضعیت یک Thread را میتوانیم به وسیله خاصیت ThreadState به دست بیاوریم که به وسیله یکی از ثابتهای شمارشی System.Threading.ThreadState معین میگردد .
System.Threading.ThreadState.Initialized : بیان میکند که Thread مقداردهی اولیه شده اما هنوز شروع نگردیده است .>System.Threading.ThreadState.Ready : Thread آماده است .
System.Threading.ThreadState.Running : بیان میکند که Thread در حال اجرا است .
System.Threading.ThreadState.Standbye : بیان میکند که Thread در حالت آماده به کاراست .
System.Threading.ThreadState.Initialized :بیان میکند که Thread به پایان رسیده است .
System.Threading.ThreadState.Transition : بیان میکند که Thread بین دو وضعیت بوده و در حالت انتقال از وضعیتی به وضعیت دیگر است .
System.Threading.ThreadState.Unknown : بیا میکند که وضعیت Thread معلوم نیست .
System.Threading.ThreadState.Wait : بیان میکند که Thread در حالت انتظار است .
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
Dim Thread1 As New Threading.Thread(AddressOf test)
Thread1.Start()
Dim Thread2 As New Threading.Thread(AddressOf test)
Thread2.Start()
End Sub
Public Sub test()
MsgBox("test")
End Sub Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
test()
test()
End Sub
Public Sub test()
MsgBox("test")
End SubGTCMPS94 (سيستم هاي كنترل توزيع شده DCS)
مقدمه
يكي از مقوله هايي كه امروزه در زمينه اتوماسيون مورد توجه قرار گرفته است ، مسئله ايجاد شبكه كامپيوتري براي كنترل فرآيندهاي صنعتي است ، يكي از اين سيستمها، سيستم كنترل توزيع شدهDCS ميباشد .
پيشرفت سريع كامپيوتر و كاربرد آنها در سيستم هاي كنترل ، در چند سال اخير افزايش حيرت انگيزي كرده است ، اين پيشرفت سريع در كشور ما نيز با سرعت كمتري نفوذ كرده و بسياري از كارخانجات كشور مجهز به سيستم هاي كنترل كامپيوتري گسترده و نيمه گسترده شده اند.صنعت توليد برق بي شك يكي از پيشگامان اين عرصه مي باشد .
تحقيق زير مطالب جمع آوري شده و انتخاب شده اي از مدرك Elsag Bailey process automation و جزوات I&C Maintenance و مدارك بهره برداري ابزار دقيق توربين گاز V94 و مدارك گسسته شركت Ansaldo و تجربيات عملي ميباشد .
فصل 1 - GTCMPS94
سيستمي الكترونيكي بوده كه صرفاً به منظور كنترل نظارت و حفاظت توربوژنراتور V94.2 به كار گرفته شده است . سيستم GTCMPS94 يك سيستم كنترل توزيع شده (DCS) ميكروپروسسوري ميباشد كه در اين تحقيق سعي شده است قسمتهاي مختلف آن بررسي گردد .
تمامي تجهيزات سخت افزاري اين سيستم در تابلوهاي اتاق كنترل واحد نصب گرديده اند .
GTCMPS94 در پردازش ، مدارهاي واسط ، ارتباطات و منبع تغذيه داراي افزونگي ( Redundant ) مي باشد .
GTCMPS94 به منظور كنترل تمام اتوماتيك مجموعه توربين گاز و ژنراتور و انجام وظايف اصلي زير طراحي شده است :
- راه اندازي ، بهره برداري ، و Shut-down خودكار
- كنترل راه انداز (Drive Control)
- كنترل سوخت
- اتصال واحد به شبكه (Synchronization )
- نظارت (Monitoring)
- حفاظت توربوژنراتور
ساختار شبكه استفاده شده براي اين سيستم بر اساس استاندارد TCP/IP مي باشد
پيكر بندي استاندارد سيستم
ساختار GTCMPS94 شامل :
• يك مجموع از تابلوها ، شامل بردهاي ميكروپروسسوري ، افزونگي منبع تغذيه ، بردهاي I/O و اتصالات
• ايستگاه واسط اپراتوري (Operator Interface Unit ياOIU ) نوع Stand-alone براي اتاق كنترل واحد شامل مونيتور ، صفحه كليد ، موس و چاپگر آلارم ( براي هر واحد )
• ايستگاه واسط اپراتوري نوع روميزي (Desk Top) براي اتاق كنترل مركزي شامل مونيتور ، صفحه كليد موس وچاپگر آلارم ( براي هر واحد )
• يك كنسول مهندس شيفت براي هر نيروگاه بايد در نظر گرفته شود . كنسول سرمهندس شيفت امكان هر گونه دسترسي به سيستم را در اختيار بهره بردار قرار مي دهد . اين كنسول بايد توانايي كنترل و نظارت بر هر يك از توربين هاي گازي مدول را داشته باشد . Refresh Time اين كامپيوتر براي صفحات تصويري حداكثر 2 ثانيه است .
• يك ايستگاه كاري مهندسي به عنوان يك دستگاه ويژه تعميرات كه مي تواند براي مجموعه نيروگاه در نظر گرفته شود اين كامپيوتر در يك اتاق مخصوص ( جنب اتاق فرمان اصلي نيروگاه ) قرار مي گيرد و مي تواند دسترسي به همه مدول هاي متصل به سيستم را با امكانات ويژه خود فراهم سازد . اين امكانات شامل سفارشي كردن سيستم ، اصلاح اطلاعات پيكر بندي ، ايجاد صفحات جدد تصويري يا اصلاح صفحات قديمي و انجام هر گونه برنامه هاي عيب يابي و تشخيص خطا مي باشد.
• SER براي 128 سيگنال با دقت زماني 1 msec .
• تابلوي توزيع انرژي
• تابلوي ابزار دقيق نظارتي توربين
GTCMPS94 از طريق شاهراه اطلاعاتي اجازه اتصال و توسعه سيستم به ايستگاه واسط اپراتور راه دور و يا سيستم هاي خارجي مرتبط با ساير واحدها را مي دهد .
ساختار سيستم بايستي بر مبناي استفاده از ريز پردازنده هاي 32 بيتي با سطح افزونگي تشريح شده در زير باشد . همچنين سيستم بايد توانايي مديريت 1800 ورودي / خروجي با 20% ظرفيت يدكي ، كه 10% آن نصب و تست شده است داشته باشد .
براي اطمينان از صحت عمل سيستم كنترل ، GTCMPS94 داراي افزونگي در سطوح زير مي باشد .
• پردازش ها
• مدارهاي واسط
• ارتباطات
• منبع تغذيه
كليه وظايف كنترل ، حفاظت و نظارت در كارت هاي پردازش كننده (MFP) با افزونگي دو تايي اجرا مي گردند پيكر بندي سخت افزاري به صورت Hot-Stanby مي باشد .
در اين جفت پردازشگر ، يكي از پردازشگرها به صورت فعال و ديگري به صورت پشتيبان عمل مي كند . درحالت عادي MFP اوليه كار عادي خود را انجام داده و MFP ديگر به صورت Hot-Stanby مي باشد به اين معنا كه چنانچه MPF اوليه دچار خرابي شود ،MFP دوم بدون هيچگونه اختلاف در روند كنترل اتوماتيك وارد عمل شده و كنترل سيستم را به عهده مي گيرد ، در چنين مواردي يك آلارم در سيستم فعال مي گردد . در اين حال MFP خراب را در حين كار واحد ، بدون هيچ مشكلي مي توان تعويض نمود .
منبع : http://www.autoir.com/page.php?id=97
چرا دو پردازنده بهتر از یك پردازنده است...
|
برای بالا بردن قدرت كامپیوتر، مردم به لطایفالحیل زیادی متوسل میشوند، كه یكی از متداولترین آنها، دو قلو كردن، یا سه قلو كردن، یا حتا چهار قلو كردن پردازندههاست. |
|
Symmetric MultiProcessing (SMP)
منبع: |
Code Mobility and Session State
Code mobility as provided for by Request Based Distributed Computing RBDC (see backgrounder) is key for delivering On-Demand computing, Distributed Computing (e.g. SETI@home) and Rich Internet Applications.
RBDC enables the mobility of code that gets its input from http sources (url, request body, cookie, and passwordless GETs). This post looks into whether session state can be made mobile as well.
In a typical scenario, http servers associate session state with client request streams through the use of a server-unique session-id that is preserved between accesses via a cookie. An example of this is PHP’s handling of sessions. Under this scheme the server held session state prevents the code being mobile. The code is not mobile because the session state is only available in the server that generated the client’s requested resource.
Using RBDC, code that relies on session state can be made securely mobile. Here is one way.
[[Since writing this post, I have realised that the mechanism described here is the same mechanism that makes Google Reader Public Pages both globally available and private.]]
Firstly, the server stores the session state using a globally-unique-id (GUID) insead of server-unique-id as the key. The key is preserved between requests in the client cookie as is now done. Then the server makes the session state publically available at a well known URL. For example, an xml serialised version of the state could be GET and POSTable at a URL like https://www.myserver.com/sessionstate. The GUID used is sufficiently long to prevent guessing and therefore session state will be securely and globally available.
With session state stored in such a secure and globally available fashion, code that requires session state may also be mobile.
منبع : http://www.davidpratten.com
اعمال هم زمان در پایتون ( بخش دوم )
استفاده از تکنیک چند نخی رو ساده تر کنه.
استفاده از تکنیک چند نخی رو امن تر کنه.
تغییر در مفسر رو راحت تر کنه.
توسعه ی مفسر رو راحت تر ساده تر کنه.
اما از طرفی هم :
نمی ذاره چند نخ به طور هم زمان اجرا بشن و فقط می تونه همزمانی رو شبیه سازی کنه.
نمی تونه از پردازنده ها و یا هسته های اضافی CPU استفاده کنه و همه ی کارها رو روی یه هسته انجام میده.
یه نکته ای که قابل ذکر هستش اینه که مفسر به کدهای خارجی کاری نداره. مثلا اگه تولکیت Qt از چند نخی استفاده می کنه, استفاده از اون در پایتون باعث تحت پوشش قرار گرفتن کار Qt توسط GIL نمیشه و اون خیلی راحت می تونه به طور واقعی از چند نخی استفاده کنه. البته موقع نوشتن رابط پایتون برای همچین برنامه هایی باید به یه سری نکاتی هم توجه بشه تا باعث به وجود اومدن مشکل نشه.
کاربران پایتون خواستار برداشته شدن این ساختار از مفسر هستن تا بتونن به طور واقعی از چند نخی استفاده کنن و همچنین از منابع اضافی مثل CPU های چند هسته ای هم بهره ببرن. ولی به دلایلی این کار به همین راحتی ها قابل انجام نیست:
GIL در سرتاسر مفسر استفاده شده و حذف اون اصلا ساده نیست.
حذف GIL می تونه باعث بشه مفسر یه بار دیگه از نو نوشته بشه.
از این به بعد دیگه باید مثل C++ خودتون مسئول مدیریت نخ هاتون باشید.
تمام توسعه های پایتون باید از اول نوشته بشن چون همشون بر پایه GIL هستن.
امکان داره مقدار زیادی سرعت رو از دست بدید!
این مورد آخر یک بار زمانی که پایتون در نسخه ی 1.5 قرار داشت آزمایش شد. یعنی GIL از مفسر حذف شد و باعث شد سرعت اجرای برنامه ای با یک نخ در پایتون به نصف سرعت قبلی برسه و چون خیلی از برنامه های پایتون از چند نخی استفاده نمی کنن این کار زیاد هم به صرفه نیست. اما امیدوارم این صحبت ها باعث نشه که فکر کنید در پایتون نمیشه از عملیات همزمانی واقعی استفاده کرد و یا فقط باید به یه CPU بسنده کرد. زبان پایتون نیازی به GIL نداره, این فقط پیاده سازی CPython که از این روش استفاده میکنه و شما توی Jython همچین چیزی رو ندارید. تو مقاله های بعدی بیشتر در مورد این زمینه ها صحبت میکنیم و راه حل های این مشکل رو مورد بررسی قرار میدیم.
اعمال هم زمان در پایتون (بخش اول)
Architecting Server/Client Convergence
In this post I argue that the current convergence of Desktop and / Web Apps (RIAs) suggests a convergence of Server and Clients and that this opens up some interesting possibilities.
I have been following an interesting series of posts by Arnon Rotem-Gal-Oz on the web/desktop convergence trend (all four posts are worth reading!). As well, in January and April, Arnon observes software converging towards:
Technologies competing for the privilege of delivering some or all of this trifecta include (but are not limited to) AJAX, Adobe Flex, Flash, Adobe Air, Microsoft Silverlight, JavaFX, Google Gears, Mozilla Prism, Aptana’s Jaxer and JNext.
These technologies are being developed in the context of increasing awareness of two trends 1) the possibilities of ‘on-tap’ cloud computing and simultaneously 2) the promise of 100’s of cores in our client computers.
Here are some observations about the current web-app situation:
What we are seeing is not just a Web/ Desktop Convergence but also the possibility of Server/Client Convergence.
This convergence has the potential to address another problem in the current state of affairs with web apps:
Actually, this is one of the drivers underlying Microsoft Volta - a technology that is designed to reduce the cost of reassigning portions of an application between server and client. However as Arnon has pointed out it does not provide an abstraction that reinforces the “coarse-grained interface” that works well in the context of the fallacies of distributed computing. Unlike Volta, tier-agnostic requests relies on the same coarse grained interface as AJAX.
Convergence of server and client technologies
However, the convergence of server and client technologies opens up the possibility for Request Based Distributed Computing and tier-agnostic requests to provide a simple mechanism for delaying architectural decisions to run-time as well as supporting:
منبع : http://www.davidpratten.com
Adaptive control of Request Based Distributed Computing
The purpose of this post is to illustrate the possibility for autonomic computing inherent in Request Based Distributed Computing (RBDC).
This is how I summarised RBDC in a recent post:
Request Based Distributed Computing is a small extension of the http protocol and notion of server, proxy and client. Rich Internet Applications, SOA architected applications and SETI@home type distributed computing alike can utilise a common unified programming model. No longer will technology dictate the locus of code execution - instead issues like availability of computing power, intellectual property and security will dictate this at run time.
This discussion focuses on the way that RBDC creates two ways to satisfy many http requests. The two ways are illustrated in the following two diagrams. These diagrams are similar to those in a earlier discussion.
In the first scenario (DIAGRAM 1) we see a client requesting resource A and evaluating code locally to satisfy its own http request.
DIAGRAM 1
In the second scenario (DIAGRAM 2) we see the same client. However in this case, when the client requests resource A, the client does not tell the server about it’s local computing capacity. In this case the relevant code is evaluated on the server.
DIAGRAM 2
The two ways of satisfying the request have differing performances. The relative performance of the two alternatives will be determined by things like the server/client balance of: response time, network bandwidth, and network latency.
A monitor can observe the time to complete each http request and recommend to the client whether to request mobile code or to let the server evaluate the code that generates the resource. This is an adaptive process because during a 24 hour period server availability, network latency and available bandwidth could change radically. Once the monitor has decided on the fastest way to execute a piece of mobile code, it may attempt the evaluation of mobile code in the opposite way once every N requests - in this way keeping its adaptive capability current.
منبع : http://www.davidpratten.com
Distributed Computing with the Browser
Recently, Subbu posted an interesting discussion of an xml analysis and presentation application - you can read it here: Distributed Computing with the Browser.
This design scenario is a good illustration of the limitations of our current situation with programming . Our current situation is that while the WWW allows a programmer to ignore the network path to an information resource, as programmers, we can’t ignore where computing will be done. The programmer’s choice of technology (framework, language etc etc) carries with it the implicit choice about the location of computation (server or client).
An assumption behind Subbu’s post is that we need to decide the location of processing during the design phase. The purpose of this post is explore how the application could be built using Request Based Distributed Computing RBDC (see backgrounder). With the application recast as a RBDC application, the location-of-processing decisions can be made at runtime based on the availability of computing power and storage, intellectual property, and security issues.
(This description presumes that you have read the RBDC backgrounder.)
The key distributed process in this application is the initial analysis of the source XML text, and the saving of the key features into a central database. Lets call this “analyse-save”. With RBDC, the code that performs analyse-save may be written as mobile code that will run on either the server, a proxy or on the client. Analyse-save may be implemented as the code that responds to a http POST request that uploads the source file to the server. It analyses the uploaded file then POSTS the results of the analysis to a central database.
When a RBDC compliant server receives the analyse-save request it may perform the analysis itself on the server or otherwise return the analyse-save code to the client. If the client receives code as a response to its analyse-post request then it would execute the code locally. In either case, the results of the analysis are POSTed to the central database using http.
Clients that have local processing capabilities signal through a http header in the POST request that they are able to accept mobile code as a response to the request. Alternatively clients without processing ability can make the same request signalling that they need the server to do all possible processing.
In this way - the architecture of the solution is the same for Subbu’s cases 1 and 3 with the decision about location of processing being made at runtime, not as part of the design.
منبع : http://www.davidpratten.com
سیستم های ردیابی و کشف نفوذ توزیع شده که با dIDS از آن یاد می کنیم،از چندین IDS در یک شبکه بزرگ تشکیل شده اند. تمامی این Intrusion Detection System ها، در ارتباط با یدیگر هستند و یا به وسیله یک سیستم (شاید یک سرور) مرکزی در حال پایش شبکه، تحلیل رویدادها و جمع آوری اطلاعات حمله های شناسایی شده، می باشند. این ترکیب برای جمع آوری اطلاعات امکان ایجاد یک دید وسیع برای تیم امنیتی/نگهدارنده شبکه در مورد وقایعی که در هر لحظه در حال جریان است را فراهم می کند.
یک distributed IDS به سازمان ها و اپراتورهای شبکه اجازه می دهد تا به صورت موثر و مستند منابع شبکه ای و سازمانی خود را تحت کنترل قرار دهند و در صورت نیاز به سرعت اطلاعات مورد نیاز را از سیستم بیرون بکشند. برای آشنایی بیشتر مقاله زیر را بخوانید:
An Introduction To Distributed Intrusion Detection Systems
Due to the greater view the agent allows the analyst to achieve, the dIDS offers the incident analyst many advantages over other single mode IDS systems. One of these advantages is the ability to detect attack patterns across an entire corporate network, with geographic locations separating segments by time zones or even continents. This could allow for the early detection of a well-planned and coordinated attack against the organization in question, which would allow the security people to ensure that targeted systems are secured and offending IPs are disallowed any access. Another proven advantage is to allow early detection of an Internet worm making its way through a corporate network. This information could then be used to identify and clean systems that have been infected by the worm, and prevent further spread of the worm into the network, therefore lowering any financial losses that would otherwise have been incurred.
تبادل اطلاعات بین IDS ها در سه گونه تقسیم بندی می شود. دسته اول محصولاتی که برای dIDS طراحی شده اند و با استفاده agentهای مختلف در نقاط مختلف شبکه اطلاعات را برای سرور کنترلی IDS ارسال می کنند. دسته دوم محصولاتی که شامل IDS هایی از یک دسته هستند و لاگ فایل های خود را در یک محل متمرکز ذخیره می کنند و مانند دسته اول ادامه کار می دهند. و بالاخره دسته سوم که شامل IDS ها و IPS های (به طور کلی آن ها را sensor خطاب می کنیم.) مختلف از مارک های متفاوتی هستند که به وسیله ابزار های مدیریت سیستم های امنیتی لاگ فایل ها را ذخیره و پردازش می کنند. استاندارد تبادل اطلاعات در سنسور ها، در قالب یک پیش نویس استاندارد IETF در حال شکل گیری است.
The Intrusion Detection Message Exchange Format (IDMEF) is intended to be a standard data format that automated intrusion detection systems can use to report alerts about events that they deem suspicious. The development of this standard format will enable interoperability among commercial, open source, and research systems, allowing users to mix-and-match the deployment of these systems according to their strong and weak points to obtain an optimal implementation.
به دو علت پروژه های کمی در مورد dIDS هم اکنون وجود دارد. اولین مورد عدم درک نیاز به چنین سیستمی در بخش تجاری و صنعتی و دلیل دوم نو بودن چنین ترکیبی است. همانطور که پیشتر گفتم، IDMEF هنوز به حالت استاندارد در نیامده است. البته جایگزینی این سیستم به وسیله سیستم های یکپارچه مدیریت امنیت گران قیمت نیز دلیل دیگری در کم بودن پروژه ها است. تعدادی از این پروژه ها را در freshmeat ببینید. بدنیست نگاهی هم به پروژه رو به پیشرفت Prelude Hybrid IDS ( حداقل What is Prelude Hybrid IDS را بخوانید.) بندازید.
* این مطلب مقدمه ای است برای سری نوشته های امنیت در عمق که در Secure2S بیشتر در مورد آن ها خواهید خواند. لطفا نظرات و پیشنهادات خود را در میان بگذارید. مجموعه نوشته های امنیت در عمق، تلاش خواهد کرد تا به امنیت در شبکه های بزرگ و تجاری و همچنین نکات امنیتی که کمتر به آن ها پرداخته می شود بپردازد.
منبع : http://secure2s.net/fa/1385/11/11/distributed-ids/
بیتتورنت چیست؟
بیتتورنت (BitTorrent) هم نام برنامه کاربردی مشتری بر مبنای توزیع فایل در شبکههای نظیر-به-نظیر است و هم نام یک پروتکل اشتراک فایل، که هر دو در آوریل 2001 توسط برنامهنویسی به نام برام کوهن ایجاد شدهاند. بیتتورنت به منظور توزیع حجم بزرگی از اطلاعات بدون کاهش در مصرف منابع پر هزینه سرور و پهنای باند طراحی شده است.
بیتتورنت چیست؟
اصطلاحات BitTorrent
منبع: wikipedia
Parallel and Distributed Processing Group -- GPPD
UFRGS - Universidade Federal do Rio Grande do Sul
Institute of Informatics
History
Parallel and Distributed Processing Group (GPPD) is a research group which has several projects concerning parallel and distributed processing. It is located within the Institut of Informatics, at UFRGS, Brazil. GPPD has started its history during 80's with the return of prof. Philippe Navaux from his doctorate in France. Initially, the research was focused on computer architectures, parallel processing and performance evaluation. With the return of prof. Claudio Geyer from Grenoble (France) in 1991, the group was named GPPD, integrating research topics redarding parallel and distributed processing. In 1995, with the conclusion of the Tiaraju Diverio's doctorate, the group has included research about high performance applications, parallel algorithms and computational complexity, as well as the creation of high performance processing courses and events.
The GPPD has always maintained close relations with French Universities and Laboratories through international cooperation projects. Joint researches originated from such projects made possible the doctorate of several researchers with master degree from UFRGS. Besides France, GPPD has nowadays copperations with several countries, such as Germany, United States, England, Spain and others.
During last years, the parallelism has been proposed as the main solution to increase computing systems performance. Several parallel machines based on new architectures have emerged on the market. However, in these architectures there are programming and management difficulties greater than those found in sequential machines. The XXI century has been marked by growing advance of cluster computing. This architecture is composed by simple machines interconnected through high performance network, allowing the assemblage of low cost systems that offer better computational power.
The complexity regarding development of distributed systems is a serious problem in those architectures usage. Sometimes, programmers must know some internal details about the operating system and its communication subsystem. Thus, parallel and distributed system development is a more complex task than sequential one and it can be simplified using adequate software tools.
GPPD considers solutions and alternatives from problems involved on parallel and distributed applications development. Following this idea, the group has different research approaches: heterogeneous network operating system (HetNOS project), parallelism and distribution exploration in logic programming (OPERA project), to foment and to develop cluster technologies (LabTec project), development of middleware for grid and mobile computing (ISAM project), web services-based Portal to unify the access to multiple clusters (JavaWSPad project).
Cluster and Grid computing
Image processing
Mobile and Ubiquitous Computing
Object-oriented distributed languages
Parallel and distributed algorithms
Parallel Prolog
Performance evaluation
Simultation and Games
Processor Architecture
Tools and environments for parallel and distributed programming
Visual debugging and programming
APSE - Superscalar Processor Architectures
DECK - Distributed Execution and Communication Environment (as part of MultiCluster project)Direto - Advanced Systems for Email, Agenda and CatalogDisperso - Distributed and Parallel Environments and SystemsDPC++ - Distributed Processing in C++ (as part of MultiCluster project)MultiCluster - Support for Parallel Programming on Multiple Clustersمنبع : http://gppd.inf.ufrgs.br
سیستم های مبتنی بر پردازندههای 4 هسته ای
پردازندههاي 4 هسته اي
شركت اينتل اولين پردازنده چهار هسته اي خود را در اواخر سال گذشته ميلادي معرفي كرد. واقعاً هدف اينتل از معرفي اين محصول جديد چيست؟
شما در ماههاي آينده اولين بازيهاي كامپيوتري كه توانايي استفاده از 4 هسته را دارند مشاهده خواهيد كرد. بازيهاي نظير RTS, Supreme Commander, Half-Life 2 Episode 2, Unreal Tournament 2007و Crysis كه در سال 2007 معرفي خواهند شد قادرند از تمامي تواناييهاي يك پردازنده 4 هسته اي استفاده كنند. علاوه بر بازيهاي كامپيوتري برخي از برنامههاي صوتي و تصويري و برنامههاي كه تصاوير سه بعدي را خلق ميكنند نيز نظير Adboe Premiere Pro 3.0 Pinnacle Studio 10 , و 3D Studio Max 8/9 نياز به پردازندههاي چند هسته اي دارند.
CPU جديد، هسته قبلي
پردازندههاي 4 هسته اي حال حاضر اينتل مبتني بر هسته جديدي بنام Kentsfield هستند كه نخستين بار توسط اينتل در پردازنده Core 2 Extreme QX6700 بكار گرفته شد. هسته Kentsfield در حقيقت از دو هسته Conroe كه در يك بستهبندي قرار گرفته، تشكيل شده است.
با توجه به اين موضوع و همانطور كه از نام پردازنده Core 2 Quad Q6600 مشخص است، اين پردازنده از دو پردازنده Core 2 Duo 6600 تشكيل شده است و پردازنده Core 2 Extreme QX6700 شامل دو پردازنده Core 2 Duo E6700 است. بنابراين Core 2 Quad Q6600 داراي فركانس 2/4 گيگاهرتز و Core 2 Extreme QX6700 داراي فركانس 2/66 گيگاهرتز است. هر دوي اين پردازندهها از FSB 1066 مگاهرتز و حافظه نهان سطح 2 مگابايت (2 عدد كش 4 مگابايتي) استفاده ميكنند.
در آزمايشات انجام گرفته روي پردازندههاي چهار هسته اي، در برخي از بازيها پردازندهي چهار هسته اي QX6700 كارايي دو برابر سريعتر از پردازنده Core 2 Duo E6700 از خود به نمايش گذاشته است و در چندين آزمايش نيز كارايي دو برابر پردازنده Core 2 Extreme X6800 ارايه كرده است.
 |
 |
پردازندههاي 4 هسته اي داراي مصرف برق متفاوتي نسبت به پردازندههاي دو هسته اي هستند. اين توان متفاوت موجب شده تا اكثر مادربردهاي كه از پردازندههاي Core 2 Duo پشتيباني ميكنند قادر به پشتيباني از پردازندههاي چهار هسته اي نباشند. بنابراين اگر قصد خريد پردازنده 4 هسته اي داريد و يا اگر به فكر ارتقا پردازنده سيستمتان در آينده هستيد حتماً در هنگام خريد مادربرد به قابليت پشتيباني از پردازندههاي 4 هسته اي آن توجه كنيد.
شركت گيگابايت يكي از چند سازنده مطرح مادربرد است كه در حال حاضر محدوده وسيعي از مادربردهايي را كه قادرند تا از پردازندههاي 4 هسته اي پشتيباني كنند معرفي كرده است.
از بين مادربردهاي موجود در اين ليست مادربرد 965P-DQ6 قادر است از پردازندههاي 4 هسته اي آينده اينتل نيز پشتيباني كند. اين مادربرد از چيپست 965P اينتل استفاده كرده و داراي خازنهاي حالت جامد است. اگر به مادربردهاي موجود در ليست بالا دقت كنيد متوجه خواهيد شد كه تمامي مادربردهاي موجود در اين ليست بجاي خازنهاي الكتروليتي از خازنهاي حالت جامد استفاده كردهاند.
منبع : http://www.avajang.com
High Performance SSH/SCP - HPN-SSH
SCP and the underlying SSH2 protocol implementation in OpenSSH is network performance limited by statically defined internal flow control buffers. These buffers often end up acting as a bottleneck for network throughput of SCP, especially on long and high bandwith network links. Modifying the ssh code to allow the buffers to be defined at run time eliminates this bottleneck. We have created a patch that will remove the bottlenecks in OpenSSH and is fully interoperable with other servers and clients. In addition HPN clients will be able to download faster from non HPN servers, and HPN servers will be able to receive uploads faster from non HPN clients. However, the host receiving the data must have a properly tuned TCP/IP stack. Please refer to this tuning page for more information.
The amount of improvement any specific user will see is dependent on a number of issues. Transfer rates cannot exceed the capacity of the network nor the throughput of the I/O subsystem including the disk and memory speed. The improvement will also be highly influenced by the capacity of the processor to perform the encryption and decryption. Less computational expensive ciphers will often provide better throughput than more complex ciphers.
With many high bandwidth connections, there is a performance gap between what SSH is capable of and what the network link has the capacity to do. The difference between these two numbers is the performance gap, or the underutilized portion of your network connection. This gap, in most situations, is the direct cause of undersized receive buffers in the SSH congestion control mechanism. The graph below shows the optimal receive buffer versus the effective SSH channel receive buffer for various round trip times along a 100Mbps path
The effect of raising the SSH buffer sizes can be seen in the following chart. The standard SSH throughput, represented by the red columns, closely matches the expected throughput for this path if the receive buffer was limited to 64KB. By increasing the size of the SSH channel receive buffers throughput, represented by the blue columns, improved by as much as 1000%. The variation now seen is due to the complexity of the cipher and the limits of the hard drive.
All patches should be applied to the OpenSSH source files using the 'patch' utility from the command line. Building SSH from source is actually quite easy and the recommended method. Some binary packages will be made available as a convenience but will not be officially supported.
Solaris Users: Some versions of Solaris use an older version of the patch and diff commands which are incompatible with this patch. Please make sure you are using a recent version of gnu patch.
This is the 1st revision of the 13th major version of the HPN patch set. The HPN12 patch set remains available here. There are two fundamental differences between the HPN12 and HPN13 patch set. The most significant of these is the inclusion of the Multi-Threaded AES-CTR (MT-AES-CTR) mode cipher. A paper and presentation about this work are available.
This cipher mode introduces multi-threading into the OpenSSH application in order to allow it to make full use of CPU resources available on multi-core systems. As the canonical distribution of OpenSSH is unable to make use of more than one core, high performance transfers can be bottlenecked by the cryptographic overhead. HPN12 dealt with this by the introduction of None Cipher Switching. However, this technique is limited to those users who are willing to allow their data to be transferred without encipherment. It also was, by design, limited to bulk data transfers which further restricts its value to some users. The MT-AES-CTR mode will allow users, on multicore platforms, to attain throughput rates comparable or equal to unencrypted data transfers. In both lab and real world tests throughput at full GigE line rates, with full encryption, were commonly seen.
MT-AES-CTR produces a cipherstream that is indistinguishable from the distributed Single Thread AES-CTR (ST-AES-CTR) mode cipher and is, to our knowledge, completely compatible with all other AES-CTR mode implementations. In other words, its completely backward compatible and will function in heterogenous connections with no problem. However, it is important to note MT-AES-CTR does impose additional overhead and may impose a performance penalty on single core machines. Additionally, the MT-AES-CTR mode cipher replaces the default ST-AES-CTR mode cipher. We are in the process of developing a method to allow user switching between the two modes. Additionally, this does rely on posix threads so you need to be sure they are properly supported in the target OS.
The second major difference is in the way in which the HPN patch set will be made available. HPN13 will be provided as both a 'kitchen sink' and 'a la carte' distribution. The kitchen sink distribution will incorporate the dynamic window patches, none cipher switching, MT-AES-CTR mode ciphers, peak throughput display in SCP, and extended server side logging. The a la carte distribution will make each of these available as distinct patches which can be used independently of each other.
Note: This patch has been gziped. You must gunzip it before applying it.
| OpenSSH Version | HPN-SSH Patch |
| OpenSSH 4.7p1 | OpenSSH-4.7p1-hpn13 v1 |
These are the a la carte patches and some of the version numbers may skew from time to time. For example, if the peak throughput patch doesn't need to be updated for various OpenSSH releases the patch number won't be updated. Not all of the patches are available just yet, as the NONE cipher switching still needs to be broken out from the HPN12 patch set.
| Patch | Description | Source |
| Dynamic Windows and None Cipher | This is a basis of the HPN-SSH patch set. It provides dynamic window in SSH and the abilityt o switch to a NONE cipher post authentication. Based on the HPN12 v20 patch. This patch is gziped. For OpenSSH 4.7p1. | openssh4.7-dynwindow_noneswitch.diff.gz |
| Threaded CTR cipher mode | This patch adds threading to the CTR block mode for AES and other supported ciphers. This may allow SSH to make use of multiple cores/cpus during transfers and significantly increase throughput. This patch should be considered experimental at this time. | openssh4.7-CTR-threading.diff |
| Peak Throughput | This patch modifes the progress bar to display the 1 second throughput average. On completion of the transfer it will display the peak throughput through the life of the connection. For OpenSSH 4.7p1. | openssh4.7-peaktput.diff |
| Server Logging | This patch adds additional logging to the SSHD server including encryption used, remote address and port, user name, remote version information, total bytes transferred, and average throughput. In order to use this patch you *must* direct syslogd to use an additional logging socket. This socket will be located in the sshd chroot, typically /var/empty. As such you will need to create a /var/empty/dev directory and add '-a /var/empty/dev/log' to your syslogd configuration. Example output can be seen here For OpenSSH 4.7p1. | openssh4.7-server-logging.diff |
How to apply the patches.
1. Get the OpenSSH source code from OpenSSH.org.
2. Untar OpenSSH source.
3. cd into the OpenSSH source directory
4. If gzipped type 'zcat pathtopatch/patchfile | patch'
Otherwise 'patch < pathtopatch/patchfile'
5. type 'configure && make'
6. type 'make install'
Multi-Threaded SSH/SCP
Chris Rapier has presented a paper describing how to dramatically increase the speed of SCP networks. It appears that because SCP relies on a single thread in SSH, the crypto can sometimes be the bottleneck instead of the wire speed. Their new implementation (HPN-SSH) takes advantage of multi-threaded capable systems dramatically increasing the speed of securely copying files. They are currently looking for potential users with very high bandwidth to test the upper limits of the system.
http://www.psc.edu/networking/projects/hpn-ssh/
تکنولوژی بکار رفته در cpu های دو هسته ای
در چندین ماه گذشته پیشرفت های جدیدی در طراحی پروسسورها، بویژه از طرف شرکت AMD حاصل شد. این شرکت علاوه بر اینکه یک cpu با طراحی کاملا ْ۶۴ بیتی عرضه کرد که باعث برتری یافتن این شرکت در بازار کامپیوترهای رومیزی پیشرفته گردید، همچنین در حذف کنترل کنندههای حافظه (MCH) پیشقدم شد که در عملکرد Athlon ۶۴ و چیپهای optron یک پیشرفت قابل ملاحظه نسبت به پروسسورهای intel به حساب میآید. اینتل به طور متقابل پروسسور سازگار ۶۴ بیتی را عرضه نمود. به تازگی نیز هر دو شرکت پردازشگرهای دوهسته ای را عرضه نمودهاند، این پروسسورها بهتر از آن چیزی که شما انتظار دارید کار میکنند. پروسسورهای اینتل و AMD هر دو دارای دو هسته پروسسور، در حال کار در یک قالب میباشند که هر یک از هستهها بصورت مستقل توابع و پردازشهای داده را انجام میدهند (در مورد اینتل این مورد کامل تر است) و هر دو این هستهها توسط نرم افزار سیستم عامل هم آهنگ می گردند.
در این مقاله سعی شده تا تکنولوژی که در این دو محصول استفاده شده و مقدار افزایش کارایی که شما می توانید از آنها انتظار داشته باشید بررسی گردد. در حال حاضر AMD فقط پروسورهای کلاس سرور opteron با دو هسته را بطور کامل به بازار عرضه کرده و بزودی Athlon ۶۴*۲ برای کامپیوترهای رومیزی را نیز به بازار عرضه میکند. در طرف مقابل اینتل در حال حاضر پنتیوم Extreme Edition ۸۴۰ رومیزی با دو هسته را به بازار عرضه نموده در حالی که خطهای تولید Pentium D و dual xeons هنوز متوقف نشده اند.
با توجه به اینکه پروسسورهای دو هستهای در اصل یک سیستم چند پروسسوره که در یک قالب قرار گرفته اند، می باشد. اجازه بدهید اینک چندین تکنولوژی که در سیستم های چند پردازشگر استفاده می شود را مورد بررسی قرار دهیم.
چند پردازشگرهای متقارن ( SMP (symmetric Multi processing
SMP روش مشترکی می باشد که چندین پردازشگر بطور جداگانه با یکدیگر در یک مادربرد کار میکنند. سیستم عامل با هر دو cpu تقریباً بطور یکسان کار میکند و کارهای مورد نیاز را به آنها ارجاع میدهد. چیپهای دوهسته ای جدید intel و AMD توانایی SMP را بصورت داخلی مورد توجه قرار دادهاند. پروسسورهای سرور opteron دوهسته ای میتواند همچنین بصورت خارجی با دیگر چیپهای دوهسته ای ارتباط برقرار کند. (بشرط آنکه چیپ متقابل نیز دارای این خاصیت باشد)
محدودیت اصلیSMP در پشتیبانی سیستم عاملها و نرم افزارها از این تکنولوژی میباشد. خیلی از سیستم عاملها (مانند ویندوز XP سری خانگی ) توانایی پشتیبانی از SMP را ندارند و از دومین پردازشگر استفاده نمیکنند. همچنین بیشتر برنامههای پیشرفته بصورت تک رشته ای کار میکنند، در اصل در هر زمان فقط یک پردازشگر در حالت فعال می باشد. برنامه های چند رشتهای از پتانسیل موجود در سیستمهای دو یا چند پرازشگر، میتوانند نتایج مفیدتری بگیرند، ولی به صورت کامل عمومیت ندارد.
در گذشته intel و AMD سعی داشتهاند تا تکنولوژی جدیدی مثل SMD را بیشتر برای پردازشگرهای سرور پیشرفته مانند opteron و Xeon استفاده نمایند ( البته تا قبل از پنتیوم ۳ )
Hyperthreading
این تکنولوژی بصورت اختصاصی توسط اینتل در پردازشگرهای چند هستهای بکار گرفته شده است. این تکنولوژی قبلاً نیز توسط این شرکت بکار گرفته شده بود. اینتل برای آنکه از منابع CPUبنحو بهتری استفاده نماید فقط قسمتهایی که کار پردازش اطلاعات را انجام می دهد را تکثیر کرده است. یعنی آنکه منابع داده در داخل CPU بصورت مشترک استفاده میشد. ایده hyperthreading برای دو برابرکردن مقدار فعالیت چیپ میباشد تا آنکه کاهش عملکرد سیستم که در اثر فقدان حافظه Cash روی میدهد کمتر گردد همچنین بصورت تئوری نشان داده شده که منابع سیستم کمتر تلف میگردند.
در صورتی که CPU های hyperthreading مانند دو پروسسور حقیقی بنظر می رسد. ولی این CPU ها نمیتوانند عملکردی مشابه دو CPU مجزا مانند CPU های دوهسته ای داشته باشند. زیرا در CPU های دو هسته ای دو “Threads”مشابه بطور همزمان و با Cash های جداگانه L۱ و L۲ میتوانند اجرا گردند که این عمل در پردازشگرهای hyperthreading قابل انجام نمیباشد.
یکی از چیپهای جدید اینتل بنام ، پردازشگر پنتیوم Extreme Edition ۸۴۰ ، در داخل هر هسته خود از تکنولوژی hyperthreading نیز پشتیبانی میکند، یعنی آنکه در یک سیستم عامل آن بصورت چهار پردازشگر حقیقی دیده میشود.
دو چیپ در یک قالب … چرا؟
چرا دو شرکت اینتل و AMD بطور ناگهانی شروع به توزیع پردازشگرهای دو هستهای کردند؟
اول از همه رقابت چنانچه بعداً بیان خواهیم کرد AMD از ابتدا توانائی بالقوه دوهستهای را در پردازشگرهای ۶۴ بیتی خود داشت. ساختمان ورودی و خروجی برای دومین هسته در CPU های فعلی ۶۴ بیتی AMD موجود میباشد.
هیچ شرکتی نمی تواند دیگران را از بدست آوردن تکنولوژیهای جدید منع نماید و AMD در حال حاضر با موفقیت چشمگیر خط تولید پرداشگرهای ۶۴ بیتی آسودگی را از intel سلب نموده است.
برای اینتل ضروری میباشد که دارای یک تولید تخصصی در تکنولوژی دوهسته ای باشد تا رقابت با شرکاء تجاری خود را حفظ نماید.
دوم، کارایی میباشد. مطمئناً برنامههای کاربردی چند رشتهای در پردازشگرهایی که توانایی انجام چند پردازش را دارند در پردازشگرهایی که یک پردازش را در هر زمان انجام میدهند، بهتر عمل خواهند نمود.
البته برای سیستم های چند پردازشگره یک ایراد عمومی وجود دارد و آن تاْخیری میباشد که این CPU ها در اجرای کار سیستم بوجود می آورند. به بیان ساده در حال حاضر روشی برای سیستم عاملهای موجود وجود ندارند تا پردازشها را بطور کاملاً مساوی در بین پردازشگرها تقسیم نماید، پردازشگر دوم عموماً بایک مداخله کمتر و کارایی پایینتر کارمیکند، در صورتی که ممکن است پردازشگر اول بصورت ۱۰۰% در حال پردازش باشد.
سومین دلیل کمتر نمایان است، ناامیدی AMD و اینتل میباشد، هر دو شرکت با یک مانع جدی برای افزایش سرعت پردازشگرها و کوچکتر کردن اندازه قالب آنها روبرو شده اند تا این مانع حذف نشود و یا اینکه تا کاربران عمومی متوجه نشوند که GHZ به تنهایی کارایی را بیان نمیکند. هر دو شرکت برای دست یافتن به هر پیشرفت که کارایی پردازشگرها را بهبود بخشید تلاش خواهند نمود و تقریباً دلیل اصلی بوجود آمدن پردازشگرهای دو هسته ای را میتوان همین دلیل سوم بیان نمود.
دسترسی AMD به تکنولوژی دو هسته ای
فرم فاکتور فعلی پردازشگر ۶۴ اتلن به طراحی دو هسته ای خیلی نزدیک میباشد. وجود کنترل کنندههای Hypertransport و کنترل کننده حافظه درقالب چیپهای فعلی ۶۴ اتلن به معنی آنست که اضافه نمودن دومین هسته در داخل چیپ چندان مشکل نمیباشد.
بدلیل رابط NorthBridge که AMD برای اتلن ۶۴ تهیه کرده است کنترل کننده حافظه و رابط Hypertransport در داخل چیپ پشتیبانی می گردد. این به چیپهای دوهستهای امکان می دهد که از داخل خود پردازشگر با یکدیگر ارتباط برقرار کنند.
تعداد ترانزیستورهای پردازشگرهای اتلن ۶۴*۲ بیش از دو برابر پردازشگرهای اتلن ۶۴ میباشد. با توجه به اینکه در ساختن CPU های جدید از روش ۹۰nm استفاده می شود سایز کل چیپ کمی افزایش پیدا کرده و ولتاژ عملکرد ۱.۳۵ تا ۱.۴ میباشد و گرمای خروجی به بیش از ۱۱۰w کمی افزایش مییابد.
هر هسته پردازشگر حافظه Cash L۱ و L۲ مخصوص به خود را دارد، ۱۲۸ KB برای L۱ و بسته به مدل ۵۱۲ KB تا ۱ MB برای L۲.
دو برتری مهمی که AMD در CPU های دو هستهای دارد عبارتند از اینکه :
“Crossbar Switch” که آدرسها را جمعآوری کرده و توزیع می کند و داده را از هر هسته به هسته دیگر یا باقی سیستم توزیع می کند در حال حاضر امکان اضافه شدن دومین هسته را دارد.
موفقیت دیگر AMD که از نظر مصرف کننده خیلی مهم میباشد امکان استفاده اتلن ۶۴*۲ از مادربردهای سوکت ۹۳۹/۹۴۰ می باشد و فقط لازم است که شرکت تولید کننده مادربرد BIOS را برای پشتیبانی از خصوصیات جدید به روز رسانی نماید.
دسترسی اینتل به پردازشگر دو هسته ای
با توجه به اینکه اینتل مانند AMD دارای مدل قبلی برای اضافه کردن هسته جدید در داخل یک قالب CPU نبود، برای ساخت آن مدل جدیدی را طراحی نمود که البته دارای نواقصی نسبت به مدل AMD میباشد.
پنتیوم D در اصل از دو پردازشگر “پرسکات” پنتیوم D در یک قالب تشکیل شده است ، این پردازنده دارای مزیت داشتن دو حافظه کش L۱ و L۲ برای هر هسته بطور مجزا میباشد، ولی دارای نواقصی نیز می باشند از جمله اینکه این دو پرداشگر برای ارتباط برقرار کردن با یکدیگر باید، از NorthBridge و FSB خارج پردازشگر استفاده نمایند. تعداد ترانزستورها برای چیپ های جدید بیش از ۲۳۰ میلیون و گرمای تولید شده به مقدار فوقالعاده ۱۳۰W برای پنتیوم Extereme Edition میرسد.
یکی از بزرگترین معایب طراحی اینتل نسبت به AMD که سوکتهای ۹۳۹ را برای طراحی پردازشگرهای دو هستهای خود حفظ نمود آن است که راه حل دو هستهای اینتل نیاز به یک جفت چیپ ست جدید بنامهای ۹۵۵X و ۹۴۵P دارد. شرکت nvidia اخیراً ویرایش اینتل SLI که پروسسورهای دو هستهای را پشتیبانی میکند را به بازار عرضه کرده است که این مورد هم زمان بیشتری را مصرف و هم هزینهای اضافی برای مصرف کننده در پی دارد.
گرما و پهنای باند :
هر دو پردازشگرهای تک هستهای AMD و Intel گرمای فوقالعاده زیادی تولید میکردند، که هیت سینکهای فوقالعاده بزرگی که برای آنها استفاده می شود گویای این مطلب میباشد. حال با اضافه کردن یک هسته اضافی چگونه میتوان این پردازشگرها را خنک نمود.
ولی AMD و Intel از چندین روش برای خنثی کردن این موضوع استفاده کردهاند، ابتدا آنکه در ساخت این پردازشگرها از تکنولوژی ۹۰nm استفاده شده که باعث کوچکتر شدن CPU ونزدیکتر شدن قسمتهای مختلف بر روی CPU شده و در نتیجه گرمای تولید شده را به مقدار زیادی کاهش میدهد و دوم آنکه فرکانس کاری این CPU ها بمقدار حدود ۴۰۰MHz نسبت به آخرین CPU های تک هسته ای کاهش پیداکرده و همچنین هسته دوم همیشه بصورت کامل کار نمیکند این سه مطلب باعث میگردد که گرمای تولید شده بمقدار خیلی زیادی نسبت به CPU های تک هستهای افزایش نیابد.
پهنای باند بکار رفته محدودیت بزرگتری برای CPU های دو هستهای میباشد، زیرا هر دو AMD و Intel پهنای باند برای CPU های تک هستهای را برای این نوع CPU ها نیز حفظ کردهاند و طرحی برای افزایش آن ندارد.
دو پردازشگر تک هسته ای در مقابل یک پردازشگر دو هستهای
محاسبات و بررسی طرحهای موجود نشان میدهد که دو چیپ اپترن AMD باید دارای سرعت بالاتری نسبت به یک چیپ دو هستهای باشد، زیرا هر یک از این OPTERON ها دارای یک کنترل کننده حافظه مجزا میباشد ولی در چیپهای دو هستهای هر دو هسته باید یک کنترل کننده حافظه را بصورت مشترک استفاده کنند.
در مورد اینتل این موضوع مطرح نمیباشد زیرا در هر دو طرح یک کنترل کننده حافظه در خارج از CPU استفاده می شود و فقط در طراحی دوهسته ای این مسیرها کوتاهتر میباشند که چندان پارامتر مطرحی در افزایش سرعت نمیباشد.
یکی از بزرگترین مزایای پردازشگرهای دو هستهای نسبت به دو پردازشگر تک هستهای بحث اقتصادی آن میباشد، زیرا اولاً خرید یک CPU دو هستهای از دو CPU تک هستهای ارزانتر میباشد و از طرف دیگر باید قیمت مادربرد را نیز لحاظ کرد که در این صورت این موضوع بیشتر جلب توجه مینماید.
لینک مقاله در تالار های گفتگوی علمی آکادمیست :: دانشجویان
فناوری P۲p و بیداری همیشگی اینترنت
با Thin Clientها آشنا شوید
همچنان كه فناوری اطلاعات، توسعه بیشتری مییابد، شبكهها نیز به عنوان یكی از پیامدهای این توسعه اهمیت بیشتری مییابند. اما شبكهها فقط منحصر به انواع متداول LANها یا WANها نمیگردند و شبكهسازی روشهای دیگری نیز دارد. در این زمینه تجهیزاتی مانند Thin Clientها، Net PCها و یا Network computerها مطرح میگردند كه هر یك ویژگیهای خاص خود را دارند. در این مقاله قصد داریم به معرفی فناوری مرتبط با Thin Clientها بپردازیم.
شبكه مبتنی بر Thin Client، شبكهای مبتنی بر سرور است كه تقریباً كلیه پردازش ها در آن توسط این سرور صورت میپذیرد. كلیه برنامههای كاربردی روی سرور اجرا شده و توسط Clientها قابل استفاده هستند. واژه thin در این تكنولوژی، به دلیل حجم پایین پردازشی است كه توسط Clientها صورت میپذیرد. در مقابلِ این تكنولوژیFat Clientها مطرح میباشند كه كلیه پردازشها را روی Client انجام میدهند. به طور كلی ساختار شبكه های مبتنی بر Thin Client از یك سرور با قدرت بالا و تعدادی Client تشكیل شده است كه كارآیی محدودی دارند.
Thin Client چیزی جز یک کامپیوتر جمع و جور نیست اما این کامپیوتر برای استفاده به صورت یک پایانهی شبکهای طراحی و تنظیم شده است. شکل بالا نمونهای از یک Thin Client ساخت HP را نشان میدهد. برای دیدن عکس در ابعاد بزرگتر، روی آن کلیک کنید.
یك شبكه مبتنی بر Thin Client چگونه فعالیت میكند؟
یك شبكه مبتنی بر این تكنولوژی دارای یك یا چند سرور با ویژگیهای خاص میباشد. سیستمعامل این سرورها میتواند هریك از سیستم عاملهای موجود (با توجه به برنامههای كاربردی موردنظر) نظیر یونیكس، لینوكس،
(Windows NT Terminal Server Edition (NT TSE ، یا ویندوز باشد. علاوه بر سیستمعامل، بر روی هر یك از این سرورها یك نرم افزار كنترلی وجود دارد كه فعالیتهای Clientها را كنترل مینماید. بسیاری از این نرم افزارهای كنترلی به صورت رایگان عرضه میشوند و معمولاً توسط شركتهای نرمافزاری، تولید میگردند.
كاربردها
این شبكهها در بسیاری از سازمانها مورد استفاده قرار می گیرند. اما بزرگترین مشتریان این شبكهها، بانكها، آژانسهای هوایی و سازمانهایی هستند كه دارای شعبات متعدد میباشند. امروزه از این تجهیزات برای تجهیز مدارس نیز استفاده میشود. با توجه به این نكته كه سیستمهای Thin Client دارای هارددیسك نمیباشند و امكان download كردن نرمافزار نیز روی آنها وجود ندارد، هیچ نوع ویروسی نمی تواند سیستم را مورد حمله قرار دهد. به این ترتیب امنیت این نوع سیستم ها تضمین شده میباشد. ارتقاء و نگهداری Thin Clientها بسیار ساده و مقرون به صرفه است. زیرا برای ارتقاء شبكه لازم است فقط سرور مربوطه را upgrade نمود.
مزایا و معایب
مدیریتپذیری، هزینه پایین، امكان كنترل ونظارت و مواردی از این دست از جمله مزایای اینگونه از شبكهها میباشند كه در ادامه به آنها اشاره خواهیم كرد.
مدیریت پذیری
در این شبكه فقط كافی است سرور مدیریت گردد. جهت رفع نقایص احتمالی نیز سرور اصلی مد نظر می باشد.
امنیت
در سیستمهای Thin Client به علت عدم وجود نقطه ورود به شبكه، عدم امكان download كردن نرمافزار از اینترنت و نصب آن بر روی Clientها و همچنین عدم وجود هارددیسك، ویروسی شدن سیستمها غیرممكن است. همچنین با استفاده از امكانات سیستم مدیریتی و كنترلی موجود بر روی سرورها میتوان دسترسی كاربران را نیز به نحو مطلوب محدود نمود.
كنترل و نظارت
كاربران شبكههای Thin Client نمیتوانند applicationهای خود را بر روی Client نصب نمایند همچنین قادر به تغییر پیكربندی سیستم نیز نمیباشند.
هزینه سخت افزار
این تجهیزات از PCها به مراتب ارزانتر میباشند. به علاوه به دلیل عدم وجود قطعات جانبی، كمتر دچار خرابی می شوند. نكته قابل ذكر در این در نتیجه هزینه نگهداری این تجهیزات نیز كمتر است.
سهولت ارتقاء
برای اضافه كردن ترمینالهای جدید به شبكه، فقط كافی است از طریق نرم افزار مركزی كه روی سرور نصب شده نرم افزار كنترلی را روی Client جدید نصب نمود. در صورت خرابی نیز میتوان به راحتی ترمینال مورد نظر را از شبكه خارج نمود.
ذخیره انرژی
در مقایسه با كامپیوترهای شخصی، این سیستمها انرژی كمتری مصرف می نمایند. در این سیستمها به علت پردازش پایین، توان مصرفی آنها در حدود ده الی بیست وات در ساعت میباشد. در حالی كه توان مصرفی یك كامپیوتر از نوع PC در حدود 250 وات در ساعت می باشد.
اما معایب استفاده از این كلاینتها را میتوان اینگونه برشمرد:
عدم انعطاف پذیری
در صورتی كه نرم افزاری بر روی سرور نصب نشده باشد، كاربران نمی توانند از آن استفاده نمایند.
وابستگی به سرور
با توجه به ساختار Thin Client، لازم است سرور از امنیت بالایی برخوردار باشد. زیرا در صورت از كار افتادن سرور، شبكه به طور كامل مختل خواهد شد. در نتیجه برای جلوگیری از این امر، روشهای مختلفی جهت ایجاد redundancy نرم افزاری و سختافزاری استفاده می شود. مكانیزمهای متفاوت Failover نیز برای پردازندهها و پایگاه داده مورد استفاده قرار میگیرد. امكان Load balancing سختافزاری و نرمافزاری نیز برای این سرورها از موارد ضروری می باشد كه همه اینها قیمت سرور موردنظر را به شدت بالا میبرد.
پهنای باند
مانند سایر شبكه های كامپیوتری، پهنای باند این شبكه نیز وابسته به تعداد Clientها می باشد. با توجه به انجام كلیه فرآیندهای پردازشی توسط سرور، ترافیك این شبكه بسیار بالا است. زیرا كلیه دستورات پردازشی باید به سرور منتقل شده و نتایج به Clientها تحویل گردند.
كمبود فضای حافظه
با توجه به ساختار این سیستم ها امكان استفاده از هیچ نوع حافظه جانبی نظیر انواع دیسك ها وجود ندارد.
استفاده از تجهیزات جانبی
در این نوع شبكهها تجهیزات جانبی محدود میباشند. تجهیزاتی نظیر دوربینهای دیجیتال یا تجهیزات تصویری را نمیتوان به این ترمینالها متصل نمود. اما در حال حاضر انواعی از ترمینالها وجود دارند كه پورت های مختلفی را پشتیبانی میكنند.
امكانات ضعیف پشتیبانی از مالتی مدیا
برنامههای كاربردی كه نیاز به پردازشهای تصویری زیاد دارند، روی این شبكهها به خوبی كار نمیكنند. زیرا كلیه فرآیندهای پردازشی توسط سرور مركزی صورت می گیرد كه در صورت تخصیص پردازنده به applicationهای مالتی مدیا، كارآیی شبكه به شدت كاهش می یابد. پیشرفت هایی كه در زمینه تكنولوژی های پردازنده ها و سرورها صورت پذیرفته است، تا حدودی این قبیل مشكلات را كاهش داده است. اما هنوز هم عدم پشتیبانی از این چنین كاربردهایی از نقاط ضعف Thin Clientها محسوب می گردد.
انواع Thin Client
همانگونه كه اشاره شد این سیستم ها نیز انواع مختلفی دارند كه با توجه به میزان پردازشی كه توسط Clientها و سرور صورت می گیرد از یكدیگر متمایز میگردند. در ادامه تعدادی از انواع این سیستم ها معرفی می گردند.
Ultra thin client
در این سیستم كاربر یك صفحه كلید، ماوس و مانیتور دارد. كلیه پردازشی كه توسط Clientها در این سیستم انجام می شود پردازش ورودی صفحه كلید، ماوس و خروجی روی مانیتور میباشد و سایر پردازشها توسط سرور انجام میشود. ترمینالهای ویژهای از این نوع، امكان پردازش كارتهای هوشمند را نیز دارند.
(Windows Based Terminal (WBT
این ترمینالها خود بر دو نوع هستند:
1- ترمینالهای استانداردی كه از پروتكلهای (RDP (Remote Desktop Protocol مایكروسافت یا Citrix ICA (Independent Computing Architecture) استفاده می نمایند.
2- ترمینالهایی كه از سیستم عاملهای نوشته شده توسط یك سازنده خاص (برای Clientهای خاص) استفاده می نمایند. البته این سیستمها از پروتكلهای استاندارد نیز پشتیبانی مینمایند.
عمده ترین شركت هایی كه این نوع ترمینالها را تولید می كنند عبارتند از: NCD ،Wyse ،Neoware و Compaq
در رابطه با این نوع ترمینالها نكته قابل ذكر این است كه مجموعهای ازPC ها نیز وجود دارند كه با محدود كردن عملكردشان میتوان از آنها در شبكههای Thin Client استفاده نمود. از این PCها برای مواردی كه كاربردهای چندرسانهای در شبكهها وجود دارد استفاده می شود. مثلاً به این ترتیب پردازشهای تصویری و صوتی توسط خود Client انجام می شود.
Internet terminal
این ترمینالها مرورگرهای اینترنت را به طور توكار ضمنی همراه دارند.
Low spec PC solution
به علت عدم نیاز به پردازش توسط Clientها میتوان از PCهایی كه از رده خارج شدهاند نیز برای ایجاد شبكههایThin Client استفاده نمود. از این راهحل بیشتر در مدارس استفاده می شود.
Tubby client
این نوع Clientها در حقیقت PCهایی میباشند كه خود دارای سیستم عامل و applicationهایی مستقل هستند این PCها با استفاده از یك نرم افزار امكان اتصال به شبكه Thin Client را نیز دارند. به ترتیب میتوانند از application هایی كه روی سرور موجود میباشند نیز استفاده نمایند.
Disabled PC solution
در این نوع از ترمینالها، از امكانات موجود در PCها نظیر Floppy disk و CD استفاده نمیشود. و به اصطلاح آنهاDisable میشوند. البته این روش برای مدت زمان طولانی روش مناسبی محسوب نمی شود. در صورتی كه از این شبكه در كنار یك شبكه استاندارد استفاده شود، راهحل بهینهای است.
Blade PC architecture
از این ساختار برای Clustering یا خوشهبندی استفاده میشود. در ساختار Blade PC از PCها به عنوان سرور استفاده می شود. این سرورها در یك محل به صورت متمركز گردآوری شده و یك سرور مدیریت، كلیه PCها را كنترل می نماید و ترافیك را میان آنها تقسیم مینماید. كلیه اجزای جانبی نظیر صفحه كلید، ماوس و مانیتور كاربران از طریق یك ارتباط استاندارد (به طور مثال 5-Cat) به PCها متصل میشود. البته این راه حل بسیار گران بوده و در عین حال ساختار مدیریتی پیچیدهای نیز دارد.
پروتكلهای ارتباطی
همان گونه كه ذكر شد، دو پروتكل مطرح در این زمینه وجود دارند.
پروتكل Citrix ICA: پروتكلی است محصول شركت Citrix كه به Clientها این امكان را میدهد تا با سرور مركزی ارتباط برقرار نمایند. با استفاده از این پروتكل بسیاری از applicationهای تحت ویندوز قابل اجرا هستند.
پروتكل RDP: این پروتكل كه توسط شركت مایكروسافت توسعه داده شده، نیز یك پروتكل ارتباطی است كه امكان برقراری ارتباط میان سرور و Clientها را میسر می سازد.
نتیجهگیری
در این نوشتار با نوع دیگری از شبكه سازی مبتنیبر فناوری Thin Clientها آشنا شدید. شبكههایی كه تمركز اصلی آن بر روی سرور بوده و كلاینتها با حداقل توان پردازشی در اختیار كاربران قرار میگیرند. كاربر عمده این قبیل شبكهها، با توجه به معایب و مزایای گفته شده، مكانهایی نظیر آژانسهای هواپیمایی، بانكها و مراكز آموزشی میباشند.
منبع :
http://forum.p30world.com/archive/index.php/t-87726.html
|
فارغ از هياهو - گفتوگوي بيل گيتس با هفتهنامه InformationWeek
| |
|
| |
|
○ ريكادلا: اخيرا آقاي Craig Mundie مدير فناوري (CTO) در مايكروسافت مقالهاي منتشر كرده كه طي آن درباره تغيير نقش و فعاليت واحد تحقيقات شركت (Microsoft Research) و واردشدن آن به حوزههايي سخن گفته كه از لحاظ تاريخي هيچگاه در زمره فعاليتهاي آن نبوده است؛ يعني عرصههايي بيرون از علم كامپيوتر. به نظر شما فناوريهاييكه واحد تحقيق و توسعه مايكروسافت ابداع كرده چگونه ميتوانند در حوزههاي وسيعتري از علوم مختلف، نظير پزشكي و مهندسي كاربرد داشته باشند؟ پينوشت:
| |
شروع پردازش موازی
مقدمه : بیش از صدها سال قبل در تلاش برای رفع نیازهای محاسباتی و عملیاتی خود بوده است .
در شرایط امروز که متحقیقین و دانشمندان دنیای کامپیوتر توانسته اند صدها و هزاران پردازشگر کوچک و بزرگ را برای رفع نیازهای زمان به صورت قابل توسعه در یکدیگر وصل نمایند که وقتی قادرند میلیاردها عمل ریاضی در ثانیه انجام دهند ولی هنوز ده ها و صدها نیاز محاسباتی و عملی وجود دارند که سیستم های موجود قادر به حل آن ها نبوده و سیستم های بزرگ تر با قدرت های محاسباتی تریلیونی لازم و ضروری است مسلما ً دستیابی به این سیستم های بزرگ از طریق طراحی و ساخت ابر کامپیوترهای تکی و یا تک پروسسری ممکن و میسر نیست .
حال سوال اصلی که در اینجا مطرح می باشد این است که چگونه می توان نیازهای محاسباتی جامعه امروزی را برطرف نمود ؟
جواب این سوال آسان است ، چنانچه امکان رفع نیاز توسط یک سیستم برطرف نگردد ، مسلما ً تعدادی از آن سیستم ها وقتی سیستم های کوچکتر خواهند توانست نیازهای محاسباتی را برطرف نمایند .
شروع این نقطه ، شروع پردازش موازی است و این فکر از سال های 1920 به مغز و به فکر متحققین کامپیوتری رسید . تلاش و کوشش متحققین و پژوهشگران کامپیوتر در هفت دهه گذشته موجب تحول و توسعه سیستم های پردازش موازی گردیده و این تحول و توسعه تا آنجا رسیده است که ماشین های امروزی توانسته اند بیش از 65 هزار پروسسور را یکجا در سیستمی به کار گیرند و چندین تریلیون عملیات را در ثانیه انجام دهند .
امروزه برای تأمین نیازهای محاسباتی و عملیاتی می توان از سه طریق استفاده کرد :
1-سیستم های Pc
2-سوپر کامپیوتر
3-سیستم های پردازش موازی
که تأ مین هزینه های مربوط به هریک در دیاگرام زیر نشان داده شده است :
هزینه سیستم های پردازش موازی از هر سیستم دیگر کمتر می باشد و دلیل آن استفاده از واحدهای ارزان و معمولی کامپیوتری است
بررسی رفتار عملکرد سیستم های پردازش موازی :
ما برای بررسی رفتار عملکرد سیستم پردازش موازی می توانیم پارامترهایی همچون راندمان سیستم (کارایی) ، ضریب بکارگیری ، کیفیت پردازش موازی را تحریف کنیم .
1-كارايي : در سیستم پردازش موازی با تعداد P پروسسور می توان فرض کرد که تعداد O(P) عملیات در زمان T(P) اجرا می نماید . چنانچه این عملیات در یک سیستم تک پردازنده اجرا گردد زمان لازم برای اجرای آن T(1) ثانیه خواهد بود.اگر بیشتر از یک عملیات به وسیله سیستم پردازش موازی با P پروسسور انجام گردد ، ازدیا سرعت را می توان به صورت زیر تعریف کرد :
.bmp)
و در نتیجه راندمان سیستم به صورت زیر تعریف می شود :
.bmp)
کمترین مقدار E(p) در سیستم موازی زمانی است که تنها یکی از پروسسورها تمام برنامه را به صورت پیاپی اجرا نماید و بزرگترین مقدار آن حالتی است که تمام P پروسسور به طور همزمان در اجرای تمام برنامه با هم همکاری داشته باشند
ضریب به کارگیری یک سیستم پردازش موازی نشانگر درصدی از واحدهایی همچون حافظه ها و پردازشگرهاست که در زمان اجرای برنامه بکارگرفته میمی
.bmp)
3) کیفیت پردازش به صورت زیر تعریف می شود:
.bmp)
طبقه بندی معماری سیستم های کامپیوتری :
میشل فلین در سال 1996 میلادی معیاری برای طبقه بندی معماری در سیستم های کامپیوتری بر اساس جریان فرامین و
داده ها و تعداد آن ها ارائه نمود . در این طبقه بندی معماری های مختلف کامپیوتر بر اساس جریان داده ها و فرامین به
چهار دسته زیر تقسیم شده است :
1) Single Instruction Stream – single data - SIMD
ماشین که در طراحی و معماری آن ها فقط یک جریان داده و یک جریان فرامین یا دستورالعمل برقرار است .
این معماری در تمامی کامپیوترهای ساده و تک پردازنده قدیمی و مدرن بکار رفته است .
2) Single Instruction Stream – Multiple Data : SIMD
ماشین هایی که در آن ها یک جریان دستورالعمل و چند جریان داده برقرار است
در این ساختار تعداد زیادی واحد عملیاتی که قادر به عملیات ریاضی/منطقی هستند . تحت کنترل وهدایت یک واحد کنترل قراردارند و قادرند داده های متعددی را همزمان از واحدهای حافظه فراخوانی نموده و عملیات یکسانی را در مورد آن ها انجام دهند .
3) Multiple Instruction Stream – single DATA : MISD
ماشین هایی که در آن ها چند جریان فرامین به طور همزمان ولی یک جریان داده برقرار است .
4)Multiple Instruction Stream - Multiple Data : MIMD
نحوه ی اجرا و عملکرد سیستم های پردازش موازی
Parallel Implementation
در روش های موازی از مجموعه ای از کامپیوتر ها استفاده می شود که توسط یک شبکه به هم متصل می باشد و تحت PVM اجرا می شوند
PVM یک بسته نرم افزاری است که به برنامه نویسی موازی کمک می کند .
ماشین های موازی تحت PVM یک مجموعه ای از پروسسور ها هستند که هم به حافظه کمکی و هم به حافظه مشترک متصل هستند
(Parallel virtual Machine ):
این مجموعه شامل یک پروسسور Master و چند پروسسور Slave می باشد .
ما می خواهیم دستگاه معادلات خطی را با استفاده از روش مونت کارلو در این سیستم حل کنیم .(با در نظر داشتن P پروسسور)
ابتدا ماتریس کامل A را به هر ریز پردازنده انتقال می دهیم . در هر ریز پردازنده
مولفه از بردار جواب محاسبه می شود و در انتها نتایج از Slave هاهیچ ارتباطی ، بین فرستادن A و دریافت مولفه های x ، جمع آوری می شود .
تنها ارتباط بین Slave ها و Masterدر آغاز و پایان الگوریتم صورت می گیرد که به ما این امکان را می دهد که کارایی خیلی بالایی از اجرای موازی داشته باشیم .
چون ما در حالت موازی می خواهیم n مولفه از بردار جواب را در P پروسسور محاسبه کنیم نه از زمان اجرای بارگذاری اولیه اطلاعات O(nNT/P) می باشد که تعداد زنجیر مار کف وT طول زنجیر مار کف است .
آزمایش ها و تجربیات نشان داده است که زمان محاسبه کل n مولفه یک تابع خطی از اندازه ماتریس یعنی n می باشد .
در اين آزمايشگاه 4 كامپيوتر دوال پروسو، دوال كور توسط يك سويچ به يكديگر متصل شده اند و يك كلاستر جهت اجراي برنامه هاي موازي بوجود آوردهاند. اين كلاستر در حقيقت يك سيستم پردازش موازي با 16 گره را بوجود مي آورد. از اين كامپيوترها يك كامپيوتر سرور كلاستر بوده و داراي سيستم عامل لينوكس و محيط پردازش موازي MPI و PVM مي باشند. اين كلاستر به شبكه محلي پرديس علوم متصل بوده و از طريق آن امكان دسترسي به كلاستر از طريق اينترنت فراهم آمده است. كاربران اين آزمايشگاه را دانشجويان تحصيلات تكميلي و دكتري علوم كامپيوتر تشكيل مي دهند و جهت انجام امور پژوهشي و تست الگوريتهاي موازي از آن استفاده مي كنند.
آیبیام تكنولوژی mainframe را به سرورهای يونيكس اضافه میكند
نويسنده: Patrick Thibodeau
Computerworld
مترجم: زهره چكنی
فرامينگهام- Gorge Martine مسئول ادغام شركت Royal Caribbean Cruises، به سرورهای با پايه Power5 ساخت آیبیام علاقهمند است. من جمله محصول جديد Uinx Server كه هفته پيش معرفی شد. اما در واقع آقای Martine خواستار نمونهای از اين محصولات است كه عملكرد برنامهای آن با ساير سيستمهای آیبیام قابل مقايسه باشد، نه اينكه خلاف اين سيستمها عمل كند.
Martine، از مديران شركت Royal واقع در ايالت ميامی آمريكا از IBM iSeries (سابقا AS/400) و Pseries Unix/Linux استفاده می كند. اين نمونهها كه عملكرد اجرايی سيستم عامل را در محصولات چندگانه آیبیام نشان میدهند به وی كمك میكند تا بهترين انتخاب را از ميان سرورها داشته باشد.
او میگويد، اگر ما نمونهای نداشته باشيم كه بتوانيم pSeries را با يك iSeries از جهت سيستم عامل (Operating System) يا OS مقايسه كنيم، آنگاه مقايسه اين محصولات با تكنولوژیهای ديگر از سازندههای ديگر نيز مشكل خواهد بود.
Jim McGaughan، مدير بخش استراتژی eServer شركت آیبیام میگويد، آیبیام فعلا برنامهای برای توليد نمونههای قابل مقايسه از اين دو محصول ندارد زيرا اصولا ساختار سختافزاری iSeries و pSeries مشابه هستند. چنانچه شركتی علاقمند مقايسه عملكرد سيستم عامل eSeries با AIX است، كه در واقع نوعی Migration محسوب میشود، در چنين شرايطی آیبیام به كاربر كمك میكند تا عملكرد اجرايی دو سيستم را ارزيابی كند.
پردازشگرPower5 با پايه RISC دو هستهای است، اما بر عكس چيپ Power4، دارای قدرت اجرايی Multi Threading است، به آن معنا كه اين پردازشگر میتواند دو جريان دستورالعمل را همزمان انجام دهد يا حتی تا 4 عملكرد را به صورت موردی انجام دهد.
پرش:
سازندگان سرور در يك مسابقه پرش بی انتهايی شركت كردهاند. به اعتقاد تحليلگران اين مسابقه در واقع رقابت در عملكرد چيپ است. اما سرورهای يونيكس و لينوكس با پايه Power5 پرش فوقالعاده بلندی داشتهاند.
Brad Day، يكی از تحليلگران موسسه تحقيقاتی Forester در كمبريج ايالت ماساچوست میگويد، آیبیام اكنون از حقوق معنوی گروه mainframe و تكنولوژی Virtual engine گروه Tivoli software group شركت پول زيادی در میآورد. هر چند سيستمهای يونيكس روز به روز بيشتر شبيه mainframe میشوند، در واقع هيچكدام mainframe نيستند.
Dave Ennen، مدير IT شركت Winnebago Industries Inc در شهر Forest City ايالت آيووا از zSeries mainframe ساخت آیبیام استفاده میكند. به اعتقاد او يونيكس و ساير سرورها جايگزين mainframe نخواهند شد. به منظور اجرای برنامههای بسيار مهم، شركت در تلاش است تكنولوژی Partitioning ريز پردازشگر را به سرورهای يونيكس اضافه كند.
Ennen میگويد، علت استفاده ما از mainframe آن است كه هرگز نخواستهايم از ارزش آن كم كنيم، در هر صورت به zSeries هرگز چنين وابستگی نداريم.
مديران آیبیام میگويند، ميان تواناييهای انواع mainframe و سيستمهايی كه با يونيكس اجرا می شوند، فاصله زيادی وجود دارد. Ravi Arimilli يكی از كاركنان آیبیام و مهندس ارشد بخش آیبیام سيستم میگويد، به عنوان مثال برخلاف سيستمهای يونيكس و لينوكس، در mainframe خطر اينكه كسی سردرگم شود تقريبا صفر است.
Arimilli میگويد، يونيكس بالاخره از طريق Virtualization و قابليت دسترسی آسان و ويژگیهای امنيتی پيشرفته، فاصلهها را پر میكند. او میگويد، نمیدانم چقدر طول میكشد، اما گمان نمیكنم به زودی اين اتفاق رخ دهد، حداقل يك دهه طول میكشد.
به گفته Robert Gamso معمار ارشد سيستمها در اين شركت توليد كننده لوازم خانگی، Virtualizing در سطح پردازشگر به معنِ آن است كه شركت Whirlpool ميتواند تعداد كارتهای شبكه، سيستمهای ذخيره سازی شبكه و نيز هزينه مديريت و مونيتورينگ سيستمها را كه بر اساس تعداد پردازشگرها محاسبه ميشود كاهش دهد.
سخت افزار Power5 به آداپتورهای مجزا نياز دارد، اما Power5 نه. Gamso میگويد، اين كار هميشه مقرون به صرفه نيست. يعنی اضافه كردن كارت برای به دست آوردن Virtualization.
جدال بر سر ابر محاسبات
محاسبات به ابرها میرود
یاهو، و گوگل سخت در تلاش هستند که قدرت «محاسبات ابری» را در عمل به کار بگیرند. در اينجا نگاه کوتاهی مياندازيم به نحوه کار این فناوری
گویا پژوهشگرانی که به دنبال یافتن روشهای هوشمندانهتری برای انجام محاسبات سنگین هستند جواب را در ابرها یافتهاند! البته نه ابری که بهصورت تودههای متراکم بخار آب در آسمان این سو و آن سو میرود. آنها فکر میکنند کلید انجام محاسبات سنگین و حجیم در چیزی به نام «ابْر محاسباتی» است. قرار است این ابر محاسباتي، قدرت ابررایانهها را در اینترنت قرار بدهد.
به تازگی IBM هم برنامههای خود برای خلق فناوریهای مربوط به محاسبات ابری را اعلام کرده است. روز پانزدهم نوامبر مدیران IBM در شانگهای از یک سیستم جدید به نام «ابر آبی» پردهبردا
