Comments 27
скорость в 10 Гбит превышает даже скорость чтения/записи многих моделей жестких дисков
Многих? Разве не всех?
Нет не всех, OCZ Z-Drive R5 7.2 ГБ/с (именно гигабайт, а не гигобит)
Ну а так как новость написана для некомпетентных в сфере IT хомячков, можно добавить, что на самом деле данные будут перекачиваться между массивами вроде такого, а не между отдельными хомячковыми винтами.
Качать торренты будет теперь совсем скучно. Ну что такое — три секунды на фильм в формате Blu-Ray?
Подобная пропускная способность позволяет передать объем данных, равный 5400 Blue-ray дискам в день.
Каждый раз, когда кто-то произносит такое, особенно на ITшном ресурсе, в мире умирает котенок.
скорость в 10 Гбит превышает даже скорость чтения/записи многих моделей жестких дисков.
А что, для кого-то 10гб/с — это много?
Да, понимаю, топик про очень дальнобойную связь. Там это считается достижением. Но в кампусных и ЦОДовых сетях 10G давно стал стандартом и уже даже чуточку начал устаревать (если отдельным серверам давать 10G, то на аплинки уже надо 40G, агрегировать 10G нежелательно).
Чего не желательно? Мы вот на сервере 2*10Г аггрегируем, нормально все.
Мы вот на сервере 2*10Г аггрегируем, нормально все.
Аплинки. Любая агрегация ethernet подразумевает, что один поток данных всегда идет по одному линку. Т.е. сервер, выдавший все 10гб/с, загрузит один 10G аплинк, и другому потоку данных, волей рандома попавшему на тот же аплинк, не повезет, и он будет толкаться с первым. Даже если всего аплинков 8, и логический интерфейс загружен на 1/8. Потому каждый индивидуальный аплинк свитча должен быть шире каждого индивидуального даунлинка. Если сервера подключаются к свитчу уровня доступа по 10G — будьте добры сделать 40G до ядра/агрегации.
Проблема не в сырой пропускной способности. На физическом/канальном уровне 10GE — уже давно не новость. И 40GE аплиньки есть, и DWDM всякие для мультиплексирования каналов в одно волокно…
Проблема в том, что утилизировать даже длинный 1GE на Application level для одной задачи уже не так просто. Утилизировать 10GE еще сложнее.
Если нам нужна гарантия доставки, то нам нужно отправлять подтверждения и как-либо контролировать потерянные пакеты (в сетях с классической коммутацией пакетов гарантированная работа без потерь на практике невозможна). А каждое такое подтверждение придет не раньше чем время RTT.
В случае классических алгоритмов с окном передачи мы имеем, что чем больше скорость канала и чем больше RTT тем хуже работает алгоритм и тем меньше получается эффективная скорость передачи данных.
Для решения этих проблем изобретают различные алгоритмы управления перегрузкой в TCP, специализированные протоколы (например, UDT), различные технологии параллельной передачи данных по множеству соединений и т.д.
Из этого можно сделать вывод, что главное — это не то, что получили 10GE — это давно не новость, а то, что получили:
В телекомах все значительно проще, по этому данное достижение и кажется спорным. Но телекомы заканчиваются на сетевом уровне (IP), а там и потери допустимы протоколами и протоколов с состоянием не наблюдается. В стандартных задачах тоже существуют множество медленных клиентских соединениях, по этому и получается забить все 10GE серверов.
Проблема в том, что утилизировать даже длинный 1GE на Application level для одной задачи уже не так просто. Утилизировать 10GE еще сложнее.
Если нам нужна гарантия доставки, то нам нужно отправлять подтверждения и как-либо контролировать потерянные пакеты (в сетях с классической коммутацией пакетов гарантированная работа без потерь на практике невозможна). А каждое такое подтверждение придет не раньше чем время RTT.
В случае классических алгоритмов с окном передачи мы имеем, что чем больше скорость канала и чем больше RTT тем хуже работает алгоритм и тем меньше получается эффективная скорость передачи данных.
Для решения этих проблем изобретают различные алгоритмы управления перегрузкой в TCP, специализированные протоколы (например, UDT), различные технологии параллельной передачи данных по множеству соединений и т.д.
Из этого можно сделать вывод, что главное — это не то, что получили 10GE — это давно не новость, а то, что получили:
К примеру, BGI передала 24 ГБ данных генетических исследований между Пекином и Университетом Калифорнии всего за 30 секунд. Парой дней ранее такой же объем данных был передан по обычным сетям (в том же направлении) примерно за 26 часов.
В телекомах все значительно проще, по этому данное достижение и кажется спорным. Но телекомы заканчиваются на сетевом уровне (IP), а там и потери допустимы протоколами и протоколов с состоянием не наблюдается. В стандартных задачах тоже существуют множество медленных клиентских соединениях, по этому и получается забить все 10GE серверов.
утилизировать даже длинный 1GE на Application level для одной задачи уже не так просто.
Под «длинный» обычно понимается «высокая задержка», а тут скорее «широкий» :)
В случае классических алгоритмов с окном передачи мы имеем, что чем больше скорость канала и чем больше RTT тем хуже работает алгоритм и тем меньше получается эффективная скорость передачи данных.
А ну быстро закрывайте учебник :)
В случае передачи данных в пределах ЦОДа на 10G линках двухсторонняя задержка составляет 10-20мкс (на плохом железе). 40G коммутаторы запросто опускат ее до уровня 1-2мкс и ниже. При достаточном размере окна и jumbo frame'ах, вызванное RTT снижение скорости работы TCP даже не «пренебрежительно мало» — его фактически нет, стоп-фактором уже скорее всего будет производительность сторы и/или CPU.
И нет, TCP дело не исчерпывается, есть еще UDP, где контроль за целостностью передан на уровень приложения. Но UDP и протоколы на его основе исключительно редко используются для передачи чего-либо кроме голоса/видео. Проблем больше, чем пользы.
Но телекомы заканчиваются на сетевом уровне (IP), а там и потери допустимы протоколами и протоколов с состоянием не наблюдается.
Расскажите про допустимость потерь FC и FCoE. И нет, «сетевой уровень» != «IP», там много чего другого может крутиться.
В современных ЦОДах считается, что трафик критических сервисов (хоть FCoE, хоть TCP) дропаться не должен вообще, а RTT должнен быть стабильным.
В стандартных задачах
Какие задачи являются стандартными? :)
Трафик репликации сторы / резервного копирования к примеру влегкую сможет уделать 10G одним потоком.
В ЦОДах. На этом Вашу мысль можно завершать.
У Вас в ЦОДе есть линьки минимум по 500км оптики (ретрансляционное и коммутирующее оборудование прикладные задачи не решает, по этому его опускаем) между двумя оконечными системами?
По этому, все что сказано мной сказано для длинных линьков. Где именно длина и как следствие большое время прохождения сигнала является ключевым фактором. И учебниках правду пишут. Только про реальные цифры нужно помнить, чтобы начинать беспокоиться только тогда, когда нужно, а не в пределах ЦОДа.
В свете вышесказанного совершенно непонятно зачем Вы расписали всю теорию для сверхкоротких линий связи. (Напомню, что в топике говориться про канал США-Китай, а он уж точно на много порядков длиннее датацентра).
А я про что сказал? UDT — на базе UDP реализован. И если мне память не изменяет его не так уж редко используют. По этому далеко не всегда UDP только для голоса используется. Далеко не всегда.
Внутри ЦОДа да, а между уже гораздо сложнее. И чем дальше — тем сложнее.
В обсуждаемом контексте все, где не нужно передать терабайты данных на тысячи километров как можно быстрее, но суть не в этом.
В пределах ДЦ легко, но некоторые вендоры, например, утверждают что синхронная репликация в их хранилищах на расстояниях более 300км не поддерживается, что как бы подтверждает, что проблема именно в длине, а не в ширине.
И чем длиннее линии связи, тем сложнее уделать 10G одним потоком.
У Вас в ЦОДе есть линьки минимум по 500км оптики (ретрансляционное и коммутирующее оборудование прикладные задачи не решает, по этому его опускаем) между двумя оконечными системами?
По этому, все что сказано мной сказано для длинных линьков. Где именно длина и как следствие большое время прохождения сигнала является ключевым фактором. И учебниках правду пишут. Только про реальные цифры нужно помнить, чтобы начинать беспокоиться только тогда, когда нужно, а не в пределах ЦОДа.
В свете вышесказанного совершенно непонятно зачем Вы расписали всю теорию для сверхкоротких линий связи. (Напомню, что в топике говориться про канал США-Китай, а он уж точно на много порядков длиннее датацентра).
И нет, TCP дело не исчерпывается, есть еще UDP, где контроль за целостностью передан на уровень приложения. Но UDP и протоколы на его основе исключительно редко используются для передачи чего-либо кроме голоса/видео. Проблем больше, чем пользы.
А я про что сказал? UDT — на базе UDP реализован. И если мне память не изменяет его не так уж редко используют. По этому далеко не всегда UDP только для голоса используется. Далеко не всегда.
В современных ЦОДах считается, что трафик критических сервисов (хоть FCoE, хоть TCP) дропаться не должен вообще, а RTT должнен быть стабильным.
Внутри ЦОДа да, а между уже гораздо сложнее. И чем дальше — тем сложнее.
Какие задачи являются стандартными? :)
В обсуждаемом контексте все, где не нужно передать терабайты данных на тысячи километров как можно быстрее, но суть не в этом.
Трафик репликации сторы / резервного копирования к примеру влегкую сможет уделать 10G одним потоком.
В пределах ДЦ легко, но некоторые вендоры, например, утверждают что синхронная репликация в их хранилищах на расстояниях более 300км не поддерживается, что как бы подтверждает, что проблема именно в длине, а не в ширине.
И чем длиннее линии связи, тем сложнее уделать 10G одним потоком.
По этому, все что сказано мной сказано для длинных линьков.
Дык и там оно не вполне соответствует действительности. Очень большое окно плюс минимальные потери плюс SACK на случай потерь = один TCP поток без проблем сможет забить 10G линк с RTT, скажем, 100мс. А сильно больше по океанской оптике и не встретить.
В свете вышесказанного совершенно непонятно зачем Вы расписали всю теорию для сверхкоротких линий связи.
Очевидно — потому что ваш комментарий касался в топиках, где как раз упоминались кампусные и ЦОДовые сети, а вот про задержки уровня десятков миллисекунд там ни слова сказано не было.
И если мне память не изменяет его не так уж редко используют.
Повторюсь — ИСКЛЮЧИТЕЛЬНО редко. Практически никогда. Единичные компании могут задействовать его для единичных потоков данных, но не более того.
некоторые вендоры, например, утверждают что синхронная репликация в их хранилищах на расстояниях более 300км не поддерживается
Видимо, речь идет про FC. Тут да — специфика FC такова, что отправитель должен получить ACK на отправленный фрейм чуть ли не в процессе проталкивания фрейма в кабель :) Там есть понятие «buffer credits». Требования повышаются при повышении расстояния либо скорости среды.
Во всех остальных случаях (сервисы на базе IP) вендоры оговаривают не расстояния, а именно RTT. И дело там в том, что скорость репликации падает, просто слишком увеличивается рассинхронизация между системами и растет вероятность ошибки.
Дык и там оно не вполне соответствует действительности. Очень большое окно плюс минимальные потери плюс SACK на случай потерь = один TCP поток без проблем сможет забить 10G линк с RTT, скажем, 100мс. А сильно больше по океанской оптике и не встретить.
Вы на практике это реализовывали? Если да, то напишите пожалуйста статью, как Вам это удалось. Я серьезно.
Повторюсь — ИСКЛЮЧИТЕЛЬНО редко. Практически никогда. Единичные компании могут задействовать его для единичных потоков данных, но не более того.
Можно посмотреть на udt.sourceforge.net/poweredby.html и оценить на сколько единичные решения у EMC и остальных проектов по списку.
Видимо, речь идет про FC.
Понятия не имею, что внутри этих железок для репликации, но наружу из них может торчать и FC и обычный 10GE c iSCSI и NFS с CIFS'ом.
И дело там в том, что скорость репликации падает,
А почему она падает? Не по той-ли причине, о которой мы рассуждаем? Если рассинхронизацию в 5мс по причине скорости света еще можно допустить, то ухудшение эффективности использования канала может существенно повысить время перекачивания данных.
А если из практики подключения хранилищ данных от EMC, то в случае клиента в соседней стойке, протокола NFC и канала 1GE все упирается в канал, а когда до клиента 5мс RTT, то и NFS и CIFS дают где-то 100-200-300Мбит/с даже на больших файлах (после файлов в 4Гб тестировать стало лень, так как и так все понятно).
Вы на практике это реализовывали?
Я — нет. Но лично знаю людей, которые — да.
Можно посмотреть на udt.sourceforge.net/poweredby.html и оценить на сколько единичные решения у EMC и остальных проектов по списку.
Вы название хотя бы одной из этих компаний/проектов слышали раньше помимо EMC?
А почему она падает?
Криво выразился. Имелось в виду, что падением битрейта TCP из-за RTT все пренебрегают, проблема вовсе не в этом.
ухудшение эффективности использования канала может существенно повысить время перекачивания данных.
Нет никакого существенного падения скорости передачи информации, забудьте. Есть тот факт, что две реплики рассинхронизированы на 200, 300 и более мс. из-за того, что репликационный трафик долго до них ползет. Даже если его там килобиты. И ни один кластер не сможет существовать поверх GPRS при тех же килобитах репликации.
А если из практики подключения хранилищ данных от EMC, то в случае клиента в соседней стойке, протокола NFC и канала 1GE все упирается в канал, а когда до клиента 5мс RTT, то и NFS и CIFS дают где-то 100-200-300Мбит/с даже на больших файлах
Ну вот кому я раньше несколько раз писал про большие окна?
Вот навскидку статья — www.kehlet.cx/articles/99.html
«we found turning up the TCP window size on our gigabit ethernet-capable systems had a significant performance boost on LAN throughput as well. Using Iperf (see links at end of article), a great tool for testing different TCP window sizes and their effect on throughput, we realized an increase from about 300Mbps to 850-900Mbps.»
Можно найти рекомендации по увеличению размера окна под любую ОС. Хотя на самом деле тема под названием «тюнинг TCP» весьма обширна. Скажем, если на линке есть потери, а окно повышается без SACK, то будет хуже, чем со стандартным окном. Тем не менее, можно добиться того, чтобы TCP не тормозил при больших задержках, в него встроено много костылей для этого.
Я — нет. Но лично знаю людей, которые — да.
А я к сожалению нет. Да и ведущие университеты мира(из США) тоже нет. По этому, как говориться, или воспроизводимое подтверждение или признание поражения. Мне жаль, что пришлось скатиться до личностей.
Вы название хотя бы одной из этих компаний/проектов слышали раньше помимо EMC?
Про университетско-научные-суперкомпьютерные слышал. Да и о некоторых других тоже.
Имелось в виду, что падением битрейта TCP из-за RTT все пренебрегают, проблема вовсе не в этом.
Все, кто с этим не сталкивался и ровно до тех пор, пока не столкнуться.
Вот навскидку статья — www.kehlet.cx/articles/99.html
Читаем: «Much better. And in fact now we're getting a full 1.9-2Mbps on our WAN link.», где Вы в этой статье увидели про высокоскоростные линии связи большой протяженности?
В вашей цитате английским по белому написано «LAN». На современном оборудовании получить в гигабитном LAN 300Мбит/с — это надо ОЧЕНЬ постараться. Вот прямо сейчас прогнал iperf между двумя серверами в соседних здания — 930Мбит. На одном RedHat 5, на втором openSUSE 12.1, настройки по умолчанию.
Про окна я знаю, но этот механизм с ростом скорости и RTT начинает работать только хуже. И большие окна с SACK тоже не панацея.
Я Вам привел реальный пример эффективности стандартных протоколов на междугородней линии связи, а Вы мне все про LAN рассказываете. Разница в том-же RTT на 4 порядка!
По этому, как говориться, или воспроизводимое подтверждение или признание поражения.
Может, мне надо предоставить воспроизводимое доказательство 2+2=4? Мне очень тяжко разговаривать с человеком, который начитался давно устаревшей матчасти и не понимает текущего состояния вещей.
На современном оборудовании получить в гигабитном LAN 300Мбит/с — это надо ОЧЕНЬ постараться.
А знаете, чем отличается старое оборудование/ПО от современного? Правильно — старые свитчи давали большую задержку, а на старом ПО был низкий размер окна (в статье поправлено).
Про окна я знаю, но этот механизм с ростом скорости и RTT начинает работать только хуже.
А вот это уже профнепригодность.
Почитайте статью bradhedlund.com/2008/12/19/how-to-calculate-tcp-throughput-for-long-distance-links/ и расскажите, каким образом я получил, что размера окна в 120мб хватит для полной утилизации 10G линка с RTT 100мс.
Вот еще NASA рассказывает, как подкрутить настройки под 10G/80мс на реальных системах — www.nren.nasa.gov/tcp_tuning.html
Я Вам привел реальный пример эффективности стандартных протоколов на междугородней линии связи
Вывод: если возникает задача постороения территориально распределенной сети, имеет смысл поручить это человеку, который хоть что-то знает про TCP, без обид :)
Может, мне надо предоставить воспроизводимое доказательство 2+2=4? Мне очень тяжко разговаривать с человеком, который начитался давно устаревшей матчасти и не понимает текущего состояния вещей.
У меня эта «давно устаревшая матчасть» вполне себе успешно работает в двух городах. И работает благодаря знанию этой «давно устаревшей матчасти».
В результате мы опять же возвращаемся к необходимости подтверждения своих слов.
А знаете, чем отличается старое оборудование/ПО от современного? Правильно — старые свитчи давали большую задержку, а на старом ПО был низкий размер окна (в статье поправлено).
Пример про 930Мбит/с был получен на вполне себе 5-и летнем оборудовании, которое я ни при каких условиях не могу назвать новым. Только про стандартные настройки я ошибся. Буфера и максимальный размер окна там подкручены в соответствии с каналами и RTT.
А вот это уже профнепригодность.
Глобальные сети без потерь существуют? Если нет, то напомните пожалуйста, как TCP понижает скорость отправки когда обнаруживает на перегрузку? И какие из этого следуют результаты в итоговой пропускной способности.
каким образом я получил, что размера окна в 120мб хватит для полной утилизации 10G линка с RTT 100мс.
А Вы знаете для чего его хватит? Его хватит только для того, чтобы гарантировать что размер окна не станет ограничивать темп передачи данных. А это справедливо только в сетях без потерь, которых в реальной жизни на больших расстояниях не бывает. По этому в статьях про настройки окон и буферов нигде не обсуждается процент потерь пакетов (из-за перегрузки оборудования, переполнения буферов, shared-канала где то в uplink'е итд. — это не важно), а там где он учитывается там все становится не так радужно и однозначно. Появляются всякие графики красивые и не очень и делаются интересные выводы…
Вывод: если возникает задача постороения территориально распределенной сети, имеет смысл поручить это человеку, который хоть что-то знает про TCP, без обид :)
Ну то есть Вам поручать такую задачу нельзя. Как говориться без обид.
У меня эта «давно устаревшая матчасть» вполне себе успешно работает в двух городах.
Не «вполне себе прилично», а «плохо», если настройки TCP штатные. А все из-за незнания протокола TCP.
Буфера и максимальный размер окна там подкручены в соответствии с каналами и RTT.
А, ну так все-таки имеются более опытные коллеги? Это хорошо.
Глобальные сети без потерь существуют?
Потери на глобальных сетях следуют из перегрузки каналов. Если между двумя институтами прямая оптика, и с обеих сторон настроен QoS — увидеть потери на приоритетных классах трафика будет непросто.
Если нет, то напомните пожалуйста, как TCP понижает скорость отправки когда обнаруживает на перегрузку?
См. выше про QoS. И да, механизм congestion window тоже можно (и нужно) подкручивать, тогда сбрасывание скорости будет совсем незначительным и скорость очень быстро нормализуется.
А это справедливо только в сетях без потерь, которых в реальной жизни на больших расстояниях не бывает.
То есть еще и не знаете, из-за чего бывают потери. Печально.
Его хватит только для того, чтобы гарантировать что размер окна не станет ограничивать темп передачи данных.
То есть до вас уже понемногу дошло, что сам по себе RTT уже не является проблемой для TCP. Отлично — всегда рад, когда удалось результативно ткнуть другого носом в матчасть. Еще бы характер исправить — подростковый максимализм как правило годам к 20-и должен проходить…
По этому в статьях про настройки окон и буферов нигде не обсуждается процент потерь пакетов (из-за перегрузки оборудования, переполнения буферов, shared-канала где то в uplink'е итд. — это не важно)
Перегрузки оборудования в глобальном интернете не бывает. Переполнение буферов — само по себе не проблема, проблемой является перегрузка канала в попытке протолкнуть через него данных больше, чем он может осилить. «shared-канал» (вам незнакомо слово «переподписка» либо «oversubscription»? Просто термина «shared-канал» не существует) является нормой, и может вызвать разве что ту самую перегрузку интерфейсов. Дроп пакетика на самой паре — событие настолько редкое, что им можно пренебречь. Итак, единственный источник дропов — перегрузка канала. Как бороться? Если канал свой (закопана оптика), то элементарно CBWFQ, неприоритетные классы подвинутся. Если канал провайдерский, то оговорить тариф с QoSами и долбить заявками до тех пор, пока количество дропов не станет равно нулю (да, у нас есть каналы через всю страну, на которых нет потерь вне момента аварии).
Но если у нас прямая оптика с 10G трансиверами между двумя подключенными по 10G машинами, то потерь не будет. Ну если оптику и трансиверы подобраны верно, разумеется.
Так что нет, «в сетях без потерь, которых в реальной жизни на больших расстояниях не бывает» — абсолютная глупость, следствие полного непонимания вопроса.
Мораль. Учите матчасть. Без знания матчасти вас никогда не допустят до серьезных железок. И не надо спорить с профессионалами по темам, в которых вы не обладаете абсолютно никакими знаниями.
А, ну так все-таки имеются более опытные коллеги? Это хорошо.
Интересно, только кто это без меня на моих тестовых серверах настройки крутил… Не подскажите, как это узнать? :)
А опытные коллеги естественно есть, но и у Вас наверное тоже.
Я у Вас спрашивал, решали ли Вы подобные задачи. Вы однозначно сказали что нет. Привести пример решенных задач Вы не захотели.
То есть до вас уже понемногу дошло, что сам по себе RTT уже не является проблемой для TCP. Отлично — всегда рад, когда удалось результативно ткнуть другого носом в матчасть.
Достаточно вспомнить, что задача TCP — обеспечение надежной доставки по ненадежной сети ( rfc2.ru/793.rfc ) и сразу же становится ясно, что проблема с матчастью у другой стороны, раз приходится отдельно указывать на то, что IP пакет может и не дойти.
Все ваше дальнейшее жонглирование словами является не более чем теорией, которая от практики бывает отличается. Судя по всему именно по этому Вы привели пример, который зашкаливает по своей абсурдности и чрезвычайной редкости в реальных условиях («Но если у нас прямая оптика с 10G трансиверами между двумя подключенными по 10G машинами, то потерь не будет.»).
Мораль. Учите матчасть. Без знания матчасти вас никогда не допустят до серьезных железок. И не надо спорить с профессионалами по темам, в которых вы не обладаете абсолютно никакими знаниями.
Мораль — приводите аргументы, а не слова.
А мораль номер 2 — не надо оценивать уровень по своему знанию теории. Другие люди могут не только матчасть знать, но и на практике решать подобные задачи.
кто это без меня на моих тестовых серверах настройки крутил
Ради интереса — вас к боевым системам уже пускают? Что-то сомнительно, учитывая ослиную упертость (не путать с упорством) и неспособность признавать свои ошибки.
А опытные коллеги естественно есть, но и у Вас наверное тоже.
У меня нет. Точнее, есть более опытные в плане стажа, но обычно архитектурными вопросами занимаюсь именно я, благо имеются знания и кругозор, как и вполне достаточный опыт.
Я у Вас спрашивал, решали ли Вы подобные задачи. Вы однозначно сказали что нет. Привести пример решенных задач Вы не захотели.
Чуть ниже привел. Устроит?
rfc2.ru/793.rfc
Давать ссылку на перевод RFC — это пять, сразу видно профессионала :)
раз приходится отдельно указывать на то, что IP пакет может и не дойти.
И снова умоляю закрыть учебники и хоть немного посмотреть на реальный мир. А в реальном мире потерь быть практически не должно. И даже если они есть — это не вызывает заметных проблем со скоростью. Да, в учебниках написано иное, потому снова советую закрыть учебники и посмотреть на реальность.
Все ваше дальнейшее жонглирование словами является не более чем теорией
В habrahabr.ru/post/146840/#comment_4946454 указана практика, довольно древняя. Устроит?
Другие люди могут не только матчасть знать, но и на практике решать подобные задачи.
Вы никогда не занимались решением подобных задач, это в достаточной мере очевидно из абсолютного непонимания самых основ, того же TCP например. А вот мне доводилось выдавать коллегам рекомендации по оптимизации стека под каналы через всю страну для эффективного задействования этих каналов (300мс RTT с 50мс джиттером — не редкость). Благодаря этим рекомендациям каналы стали прогружаться полностью, а пользователи недоумевали от радикального повышения скорости загрузки доменной машины.
Снова резюмирую. Читайте матчасть (не устаревшие учебники, а актуальные материалы) и заканчивайте спорить по темам, в которых ничего не смыслите.
Вот еще на что нечаянно наткнулся.
proj.sunet.se/LSR3-s/
42 хопа, ни разу не выделенные каналы, RTT 436мс.
Шел 2004-й год…
proj.sunet.se/LSR3-s/
42 хопа, ни разу не выделенные каналы, RTT 436мс.
According to the Internet2 LSR contest rule #5A, IPv4 TCP single stream, we achieved the following results, using the upcoming 2.0 version of the NetBSD operating system, and using a MTU of 4470 bytes:
1966080000000 bytes in 3648.81 real seconds = 4310.62 Mbit/sec
The complete output from ttcp during the transmission as seen from the transmitter and the receiver. The test run lasted 3648 seconds (1 hour, 48 seconds). Note that this means that we didn't loose a single bit on this path for the duration of the transmission!
We noted that it is the PC hardware (excluding the Intel PRO/10GbE network adapter) that is the limiting factor in our setup. The operating system, the network adapter, as well as the network itself, including the routers, are capable of handling more traffic than this, but the PCI-X bus and the memory bandwith in the end hosts are currently the bottlenecks.
Шел 2004-й год…
По 10GE получили 4310.62 Mbit/sec. Эффективность всего 43%.
Или я что-то проглядел и у них канал не 10GE был, а только сетевые карты 10GE?
Не путайте потери в линии связи с потерями IP-пакетов, которые не дошли.
Дамп трафика не смотрел, но события перегрузки там явно были, иначе почему эффективность такая низкая?
Если интересно, то завтра я приеду с дачи к нормальному интернету и могу проанализировать приведенные дампы.
Или я что-то проглядел и у них канал не 10GE был, а только сетевые карты 10GE?
Note that this means that we didn't loose a single bit on this path for the duration of the transmission!
Не путайте потери в линии связи с потерями IP-пакетов, которые не дошли.
Дамп трафика не смотрел, но события перегрузки там явно были, иначе почему эффективность такая низкая?
Если интересно, то завтра я приеду с дачи к нормальному интернету и могу проанализировать приведенные дампы.
события перегрузки там явно были, иначе почему эффективность такая низкая?
Читать умеете? Я же специально процитировал ключевые моменты.
«We noted that it is the PC hardware (excluding the Intel PRO/10GbE network adapter) that is the limiting factor in our setup.»
И размер окна в 250мб был маловат.
Еще раз, это — 2004-й год. Тогда наши корабли еще не бороздили просторы вселенной, а 10гб/с было действительно очень круто даже в локальной сети.
Не путайте потери в линии связи с потерями IP-пакетов, которые не дошли.
А разве IP пакеты могут не дойти по каким-либо причинам помимо потерь в линиях связи (в том числе на порту при его перегрузке)?
завтра я приеду с дачи к нормальному интернету и могу проанализировать приведенные дампы.
На здоровье. Но там всего 3 секунды. Дропов нет. Хотите скачать 2пб полного дампа? Боюсь, его никто не озаботился сделать…
Это пустое. человек не понял проблему (которую решили китайцы с америкосами) и зачем-то взялся с вами спорить. Пожалейте своё время. Когда у него появится второй дата-центр глубоко в России и обязательная репликация — он вспомнит вас и этот пост и обратится за советом.
Первое печально… Жалко людей, которые не имея своего опыта ввязываются в вопросы, которыми в последнее время активно занимаются как компании, так и университеты.
А китайцы с америкосами похоже решили очередной частный случай. Частное решение для наших задач есть и у нас, а вот общего решения похоже пока не предвидится. Если оно конечно возможно :)
Кстати такого-же рода передачи сверхбольших объемов данных уже были, но между США и Европой. Те это не первое решение конкретной проблемы.
А китайцы с америкосами похоже решили очередной частный случай. Частное решение для наших задач есть и у нас, а вот общего решения похоже пока не предвидится. Если оно конечно возможно :)
Кстати такого-же рода передачи сверхбольших объемов данных уже были, но между США и Европой. Те это не первое решение конкретной проблемы.
Боюсь, я — единственный, кто понял их достижение :)
Печально, что в телекоммуникациях работает такое количество некомпетентных людей. Непонимание TCP и того, что его можно и нужно крутить под конкретные задачи — это, как я уже говорил, штамп профнепригодности.
Печально, что в телекоммуникациях работает такое количество некомпетентных людей. Непонимание TCP и того, что его можно и нужно крутить под конкретные задачи — это, как я уже говорил, штамп профнепригодности.
Такое чувство, что новость из 2005 года.
«BGI передала 24 ГБ данных генетических исследований между Пекином и Университетом Калифорнии всего за 30 секунд. Парой дней ранее такой же объем данных был передан по обычным сетям (в том же направлении) примерно за 26 часов.»
То есть они сранивают с древними 2мбит и называют это «обычной сетью»? На 100мбит это бы заняло всего 30 минут.
То есть они сранивают с древними 2мбит и называют это «обычной сетью»? На 100мбит это бы заняло всего 30 минут.
Sign up to leave a comment.
Осуществлена передача данных со скоростью 10 ГБит между Китаем и США