LINUX.ORG.RU

Прокачаться в low-latency сетевом программировании и многопоточностях.


1

2

Писал сетевые приложения под linux с использованием select, epoll на C++. Многопоточность использовал pthreads и boost кросс-платформенно.

Хочется прокачаться в низком уровне - какие бывают примитивы синхронизации на уровне ядра: какие в линуксе, какие в винде, какие во фре, всякие там отличия и особенности. Какие бывают разновидности потоков и процессов под всеми этими платформами. Знать про все compare-and-swap, про межпроцессную коммуниацию, особенности шаринга памяти и т.д.

Есть какой-нибудь крутой мануал, где всё старательно собрано в кучу и тема раскрыта по самое небалуйся? Можно на английском, я не жадный.

★☆

Последнее исправление: kiverattes (всего исправлений: 1)
Ответ на: комментарий от anonymous

Т.е. ты просто писал сетевой код для говна? Никакая сеть даже один «поток» не прокачает.

Штуки 4 10-гигабитных адаптера заткнут весь канал памяти у младших E5. С запасом заткнут.

mv ★★★★★
()
Ответ на: комментарий от mv

Штуки 4 10-гигабитных адаптера заткнут весь канал памяти у младших E5. С запасом заткнут.

точно? /me мерзко хихикает.

darkmag
()
Ответ на: комментарий от darkmag

точно? /me мерзко хихикает.

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

mv ★★★★★
()
Ответ на: комментарий от mv

Штуки 4 10-гигабитных адаптера заткнут весь канал памяти у младших E5. С запасом заткнут.

Что такое «канал памяти» - поясни.

anonymous
()
Ответ на: комментарий от anonymous

Что такое «канал памяти» - поясни.

Ну так как речь идёт про:

Никакая сеть даже один «поток» не прокачает.

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

mv ★★★★★
()
Ответ на: комментарий от mv

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

В сегодняшних реалиях ядро может прокачитвать 200гигов.

Только суть в том, что всё упрётся либо в твой говнокод, либо в ограничения твоих подсистем, но никак не в ведро.

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

Если это шины и обвес, то тоже - кроме возможно каких-то особенностей о которых я не знаю.

Обычно всё упирается в говнокод и обилием нитей пытаются уперется хотябы в память. Кернелспейс->юзерспейс->кернелспейс чейчас в худшем случае гигов 5 уж точно выдаёт. Поэтому юзом вёдер ты скорее всего сможешь повесить больше логики, чем прокачать больше.

anonymous
()
Ответ на: комментарий от anonymous

В сегодняшних реалиях ядро может прокачитвать 200гигов.

200 гигов чего?

Поэтому юзом вёдер ты скорее всего сможешь повесить больше логики, чем прокачать больше.

Ну вообще-то каналов памяти (те, на которые планки памяти цепляются) на весь проц типично больше, чем на одно ядро. Поэтому говнокод-неговнокод, а мувать дейту в 2-3 треда имеет смысл.

mv ★★★★★
()
Ответ на: комментарий от mv

200 гигов чего?

Скорость доступа к l1.

Ну вообще-то каналов памяти (те, на которые планки памяти цепляются) на весь проц типично больше, чем на одно ядро. Поэтому говнокод-неговнокод, а мувать дейту в 2-3 треда имеет смысл.

Канал памяти даже, если у тебя тотальное копирование крнел->юзер->кернел в сегодняшних реалиях больше 5жилких гигов.

Обычно да не обычно - я создавал по этому поводу тред. На штеудах одно ядро покачивает 90%+ памяти, 2 ведра 100%. На говяных амд прокачивают лишь 4ведра. Скорость памяти в текущих реалиях 30гигов+. Я не знаю как там себя ведут хеоны со стопицот канальной памятью, но одно ведро 15гигов прокачает 100%. Думаю, что хеоны уже до полтиника доросли.

Мувать дейту имеет смысл в 2-3треда только, если твой код говно, либо в случаях особенностей подситемы памяти. Первый случай 99% - на второй кладут.

Реально же одно ядро 100% прокачает сеть, если нет - тебя треды не спасут, а уж о low-latency не стоит говорить. Тут у тебя решение одно - добро пожаловать в кернелспейс.

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

anonymous
()
Ответ на: комментарий от kiverattes

В чем агрессивность и я не анонимен нихрена, да и я не тролль. Ты что-то хотел сказать?

anonymous
()
Ответ на: комментарий от anonymous

Скорость доступа к l1.

Ты ведь знаешь, что L1D всего 32 кб, он сбрасывается при каждом context switch, и в него данные по DMA не попадают?

Касаемо всего остального, что ты написал: ты про устройство компьютера знаешь, да? Что есть память, есть контроллер памяти, через который и процессор, и девайсы в память ходят? И что между ними всякие конфликты возникают?

mv ★★★★★
()
Ответ на: комментарий от mv

Ты ведь знаешь, что L1D всего 32 кб, он сбрасывается при каждом context switch, и в него данные по DMA не попадают?

А причем тут это - ты спросил я ответил. Ядро может читать много - другое дело ограничение не ведра.

Касаемо всего остального, что ты написал: ты про устройство компьютера знаешь, да? Что есть память, есть контроллер памяти, через который и процессор, и девайсы в память ходят? И что между ними всякие конфликты возникают?

Я знаю, но суть не в этом - все эти устройства общие для процессора. Если что-то упрётся в контроллер памяти/память - тебе вёдра не могут. Кроме отдельных случаев.

В реальных же случаях ведро может прокачать больше, чем выдют даже твои теоретические 40гигабит. Это основной мой тезис. Считай, что я идиот, который ничего не понимает - просто объясни почему это не так.

