Вопрос в связи с тем, что от этого зависит эффективная скорость перекачки файлов.
Например это критично для удаленных камер или проcлушивания по TCP.

Т.е. как SIM300 справляется с заторами на NAT-сервере провайдера, не слишком ли длинные паузы на ретрансмит.
Быстрая ли реакция на дублирующиеся пакеты с ACK.
Быстро ли сам отправляет ACK. Правильно ли определяет емкость канала на этапе разгона.
Какое окно на прием.
Правильно ли встроенный FTP отрабатывает подключение перез NAT по активному FTP.

А то, например, Telit GE863 показал хреновые результаты по прокачке, где-то 1 кбайт/сек при закачке файлов на удаленный сервер в идеальных условиях. Плохо емкость канала просчитывает. (т.е. сколько можно послать пакетов не ожидая подтверждения).

А вот NOKIA12 с тойже SIM картой и на тот же сервер показывает скорость 6 кбайт/сек.

аплоад по gprs 48кбит? фантастика.
судя по всему там class 10, теоретически аплоад до 40кбит, пратически 8-16.

или нокия аплоадит по edge? в sim300 edge не поддерживается

Вряд ли кто-то проводил подобные исследования.

Я видел максимальную скорость аплоада в районе 3 с хвостиком кб/сек (средняя на на файле в пару мегабайт). Машина была под WinXP.

В плохих условиях, при загруженных каналах в центре города, начались какие-то непонятки. Правда, на той машине была другая, совсем не виндовая, ОС и, соотвественно, другой PPP-клиент. Все страшно тормозило. В статистике PPP-интерфейса на передачу было огромное кол-во ретрансмитов по таймауту (объем физически прокачанных через модуль данных был почти в два раза больше логически отправленных). В статистике на прием - очень много out-of-order blocks. За сеанс было два запроса на смену размера окна.

Я не знаю, кто был виновен в таком поведении - неудачный PPP-клиент на компе, модуль, или я так неудачно попал, что именно в этот момент колбасило оператора (тогда даже ответы на пинги приходили порой не по порядку).

В другом месте города, на другом операторе - 3 и более кб/сек без проблем.

какие ретрансмиты в ppp?!? ppp отсылает пакет и забывает про него.
перепосылки могут быть в tcp.

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

ну это вообще штатная ситуация. первая пришедшая в голову аналогия "по дороге на работу 2 раза видел машины с включенными поворотниками".

Отдельный пакет с требованием изменить окно должен наверно говорить о возникновени неожиданных тормозов на приемной стороне.

Я так склоняюсь к версии, что в плохом трафике модем не меньше виноват чем сеть самого оператора.
Так в том же примере с NOKIA и Telit.
Я ж их проверял практически в одно и тоже время с одной и той же картой.
Характеристики сети оператора не могли успеть измениться. Тем более модемы я чередовал несколько раз.
Антена базовой станции в 50 метрах от модемов была в прямой видимости.
И NOKIA с EDGE могда качать 6 KB и сеть не стопорила, а Telit и 1 KB без заторов прокачать не мог как будто сеть не успевает за ним.

Правда в другое время дня и Telit мог качать без создания заторов в TCP трафике но очень медленно, как будто у оператора сильно увеличился round-trip time.

где сказано про отдельный пакет?

я не пойму, вы сравниваете gprs с edge или реализацию tcp-стека в разных модемах?

От обратного, как вы себе представляете обмен в течении которого приемная сторона только два раза изменила размер приемного окна?

Я сравниваю количество заторов (из-за пропусков или отсутствия ответов, не важно) на одном и другом модеме.
Или вы хотите сказать, что TCP/IP по EDGE принципиально по другому обрабатывается?

сразу уточню - я не использую tcp-стек модема, ничего про него сказать не могу.

просто хотел обратить внимание на неточности - в одном случае сравнивались два модема, работающих по разным протоколам (и неясно, какой вклад в результат вносит именно tcp-стек). в другом случае обсуждаемый tcp-стек модема вообще не использовался, зато откуда-то появлись "ретрансмиты ppp".

Модем был в режиме GPRS и соединен с компом через ppp. Смотрелся вывод netstat с разными параметрами (tcp/udp/interface и т.п. statistic). Других интерфейсов, кроме lo, на машине не было. lo у меня никто не использует, так что вся статистика относилась только к ppp.

Ретрансмиты, конечно, были tcp/ip. Собственно по физическому ppp-обмену все было чисто. Кто был виноват (стек в компе, модеме, или у оператора) - я сказать не могу.

протестировал скорость на sim300d (+ linux tcp/ip стек).
условия: ночь (сеть свободна), сигнал хороший.
модуль подключен к компьютеру с linux.
на ftp-сервер (тоже linux, выделенка) закачивался файл, после скачивался обратно.

результаты:
upload
560441 bytes sent in 132.63secs (4.1 kB/s)
или примерно 33кбит/с

download
560441 bytes received in 62.90 secs (8.7 kB/s)
или примерно 70кбит/с

что полностью согласуется с теоретическими данными:
у нас gprs class 10
максимальный ulpoad - 2 таймслота, при кодировани cs-4 это ~43кбит/с
максимальный download - 4 таймслота, при кодировании cs-4 это ~86кбит/с

мы несколько недобрали до теоретического максимума (с другой стороны явно использовалось кодирование cs-4 - cs-3 может дать ~31кбит/c upload и ~62кбит/с download). с другой стороны это скорость передачи полезных данных, надо накинуть ещё немного на это.

ps: никакого отношения к реализации tcp/ip в sim300 это конечно не имеет, просто комментарий по поводу теоретической и практической максимальной скорости в gprs сетях с class 10 модемами. edge разумеется даст больше. umts ещё больше