объеденить 2x1gbit ethenet в один канал 2гбита - реально?

Это же чтение, а не запись.

Речь изначально шла а) про запись, и б) про практическое применение (обеспечение заливки по сети тех самых 200 Мб/с), при котором влияние сторонних факторов не учитывать несколько самонадеянно.

запись получается (средняя) 170мб/с, начинается от 190 и заканчивается 150, если весь диск форматировать. 2x1gbit бондинг не вытянет это.

объясню вам зачем мне это. периодически делаю бэкап нескольких терабайт инфы, через rsync, реально переливается около терабайта изменённых данных. сейчас использую два внешних винта на юсб3.0, бэкап на каждый из которых занимает примерно 5 часов. хочу ускорить этот процесс, так как работать не могу в процессе бэкапа.

Ночью это делать не проще? А так читай выше про balance-rr, либо покупай 10гбит карту или тот же инфинибэнд, но с ним заморочек больше т.к. нужен доп софт для поддержки IB-сети.

ночью это делать проблематично, т.к. работаю дома, и системник гудит так, что спать будет нереально.

2x1gbit бондинг не вытянет это.

Только я вижеу противоречие? Сначала «800 Мбит/с = 100 Мб/с», потом процитированное... Ж;-)

Есть у меня всё-таки подозрение, что проблема решается неоптимальным способом... Впрочем, вам виднее.

попробовать однозначно буду, т.к. вроде гляжу есть люди у которых после долгого тюнинга получилось вытянуть 240мб/с. http://serverfault.com/questions/287475/why-does-my-gigabit-bond-not-deliver-...

Купить SAS-контроллер или SATA с hot-swap, рэк на нужное число дисков, и не морочить людям голову.

на контроллере есть внешний порт, sff-8088. есть такие sata-реки с собственным питанием чтоб их можно было подсоединить на горячую к этому порту?

мне нужен рек максимум на 4 винта.

гигабит - предельная теоретическая скорость. это как у меня на машине на спидометре 280, а выше 200 она никогда не шла.

Коммутатор ровно гигабит (не 800 мбит, а именно 1000) жует без вопросов. Есть графики если что. Вот сетевухи в сервере не факт, может тюнить для этого надо.

Не вполне верно. На практике так не получится.

800 мбит это и есть 100 мБайт. 800*10^6 /8/10^6=100. арифметика за детский сад

200Мб на двух винтах в RAID0 при линейном чтении-записи - легко

RAID0 не нужен. Касательно 200Мб - так уж и легко? Посмотри за сколько сольется хотя бы 1 гиг мелких файлов по 1-2 килобайта. Часа четыре небось. И сетки в 10 МБит выше крыши будет. Практика она разная. Я измерял время секундомером и смотрел на суммарный размер файлов. То что показывают всякие софтовые фиговиночки обычно чушь собачья.

Читаем внимательнее - линейное чтение\запись. При передаче толпы мелких файлов в основном имеет место дёргание головки при поиске и ни о каком линейном чтении речи быть не может. Там всё зависит от фрагметации и взаимного расположения файлов на ФС, да и от самой ФС. Дохрена факторов.

800 мбит это и есть 100 мБайт. 800*10^6 /8/10^6=100. арифметика за детский сад

Мсье точно знает разницу между кадром Ethernet, пакетом IP (ну или другого протокола) и полезной нагрузкой (она же payload)? Ж;-)

арифметика за детский сад

Садись, двойка.

Мсье точно знает разницу между кадром Ethernet, пакетом IP (ну или другого протокола) и полезной нагрузкой (она же payload)? Ж;-)

Мсье знает ccna и mpls. Речь идет про application, а полезная нагрузка называется goodput, а не payload. Если это было непонятно из методики измерений (размер файлов поделить на время), то сочувствую.

Тебе так точно. мега/мега=1. Впрочем многие лохи считают мега за меби.

Я надеюсь ты понял что твои 100500 Мб никому не нужны и не имеют места в практике. Именно при работе с мелкими файлами хороши оборотистые винты. P.S. дергание головки отсутствует на SSD, но в сервера их чего-то не ставят.