Дано: 40гигабит, контроллер памяти, который прокачивает минимум 30гб в текущих реалиях. Одно ведро, которое в любом случае 50% имеет. Что тут и куда по твоей логике упрётся.

Заодно поведай мне устроство компьютера - мне интересно.

anonymous
()
Ответ на: комментарий от anonymous

Дано: 40гигабит, контроллер памяти, который прокачивает минимум 30гб в текущих реалиях. Одно ведро, которое в любом случае 50% имеет. Что тут и куда по твоей логике упрётся.

Часть трафика будет тратится на общение контроллера и памяти. Теоретические 30гб существуют в теории, подобраться к ним можно только в синтетическом тесте. В реальности 4 штуки 10GE-контроллера будут делать почти случайный доступ. Плюс процессору нужно эти данные сначала считать, а потом записать, а часто ещё и sata'шному контроллеру надо будет за теми же данными в память подлезть.

Я знаю, но суть не в этом - все эти устройства общие для процессора. Если что-то упрётся в контроллер памяти/память - тебе вёдра не могут. Кроме отдельных случаев.

Контроллер памяти на современных интелах встроен в процессор, 10% LLC доступно для DDIO (это когда трафик с железки идёт не в память, а сразу в кэш). Латентность и way'ность LLC гораздо лучше, чем у памяти. Таким образом, если успевать выгребать данные из этих 10 процентов, то можно сэкономить на записи в память девайсом и последующим чтением процессором. Одним ядром это не сделать, уж поверь.

mv ★★★★★
()
Ответ на: комментарий от mv

Часть трафика будет тратится на общение контроллера и памяти.

Да, та часть, которую ведро не прокачает.

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

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

В реальности 4 штуки 10GE-контроллера будут делать почти случайный доступ.

Кто это проектировал?

Плюс процессору нужно эти данные сначала считать, а потом записать, а часто ещё и sata'шному контроллеру надо будет за теми же данными в память подлезть.

Это я учел. Зачем, ладно - пусть лезит.

Контроллер памяти на современных интелах встроен в процессор

Да, ибо он был всегда говно и протух на заре коре2.

10% LLC доступно для DDIO (это когда трафик с железки идёт не в память, а сразу в кэш).

Хорошо. Что мешает их читать? Запилить в общем случае обходя память это сложно из-за х86проблем - пилят ли?

Латентность и way'ность LLC гораздо лучше, чем у памяти.

Это тоже логично и понятно.

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

Это уже кернелспейс проблемы и рядовой ваяйщик туда даже не лезит.

Одним ядром это не сделать, уж поверь.

Ну какбэ одно ведро читает из llc по определнию минимум реально в 10раз быстрее, чем теоретически пишут твои сетевухи. Почему не сделать? Т.е. в другую часть кеша мы записывать теоретически успеваем с 5-тикратным запасом - в чем проблема?

anonymous
()
Ответ на: комментарий от anonymous

У тебя есть личный положительный пример использования хотя бы одного 10GE на полную катушку? Чтобы трафик гигабайт в секунду пёр, и твой софт успевал его обрабатывать?

mv ★★★★★
()
Ответ на: комментарий от mv

Ну отдолжи мне пару 10ге - я попробую, потом верну - авось что-то путное выйдет. Для софта гигабайт - смешно. Больше, чем 1 ширпотребный недо ge не юзал, поэтому я с тобой и не спорю.

С ge игрался - запас был ещё большой, даже на моём тогдашнем говне. Поэтому я не понимаю проблем с прокачкой 10гигабит - возможно у вас там есть свои нюансы, но с моей ТЗ - я не вижу проблем. Если ты мне расскажешь об этих нюансах - я буду рад.

anonymous
()
Ответ на: комментарий от anonymous

Ну отдолжи мне пару 10ге - я попробую, потом верну - авось что-то путное выйдет.

Ну приезжай ;)

08:00.0 Ethernet controller: Solarflare Communications SFC9020 [Solarstorm]
08:00.1 Ethernet controller: Solarflare Communications SFC9020 [Solarstorm]

С ge игрался - запас был ещё большой, даже на моём тогдашнем говне. Поэтому я не понимаю проблем с прокачкой 10гигабит - возможно у вас там есть свои нюансы, но с моей ТЗ - я не вижу проблем. Если ты мне расскажешь об этих нюансах - я буду рад.

Ну вот достань капчу Nasdaq'а в день, когда фейсбук на IPO вышел, и попробуй написать парсилку протокола и ордербук, чтобы queueing'а не было (т.е. чтобы латентность была постоянной и не увеличивалась под нагрузкой). FIX - протокол простой, ордербук тоже не самый сложный софт. Если такое осилишь, то, считай, разбогател.

mv ★★★★★
()
Ответ на: комментарий от mv

Ну приезжай ;)

А ты меня возмёшь к себе? Я очень способный, неглупый и хороший. Пилю что угодно на «высшем» уровне за просто так, если ты меня чему-то учишь.

Ну вот достань капчу Nasdaq'а в день, когда фейсбук на IPO вышел, и попробуй написать парсилку протокола и ордербук

Что такое капча и ордербук?

чтобы queueing'а не было (т.е. чтобы латентность была постоянной и не увеличивалась под нагрузкой).

Нагрузка - это сколько? Сколько должна быть латентность.

FIX - протокол простой, ордербук тоже не самый сложный софт. Если такое осилишь, то, считай, разбогател.

Не люблю текст - слишком сложно избыточно и непрофитно, да и противоречит быстроте и латентности.

Что такое ордербук я не знаю - расскажи. Меня не особо интересует богаство пока, а опыт запила - да.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.