Здравствуйте all
Обнаружил такую непрятную закономерность при отправке данных через стек.
Использую модуль
Revision:1008B14SIM300D32_SST34HF3284

Так вот, при отправке данных командой AT+CIPSEND обычно сразу получаю ответ SEND OK.
Под словом сразу подразумевается относительно небольшая задержка сети, обычно от 100 до 5000 мс в зависимости
от погодных условий, размера данных, ну в общем то понятных факторов.
НО! Иногда происходит стабильная задержка длиной 60...65 сек, причем стабильно не менее 60 сек, если уж она призошла.
Единтсвенная мысля пока что, это предполжение, что здесь имеем дело с тайм-аутом перезапроса потерянного tcp кадра.
Но неужели тайм-аут настолько велик???
Или не там копаю? Если там, то можно ли как то его регулировать посредством команд?

Тайм-аут перезапроса равен приблизительно 0.5 секунды (по стандарту).
Судя по длинному номеру, вы используете Симком.
Внутренние стеки модемов почти не настраиваются в смысле таймаутов, поэтому и Сименc ведёт себя аналогично.
Отсюда и тяга народа к программным стекам и линуксу.

это сеть, посему если кто-то захочет по пути изобразить таймаут немереннных размеров он его изобразит. Причем пофигизм в обработке ошибок нижних уровней достиг немерянных размеров и пофигистский подход а "пусть все TCP/IP вытягивает" процветает. В линуксе в том числе таймауты именно многие десятки секунд, или пока системные буфера не забьются не узнаете, в приложении, что работаете в пустоту.

Я вообще только предположил, что дело в перезапросах tcp, похоже, что дело действительно в этом?
Если да, то сталкивались вы с таким же случаем, именно с минутным тайм-аутом, или какая была реальная обстановка на практике?
И кстати, что вообще означает сообщение SEND OK? Данные приняты опсосом или сервером?

сегодня поснифил трафик wireshark-ом со стороны сервера, оказалось, что нет никаких перезапросов,
пакет иногда тупо приходит на минуту позже, что позволяет предположить, что задержка происходит на уровне опсоса.
привожу кусог лога:

14:16:31.198565 192.168.17.46 94.153.118.93 TCP 4881 > 2020 [PSH, ACK] Len=10 - команда от сервера
14:16:31.918073 94.153.118.93 192.168.17.46 TCP 2020 > 4881 [ACK] Len=0 - аск от стека модема
14:17:35.619862 94.153.118.93 192.168.17.46 TCP 2020 > 4881 [PSH, ACK] Len=74 - ответ от модема

сегодня вместо карточки КС, поставил карточку МТС, задержки пока не наблюдаются... вот такие пироги с котятами....

А за ним целый интернет и .... читайте выше .

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

Господа девелоперы, кто нить использует киевстар GPRS, имеет ли место такие большие замирания при передаче/приеме? или такое у всех
опсосов бывает. Вот у мтс пока не заметил, или мало наблюдал?
Реально ли эти пофиксить, общаясь с оператором? или может просто сменить его? КС хорош своим покрытием однако и редкими глюками сети...

Использую КС, задержка в обе стороны обычно секунды две, иногда полторы, достаточно стабильно по Украине.
Лайф хуже, иногда намного.

Как-то странно вы понимаете ситуацию.
Замирания - врожденная фича GPRS.
Не говоря уже что могут быть элементрарно затухания и потери в радиоканале.
Тут приходится иногда наблюдать за сетью из 50-и дивайсов подключенных по GPRS в одной соте.
Так я легко ложу весь GPRS в этой соте поставив на закачку по FTP всего 10-15 шт.дивайсов.
У всех остальных в соте начинает деградировать качество связи, задержки не то что минуту, а десятки минут могут быть.
Так что если хотите качественную связь то ставьте сразу 2-а, 3-и модема на разных операторов.

Хм... вы конечно все правильно говорите, но уж очень моя ситауция не похожа не перегрузку сети и затухание сигнала.
Во первых, пробовал в разное время суток и в разных районах города, результат одинаковый.
Во вторых, задержка, если случается, всегда стабильна - 65 +/- 2сек, таких архичетких затуханий имхо не бывает.
Тут очень похоже на какую то нестыковку стеков симкома и оператора, какая то нелюбовь у них взаимная на протокольном уровне.... именно с киевстаром

Блин, в 8 посте не совсем верно задал вопрос, имел ввиду, юзаете ли GPRS именно через встроенный TCP/IP стек симкома?

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

Совершенно неправдоподобно, когда вы заявляете, что наблюдаете задержки либо меньше 5 сек либо больше 60.
Мои выборки на тысячах замеров говорят что распределение задержек не может быть таким дискретным и вы должны были наблюдать и 10-и и 20-и секундные задержки.

Я бы сначала поискал проблему в самих методах тестирования.

Вы не поверите, но это то, что вижу даже сейчас, при написании этих строк в окне терминала
Если предположить, что в данное время отличная погода, отличное качество сигнала и нет перегрузок в сети, почему бы обычным
задержкам не быть в пределах 5 сек. А задержки в 65 сек, совершенно внезапные, всплывающие через 10-20 обычных транзакций
по 1 килобайту, разве это не может на уровне транспортного протокола?
Возможно аски tcp просто не доходят с какого то узла уже за пределами оператора, мы ж не знаем, как у них там маршрутизация настроена...



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

Так выкладывать весь .pcap файл со снифера надо, а не кусочек показывать.
Вот теперь мне кажется, что у вас просто TCP окно было все загружено, передача и остановилась, пока с сервера не пришло сообщение о появлении места в окне.
Так стоит у сервера окно уменьшить, чтоб слишком много IP пакетов не уходило безответно в сеть.

Выложил весь файл .pcap, только вы там увидете тоже самое (при просмотре поставьте фильтр - ip.addr == 94.153.118.93).
Дело в том, что до сервера вообще ничего не приходило в течении этой задержки, поэтому он и был исключен как причинный.
Там ниже еще есть и другие варианты, например с ретрансмитами tcp, но я рассматривал случай, когда было просто тупое молчание
на линии в течении минуты - 14:16:31 <--> 14:17:35, и такое же молчание было со стороны модема в ожидании SEND OK

Похоже ситуация с точностью до наоборот.
Модем на самом деле оттягивает ретрансмиты насколько можно.
На старте соединения произошла уже сильная задержка на 2 сек, но ретрансмита не было.
А потом видимо в силу вступает алгоритм медленного старта, чтобы не создать затор.
Но там перестраховались по полной поэтому почуяв задержки оттягивают передачу первого крупного блока как можно дольше.
И судя по логу есть подозрение, что в модеме не реализован алгоритм Нэйгла, т.е. концентрация малых пакетов в более крупные перед отправкой.
Т.е. я считаю проблема в модеме.
Но у другого оператора видимо не такие сильные задержки на старте из-за чего и не видна особенность стека модема.

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

Ну тогда думаю ловить больше нечего.
От маршрутизатора провайдера еще могут поступать на модем всякие плохие сообщения по ICMP.
Поэтому я всегда и говорю, что встроенные стеки это коты в мешке.
Тестируйте работу с провайдером снифером по PPP через компьютер.
Поскольку внутренние сети провайдера полностью открыты всем абонентам, то велика вероятность что модем тормозит какой-то левый внутренний трафик по TCP/IP.

Тут была комичная история один раз.
Взяли партию SIM карт для телеметрии, все сервисы отключены, только GPRS.
Расслабились, защит не делали.
И что то стало слегка тормозить время реакции на команды периодически.
Оказывается приходили рекламные SMS-ки пачками. Типа в расплату за дешевый план воткнули рекламу по полной.

Вы имеете ввиду, что можно тестить снифером и при этом использовать встроенный стек?
И каким образом можно подключится к внутренней сети провайдера? Разве она доступна для кого то, кроме их инженеров?

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

Ясно, всем спасибо, будем пока что подбирать провайдера под стек

У меня вообще SEND OK не приходит иногда, жду по 10 минут, перезагружаю....
Модем в ступор впадает...