Мсье знает ccna и mpls

Плохо знает. Садитесь, два.

Речь идет про application

Мсье плохо умеет читать - домашнее задание: перечитать всю цепочку и написать объяснение, о чём говорилось в каждом сообщении и почему мсье ляпнул глупость, вписываясь в поток.

а полезная нагрузка называется goodput, а не payload

Ещё и с терминологией сложности. Правда, слегка простительные.

Если это было непонятно из методики измерений (размер файлов поделить на время), то сочувствую.

У мсье сложности с проходом по простейшей логической цепочке? Сочувствую. Даже помогу намёком: методика измерений там шла несколько в другом ключе.

RAID0 не нужен.

Мсье, очевидно, пьян. Рекомендую длительный сон и рассольчику - причём немедленно, чтобы не веселить людей глупостями и абсолютизацией своего (неверного, кстати) мнения.

Плохо знает. Садитесь, два.

Два именно вам. Я написал, что с сервака на сервак средняя скорость записи по сети на винты в моем опыте составила 800 мбит/c (goodput). 18+20=38 байт из 1518 байт составляют примерно 2,5% - потери на фреймах и пакетах. Гигабитный ethernet порт может обеспечить ~975 мбит goodput для приложений. 800 заметно меньше, чем 975.

Мсье плохо умеет читать - домашнее задание: перечитать всю цепочку и написать объяснение, о чём говорилось в каждом сообщении и почему мсье ляпнул глупость, вписываясь в поток.

Перечитай, и пересчитай. Узкое место - не сеть. На коммутаторах у меня был 1 гигабит вместе со служебной информацией, а ее не так уж много.

Ещё и с терминологией сложности. Правда, слегка простительные.

Вам помочь с терминологией или сами разберетесь? С информацией проблем сейчас обычно нету.

Мсье, очевидно, пьян. Рекомендую длительный сон и рассольчику - причём немедленно

Рассольничек после падения любого винта из raid0 вам надеюсь очень поможет. Еще веселее когда отказывает контроллер (я сталкивался с этим уже дважды - вещь очень неприятная). Напоследок дам хороший совет - использовать массивы с избыточностью, а для пущей пущести - еще и с горячим резервом. По каким-то загадочным обстоятельствам новые винты через 5 минут для замены не появляются и порой приходится ждать месяц.

если уж подходить к расчетам еще более тщательно, то в моем предыдущем сообщении не учтен расход на tcp/udp и всякий несущественный мусор, но 1-2% все равно кардинально картину не меняют.

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

P.S. SSD на сервера ставят, просто у тебя видать на них нету денег. Энтерпрайзные SSD стоят что-то около 6к$ за 256Гб железяку.

P.S. дергание головки отсутствует на SSD, но в сервера их чего-то не ставят.

Ставят. только дорого и дохнут очень быстро. Даже в прайсе HP уже есть.

Оборотистые винты у меня стоят в серверах, аж на 15 тысяч, но вот что-то сильно быстре с мелкими файлами они не работают, т.к. время поиска на них не слишком сильно ниже чем на прочих.

А вот это - уже 4.2!

Есть у меня собственные измерения серверных и десктопных дисков от 2005-го года. Вот посмотри, пожалуйста, время доступа и позиционирования головок.

1) Seagate Baracuda 7 (SATA)

	512         	# sectorsize
	80026361856 	# mediasize in bytes (75G)
	156301488   	# mediasize in sectors
	155061      	# Cylinders according to firmware.
	16          	# Heads according to firmware.
	63          	# Sectors according to firmware.

Seek times:
	Full stroke:	  250 iter in   4.995209 sec =   19.981 msec
	Half stroke:	  250 iter in   3.654328 sec =   14.617 msec
	Quarter stroke:	  500 iter in   6.020943 sec =   12.042 msec
	Short forward:	  400 iter in   1.936407 sec =    4.841 msec
	Short backward:	  400 iter in   2.357087 sec =    5.893 msec
	Seq outer:	 2048 iter in   0.253319 sec =    0.124 msec
	Seq inner:	 2048 iter in   0.268042 sec =    0.131 msec
