Мое ADSL-соединение со скоростью 2048 Кбит / с загружается с ожидаемой скоростью загрузки 220 КБ / с, но для достижения этой скорости требуется слишком много времени, другими словами, максимальная скорость нормальная, но ускорение ужасное. Это не проблема с большими загрузками, потому что скорость в конечном итоге достигает максимальной скорости. Проблема заключается в просмотре или вводе через SSH, потому что это зависит от начальной скорости пакетов, которая может составлять всего 3 КБ / с! Задержка ужасная, и интернет-провайдер не может этого понять. Несмотря на приемлемые значения для линейного затухания (14,0) и запаса по SNR (32,4)
Прокси не используются ...
Я не могу найти подобных ответов в Google. Может я не могу описать проблему? Какой термин определяет эту проблему (например, задержка, потеря пакетов), я не знаю. А что я могу сказать своему провайдеру?
РЕДАКТИРОВАТЬ: вот результат traceroute google.com
портативный компьютер: ~ $ traceroute google.com traceroute to google.com (173.194.38.102), максимум 30 переходов, 60 байтовых пакетов
1 192.168.1.254 (192.168.1.254) 5,538 мс 5,772 мс 12,180 мс
2 * KHANKA-R01C-C-EG (163.121.170.229) 38,951 мс 53,544 мс
3 host-163.121.211.134.tedata.net (163.121.211.134) 1022,649 мс 1157,199 мс 1171,533 мс
4 host-163.121.211.134.tedata.net (163.121.211.134) 1368,481 мс 1392,954 мс 1456,449 мс
5 host-163.121.211.125.tedata.net (163.121.211.125) 1483,733 мс 1485,976 мс 1559,233 мс
6 10.42.0.3 (10.42.0.3) 2137,709 мс 984,750 мс 1311,599 мс
7 10.32.8.107 (10.32.8.107) 1184,654 мс 1188,532 мс 1529,284 мс
8 host-163.121.215.194.tedata.net (163.121.215.194) 1537.709 ms host-163.121.209.170.tedata.net (163.121.209.170) 1525.038 ms host-163.121.215.194.tedata.net (163.121.215.194) 1784.301 ms
9 72.14.212.13 (72.14.212.13) 1779,373 мс 1863,601 мс 2083,181 мс
10 * 209,85,252,194 (209,85,252,194) 2598,120 мс 209,85,252,36 (209,85,252,36) 2643,383 мс
11 216.239.43.42 (216.239.43.42) 2670,846 мс 2674,115 мс 3114,124 мс
12 216.239.43.4 (216.239.43.4) 2970,444 мс 2983,826 мс 216.239.46.218 (216.239.46.218) 1316,574 мс
13 209.85.249.11 (209.85.249.11) 1287.924 мс 1309.304 мс 72.14.239.93 (72.14.239.93) 1309.548 мс
14 216,239,48,69 (216,239,48,69) 1327,934 мс 1333,812 мс 1418,224 мс
15 66,249,94,24 (66,249,94,24) 1426,165 мс 1435,831 мс 66,249,94,22 (66,249,94,22) 1434,125 мс
16 72.14.239.83 (72.14.239.83) 1642,336 мс 1647,606 мс 1663,440 мс
17 64.233.174.177 (64.233.174.177) 1767,621 мс 1806,839 мс *
18 209,85,255,37 (209,85,255,37) 1554,591 мс 1483,272 мс 1498,464 мс
19 209,85,251,239 (209,85,251,239) 1301,597 мс 1308,220 мс 1319,829 мс
20 nrt19s18-in-f6.1e100.net (173.194.38.102) 1321,308 мс 1323,904 мс 1338,072 мс
С информацией, представленной в вашем вопросе, действительно нет никакого способа помочь вам. Фактически, если это вся собранная вами информация, вы даже не можете помочь себе. Есть три правила устранения неполадок:
Могут быть и другие правила, но все они подчиняются первым трем. Вам необходимо собрать как можно больше информации в демаркационной точке. Каким бы ни был ваш CPE (в вашем случае DSL-модем), вам необходимо извлечь из него как можно больше информации. Опросите его для получения информации о SNMP, вытащите из него системный журнал, проверьте его руководство на предмет каких-либо специальных API-интерфейсов, все девять ярдов.
Вам также необходимо пройти тесты с временным интервалом, касающиеся задержки, пропускной способности, потери пакетов и т. Д. Настройте SmokePing. Используйте запланированный сценарий iperf и запишите соответствующую информацию. Вы, заказчик, всегда обязаны доказать, что проблема заключается в провайдере. Вы и ваше оборудование считаются виновными, пока не будет обнаружено иное. Кроме того, доказательства, которые вы предоставляете для доказательства своей невиновности, должны быть в трех экземплярах с блестящими графиками и, возможно, вступительной музыкой.
Это может быть так же просто, как какой-нибудь шаткий контроль перегрузки (Медленный старт приходит в голову). Это могут быть плохие линии DSLAM. Это может быть любое количество вещей, но вы не можете знать ни одной из возможностей, пока не вооружитесь как можно большим объемом данных с вашего конца линии.
Идите и соберите данные.
Если у вас плохая задержка, вы, вероятно, ничего не сможете сделать для ssh, поскольку скорость обычно не нужна для ssh, а интерактивность нужна.
Для просмотра веб-страниц, если вы можете создать установленное соединение с прокси-сервером, где задержка не так велика, она может улучшиться (если медленный запуск является источником проблемы). По крайней мере, ваше соединение с прокси будет максимально быстрым, и вы сможете поставить все свои веб-запросы в очередь на другой стороне.