Каморка

Никто не сталкивался с такой хренью.
Если клиент пишет в сокет буфер целиком, то все ок, но если писать тот же буфер, байт за байтом, то на сервере данные появляются с задержкой 40-50ms
TCP_NODELAY выставлен...
Ну никак не пойму, что за что...

ИМХО Я вообще то Виндовсник, а не Линуксоид, но может аппликуха просто дольше пишет, ежели по байту?

Может у тебя OutputStream обёрнут в BufferedOutputStream?

Stanislav писал(а):ИМХО Я вообще то Виндовсник, а не Линуксоид, но может аппликуха просто дольше пишет, ежели по байту?

Неа, моментально, да, и, все это проверялось на клентах написанных на C, Java и PHP, везде таже хрень...
Может в TCP стеке чего не так закручено?

Чайниковский вопрос по-поводу: не замешана ли там буферизация на принимающей стороне?

Marmot писал(а):Никто не сталкивался с такой хренью.
Если клиент пишет в сокет буфер целиком, то все ок, но если писать тот же буфер, байт за байтом, то на сервере данные появляются с задержкой 40-50ms
TCP_NODELAY выставлен...
Ну никак не пойму, что за что...

Траффик у вас раз в 40 увеличивается примерно, стек тратит на каждый байт по целому IP пакету.
И количество прерываний увеличивается соответственно.

Ковырялся лет пять назад с подобной проблемой (правда не очень
детально - время поджимало).
Насколько помню тогда в либ-С буферок ~1М в сокет имплементации
был. Север (плеер в том случае) уже кони двинул и ничего в сокет не
пишет, а клиент данные все получает, получает....
" проверялось на клентах написанных на C, Java и PHP, везде таже хрень..."
- все дороги ведут в либ-С или в Кернел
"Может в TCP стеке чего не так закручено?" 2.4? или 2.6?

aldep писал(а):

Marmot писал(а):Никто не сталкивался с такой хренью.
Если клиент пишет в сокет буфер целиком, то все ок, но если писать тот же буфер, байт за байтом, то на сервере данные появляются с задержкой 40-50ms
TCP_NODELAY выставлен...
Ну никак не пойму, что за что...

Траффик у вас раз в 40 увеличивается примерно, стек тратит на каждый байт по целому IP пакету.
И количество прерываний увеличивается соответственно.

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

Groundhog писал(а):Ковырялся лет пять назад с подобной проблемой (правда не очень
детально - время поджимало).
Насколько помню тогда в либ-С буферок ~1М в сокет имплементации
был. Север (плеер в том случае) уже кони двинул и ничего в сокет не
пишет, а клиент данные все получает, получает....
" проверялось на клентах написанных на C, Java и PHP, везде таже хрень..."
- все дороги ведут в либ-С или в Кернел
"Может в TCP стеке чего не так закручено?" 2.4? или 2.6?

2.6 у нас, понятно что это где-то внутрях, вопрос в том где копать...

CdR писал(а):Чайниковский вопрос по-поводу: не замешана ли там буферизация на принимающей стороне?

На уровне апликухи буферизации нет, на уровне TCP - об этом и спрашиваю...

Думаю вам следует покопаться в внутри С- библиотеки.
Именно в инмплементации сокетов,
Попробуйте поиграться (при организации сокета) на нижнем уровне с размерами буферов сокета:
SO_SNDBUF
This option gets or sets the size of the output buffer. The value is a size_t, which is the size in bytes.

SO_RCVBUF
This option gets or sets the size of the input buffer. The value is a size_t, which is the size in bytes.
______________________________________________
Ищите описание The GNU C Library + ТОС или "libc_toc.html". Большой документец...
Не знаю как там в яве можно контролировать размеры думаю можете перекомпилиривать
(удачи ) glibc установив дефолт размер буфера по своему хотению. Тогда ваши явы и PHP их и будут
использовать.
Кернел вам вряд ли здесь помошник, хотя тоже можете поуправлять (естественно забыл имена переменных
- чудноватые немного - с полгода уже в кернел не нырял).

Groundhog писал(а):Думаю вам следует покопаться в внутри С- библиотеки.
Именно в инмплементации сокетов,
Попробуйте поиграться (при организации сокета) на нижнем уровне с размерами буферов сокета:
SO_SNDBUF
This option gets or sets the size of the output buffer. The value is a size_t, which is the size in bytes.

SO_RCVBUF
This option gets or sets the size of the input buffer. The value is a size_t, which is the size in bytes.
______________________________________________
Ищите описание The GNU C Library + ТОС или "libc_toc.html". Большой документец...
Не знаю как там в яве можно контролировать размеры думаю можете перекомпилиривать
(удачи ) glibc установив дефолт размер буфера по своему хотению. Тогда ваши явы и PHP их и будут
использовать.
Кернел вам вряд ли здесь помошник, хотя тоже можете поуправлять (естественно забыл имена переменных
- чудноватые немного - с полгода уже в кернел не нырял).

Эх, это все я уже давно знаю , я на оптимизации TCP собаку съел
Проблема именно в в том что, поведение разное в зависомости от способа посылки данных.
Вобщем-то, сбуферить байты в Java или C совсем даже не проблема, а вот в PHP есть какой-то тонкий напряг...
Ну да ладно, похоже легче будет разобраться с PHP ...

Marmot писал(а):Ну да ладно, похоже легче будет разобраться с PHP ...

ну ты хоть расскажи потом, а? Интересно же.

От нет чипа не зависит?
Чудны бывают драйверочки. Сам корректировал
такой. DMA структура в одном по 8 границе не
выровняна была. Такие чудеса выдавал в зависимости
от того как в памяти ляжет. Скорость передчи раз в 20
менялась.

блокинг/нонблокинг ресив ?