Transfer rates:
	outside:       102400 kbytes in   1.754534 sec =    58363 kbytes/sec
	middle:        102400 kbytes in   2.114727 sec =    48422 kbytes/sec
	inside:        102400 kbytes in   3.505433 sec =    29212 kbytes/sec

2) Quantum Atlas V (Ultra Wide SCSI)

	512         	# sectorsize
	36722061312 	# mediasize in bytes (34G)
	71722776    	# mediasize in sectors
	4464        	# Cylinders according to firmware.
	255         	# Heads according to firmware.
	63          	# Sectors according to firmware.

Seek times:
	Full stroke:	  250 iter in   3.796994 sec =   15.188 msec
	Half stroke:	  250 iter in   2.938539 sec =   11.754 msec
	Quarter stroke:	  500 iter in   5.008084 sec =   10.016 msec
	Short forward:	  400 iter in   1.502883 sec =    3.757 msec
	Short backward:	  400 iter in   1.324614 sec =    3.312 msec
	Seq outer:	 2048 iter in   0.240692 sec =    0.118 msec
	Seq inner:	 2048 iter in   0.301687 sec =    0.147 msec
Transfer rates:
	outside:       102400 kbytes in   3.535468 sec =    28964 kbytes/sec
	middle:        102400 kbytes in   4.034812 sec =    25379 kbytes/sec
	inside:        102400 kbytes in   6.197584 sec =    16523 kbytes/sec

3) Seagate Cheeta 10k (Ultra 169 Wide)

	512         	# sectorsize
	36703934464 	# mediasize in bytes (34G)
	71687372    	# mediasize in sectors
	4462        	# Cylinders according to firmware.
	255         	# Heads according to firmware.
	63          	# Sectors according to firmware.

Seek times:
	Full stroke:	  250 iter in   3.072824 sec =   12.291 msec
	Half stroke:	  250 iter in   2.290970 sec =    9.164 msec
	Quarter stroke:	  500 iter in   3.725175 sec =    7.450 msec
	Short forward:	  400 iter in   1.317771 sec =    3.294 msec
	Short backward:	  400 iter in   1.252767 sec =    3.132 msec
	Seq outer:	 2048 iter in   0.209538 sec =    0.102 msec
	Seq inner:	 2048 iter in   0.213582 sec =    0.104 msec
Transfer rates:
	outside:       102400 kbytes in   1.516307 sec =    67532 kbytes/sec
	middle:        102400 kbytes in   1.841654 sec =    55602 kbytes/sec
	inside:        102400 kbytes in   2.742910 sec =    37333 kbytes/sec

s/Ultra 169 Wide/Ultra 160 Wide/g

Вот еще одно с WD Raptor:

	512         	# sectorsize
	74355769344 	# mediasize in bytes (69G)
	145226112   	# mediasize in sectors
	144073      	# Cylinders according to firmware.
	16          	# Heads according to firmware.
	63          	# Sectors according to firmware.
	ad:WD-WMAKE2335629	# Disk ident.

Seek times:
	Full stroke:	  250 iter in   2.709131 sec =   10.837 msec
	Half stroke:	  250 iter in   2.224481 sec =    8.898 msec
	Quarter stroke:	  500 iter in   3.900419 sec =    7.801 msec
	Short forward:	  400 iter in   1.075775 sec =    2.689 msec
	Short backward:	  400 iter in   1.382611 sec =    3.457 msec
	Seq outer:	 2048 iter in   0.134457 sec =    0.066 msec
	Seq inner:	 2048 iter in   0.131147 sec =    0.064 msec
Transfer rates:
	outside:       102400 kbytes in   1.483799 sec =    69012 kbytes/sec
	middle:        102400 kbytes in   1.542086 sec =    66404 kbytes/sec
	inside:        102400 kbytes in   2.007955 sec =    50997 kbytes/sec

