في جون واللهي يا لومارك .... كتر مشاهدة البرسا خلاك ولا لييوناردو
شكرا على المعلومة القيمة
الاخ لو مارك
الى انت قولت عليه ده كله اسمه auto-negotiating
AUTO=آلى
negotiating=محاورة للوصول الى التفاهم و قرار
قرار بالسرعة يعنى
حقول تانى للى عنده فقدان ذاكرة و الى الانجليزى بتاعه تعبان
The term ``sensing'' refers to testing the other end
بالعربى يعنى اختبار مش اختيار
و اى اختبار له مراحل يا سيدى الفاضل من ضمنها اختبار الكابل الى واصل ما بين اى سويتشين
خد بالك المعلومات ديه مفيش حد حيقولهالك غير الى فاهم
مع أنني لا أشك مثقال ذرة في كلام أخي لومارك
ولكن بسسب اتهامك لنا بعدم تقبلنا للعلم وعدم معرفتنا باللغة الإنجليزية ومش بنعرف نترجم كويس
إيه رأيك في الكلام اللي جاي
Definition: Network adapters that support both traditional and Fast Ethernet choose the speed at which they run through a procedure called autosensing. Autosensing is a feature of so-called "10/100" Ethernet hubs, switches, and NICs. Autosensing involves probing the capability of the network using low-level signalling techniques to select compatible Ethernet speeds. Autosensing was developed to make the migration from traditional Ethernet to Fast Ethernet products easier.
When first connected, 10/100 devices automatically exchange information with each other to agree on a common speed setting. The devices run at 100 Mbps if the network supports it, otherwise they drop down to 10 Mbps to ensure a "lowest common denominator" of performance. Many hubs and switches are capable of autosensing on a port-by-port basis; in this case, some computers on the network may be communicating at 10 Mbps and others at 100 Mbps. 10/100 products often incorporate two LEDs of different colors to indicate the speed setting that is currently active
الكلام السابق من موقع باللغة الإنجليزية يمكن يكونوا بيفهموا أكتر من اللي عندنا ....... والله حاجة غريبة
ياريت انت اللي تتقبل العلم
ودا الرابط
https://compnetworking.about.com/od/..._autosense.htm
لا اله الا الله محمد رسول الله
Autosensing involves probing
probing=diligent and thorough in inquiry or investigation
probare to try, examine
designed to investigate and obtain information
يا رب صبرنى
مين عاوز طبق؟
أنا مش عارف ربنا يصبر مين بالضبط
يا أخي الفاضل / هل فكرت مرة إن المصطلحين يكونوا بنفس المعنى ؟؟؟؟
Abstract
This document, primarily intended for University of Illinois at Urbana-Champaign system administrators, explains the different ways that varying Ethernet standards communicate with each other and select a common speed and method of data exchange. The options discussed most thoroughly in this document are 10 megabits per second (Mbps), 100 Mbps, half-duplex, and full-duplex.
In addition, this document also discusses the configuration methods recommended for use on the Urbana-Champaign campus, and contacts for more information.
Table of contents
Introduction
Available modes
How it's supposed to work (and why it sometimes doesn't)
Unexpected consequences (and why there's no better alternative)
The upshot: Either trust auto-negotiation or manually configure everything
Quick summary
More information
Sun systems
AIX systems
Macintosh systems
Windows systems
Cisco Catalyst switches
Contacts (for UIUC affiliates)
--------------------------------------------------------------------------------
Introduction
These days, twisted pair Ethernet comes in many different flavors. Not only are there different speeds available, there are also different duplex modes. Some Ethernet interfaces can run full-duplex, allowing information to be transmitted in both directions at the same time. This effectively doubles the available bandwidth on well-balanced links. In other cases, network topology or older interfaces may limit a network to running half-duplex, which allows a device to either transmit or receive, but not both at the same time.
If every Ethernet device could communicate using only one specific mode, it would be a networking nightmare. To ease this logistic problem, most newer interfaces that are capable of running the newer, faster, more robust configurations can also run the older, slower, more traditional ones. This allows a gradual upgrade of the network, one component at a time.
The problem remains that if you plug a device into a jack, the device needs to determine what mode it needs to run in to get the best performance. One way to do this would be to manually configure both sides of the connection to use a specific speed and duplex mode. The designers of the newer Ethernet specs knew this would not be a popular option, so they designed a system called auto-negotiation (sometimes refereed to by the misleading name auto-sensing), whereby an Ethernet interface can probe and determine the capabilities and characteristics of the other side of the new link. Once each side knows what the other side can do, they can pick the best communication method.
Available modes
Before we get into how auto-negotiation works, we will look at the possible modes. Currently there are standards for three Ethernet speeds: 1000 megabits per second (also known as Gigabit Ethernet, or simply GigE), 100 megabits per second (also know as Fast Ethernet), and the original 10 megabits per second (sometimes refered to as Legacy Ethernet).
Gigabit Ethernet is still fairly expensive, and not all that commonly used on desktop machines. Fast Ethernet has become the de facto interface found on workstations. There are also millions of older hosts and networking gear and media that still run at the traditional 10 Mb.
With most newer computers having Fast Ethernet interfaces, that leaves two common choices in speed: 100 megabits per second, and 10 megabits per second. Add to that the ability to run half-duplex or full-duplex at each speed and we are left with four most common modes. Listed here from "best" to "worst," they are:
100Mb full-duplex
100Mb half-duplex
10Mb full-duplex
10Mb half-duplex
The auto-negotiation mechanism allows the two interfaces on a link to select the best common mode automatically, the moment a cable is plugged in. The problem is that it looks great on paper, but it doesn't always work as intended. Although the final Fast Ethernet standard did contain a section on auto-negotiating, that section was one of the last things put into the standard and many vendors had already implemented their own auto-sensing systems and deployed them before the standard was ratified. If this wasn't bad enough, there is no standard for detecting modes at 10Mb. As a result, there are a number of different ways various interfaces attempt to detect the capabilities of the link, and most of them are not compatible.
How it's supposed to work (and why it sometimes doesn't)
First, let us get into how auto-negotiation is supposed to work before we get into why it often fails (or, more often, appears to fail). Let us assume we have two interfaces we want to connect together. Each interface has auto-negotiation enabled. When the interfaces first detect link with each other, each interface transmits a list of possible modes it can operate at. Once that is done, each interface knows both what it is capable of doing and what the other side is capable of doing. With this information, each side can independently pick the best common mode, and sets itself to use that mode.
That's how it is supposed to work, anyways. The most obvious problem is that the interfaces never actually communicate which mode they are setting themselves to. It is assumed that if both interfaces have the same lists, they will come to the same conclusion. That is usually true when both interfaces are using the same auto-negotiation system, but it isn't perfect. A bigger problem is when one of the interfaces doesn't follow the standard for auto-negotiation, and uses some other means to guess at the abilities of the other interface.
Auto-negotiation is an active method of determining link mode. Each interface is expected to transmit specific information in a specific format. If an interface that is expecting to use auto-negotiation does not receive this information from the other side, it assumes the other side cannot detect or change its mode. Many of the "pre-standard" detection means are passive. They looked at the characteristics of the system data they are sending and receiving to make a "best guess" at what the other side of the link is capable of doing. When using this passive auto-sensing mechanism, there is no communication between the interfaces regarding the mode at which they are to operate. Passive systems are not very reliable, which is why the Fast Ethernet standard uses auto-negotiating instead of auto-sensing. The problem is that when they mix, the passive system might guess correctly, but the active system will not receive the information it requires, and falls back to modes that are usually less desirable.
In order to understand why this is happens, we must look at the problem these auto-negotiation and auto-sensing systems are trying to solve. The four modes come from two questions, each with two answers. The first question is "what speed?" with the choices of 10Mb or 100Mb. The second question is "what duplex?" with the choices of half or full.
Passively detecting speed is the easy one. Each Ethernet frame (or packet) starts out with a sequence of bits that alternate between 1 and 0 that looks like this: 1010101010101010.... Each value (1 or 0) is represented by a specific state change, so when these bits are transmitted, the electrical signal on the Ethernet media transitions from "high" to "low" and back at the same speed the bits are being transmitted. To determine the speed, the interface needs to measure only the time between the transitions. If an interface is not capable of doing a higher speed, the bit pattern will look like signal noise, just like human speech played at ten times the normal speed sounds like noise. If each interface starts at its highest speed and works down, it can sync to the first speed it understands from the other side. This passive system allows the interfaces to determine a common speed very quickly with a great deal of reliability. It is also worth pointing out that the contents and format of the data that is sent is irrelevant, just the fact that the data is sent.
The task of passively determining duplex mode is almost impossible. There are ways to make a "good guess", but there is no way that you can be sure. To make things more complex, network topology can limit what duplex mode you can use. For example, if you have four machines that can each do full-duplex, but they are connected together using a repeater, they cannot operate in full-duplex mode. (Repeaters can also be called hubs, although not all hubs are strictly repeaters.) To make this task even more complex, the Ethernet link will still operate if the duplex modes are mismatched. If there is a speed mismatch, the link will not transfer data, but if there is a duplex mismatch, most of the data will still transfer correctly (especially on a low-usage machines or single-user machines), but one side of the link will have an abnormally high number of errors.
If there is a duplex mismatch, and one end of the link is in full-duplex mode when the other end is in half-duplex mode, network problems will occur. The half-duplex side of the link will not transmit data while it is still receiving data from the other side. The full-duplex side of the link has no such restriction, however, and will transmit the instant data is available to send-- it will not wait for the other side to stop transmitting before sending its own data. If the full-duplex side does this, the half-duplex side will start to receive data before it is finished with its own transmission. Seeing data on "both sides of the line," the half-duplex interface assumes a collision has taken place, discards the incoming packet, and counts it as an error.
This means the only way to detect, or attempt to guess, if the other side of a link can do full-duplex or not is to start transmitting something as soon as you start to receive a signal from the other end. The other side will start to receive your transmission before finishing up their own. If the other side is happy with this, it must be in full-duplex mode. If the other side thinks a collision has taken place, you know the other interface is in half-duplex mode.
BUT-- there is a catch. Almost all types of collisions are passive errors! If a collision happens, all the interfaces involved are expected to detect the error and react independently. That means that if a full-duplex interface is trying to probe an interface on the other side of a link by sending data "on top" of incoming data, even if the other interface is indeed half-duplex, senses a collision error and reacts, the original full-duplex interface never knows if the other interface considered the transmission an error or not! The end result is that there is a somewhat reliable (although not perfect) system of announcing the ability to do full duplex, but there is no way to probe the other side of the link.
Due to the problems with the older auto-sensing schemes (and the less than perfect ability of auto-negotiation to get things correct), many people have gotten in the habit of "forcing" an interface into a specific mode. In general, it is standard practice here at the University of Illinois U-C campus to hand configure all switch uplink interfaces and router interfaces to a specific mode of operation, and not rely on any of the auto-negotiating or auto-sensing systems. When a specific mode is configured, it disables auto-negotiating and just blindly runs in that mode, no matter what the other side is doing.
Unexpected consequences (and why there's no better alternative)
This sometimes has unexpected results, however. Many people think that if they set a switch port (or interface) to a specific mode (say 100Mb/full-duplex), and then plug in a workstation, it should automatically sync up with the switch port and configure itself to 100Mb/full-duplex. They are then surprised when the workstation settles into 100Mb/half-duplex, and their network starts experiencing a very high number of errors. The problem is that most new interfaces shipping today (including most switch interfaces) use the more robust auto-negotiation standard. As stated before, auto-negotiating is an active system, requiring data be sent by both sides. If auto-negotiation is turned off at the switch, any host plugged into it will send its auto-negotiation information and wait for the switch to send its own auto-negotiation information back. When the switch fails to do so (because auto-negotiation is disabled), the host assumes the interface is not capable of full-duplex. It falls back on the passive means used to detect speed, and sets itself up at the correct speed, but in half-duplex mode.
Although this may look dumb at first, it really is the Right Thing To Do. When the host failed to get any information from the switch interface, it has no idea what it could or could not do. Since there is no good way to detect duplex mode, it assumed the lowest common denominator (half-duplex). More importantly, it had no idea what the network topology between it and the switch looks like. If the switch port was connected to a hub that had many workstations plugged into it, the host would cause serious errors for the whole network segment if it put itself in full-duplex mode.
The upshot: Either trust auto-negotiation or manually configure everything
What this all boils down to is this: you have to make a choice of either trusting auto-negotiation to get it right, or you have to hand configure both sides of the Ethernet link. This is especially true if you intend to use full-duplex mode. If either side of the link has auto-negotiation turned off, the other side of the link will find the right speed, but will always default to half-duplex. If you want full-duplex, you must leave auto-negotiation enabled on both sides of the link, or you must hand configure both sides for full-duplex.
This can be a pain on some systems, such as laptops, that are moved around from port to port. To make the situation even worse, many vendors and OS makers don't provide a means to force the interface to one mode or another-- you have to trust auto-negotiation because it is the only game in town. In most cases, this is not a problem. Auto-negotiation is considerably better than auto-sensing at getting everything correct, and even if there is a duplex mismatch, the average workstation will not generate enough errors to cause concern. If worse comes to worse, you can just unplug the cable for a few seconds, and then plug it back in. The interfaces will reinitialize themselves, and go through the auto-negotiation sequence again.
Where many problems arise is with servers or multi-user systems that have a large amount of network I/O. Luckily, most of these systems tend to be rather static. They tend not to move around a lot, and they tend to have many manual configurations and tweaks to get the best performance. One more network configuration (if it is available) isn't a problem.
It should also be noted that 100 Mb interfaces that were manufactured when the 100 Mb standard was first ratified (or before) often have serious problems interoperating with systems that follow the full auto-negotiation standard. There have been cases of systems from this era refusing to link at all until the switch interface it was connected to had a specific duplex and speed mode configured. If you have one of these interfaces manufactured in the mid 90s, extra care may be required to configure proper speed and duplex modes to get the system to work at all with the newer standardized hardware.
I hope this has helped you understand more about auto-negotiation. If you are a member of the UIUC campus community and have a question about your own network configuration, please see your department's Network Administrator. If you are the Network Administrator, and still have questions, please contact the Network Administrator Support group (NAS) at CITES. They should be able to answer general questions, and help understand any auto-negotiation issues you might have. NAS is also a good source of information for when it might (or might not) be a good idea to hand-configure switch port speeds and duplex settings. If NAS is unable to help, you can also contact the Network Design Office (NDO) at CITES. They should be able to answer questions about specific networking hardware, or route any additional questions.
منقول
انا خلاص مش حرد لان كل شرحى واضح جدا جدا جدا
انا ممكن اجيبلك كتاب تعليم النتورك و احطهولك ايه رأيك ؟
ههههههههههههههه
سلام م م م م م
المهم تكون أخذت بالك إن زي ما هو كلامك صحيح
برده كلام غيرك صحيح
ودا المهم إننا نوصل للمعلومة الصحيحة يا أخي
المهم ألا نحكم على كلام الآخرين بالصحة والخطأ حتى نتأكد من خطأ كلامهم وليس العكس بأننا متأكدين من صحة كلامنا
لأ يا ريس إنت مش واخذ بال حضرتك خالص خالص خالص
إنت مش عارف الفرق بين ال Auto-negotiation و Auto-Sensing
الحكاية مش حكاية إنجليزي يا عم الحج، الحكاية هي إنك مش عارف الفرق بين الإثنين خالص، ومش عارف تميز كل واحد بيعمل إيه ووظيفته إيه.
قولتلك إسمعني بقه وسيبك من الكلام الزيادة ده يا ريس ، مفيش حد عنده فقدان ذاكرة ولا حاجة، الحكاية كلها إنك كنت بتتريق على الراجل و كتبت معلومات غلط وعايز تفرش عضلاتك على الراجل اللي كان بيكتب المقال، ولما صدناك عمال تلف يمين وشمال ، خلاص يا ريس الكلام اللي قولته حضرتك متثبت عليك مفيش طريقة إنه يتشال عشان أنا عملت ليه إقتباس خلاص.
إسمع بقه وفتح وذانك معايا كويس:
Auto-negotiation و Auto-Sensing
لو تقرأ كلامي مرة تانية بهدوء حتلاقي إني قلت إنه ال Sensing هو إستشعار، تحسس، بالعربي بيطبطب يعني ، يعني الجهاز الأول بيبعت شحنة كهرباء Signal أو يعني بالعامية Puls ، بيبعت الشحنة ديت على البورت أو كرت الجهاز التاني، ال Puls ديت بتحسس وبتستشعر سرعة الجهاز الثاني، هل هي 10 ولا 100 .
أما يعرف الجهاز الاول إن كرت الجهاز الثاني أو البورت بتاع الجهاز الثاني سرعته بس 10 بيقوم الجهاز الأول بيبدأ ال Negotiation ، يعني الجهاز الأول بيقول للجهاز الثاني يا ولد أنا إستشعرت وعرفت إن كرتك بيدعم بس سرعة 10 عشان كده أنا حأبعتلك البايانات أو ال Packets بسرعة 10 ، موافق يا عم الحج ؟؟؟
بيقوم الجهاز الثاني بيرد عليه وبيقوله: صبح صبح يا عم الحج، إيوه موافق، إبعت البيانات بتاعتك على سرعة 10 وكثر الله خيرك.
العملية ديت إسمها Negotiating وديت بتم بعد أن يتأكد الجهاز المرسل من سرعة الكرت أو البورت عند الجهاز الثاني.
زمان أول أيام جدي وجدك الله يرحمهم مكنش فيه Auto-Sensing ، ولا كان فيه Negotiating ، كان الجهاز الأول لما عايز يبعت Packets للجهاز الثاني (دب دب دب) بيقوم مودي البيانات وخلاص، مش بيسأل عن سرعة كرت الجهاز الثاني خالص، لكن بعد إضافة خاصية ال Auto-Sensing الأمور تطورت ، وأصبحت هذه الميزة تجعل الإتصال يتم بين أجهزة بكروت سرعتها 10 وأجهزة بكروت أو بورتات سرعتها 100 بدون مشاكل خالص.
هاه قولت إيه ؟؟؟ إقتنعت ولا لسه؟؟!!
CCIE Voice # 26926CCIE R&S # loadingاللهم لك الحمد والشكر حتى ترضى ... ولك الحمد والشكر إن رضيت
المشاركة الأصلية كتبت بواسطة Spy4Life
إستنى إستنى يا عم الحج سلام فين وجاي منين
متجريش يا راجل خليك معانا شوية وقولي يا راجل
الكلام اللي كاتبه حضرتك جايبه منين؟؟؟؟ من أي كتاب ؟؟؟ من اللي دماغه مهبب درسك الحاجات ديت ؟؟؟
يا راجل هههههههههههههههههههههههههههههه
ال Auto-Sensing ديت تتعلق بإتصال السوتشات ببعضيها البعض لو حد ركب عليها كابل غلط غير الكروس وغير الستريت ؟؟؟؟!!!!!!!!!
ههههههههههههههههههههههه
يا راجل جايب الكلام ده منين يا حج ؟؟؟؟
كككككككككككككككككككككككككككككككككك
قولي قبل ما تجري جبت الكلام ده منين بس قولي يا راجل هههههههههههههههههه
CCIE Voice # 26926CCIE R&S # loadingاللهم لك الحمد والشكر حتى ترضى ... ولك الحمد والشكر إن رضيت
والله إنك رائع يا أخ لومارك
ربنا يبارك فيك وفي علمك (قولوا آمين ) ويعطيك المزيد والمزيد من العلم وتبقى ccie مش(( نص ccie ) هههههههه
بجد دائمًا بنتعلم وبنفهم منك الكتير
ربنا معاك
هو انت عندك اعتراض كمان على ان Auto-Sensing دى بتاعة حاجة تانية ولا حاجة ؟
لا حول الله
المفروض انك تعرف المثل الى بيقول من علمنى حرفا صرت له ايه ؟؟؟؟
قول متتكسفش
ايه بتفكر انك كبير ؟
سيبك من الحجم
لأ لأ لأ
متتهربش يا ريس ... أرجوك خليك مقدع وقد كلمتك ... أمال إيه يا ريس ... اللي بيقول كلام لازم يكون قده ولا بعدين يطلع عيل .... قولي بقه متختشيش يا ريس قولي وخلصني يا راجل ... قولي وأنا أصير لك عبداً يا أخي ... مش عيب ولا غلط ... من علمني حرفاً صرت له عبداً .... وكاد المعلم أن يكون رسولاً ... والله لن أخجل أن أكون لك عبداً ... ولكن يا أخي أصير لك عبداً لما تعلمني حاجة صح ... مش تجيب حاجات من دماغك وتقول لي انا علمتك حرفاً .... عايزين أصير لك عبداً .... مافي مشكلة .... جاوبني على سؤالي للمرة المليون جاوبني على عبارتك التي كتبتها :
الكلام ده جبته منين؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟ ؟؟
إسم المحاضر اللي قال الكلام ده إيه ؟؟؟؟؟؟؟؟؟؟؟؟؟
CCIE Voice # 26926CCIE R&S # loadingاللهم لك الحمد والشكر حتى ترضى ... ولك الحمد والشكر إن رضيت
يا عم إيهاب الله يهدينا ويهديك مين اللي قالك كلامه صح يا راجل؟؟؟؟؟!!!
يا عمي مفيش واحد في العالم بيقول الكلام اللي بيقوله ... مش حينفع خالص يا عم إيهاب.
يا أحبة ال Auto-Sensing هو زي ما شرحته بالظبط، وانا أتحمل مسؤولية هذه المعلومة أمام الله، وال Negotiating هو نفس ما شرحته بالظبط وأتحمل مسؤولية هذه المعلومة أمام الله سبحانه وتعالى.
الكلام اللي بيقوله أخونا ده مش صحيح خالص خالص، ده هو مش عارف الفرق بين ال Sensing وال Negotiation ، ده مش عارف مين اللي بيبتدي أولاً، فكروا معايا شوية يا أحبة:
فاكرين ال CSMA/CD بتاع ال Ethernet Technology ؟؟ ممكن نكتب معناه كامل:
Carrier Sense Multiple Access / Collision Detection
تحسس الحامل أو إستشعار الحامل هذه هي ترجمة ال Carrier Sense.
يا أحبة ال Sensing هو تقنية تم إضافتها لحل العديد من المشاكل، زمان لما تم إختراع بروتوكول أو تكنولوجيا الإيثرنت كانت كلها مشاكل، لأنها كانت تخلو من معرفة حال الطرف الأخر المرسل إليه، يعني الطرف المرسل لم يكن يعلم بأن الطرف المرسل إليه هو في حالة إرسال أو سكون، أيضاً الطرف المرسل لم يكن يعلم حال سرعة البورت عند الطرف الآخر هل هو 10 ولا 100 ولا 1000 ، ولكن بعد إضافة ال Sensing تطورت هذه التكنولوجيا وهي ال Ethernet وأصبحت من أشهر البروتوكولات المستعملة في عالمنا الآن لأنها صارت تعتمد على الإستشعار قبل الإرسال، ومن ثم يبدأ التفاوض على السرعة وأمور أخرى.
أما أن يقال بأن ال Auto-Sensing هي
فهذا كلام مغلوط ولا أساس له من الصحة على الإطلاق ..... فين مصدر الكلام ده يا أستاذ ؟؟؟
CCIE Voice # 26926CCIE R&S # loadingاللهم لك الحمد والشكر حتى ترضى ... ولك الحمد والشكر إن رضيت
لى طلب
انك تعلن بعدها عزلك من رتبة مدير أقسام الشهادات العلمية فى منتدى عرب هاردوير
و الاعتذار لى فى كل منتدى
موافق يا ريس ويشهد الله و الأحبة على ما أقول أنني سأعتذر لك أمام الجميع و سأعتزل هذا المنصب التطوعي ... يلا قول وسمعني يا ريس .
CCIE Voice # 26926CCIE R&S # loadingاللهم لك الحمد والشكر حتى ترضى ... ولك الحمد والشكر إن رضيت
ضوابط المشاركة
المفضلات