Maxim S. Shatskih wrote:
> C>Кстати, еще один способ обрабатывать переполнение очереди — просто
> выбрасывать переполняющие пакеты.
> В низкоуровневых протоколах, которые либо заявлены как ненадежные (UDP),
> либо имеют ретрансмит (TCP) — это и делается.
> Но на уровне приложения? выдать юзеру "сервер перегружен, попробуйте
> позже" — это омерзительно.
Опять же, смотря где. При передаче аудио или видео, например, может быть
лучше выбросить полсекунды, а потом восстановиться, чем пытаться
полностью передать поток.

> C>Лимиты должны находится в "серверном" коде. Клиент должен либо
> блокироваться, либо получать EWOULDBLOCK'ом по зубам. Заниматься
> планированием нагрузки он не должен.
> Не всегда речь об архитектурах клиент-сервер. Часто речь о настольной
> апликации, которая на 100% грузит disk IO.
Я поэтому и взял слово "серверном" в кавычки — мы можем рассматривать
операционную систему как "сервер IO" с точки зрения приложения.

> MSS>>В какой это ОС у нас есть планировщик дискового IO? в виндах до
> Висты не было никакого, был только elevator seek и использование SCSI
> tagged queue, да и в Висте какой-то убогий.
> C>Ээээ... Linux (http://www.linuxjournal.com/article/6931
> И чего? примерно то же, что в виндах, разница в мелочи. Самое главное —
> в статье по ссылке нет понятия "IO приоритет процесса" и планирования
> дисковых реквестов в зависимости от того, кто их издал
Есть. Просто ты невнимательно смотришь.

Во-первых, есть ionice (http://linux.die.net/man/1/ionice) — банально
менять приоритет.
Во-вторых, в более новых Линуксах для десктопных процессов можно
автоматом повышать приоритет планировщика.
В-третьих, ты сам можешь написать плугабельный user-space планировщик и
подключить его в ядро (там для этого фреймворк есть).

> ), Solaris, AIX? ionice в Линуксе так уже года четыре есть — использовал
> пару раз.
> А сколько народу у нас пишут под винды? а насколько портабелен такой код?
Кривость массовостью не оправдывается.

> C>Не сталкивался. Если бы столкнулся — настроил бы правила файрвола.
> То есть предполагается, что для работы вашей софтины юзер должен иметь
> файрволл? хороший подход для ляпов на коленке, плохой — для продукта.
Я вижу вообще только одно применение для явного ограничения траффика —
это всякие p2p-клиенты и скачивалки, которым иногда хочется обрезать
аппетит.

> C>И что дальше? Всем ставить Sleep(100) после каждого вызова ReadFile?
> Не всем, и не 100. Надо замерять, сколько времени выполнялись дисковые
> операции, каков незатротленный disk IO bandwidth, и на основании этого
> рассчитывать длительность каждого Sleep персонально. Иногда она может
> оказаться равной нулю, в коем случае вообще не надо звать Sleep.
Некрасиво. И не всегда работать будет — если я буду писать во
фрагментированый файл, то io bandwidth будет низким, а вот диск будет
занят на всю катушку.

> C>Может быть не процессор, а сеть, например (ее проще загрузить).
> Нет, с процессором у нас чуть иначе все. С процессором сложность в
> снятии адекватных статов его загрузки данной нитью. Снятие меток времени
> до и после CPU-bound кода — действительно идиотизм, ты прав. Тут нужен
> только и исключительно GetThreadTimes.
Это тоже идиотизм. В XP и Linux'е в результате можно сделать процесс,
сжирающий 100% процессорного времени, но при этом в статистике
системного времени он будет близок к нулю.

> C>Умные планировщики знают состояние ВСЕЙ системы и спокойно избегают
> таких случаев, а вот самопальный хак — самоспалится.
> Что вы предлагаете? для ограничения сетевого трафика, создаваемого
> софтом, обращаться к psched? какова цена реализации такого дела?
Как это сделано в Линуксе — в сетевых пакетах есть информация о том, кто
их засунул в стек. Соответственно, получить информацию о потоке — легче
легкого. Ну а дальше можно делать shaping и т.п.

Я согласен — Sleep может покрывать недостатки системы. Но его
"грязнохаковый" статус это ничуть не меняет. Нормальным инжинерным
решением было бы исправить саму операционную систему.