И для сравнения WD Carair Blue 320:

	512         	# sectorsize
	320072933376	# mediasize in bytes (298G)
	625142448   	# mediasize in sectors
	620181      	# Cylinders according to firmware.
	16          	# Heads according to firmware.
	63          	# Sectors according to firmware.
	ad:WD-WCAV2AW51709	# Disk ident.

Seek times:
	Full stroke:	  250 iter in   7.355468 sec =   29.422 msec
	Half stroke:	  250 iter in   4.477947 sec =   17.912 msec
	Quarter stroke:	  500 iter in   6.899079 sec =   13.798 msec
	Short forward:	  400 iter in   1.536657 sec =    3.842 msec
	Short backward:	  400 iter in   2.345542 sec =    5.864 msec
	Seq outer:	 2048 iter in   0.296127 sec =    0.145 msec
	Seq inner:	 2048 iter in   0.253150 sec =    0.124 msec
Transfer rates:
	outside:       102400 kbytes in   1.017834 sec =   100606 kbytes/sec
	middle:        102400 kbytes in   1.114046 sec =    91917 kbytes/sec
	inside:        102400 kbytes in   1.879646 sec =    54478 kbytes/sec

Два именно вам.

ОК. Согласен, но не на «два», а на замечание за невнимательность - упустил в исходном сообщении, что речь шла про поток именно чистых данных.

Перечитай, и пересчитай. Узкое место - не сеть.

А тут вам замечание за невнимательность - потому как чуть ниже я писал в ответ на сообщение со смыслом «2x1 Гбит/с это не потянет», что как-то странно подсчёт идёт.

Консенсус? Ж;-)

Вам помочь с терминологией или сами разберетесь? С информацией проблем сейчас обычно нету.

Тем не менее, инкапсулированные в любой уровень данные назывваются payload - что для самого верхнего уровня (TCP, UDP или что там ещё) означает именно чистые «полезные» данные. И payload применяется чаще - по крайней мере, лично мне термин goodput практически не встречался.

Рассольничек после падения любого винта из raid0 вам надеюсь очень поможет. (остальное опустил для краткости)

Это абсолютно не значит, что RAID-0 не нужен. Это значит только то, что нужно тщательно думать, нужен он именно здесь, или нет.

И что? Где 4.2? Я написал «не слишком сильно ниже». 19 против 12 мсек это 1.5 раза, оно не дает на практике сильно ощутимого прироста поиска. Мои 15к винты, пусть, имеют 8-9мсек, это всё равно радикально на работу с кучей мелких файлов не влияет, так как при работе на SSD.

В сетях десятичная кратность. То.е 1 гигабит = 10^9 = бит, а не 2^30.

800 мбит это и есть 100 мБайт. 800*10^6 /8/10^6=100

800 мбит= 800*10^6 /8 /2^20= 95,36743 мБайт
И это теормаксимум, без учета передаваемой техинформации, про которую написали выше.

Подробности в цифрах тут http://www.thg.ru/forum/showthread.php?t=39884&page=3

Вобщем, двойка и запись в дневник за пререкания со старшими.

Я написал «не слишком сильно ниже». 19 против 12 мсек это 1.5 раза, оно не дает на практике сильно ощутимого прироста поиска. Мои 15к винты, пусть, имеют 8-9мсек, это всё равно радикально на работу с кучей мелких файлов не влияет, так как при работе на SSD.

Ну, с SSD, конечно, не сравнить, но я проверял на скорости checkout для дерева исходников как раз в 2005-м. Держал тогда зеркало CVS дерева портов FreeBSD на этих дисках. Скорость там как-раз была 2:1 между читой и баракудой. И даже 5-й атлас уделывал баракуду на 20-25% за счет скорости работы механники позиционирования головок.

(На 15к дисках сравнения привести не могу - они все в аппаратных рейдах и совсем даже не на фряке, чей diskinfo я для тестирования использовал).

800 мбит= 800*10^6 /8 /2^20= 95,36743 мБайт

