[jcxz 184]

12 минут назад, mantech сказал:

Задержка между отправкой пакета с данными компу и ответом подтверждения от компа. Походу комп как-раз и ждет еще пакетов, т.к. скорее всего окно приема на компе гораздо больше 1.5Кбайта...

Можно попробовать указать флаг PUSH в последнем пакете (после которого хотите быстрее ACK получить).

А ещё замечал: после первого кадра виндовый стек ждёт перед отправкой ACK, но после 2-го кадра - отправляет. Вне зависимости от их размера. Т.е. - если просто порезать кадр на два более мелких, то после второго скорее всего сразу получите ACK.

13 минут назад, aaarrr сказал:

На win по умолчанию 32 было, если не путаю.

В стандартных (не huge) кадрах для размера отведено 16 бит. И обычно винда всегда выставляет все единички в этом поле. Редко удаётся так быстро передавать с устройства, чтоб принимающая сторона не успевала обрабатывать и этот размер стал уменьшаться меньше 65535. Хотя конечно - зависит от клиента-хозяина сокета на ПК.

[AlexandrY 3]

2 hours ago, mantech said:

но самое интересное то, что закачка идет на скорости 500 и более Кбайт сек.

Думаю что скорость закачки сильно преувеличена. 
Тут опять надо сказать людям на что закачивалось и с чего скачивалось: RAM, SPI Flash, NAND, SD...?  

[jcxz 184]

1 час назад, AlexandrY сказал:

Думаю что скорость закачки сильно преувеличена. 
Тут опять надо сказать людям на что закачивалось и с чего скачивалось: RAM, SPI Flash, NAND, SD...?  

С чего "преувеличена"?

Был у меня как-то проект на LPC1768 (уже стареньком, на 100МГц всего), так там работало 2 TCP-сокета одновременно параллельно. Скорость по каждому была порядка <=1.2...1.5 МБ/сек. Да и то - просто выше не требовалось, поток такой был, может и больше работало бы.

[mantech 34]

1 час назад, AlexandrY сказал:

Думаю что скорость закачки сильно преувеличена. 
Тут опять надо сказать людям на что закачивалось и с чего скачивалось: RAM, SPI Flash, NAND, SD...?  

С чего бы вдруг???  Должно быть выше раз в 5, но я специально понизил приоритет работы с сетью, чтоб всякие попытки подвесить систему непрерывными запросами были недопустимы. Читаю и записываю на сд-карту или усб флешку.

45 минут назад, jcxz сказал:

Скорость по каждому была порядка <=1.2...1.5 МБ/сек. Да и то - просто выше не требовалось

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

2 часа назад, aaarrr сказал:

Автор передает, а не принимает.

Так и есть, мой стек выставляет винде размер окна равный пакету, т.е. 1,5Кбайта, что винда мне выставляет еще не смотрел..

[AlexandrY 3]

18 hours ago, jcxz said:

Был у меня как-то проект на LPC1768 (уже стареньком, на 100МГц всего), так там работало 2 TCP-сокета одновременно параллельно. Скорость по каждому была порядка <=1.2...1.5 МБ/сек. Да и то - просто выше не требовалось, поток такой был, может и больше работало бы.

В прошлом месяце Netflix заявил что его FreeBSD TCP/IP стек умеет выдавать на скорости 200Gb/s с одного чипа.
Заметьте - это вместе в TLS шифрованием.
Так что вам есть куда расти. 

 

[mantech 34]

Приветствую. Долго не занимался стеком, пришлось, но не все так здорово... 

Собственно вопрос, передаю TCP пакет в комп, размер 1500байт, флаги PSH+ ACK, затем след. пакет, без приема ACK-а той же длины, но с другими даными, КС и Seq num, но wireshark первый пакет идентифицирует, как FTP DATA, а второй как ретрансмит. В чем прикол? Какие поля второго пакета должны отличаться от первого, чтоб не ретрансмит был? Чет запарился с этой глупостью...