11 ноября 2012 в 05:09

Физика Ethernet для самых маленьких tutorial

  • Что такое домен коллизий?
  • Сколько пар используется для Ethernet и почему?
  • По каким парам идет прием, а по каким передача?
  • Что ограничивает длину сегмента сети?
  • Почему кадр не может быть меньше определенной величины?


Если не знаешь ответов на эти вопросы, а читать стандарты и серьезную литературу по теме лень — прошу под кат.


Кто-то считает, что это очевидные вещи, другие скажут, что скучная и ненужная теория. Тем не менее на собеседованиях периодически можно услышать подобные вопросы. Мое мнение: о том, о чем ниже пойдет речь, нужно знать всем, кому приходится брать в руки «обжимку» 8P8C (этот разъем обычно ошибочно называют RJ-45). На академическую глубину не претендую, воздержусь от формул и таблиц, так же за бортом оставим линейное кодирование. Речь пойдет в основном о медных проводах, не об оптике, т.к. они шире распространены в быту.

Технология Ethernet описывает сразу два нижних уровня модели OSI. Физический и канальный. Дальше будем говорить только о физическом, т.е. о том, как передаются биты между двумя соседними устройствами.

Технология Ethernet — часть богатого наследия исследовательского центра Xerox PARC. Ранние версии Ethernet использовали в качестве среды передачи коаксиальный кабель, но со временем он был полностью вытеснен оптоволокном и витой парой. Однако важно понимать, что применение коаксиального кабеля во многом определило принципы работы Ethernet. Дело в том, что коаксиальный кабель — разделяемая среда передачи. Важная особенность разделяемой среды: ее могут использовать одновременно несколько интерфейсов, но передавать в каждый момент времени должен только один. С помощью коаксиального кабеля можно соединит не только 2 компьютера между собой, но и более двух, без применения активного оборудования. Такая топология называется шина. Однако если хотябы два узла на одной шине начнут одновременно передавать информацию, то их сигналы наложатся друг на друга и приемники других узлов ничего не разберут. Такая ситуация называется коллизией, а часть сети, узлы в которой конкурируют за общую среду передачи — доменом коллизий. Для того чтоб распознать коллизию, передающий узел постоянно наблюдает за сигналов в среде и если собственный передаваемый сигнал отличается от наблюдаемого — фиксируется коллизия. В этом случае все узлы перестают передавать и возобновляют передачу через случайный промежуток времени.

Диаметр коллизионного домена и минимальный размер кадра


Теперь давайте представим, что будет, если в сети, изображенной на рисунке, узлы A и С одновременно начнут передачу, но успеют ее закончить раньше, чем примут сигнал друг друга. Это возможно, при достаточно коротком передаваемом сообщении и достаточно длинном кабеле, ведь как нам известно из школьной программы, скорость распространения любых сигналов в лучшем случае составляет C=3*108 м/с. Т.к. каждый из передающих узлов примет встречный сигнал только после того, как уже закончит передавать свое сообщение — факт того, что произошла коллизия не будет установлен ни одним из них, а значит повторной передачи кадров не будет. Зато узел B на входе получит сумму сигналов и не сможет корректно принять ни один из них. Для того, чтоб такой ситуации не произошло необходимо ограничить размер домена коллизий и минимальный размер кадра. Не трудно догадаться, что эти величины прямо пропорциональны друг другу. В случае же если объем передаваемой информации не дотягивает до минимального кадра, то его увеличивают за счет специального поля pad, название которого можно перевести как заполнитель.

Таким образом чем больше потенциальный размер сегмента сети, тем больше накладных расходов уходит на передачу порций данных маленького размера. Разработчикам технологии Ethernet пришлось искать золотую середину между двумя этими параметрами, и минимальным размером кадра была установлена величина 64 байта.

Витая пара и дуплексный режим рабты

Витая пара в качестве среды передачи отличается от коаксиального кабеля тем, что может соединять только два узла и использует разделенные среды для передачи информации в разных направлениях. Одна пара используется для передачи (1,2 контакты, как правило оранжевый и бело-оранжевый провода) и одна пара для приема (3,6 контакты, как правило зеленый и бело-зеленый провода). На активном сетевом оборудовании наоборот. Не трудно заметить, что пропущена центральная пара контактов: 4, 5. Эту пару специально оставили свободной, если в ту же розетку вставить RJ11, то он займет как раз свободные контакты. Таким образом можно использовать один кабели и одну розетку, для LAN и, например, телефона. Пары в кабеле выбраны таким образом, чтоб свести к минимуму взаимное влияние сигналов друг на друга и улучшить качество связи. Провода одной пару свиты между собой для того, чтоб влияние внешних помех на оба провода в паре было примерно одинаковым.
Для соединения двух однотипных устройств, к примеру двух компьютеров, используется так называемый кроссовер-кабель(crossover), в котором одна пара соединяет контакты 1,2 одной стороны и 3,6 другой, а вторая наоборот: 3,6 контакты одной стороны и 1,2 другой. Это нужно для того, чтоб соединить приемник с передатчиком, если использовать прямой кабель, то получится приемник-приемник, передатчик-передатчик. Хотя сейчас это имеет значение только если работать с каким-то архаичным оборудованием, т.к. почти всё современное оборудование поддерживает Auto-MDIX — технология позволяющая интерфейсу автоматически определять на какой паре прием, а на какой передача.

Возникает вопрос: откуда берется ограничение на длину сегмента у Ethernet по витой паре, если нет разделяемой среды? Всё дело в том, первые сети построенные на витой паре использовали концентраторы. Концентратор (иначе говоря многовходовый повторитель) — устройство имеющее несколько портов Ethernet и транслирующее полученный пакет во все порты кроме того, с которого этот пакет пришел. Таким образом если концентратор начинал принимать сигналы сразу с двух портов, то он не знал, что транслировать в остальные порты, это была коллизия. То же касалось и первых Ethernet-сетей использующих оптику (10Base-FL).

Зачем же тогда использовать 4х-парный кабель, если из 4х пар используются только две? Резонный вопрос, и вот несколько причин для того, чтобы делать это:

  • 4х-парный кабель механически более надежен чем 2х-парный.
  • 4х-парный кабель не придется менять при переходе на Gigabit Ethernet или 100BaseT4, использующие уже все 4 пары
  • Если перебита одна пара, можно вместо нее использовать свободную и не перекладывать кабель
  • Возможность использовать технологию Power over ethernet


Не смотря на это на практике часто используют 2х-парный кабель, подключают сразу 2 компьютера по одному 4х-парному, либо используют свободные пары для подключения телефона.

Gigabit Ethernet


imageВ отличии от своих предшественников Gigabit Ethernet всегда использует для передачи одновременно все 4 пары. Причем сразу в двух направлениях. Кроме того информация кодируется не двумя уровнями как обычно (0 и 1), а четырьмя (00,01,10,11). Т.е. уровень напряжения в каждый конкретный момент кодирует не один, а сразу два бита. Это сделано для того, чтоб снизить частоту модуляции с 250 МГц до 125 МГц. Кроме того добавлен пятый уровень, для создания избыточности кода. Он делает возможной коррекцию ошибок на приеме. Такой вид кодирования называется пятиуровневым импульсно-амплитудным кодированием (PAM-5). Кроме того, для того, чтоб использовать все пары одновременно для приема и передачи сетевой адаптер вычитает из общего сигнала собственный переданный сигнал, чтоб получить сигнал переданный другой стороной. Таким образом реализуется полнодуплексный режим по одному каналу.

Дальше — больше


10 Gigabit Ethernet уже во всю используется провайдерами, но в SOHO сегменте не применяется, т.к. судя по всему там вполне хватает Gigabit Ethernet. 10GBE качестве среды распространения использует одно- и многомодовое волокно, с или без уплотнением по длине волны, медные кабели с разъемом InfiniBand а так же витую пару в стандарте 10GBASE-T или IEEE 802.3an-2006.

40-гигабитный Ethernet (или 40GbE) и 100-гигабитный Ethernet (или 100GbE). Разработка этих стандартов была закончена в июле 2010 года. В настоящий момент ведущие производители сетевого оборудования, такие как Cisco, Juniper Networks и Huawei уже заняты разработкой и выпуском первых маршрутизаторов поддерживающих эти технологии.

В заключении стоит упомянуть о перспективной технологии Terabit Ethernet. Боб Меткалф, создатель предположил, что технология будет разработана к 2015 году, и так же сказал:
Чтобы реализовать Ethernet 1 ТБит/с, необходимо преодолеть множество ограничений, включая 1550-нанометровые лазеры и модуляцию с частотой 15 ГГц. Для будущей сети нужны новые схемы модуляции, а также новое оптоволокно, новые лазеры, в общем, все новое


UPD: Спасибо хабраюзеру Nickel3000, что подсказал, про то что разъем, который я всю жизнь называл RJ45 на самом деле 8P8C.
UPD2:: Спасибо пользователю Wott, что объяснил, почему используются контакты 1,2,3 и 6.
Alexander Efremov @siberianMan
карма
40,0
рейтинг 0,0
System Analyst
Похожие публикации
Самое читаемое Администрирование

Комментарии (76)

  • +8
    Спасибо, именно про домен коллизий нужно читать начинающим айтишникам. Куда же они без домена коллизий, да в сеть на коммутаторах сунутся? Расскажите ещё больше про коаксиал, хабы и особенности эксплуатации 10Мбит half-duplex интерфейсов.

    Заметим, реально нужная и серьёзная часть (например, про типы оптики, особенности их кроссировок и возникающие специфичные для оптики проблемы) опущена на словах «а ещё, кроме антиквариата, там и нормальные сети бывают».
    • +19
      amarao: Вы, конечно, человек на этом ресурсе известный и уважаемый, ethernet — одна из постоянно используемых Вами технологий, а хабы, домен коллизий и прочее — устаревшая рухлядь. Но! Не смотря на все это я с удовольствием прочитал статью siberianMan, т.к. пользоваться этой «устаревшей рухлядью» приходилось, но, что такое домен коллизий на столько ясно нигде обяснено небыло (особенно в те мохнатые годы). Возможно, это будет интересно и кому то еще. Если мой комментарий обижает — прошу прощения.
      • +3
        Я согласен с amarao. Если человек не знал написанного в топике, то ему и не стоит забивать себе голову терминами времен прошлого тысячелетия. У меня немало знакомых, уверенных, что коллизии — до сих пор бич ethernet сетей, и чтобы их не было, нужны обязательно управляемые свитчи или роутеры :) Ну и, конечно, любой отправленный одним компьютером пакет обязательно вылетит из всех портов.

        В современном мире коллизий не существуют. В современном мире все хабы давно выкинуты на свалку. Точка. Иначе придется признать, что и IPX неплохо бы изучать всем подряд, с ним ведь тоже когда-то работали.

        Соответственно, к статье есть одна серьезная претензия. В ней не сказано в явном виде, что ко всему в первой половине топика следует относиться как к историческому экскурсу, и что сейчас «домен коллизий» всегда содержит ровно два устройства, которые всегда передают данные в полнодуплексном режиме и потому не могут столкнуться с коллизией.
        Или могут? Да, могут. Например, изначально на свитче и на подключенном у нему устройстве стояло автосогласование, согласовывалось на 100/full. А потом серверному админу пришло в голову, что надо бы жестко выставить 100/full, для надежности. Почему-то после этого сеть начала работать не пойми как, с дикими потерями… Да, это, пожалуй, единственный способ увидеть коллизии в современном мире. И про это автор ничего не рассказал.
        • НЛО прилетело и опубликовало эту надпись здесь
          • +1
            Выше я привел рабочий способ получить коллизии. Однако, этот сценарий не имеет ничего общего с тем, что было раньше.
            «Коллизии между двумя девайсами сейчас можно запросто получить превысив длину сегмента физической линии»
            «А какое поле для «деятельности» в случае каскадирования коммутаторов, вы даже не представляете.»
            Ну-ка с этих моментов поподробнее. Особенно «каскадирование коммутаторов» меня заинтересовало. Я вот не могу себе представить цепочку даже из сотни свитчей, в которой будут коллизии ;)
            • +1
              Ну как ни крути, а методы CSMA/CD являются частью технологии 802.3, думаю, если уж изучать стандарт, то нужно хотя бы общее представление иметь.
              • +1
                CSMA/CD лишь формально присутствует в гигабите, и его вообще нет в 10G и выше.

                Изучать стандарт? Ну признаюсь: я отвратительно знаю, как работает L1 на витой паре. До данного топика даже примерно не представлял себе модуляцию сигнала в 100M/1G линках. Когда-то слышал про слово «преамбула», но смутно понимаю, что это.
                Однако, я весьма хорошо знаю, как работать с L1, какие могут вылезти проблемы, как их обнаружить и устранить.
                Да, я в курсе, что такое «коллизия», однако мне это никак не помогает. Фактически, единственное, что про них надо знать, это краткий алгоритм «видишь коллизии на порту => проверь speed и duplex с обеих сторон => проблема решена».
                • –1
                  Собственно, в статье ничего интересного не сказано. Ни про алфавит гигабита, ни про протоколы согласования скоростей…
                  • +4
                    Я узнал, что в гигабите сигнал кодируется 4-мя состояниями. Это, наверное, сразу удвоило мои знания об устройстве гигабитного езернета на L1.
                    • 0
                      «Кроме того добавлен пятый уровень...»
                  • –2
                    кроме Вас тут есть другие Люди, которым Это может быть интересно и полезно…
        • +1
          а потом вот такие «не нужно забивать голову коллизиями и прочим барахлом» прохвесиионалы лезут своими немытыми руками в Wi-Fi и удивляются, почему все так хреново работает…
          • +1
            Я плотно работаю с вайфайной инфраструктурой (угадайте какого вендора :) ). Работает она зашибись. Если бы она работала не зашибись, то была бы масса жалоб на работу массы вайфай телефонов. Они — ребята очень нежные по части качества сигнала.
            А все потому, что для грамотной организации вайфай сети надо понимать, как она устроена (хотя я все никогда не интересовался методами кодирования), а езернет — «воткнул и поехали».
        • +1
          «У меня немало знакомых, уверенных, что коллизии — до сих пор бич ethernet сетей».

          Это действительно так (о распространенности мненеия), более того, это транслируется некоторой литературой. Хотя в Олиферах начала 2000 это все прекрасно расписано. И про сужение домена коллизий до порт-сетевая в случае свича и полудуплекса и разрешение ситуации в случае фулдуплекса.

          Тут довелось позаниматься достаточно поверхностно темой индастриалезернета, так в относительно свежих специализированных статьях до сих пор пишут, что общий доступ к среде с контролем несущей и коллизии — это то, что мешает немодифицированному езернету активно использоваться на нижнем уровне АСУТП. Хотя давно есть EthernetIP и набор рекомендаций (не упоминаю про синхронные модфицикации езернета, речь об обычном), как на свичах строить нижний уровень при требованиях Soft RealTime. Ну там сегментация, сужение широковещательного домена, CoS, QoS и прочее.
          • 0
            Под рил-тайм есть специальные свитчи, с чертовски низким latency, с первоклассной приоритезацией отдельных видов трафика. Для Nexus 3000 заявляют менее 200нс. Есть конкурент от Arista, там около 500нс. Я как-то посчитал на калькуляторе, сколько метров оптического патч-корда дают такую же задержку, и сколько времени требуется для сериализации 1500-байтного пакета на 40G линке, и проникся безграничным уважением к разработчикам данных ASICов.
            В основном оно предназначено для трейдеров — где иногда лишние 500 наносекунд задержки при передаче пакета крайне нежелательны.
            • +1
              Это все рилтайм не какой надо рилтайм. Рилтайм это не скорость и не низкие задержки, рилтайм это гарантированность и изохронность. Какая-нибудь промшина старая со скоростью меньше мегабита будет рилтайм, а 1G или 10G пусть даже с задержками минимальными — нет. Максимум это будет SRT, но не IRT.
              АСУ-шники за настоящий жесткий рилтайм считают только изохронные вещи. И эти реализации могут работать вообще без свичей, на разделямой среде в том числе, но коллизий там не будет за счет наличия мастера и четкой синхронизации всех устройств с выделением мастером четкого графика передачи для каждого устройства. Хотя да, при сбое синхронизации колллизии там возможны.
              • 0
                рилтайм это гарантированность и изохронность

                Именно под это и делаются подобного класса свитчи.
                Хотя в принципе любые свитчи с DCB и FCoE годятся под рилтайм. Ибо FCoE трафик очень чувствителен и к джиттеру, и к потерям. Ни при каких обстоятельствах не должно быть потерь.
                Ну и сами понимаете — если некое приложение требует микросекундного RTT и за эти микросекунды прокачивает миллионы долларов, то, опять же, связь должна быть исключительно надежной и предсказуемой.
                • 0
                  То, что вы написали — не поставят на управление системой с быстротекущими процессами, на самый нижний уровень, где исполнительные механизмы и контроллеры — это сфера синхронных промышленных шин или модифицированного езернет — так называемые IRT требования. А вот чуть выше, где тоже требования достаточно жесткие, но уже не смертельно, там где SCADA и еще что-то подобное — поставят.
                  Ключевые слова — Powerlink, EtherCAT, ProfiNET. Там модифицирован сам принцип классического езернета. В этих сетях не только гарантированный цикл доставки пакета от точки до точки, но и гарантированный цикл передачи для всех устройств в сети.
                  Если при правильно спроектированной сети на пусть даже прецезионных свичах, но обычного езернет — риск потерь можно минимизоровать максимально, одномастерная синхронная система их исключает на уровне дизайна, архитектуры и принципа работы протокола. Возможность потерь исчезает как класс. Ну, разве кроме ситуаций физической неисправности.
                  • 0
                    обычного езернет — риск потерь можно минимизоровать максимально, одномастерная синхронная система их исключает на уровне дизайна, архитектуры и принципа работы протокола. Возможность потерь исчезает как класс.

                    Я не зря упоминал FCoE. Малейшие потери — и весь массив переходит в RO, вызывая дикую головную боль у администраторов. Современные ЦОДовые коммутаторы гарантируют доставку пакетов (в том числе FCoE) без потерь, для этого применено множество разных технологий. А та же 3000-я линейка нексусов вдобавок к этому еще и обеспечивает невероятно низкую задержку при передаче данных.
                    Нагуглите lossless ethernet.
                    И да, за последние несколько лет в этой области произошел заметный прогресс. Цискины каталисты например все до единого не годятся для беспотерьной передачи данных. А нексусы специально для этого и разрабатывали, такая вот у них архитектура.
                    • +1
                      Я охотно верю. Но факт есть факт. В АСУТП нижнерго уровня это не используют. Невероятно низкая задержка хорошо, но она не всегда нужна а автоматизации. Важнее дать «высказаться» каждому узлу сети ровно в необходимый момент времени. Даже если не будет никакой потери, но не будет выдержан график — катастрофа. Люди не зря придумали все эти модификации, хотя в момент их создания классический езрнет уже был намного быстрее. И индустриальные свичи существовали. Почитайте, как работает Powerlink хотя бы — поймете разницу. Это примерно как спорить, что линукс (оговорюсь — без спец-патчей) ОС реального времени потому, что запущенный на каком-нибудь мегаксеоне последнем он быстрее на порядки, чем QNX на первом пне. Быстрее, но дело не в этом.

                      lossless ethernet погуглю :)
                      • 0
                        Даже если не будет никакой потери, но не будет выдержан график — катастрофа.

                        Именно для этого и разрабатываются low-latency коммутаторы.
                        Еще раз: есть некие приложения, которые играют на том, что два других узла рассинхронизированы на несколько микросекунд. Им требуется мгновенная, гарантированная доставка пакетов и абсолютная синхронизация. Как и в случае ваших АСУТП. Точнее — в моем случае требования к качеству передачи данных куда выше, чем в вашем.
                        Указанные вами технологии используются по инерции — потому что их хватает, и надобности заменять их на что-то более совершенное нет.
                        • 0
                          Ремарка.
                          В промышленных сетях АСУТП (не во всех конечно, там где это необходимо) точность синхронизации (посредством PTP) — мньше 1 мкс. Вы меня убедили, что данный класс оборудования дает тот же самый результат и даже лучше. Вопрос только в том — что решение это своего рода брутфорс. В классических же АСУТП сетях это решение — архитектурное. Ваша линейка оборудования доросла до того, что бы обеспчивать losless? Здорово. Но АСУ изначально шло по пути изменения протокола и архитектуры.
                • 0
                  Вы поймите, езрнет девайсы давно достигли в своем развитии определенного уровня, однако на производствах, где технопроцессы связаны с опасными средами, где требования непрерывности и прочие риски — используются другие вещи. Классический езернет — по сути мультимастерная сеть. Синхронный езернет — каждый передает по четкому графику, пусть даже не с такими классными параметрами, как вы привели выше. Именно поэтому классические синхронные шины еще и не сдают своих поизиций… пока.
                  • 0
                    Вы поймите, что требование передачи данных по ethernet без потерь встречается не только в указанных вами случаях. Оно на самом деле широко распространено. Ваши классические синхронные шины используются потому, что, во-первых, их производительности хватает, а во-вторых — современное железо, исключающее потери на ethernet транспорте, стоит вовсе не две копейки.
                    • 0
                      Вы все о потерях… Да может не быть потерь, может. В обычном езрнете каждая станция сама себе голова — когда захотела, тогда и передала данные. Потерь не будет, может и задержек даже критичных не будет. Но это за счет… как бы это сказать… Запаса. По принципу — сила есть, ума не надо. Если же передачу каждой станции контролировать — вопрос решен. Для любых скоростей. Разница чувствуется? Им просто неоткуда взяться, если мы управляем передачей централизовано. Это гарантия принципиальная, а не по логике — на это способно крутое железо.
                      • 0
                        Потерь не будет, может и задержек даже критичных не будет. Но это за счет… как бы это сказать… Запаса.

                        Назовите конкретную особенность, которая не позволяет использовать современные коммутаторы под указанную вами задачу.

                        Централизация управления передачей данных — куда более отвратительный подход, чем неблокируемая локальная фабрика коммутации и мощная приоритезация на уровне каждого порта, с большим запасом по пропускной способности.
                        • 0
                          Я возьму паузу для ответа :) Пока считайте, что убежден вашими доводами.
                        • 0
                          Да, кстати. Помнится в теме про связь ДЦ по L2 вы много чего про L2 недоброго говорили. Домен отказа и все такое. В ваших устройствах со всевозможными глюками типа штормов широковещательных и прочего чем бороться? Классическими средствами типа storm-control и прочие механизмы защиты? Ну та же приоритезация может помочь. Может мой пример неудачный, но вы поймете, что я имею в виду. В системе с разделением времени, когда для передачи каждого узла выделен временной слот, любые траблы, создаваемые одним узлом не повлияют на передачу других. Их слот у них никто не отнимет. При этом источник проблем может как угодно «засрать» свой. Поправьте меня, если я что-то переврал.
                          • 0
                            В ваших устройствах со всевозможными глюками типа штормов широковещательных и прочего чем бороться?

                            Грамотным дизайном. Современные коммутируемые сети строятся не на STP, а на TRILL. Плюс — «QoS на стероидах» вроде DCB и PFC. В итоге даже тотальный шторм никак не повлияет на время или качество доставки приоритетных пакетов. Хотя никто не отменял storm control…

                            А сколько должно быть устройств в широковещательном сегменте для ваших АСУТП? Если десяток-два, то широковещательный сегмент может быть представлен в виде одного-двух (для резервирования) коммутаторов.
                            А реализовано ли у вас резервирование коммутаторов с временем восстановления в пределах нескольких миллисекунд (в зависимости от характера аварии)?
                            • 0
                              В пром сетях не используют обычный STP. Там проприетарные протоколы типа TurboRING, HyperRING и прочее. Могу ошибиться, но что-то в районе 20mc. Но опять же, это в сетях верхнего уровня. В по-настоящему критичных и жестких случаях делается полное дублирование. Хотя это бывает и дорого. И да, я писал, свичей может не быть вообще. Они даже могут мешать. Если надо сделать отказоустойчиво — выполнят второй контур. Он будет работать параллельно и независимо.
      • +1
        Я не возражаю против объяснения всёго этого, я за то, чтобы разделять now() и history(). Пишешь про устройство таблицы прерываний на какой-нибудь Амиге — явно отделяй его от современного MSI-X. Одно дело почитать о том, как были устроены компьютеры/сети/программы в прошлом (поучительно и любопытно), другое дело читать про то, как работает инфраструктура сейчас (необходимо и обязательно).

        Когда их путают — получается плохая статья.
        • +1
          Согласен с Вами. Выводы сделал.
    • 0
      Ну что вы, вот мне все это полезно было прочитать, хотя на мой взгляд название для статьи не самое удачное, но было вполне интересно.
      PS. справедливости ради, тема с оптическими кабелями как-то внезапно уж оборвалась, можно было как раз тут «физику» и раскрыть.
  • 0
    Всё равно не понимаю, как так получается: при переходе с 100 Мбит на 1 Гбит количество пар увеличилось вдвое, а скорость в 10 раз.
    • 0
      зависимость не линейная. меняется (увеличивается) частота передачи данных, при том, что меньше пакетов теряется из-за ошибок.
    • +4
      Ну просто же совсем.
      Вместо одной пары на передачу используются все 4 = рост в 4 раза.
      Вместо двух уровней сигнала в паре используется 4 уровня = рост еще в 2 раза.
      Плюс подняли опорную частоту со 100 до 125 МГц = рост еще в 1.25 раза.
      Итого 4х2х1.25 = 10.
      • –2
        А принимать сигнал по оставшимся 0 парам?
        • +2
          >>Кроме того, для того, чтоб использовать все пары одновременно для приема и передачи сетевой адаптер вычитает из общего сигнала собственный переданный сигнал, чтоб получить сигнал переданный другой стороной. Таким образом реализуется полнодуплексный режим по одному каналу.

          Кстати говоря именно по этой причине в обе стороны обычно не более 60МБ\с (~0.5Гб\с).
          • 0
            Понял, спасибо.
          • 0
            Кстати говоря именно по этой причине в обе стороны обычно не более 60МБ\с (~0.5Гб\с).

            Зависит от кривизны рук производителей сетевых карт.
            Сейчас специально провел колхоз-тест двумя парами iperf'ов и получил в одну сторону 930Мбит/с, а в другую 600 Мбит/с при одновременной передаче, с сетевыми картами Intel. При этом на источнике трафика, который показал 600Мбит/с, можно бы и больше выжать, если подкрутить настройки сетевой подсистемы.

            В то-же время позволю себе кинуть камень в огород Realtek, так как я пока не встречал у них сетевых карт, которые вытягивали бы более ~600Мбит/с даже при односторонней передаче данных.
            • 0
              Не забывайте, общей пропускной способности мало.
              Надо учитывать pps при минимальных и максимальных размерах пакетов.
              • +1
                А при чем тут pps? Их имеет смысл считать только когда пакеты маленькие и, по этому, их много. В данном случае iperf не дает большого количества маленьких пакетов, так как отправляет данные большими блоками. В связи с этим сетевая карта должна вытягивать полную пропускную способность.
                • 0
                  Так и пишите, размер пакетов.
                  А в реальной жизни большая доля мелких пакетов.
                  • +1
                    Я указал на используемый для тестирования общепринятый инструмент.
                    Из справки следует, что «set length read/write buffer to n (default 8 KB)», те буфер на уровне приложения по умолчанию 8кбайт, что при отключенных jumbo frame значительно больше, чем размер одного ethernet-кадра, следовательно смотреть на pps не имеет смысла. При полученной пропускной способности у нас и так будет минимально возможное значение pps на L2 уровне.

                    А в реальной жизни большая доля мелких пакетов.

                    Разрешите уточнить, какую из реальных жизней Вы имеете ввиду?
                    Моя основная реальная жизнь, где из приложений сетевой подсистеме передаются блоки размеры которых измеряются мегабайтами (и следовательно фрагментируются они оптимально) чем-то менее реальна, чем жизнь в телекоме с торрентами?
        • 0
          А принимать по тем же самым 4м парам. В статье про это написано.
    • 0
      На самом деле есть (была) и другая версия гигабита — две пары туда, две пары обратно, каждая выдаёт по 500 мбит/с. Не прижился.
  • –1
    Боб Меткалф, создатель Eедположил, что технология будет разработана к: е сказал:
    коллизия моска :)
    спасибо за интересную статью.
  • 0
    Не смотря на это на практике часто используют 2х-парный кабель, подключают сразу 2 компьютера по одному 4х-парному,


    Убил бы кулибиных за такое доброе использование, когда простой переход с «напольной» сети на нормальную «внутристенную» певращается в ад с попыткой разобраться куда же залинкован этот грёбанный хвост!

    • 0
      самая жесть когда этот кабель потрошат вдоль и получают 2 кабеля по 2 пары :(
      • 0
        Потрошение UTP — это для извращенцев-мазохистов. Извращенцы-эстеты используют кроссировочные кабели.
  • 0
    Наиболее интересующий меня вопрос во всем этом — почему используются именно контакты 1-2 и 3-6, кто это придумал и сколько он будет гореть в аду?
    В том плане, почему было не взять 1-2, 3-4 что сэкономило бы кучу сил монтажникам…
    • +3
      если посмотреть на схему то видно что пары расходятся от центра 4-5 3-6 и две по бокам ( точнее нумерация пар чуть-чуть другая, но не важно )
      если посмотреть на RJ-11 и прочие то видно что это сделано для совместимости, то есть в разетку можно воткнуть телефон и на другой стороне центральную пару завести на телефонный аналоговый кросс и это будет нормально работать ( даже можно и FE паралельно пользовать, но не нужно )
      • +5
        Черт. Спасибо, что просветили… В общем ширина задницы римской лошади определила габариты Шаттла.
      • +2
        Спасибо. Никогда не задумывался об этом раньше. Добавил в текст статьи.
    • +1
      The original idea in wiring modular connectors, as seen in the registered jacks, was that the first pair would go in the center positions, the next pair on the next outermost ones, and so on. Also, signal shielding would be optimized by alternating the «live» and «earthy» pins of each pair. The TIA/EIA-568-B terminations diverge slightly from this concept because on the 8 position connector, the resulting pinout would separate the outermost pair too far to meet the electrical echo requirements of high-speed LAN protocols.

      en.wikipedia.org/wiki/TIA/EIA-568#Theory

      А вы не задумывались, почему витая пара… витая?)
      • 0
        тогда бы пользовались пары 4-5 и 1-2
  • +1
    Опоздала статья лет так на 15, домен коллизий, кроссовер кабеля, коаксиал, концентраторы — зачем все это? Те кто помнит и так разбираются в сетях, те кто только изучает — получит багаж устаревшего ненужного хлама знаний. Лучше бы про типы оптики и современные тенденции побольше. В средних и крупных городах уже и SOHO сегмент перетянут на оптику вплоть до «последней мили», а тут на тебе коаксиал.
  • 0
    PoE работает на двух парах.
    Практика критерий истины ;)

    Во избежание недопонимания: есть работающий VoIP телефон, питающийся через PoE и подключенный через две пары.
    • 0
      PoE работает на двух парах.

      Когда — как. PoE разный бывает.
      supportforums.cisco.com/docs/DOC-10259
      • 0
        Как следует из ссылки:
        По стандарту — работает
        По стандарту Cisco — не работает

        Не удивительно ;)
        • +1
          Потому что Cisco, как всегда, первой реализовала технологию питания устройств по ethernet, и только потом появился стандарт ;)
  • +1
    >40-гигабитный Ethernet (или 40GbE) и 100-гигабитный Ethernet (или 100GbE). Разработка этих стандартов была закончена только в июле 2010 года. В настоящий момент ведущие производители сетевого оборудования, такие как Cisco, Juniper Networks и Huawei уже заняты разработкой и выпуском первых маршрутизаторов поддерживающих эти технологии.

    Это с какого такого древнего рекламного проспекта Cisco копипаст? «только в июле 2010 можно сказать в конце 2010, но в конце 2012 это уже седая древность.

    И вообще-то даже на момент принятия стандарта были продукты с 40G на драфте. В любом случае стандарт специально делался для упрощения работы и имеющиеся платы 4x10G относительно легко стали 1x40G. Другой вопрос что архитектура „ведущих производителей“ не позволяла полноценно работать на этих скоростях.
    • 0
      extreme networks же, не?
    • 0
      Mellanox, BNT
    • 0
      не буду раздувать холивар вокруг брендов, скажу лишь
      L2 свитч с несколькими 40G это уже не экзотика — если надо таковой можно найти практически у любого серьезного вендора
      проблема возникает на рутинге — старые шасси не справляются с такими скоростями, архитектура с центральных процом тоже. Требуются уже более умные линейные платы aka ASIC и полноценный MPLS. Для датацентра это все не так актуально, а вот для провайдера уровня города — очень даже. Хотя даже в Москве выше 40G еще вроде никто не прыгал.
      • 0
        Требуются уже более умные линейные платы aka ASIC и полноценный MPLS. Для датацентра это все не так актуально

        Да ну на фиг? Современный ЦОД без MPLS — фигня какая-то. Да и с учетом виртуализации, 10G на аплинк — маловато будет. Так что как раз для ЦОДов и нужны быстрые коммутаторы. Причем именно L3 коммутаторы.
        старые шасси не справляются с такими скоростями

        Потому делают новые. К примеру, у циски есть абсолютно модульные нексусы 7k, в которых и фабрика поддается замене. Всего можно вставить 5 модулей, каждый дает по 110гб/с на слот (кроссбар). Выйдут новые — не проблема обновиться без замены шасси, и, наверное, плат и супервизоров.
        По роутингу тоже никаких проблем. Старые F1 платы, правда, роутить не умели, задействуя ресурсы М карт, но F2 избавлены от этого позорного недуга (хотя временами все равно могут задействовать ресурсы М-ок).
        • 0
          >10G на аплинк

          А что IX стал давать больше 10G?

          >Современный ЦОД без MPLS — фигня какая-то.

          И много у нас ЦОД, которым реально нужен MPLS?
          несколько разнесенных аплинков?
          распределенные кластера виртуализации?
          • 0
            А что IX стал давать больше 10G?

            Причем тут IX? Под «датацентр» я понимаю «корпоративный датацентр со своим сетевым и серверным оборудованием».
            И много у нас ЦОД, которым реально нужен MPLS?
            несколько разнесенных аплинков?
            распределенные кластера виртуализации?

            Много. Очень. Если взять 1000 крупнейших компаний страны (по капитализации), то у каждой из них в ЦОДах будет тот самый MPLS, полностью резервированная двухуровневая (или даже трехуровневая) сетевая топология и виртуализация.
            Скорее всего, цифры «1000» сильно занижена.
          • 0
            >А что IX стал давать больше 10G?
            40G
  • 0
    На самом деле, для 10GE Ethernet используются модули и кабели SFP+, а для 40GE QSFP.
    • 0
      Это вы вообще к чему? XENPAK, XFP, X2 — тоже вполне себе десяточные и очень распространённые модули. SFP+ это всего лишь самый современный формфактор, обеспечивающий максимальную плотность десяток на слот (не считая переходников из QSFP в 4x10GE).
      А 40GE, в свою очередь, может работать и через CFP-модули, необязательно QSFP.
      • 0
        >>XENPAK, XFP, X2 — тоже вполне себе десяточные и очень распространённые модули.

        >>CFP-модули

        Очень большие модули. Для маршрутизатора пойдут, а вот для L2 комутатора слишком большие. К тому же эти модули только оптические, а с SFP+ и QSFP есть и медные кабели, что на много дешевле.
        • 0
          Насчёт компактности всё верно, SFP+ самый молодой и технически самый актуальный форм-фактор для 10GE, позволивший спрятать всю начинку в сверхкомпактный корпус, позволяющий создавать одноюнитовые коммутаторы с 48 десятками на борту. Уже даже и дальнобойные ZR для SFP+ появились, что раньше казалось невозможным.

          А вот насчёт исключительно оптической направленности указанных мной модулей не надо сказок. XENPAK и X2 имеют возможности подключения медных модулей — у циски это архаичный CX4 для первого и 10GBASE-T для второго. У других вендоров не смотрел.
  • 0
    Всегда было интересно, каким образом происходит синхронизация передатчика и приемника по скорости при отсутствии сигнала синхронизации как, например, в SPI? Например, если подключить роутер, поддерживающий только 100 мбит, к гигабитной сетевой карте, всё будет отлично работать. Как сетевая карта определяет, что устройство на другом конце провода поддерживает только более старый стандарт и более низкую скорость?
    • +1
      В начале каждого кадра идет последовательность из высоких и низких сигналов. Она обозначает начало кадра, а также её длина такова, что если коллизия произойдет, то она произойдет во время передачи этой последовательности.
  • 0
    > Возникает вопрос: откуда берется ограничение на длину сегмента у Ethernet по витой паре, если нет разделяемой среды?

    >Таким образом если концентратор начинал принимать сигналы сразу с двух портов, то он не знал, что транслировать в остальные порты, это была коллизия. То же касалось и первых Ethernet-сетей использующих оптику (10Base-FL).

    Я далек от физики, но вот тут не понял. Всегда думал что ограничение ~100 метров из-за затухания сигнала. На некоторых древних 10мбитных цисках и хорошей витой пары добивало до 170 метров.
    Или я путаю термины и длина сегмента это про размер кадра, а не длину кабеля между двумя устройствами?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.