Что ты курил? МЕГА/МЕГА=1. В байте 8 бит. 800мегабит= 100 мегабайт. Подробности в справочниках по физике или математике. Но даже если ты будешь считать мега за 3^39237648923648236478236489236496, то все равно МЕГА/МЕГА=1. Для устранения путаницы ввели единицы измерения, кратные степени двойки, например мебибайт. А мега - это 10^6.

Иди в школу, двоечник.

Есть еще одна интересная вещь - при высокой загрузке канала - более 80% данные в него впихиваются хуже. Например, мультикаст с видео будет идти с дропом. Но тем не менее в канал впихивается именно 1000 мегабит/c.

Это абсолютно не значит, что RAID-0 не нужен. Это значит только то, что нужно тщательно думать, нужен он именно здесь, или нет.

У меня не возникает сомнений, что для бэкапа raid0 - идея не из самых лучших. На поиграться - здорово). Лучше конечно raid 10. Тут и повышенная скорость и надежность - сочетание raid1 и raid0, но где ж столько винтов набраться.

SSD решение для серверов не актуальное. Причины очень правильно написал. А то что в прайсе есть - так берут те, кому надо в основном читать, а не писать.

какие-нибудь варианты кроме ethernet-а есть ещё? надо связать два компа стоящих рядом

firewire, infiniband

800 мбит/c в сети с учетом десятичной кратности =95,36743 мБайт/c реальных данных. Вобщем, мне надоел этот поток пурги от вас, и я торжественно заношу вас в игнор.

И наверно для вас будет большим ударом, но я скажу. В 500 гигабайтном диске нет 500 гигабайт, в нем дай бог 460 есть, так как производители дисков упорно считают килобайт равным 1000 байт. А килобайт файлов, несмотря на маркетинговые ходы, почему-то упорно занимает на диске 1024 байта.

Есть еще одна интересная вещь - при высокой загрузке канала - более 80% данные в него впихиваются хуже.

Да тут-то как раз достаточно понятно - есть несколько мест, где рост нагрузки будет приводить к снижению производительности.

но где ж столько винтов набраться.

Ну всё-таки денег, наверное? Ж;-) С винтами-то проблем нет...

800 мбит/c в сети с учетом десятичной кратности =95,36743 мБайт/c реальных данных.

ты точно упоролся

В 500 гигабайтном диске

причем тут размер винчестеров? Видишь, сам же написал, что в килобайте 1000 байт.

А килобайт файлов, несмотря на маркетинговые ходы, почему-то упорно занимает на диске 1024 байта.

Смотря как считать. И 2+2 может быть равным 0. Твоя ошибка в том что ты считаешь мегабиты десятичными, а мегабайты двоичными. Скорость передачи данных в 800мегабит/c (десятичных/двоичных)= 100 мегабайт/c (десятичных/двоичных СООТВЕТСТВЕННО).

Ну всё-таки денег, наверное? Ж;-) С винтами-то проблем нет...

Если не учавствуешь в закупках, то достается то что достается.

Твоя ошибка в том что ты считаешь мегабиты десятичными, а мегабайты двоичными.

Я считаю правильно, а вы нет. Ошибка на вашей стороне))

причем тут размер винчестеров

При том, что мы передаем реальные данные, в которых 1 кбит=1024 бит. А в гигабитной сети считается, что 1 килобит=1000 бит. Отсюда разница в том что будет реально передано. За секунду через сеть в 800 мбит теормаксимум, будет передано 95,36743 мБайт реальных живых данных, а не 100, как вы пишете. Если не понимаете, прочитайте тред с начала. Мы про реальное железо говорим, а не школьные задачи по информатике решаем.

При том, что мы передаем реальные данные, в которых 1 кбит=1024 бит....

Тяжелый случай. я писал про реальные измерения на серверах и коммутаторах расчитанных не для домашнего использования. Есть железо и покруче если что. Сильно покруче.

А в гигабитной сети считается...

А в стагигабитной уже не считается?