AlexandrY 3 4 ноября, 2007 Опубликовано 4 ноября, 2007 · Жалоба Вопрос в связи с тем, что от этого зависит эффективная скорость перекачки файлов. Например это критично для удаленных камер или проcлушивания по TCP. Т.е. как SIM300 справляется с заторами на NAT-сервере провайдера, не слишком ли длинные паузы на ретрансмит. Быстрая ли реакция на дублирующиеся пакеты с ACK. Быстро ли сам отправляет ACK. Правильно ли определяет емкость канала на этапе разгона. Какое окно на прием. Правильно ли встроенный FTP отрабатывает подключение перез NAT по активному FTP. А то, например, Telit GE863 показал хреновые результаты по прокачке, где-то 1 кбайт/сек при закачке файлов на удаленный сервер в идеальных условиях. Плохо емкость канала просчитывает. (т.е. сколько можно послать пакетов не ожидая подтверждения). А вот NOKIA12 с тойже SIM картой и на тот же сервер показывает скорость 6 кбайт/сек. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
edo 0 4 ноября, 2007 Опубликовано 4 ноября, 2007 · Жалоба аплоад по gprs 48кбит? фантастика. судя по всему там class 10, теоретически аплоад до 40кбит, пратически 8-16. или нокия аплоадит по edge? в sim300 edge не поддерживается Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
stream 0 5 ноября, 2007 Опубликовано 5 ноября, 2007 · Жалоба Вряд ли кто-то проводил подобные исследования. Я видел максимальную скорость аплоада в районе 3 с хвостиком кб/сек (средняя на на файле в пару мегабайт). Машина была под WinXP. В плохих условиях, при загруженных каналах в центре города, начались какие-то непонятки. Правда, на той машине была другая, совсем не виндовая, ОС и, соотвественно, другой PPP-клиент. Все страшно тормозило. В статистике PPP-интерфейса на передачу было огромное кол-во ретрансмитов по таймауту (объем физически прокачанных через модуль данных был почти в два раза больше логически отправленных). В статистике на прием - очень много out-of-order blocks. За сеанс было два запроса на смену размера окна. Я не знаю, кто был виновен в таком поведении - неудачный PPP-клиент на компе, модуль, или я так неудачно попал, что именно в этот момент колбасило оператора (тогда даже ответы на пинги приходили порой не по порядку). В другом месте города, на другом операторе - 3 и более кб/сек без проблем. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
edo 0 5 ноября, 2007 Опубликовано 5 ноября, 2007 · Жалоба В статистике PPP-интерфейса на передачу было огромное кол-во ретрансмитов по таймауту какие ретрансмиты в ppp?!? ppp отсылает пакет и забывает про него. перепосылки могут быть в tcp. В статистике на прием - очень много out-of-order blocks. опять это скорее tcp. бывает, в общем ничего страшного при нормальной реализации tcp. За сеанс было два запроса на смену размера окна. ну это вообще штатная ситуация. первая пришедшая в голову аналогия "по дороге на работу 2 раза видел машины с включенными поворотниками". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 5 ноября, 2007 Опубликовано 5 ноября, 2007 · Жалоба Отдельный пакет с требованием изменить окно должен наверно говорить о возникновени неожиданных тормозов на приемной стороне. Я так склоняюсь к версии, что в плохом трафике модем не меньше виноват чем сеть самого оператора. Так в том же примере с NOKIA и Telit. Я ж их проверял практически в одно и тоже время с одной и той же картой. Характеристики сети оператора не могли успеть измениться. Тем более модемы я чередовал несколько раз. Антена базовой станции в 50 метрах от модемов была в прямой видимости. И NOKIA с EDGE могда качать 6 KB и сеть не стопорила, а Telit и 1 KB без заторов прокачать не мог как будто сеть не успевает за ним. Правда в другое время дня и Telit мог качать без создания заторов в TCP трафике но очень медленно, как будто у оператора сильно увеличился round-trip time. >За сеанс было два запроса на смену размера окна. ну это вообще штатная ситуация. первая пришедшая в голову аналогия "по дороге на работу 2 раза видел машины с включенными поворотниками". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
edo 0 5 ноября, 2007 Опубликовано 5 ноября, 2007 · Жалоба Отдельный пакет с требованием изменить окно должен наверно говорить о возникновени неожиданных тормозов на приемной стороне. где сказано про отдельный пакет? И NOKIA с EDGE могда качать 6 KB и сеть не стопорила, а Telit и 1 KB без заторов прокачать не мог как будто сеть не успевает за ним я не пойму, вы сравниваете gprs с edge или реализацию tcp-стека в разных модемах? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 5 ноября, 2007 Опубликовано 5 ноября, 2007 · Жалоба От обратного, как вы себе представляете обмен в течении которого приемная сторона только два раза изменила размер приемного окна? Я сравниваю количество заторов (из-за пропусков или отсутствия ответов, не важно) на одном и другом модеме. Или вы хотите сказать, что TCP/IP по EDGE принципиально по другому обрабатывается? где сказано про отдельный пакет? я не пойму, вы сравниваете gprs с edge или реализацию tcp-стека в разных модемах? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
edo 0 5 ноября, 2007 Опубликовано 5 ноября, 2007 (изменено) · Жалоба сразу уточню - я не использую tcp-стек модема, ничего про него сказать не могу. просто хотел обратить внимание на неточности - в одном случае сравнивались два модема, работающих по разным протоколам (и неясно, какой вклад в результат вносит именно tcp-стек). в другом случае обсуждаемый tcp-стек модема вообще не использовался, зато откуда-то появлись "ретрансмиты ppp". Изменено 5 ноября, 2007 пользователем edo Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
stream 0 6 ноября, 2007 Опубликовано 6 ноября, 2007 · Жалоба просто хотел обратить внимание на неточности - в одном случае сравнивались два модема, работающих по разным протоколам (и неясно, какой вклад в результат вносит именно tcp-стек). в другом случае обсуждаемый tcp-стек модема вообще не использовался, зато откуда-то появлись "ретрансмиты ppp". Модем был в режиме GPRS и соединен с компом через ppp. Смотрелся вывод netstat с разными параметрами (tcp/udp/interface и т.п. statistic). Других интерфейсов, кроме lo, на машине не было. lo у меня никто не использует, так что вся статистика относилась только к ppp. Ретрансмиты, конечно, были tcp/ip. Собственно по физическому ppp-обмену все было чисто. Кто был виноват (стек в компе, модеме, или у оператора) - я сказать не могу. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
edo 0 12 ноября, 2007 Опубликовано 12 ноября, 2007 · Жалоба протестировал скорость на 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 ещё больше ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться