ДОброго времени суток
Подскажите -кому не лень, в чем может быть
1.проблема медленной работы в ssh сессии через инет с удаленным сервером (под Freebsd 4.x), причем при работе из локалки с сервером - проблем никаких
полосу канала в 128 КБит/с назвать узкой сложно для ssh
может имеет смысл выделить полосу в ipfw+natd (работает именно эта связка) отдельно для ssh-если да - то как правильно это сделать?
2. как (по какому пр-лу) в ipfw выполняется выделение полосы
скажем канал есть 128 КБит/с, на машине, скажем , есть3 сетевухи, и 2-м из них я выделяю по 64КБит/с, то это зачит - что я даю им максимал но не гарантированные полосы?
т.е. при макс трафике на обоих - третьей из полосы ничего не достанется?
или же ей не достанется вообще ничего никогда - даже если первые два интерфейса молчат??
для меня это принципиальноЗаренее благодарен за любой ответ
спасибо
>ДОброго времени суток
>Подскажите -кому не лень, в чем может быть
>1.проблема медленной работы в ssh сессии через инет с удаленным сервером (под
>Freebsd 4.x), причем при работе из локалки с сервером - проблем
>никаких
>полосу канала в 128 КБит/с назвать узкой сложно для sshПри загруженном канале (http/ftp и иже с ними) - 128К _ОЧЕНЬ_ мало...
>может имеет смысл выделить полосу в ipfw+natd (работает именно эта связка) отдельно
>для ssh-если да - то как правильно это сделать?самое большее, что можно сделать средствами ipfw:
1. ограничить весь остальной траффик - man ipfw на предмет pipe
2. запихать все это в очереди с приоритетами (весами), дав наивысший приоритет (вес) очереди с ssh - man ipfw на предмет pipe, queue>2. как (по какому пр-лу) в ipfw выполняется выделение полосы
>скажем канал есть 128 КБит/с, на машине, скажем , есть3 сетевухи, и
>2-м из них я выделяю по 64КБит/с, то это зачит -
>что я даю им максимал но не гарантированные полосы?Именно так - ты их ограничиваешь сверху, но не гарантируешь, что им достанется вся полоса.
>т.е. при макс трафике на обоих - третьей из полосы ничего не
>достанется?практически не достанется
>или же ей не достанется вообще ничего никогда - даже если первые
>два интерфейса молчат??нет
>для меня это принципиально
>
>Заренее благодарен за любой ответ
>спасибоудачи
>>ДОброго времени суток
>>Подскажите -кому не лень, в чем может быть
>>1.проблема медленной работы в ssh сессии через инет с удаленным сервером (под
>>Freebsd 4.x), причем при работе из локалки с сервером - проблем
>>никаких
>>полосу канала в 128 КБит/с назвать узкой сложно для ssh
>
>При загруженном канале (http/ftp и иже с ними) - 128К _ОЧЕНЬ_ мало...
--------------------------------
в том то и дело - что проверял на пустом канале - хорошо была такая возможность
а нет ли каких других методов поднять конечную "производительность" канала для sshd2
дело в том - что нечему тормозить ssh-трафику - и ЭТО НЕ понятноЗАРАНЕЕ спасибо
--------------------------------
>
>
>>может имеет смысл выделить полосу в ipfw+natd (работает именно эта связка) отдельно
>>для ssh-если да - то как правильно это сделать?
>
>самое большее, что можно сделать средствами ipfw:
>1. ограничить весь остальной траффик - man ipfw на предмет pipe
>2. запихать все это в очереди с приоритетами (весами), дав наивысший приоритет
>(вес) очереди с ssh - man ipfw на предмет pipe, queue
>
>
>>2. как (по какому пр-лу) в ipfw выполняется выделение полосы
>>скажем канал есть 128 КБит/с, на машине, скажем , есть3 сетевухи, и
>>2-м из них я выделяю по 64КБит/с, то это зачит -
>>что я даю им максимал но не гарантированные полосы?
>
>Именно так - ты их ограничиваешь сверху, но не гарантируешь, что им
>достанется вся полоса.
>
>>т.е. при макс трафике на обоих - третьей из полосы ничего не
>>достанется?
>
>практически не достанется
>
>>или же ей не достанется вообще ничего никогда - даже если первые
>>два интерфейса молчат??
>
>нет
>
>>для меня это принципиально
>>
>>Заренее благодарен за любой ответ
>>спасибо
>
>удачи
>в том то и дело - что проверял на пустом канале -
>хорошо была такая возможность
>а нет ли каких других методов поднять конечную "производительность" канала для sshd2
>
>дело в том - что нечему тормозить ssh-трафику - и ЭТО НЕ
>понятно
>
>ЗАРАНЕЕ спасибо
>--------------------------------хм, интересно... А канал пустой с двух сторон?
можешь попробовать bing - он померяет пропускную способность канала между двумя машинами (общую). Возможно, где-то что-то обрезано по дороге?
>хм, интересно... А канал пустой с двух сторон?
>можешь попробовать bing - он померяет пропускную способность канала между двумя машинами
>(общую). Возможно, где-то что-то обрезано по дороге?мой канал 128 - свободный был
с другого конца пропускная способность достаточная - что б каждый день качать по 2 образа Free
думаю - не в этом деле - а в настройках - только вот где- не могу никак понять
>>можешь попробовать bing - он померяет пропускную способность канала между
вот рез -bing-а
1024 bits in 7.321ms: 139872bps, 0.007149ms per bit
1024 bits in 0.000ms
1024 bits in 16.221ms: 63128bps, 0.015841ms per bit
1024 bits in 26.902ms: 38064bps, 0.026271ms per bit
1024 bits in 27.420ms: 37345bps, 0.026777ms per bit
1024 bits in 26.900ms: 38067bps, 0.026270ms per bit
1024 bits in 11.204ms: 91396bps, 0.010941ms per bit
1024 bits in 12.243ms: 83640bps, 0.011956ms per bit
1024 bits in 17.758ms: 57664bps, 0.017342ms per bit
1024 bits in 16.727ms: 61218bps, 0.016335ms per bit
1024 bits in 12.375ms: 82747bps, 0.012085ms per bit
^C
--- 192.168.37.49 statistics ---
bytes out in dup loss rtt (ms): min avg max
44 157 157 0% 0.237 0.507 39.218
108 157 157 0% 0.208 0.713 39.258
--- 217.106.255.5 statistics ---
bytes out in dup loss rtt (ms): min avg max
44 157 156 0% 62.789 185.868 909.541
108 157 156 0% 75.164 185.750 629.999
мда - бывает даже ниже 30 КБит/с
кстати - а сколько - вообще - на практике - хватало для терпимой работы ssh???
>>>можешь попробовать bing - он померяет пропускную способность канала между
>вот рез -bing-а
>1024 bits in 7.321ms: 139872bps, 0.007149ms per bit
>1024 bits in 0.000ms
>1024 bits in 16.221ms: 63128bps, 0.015841ms per bit
>1024 bits in 26.902ms: 38064bps, 0.026271ms per bit
>1024 bits in 27.420ms: 37345bps, 0.026777ms per bit
>1024 bits in 26.900ms: 38067bps, 0.026270ms per bit
>1024 bits in 11.204ms: 91396bps, 0.010941ms per bit
>1024 bits in 12.243ms: 83640bps, 0.011956ms per bit
>1024 bits in 17.758ms: 57664bps, 0.017342ms per bit
>1024 bits in 16.727ms: 61218bps, 0.016335ms per bit
>1024 bits in 12.375ms: 82747bps, 0.012085ms per bit
>^C
>--- 192.168.37.49 statistics ---
>bytes out in dup
>loss rtt (ms): min
> avg max
> 44 157 157
> 0%
> 0.237
> 0.507 39.218
> 108 157 157
> 0%
> 0.208
>0.713 39.258
>
>--- 217.106.255.5 statistics ---
>bytes out in dup
>loss rtt (ms): min
> avg max
> 44 157 156
> 0%
> 62.789 185.868
> 909.541
> 108 157 156
> 0%
> 75.164 185.750
>629.999
>
>
>мда - бывает даже ниже 30 КБит/св среднем около 64К вроде...
где-то канал урезан (либо он с той стороны такой) (и учти, это общая пропускная способность, сколько там на ssh - еще меньше)>
>кстати - а сколько - вообще - на практике - хватало для
>терпимой работы ssh???сложно сказать - ему особо много-то не надо, он чувствителен скорее ко времени реакции (запрос/ответ), чем к пропускной способности.
>>мда - бывает даже ниже 30 КБит/с
>
>в среднем около 64К вроде...
>где-то канал урезан (либо он с той стороны такой) (и учти, это
>общая пропускная способность, сколько там на ssh - еще меньше)
>
>>
>>кстати - а сколько - вообще - на практике - хватало для
>>терпимой работы ssh???
>
>сложно сказать - ему особо много-то не надо, он чувствителен скорее ко
>времени реакции (запрос/ответ), чем к пропускной способности.
выходит - поправить ничего не получится?
кроме установки queue в ipfw (на случай - когда канал - ьудет пользоваться не только ssh :o) )
>>>мда - бывает даже ниже 30 КБит/с
>>
>>в среднем около 64К вроде...
>>где-то канал урезан (либо он с той стороны такой) (и учти, это
>>общая пропускная способность, сколько там на ssh - еще меньше)
>>
>>>
>>>кстати - а сколько - вообще - на практике - хватало для
>>>терпимой работы ssh???
>>
>>сложно сказать - ему особо много-то не надо, он чувствителен скорее ко
>>времени реакции (запрос/ответ), чем к пропускной способности.
>
>
>выходит - поправить ничего не получится?
>кроме установки queue в ipfw (на случай - когда канал -
>ьудет пользоваться не только ssh :o) )если честно, с queue у меня он тоже тормозил, хотя замечено было следующее: тормозит, но задержка постоянная - время между запросом/ответом примерно одинаковое, поэтому вроде как жить можно...
>>выходит - поправить ничего не получится?
>>кроме установки queue в ipfw (на случай - когда канал -
>>ьудет пользоваться не только ssh :o) )
>
>если честно, с queue у меня он тоже тормозил, хотя замечено было
>следующее: тормозит, но задержка постоянная - время между запросом/ответом примерно одинаковое,
>поэтому вроде как жить можно...
а какова задержка (и при каком канале с какой загруженностью - если не секрет)? - интерес - что б со своими сравнивать при настройках
>>>выходит - поправить ничего не получится?
>>>кроме установки queue в ipfw (на случай - когда канал -
>>>ьудет пользоваться не только ssh :o) )
>>
>>если честно, с queue у меня он тоже тормозил, хотя замечено было
>>следующее: тормозит, но задержка постоянная - время между запросом/ответом примерно одинаковое,
>>поэтому вроде как жить можно...
>
>
>а какова задержка (и при каком канале с какой загруженностью -
>если не секрет)? - интерес - что б со своими сравнивать
>при настройкахну я не меряла в миллисекундах задержку :)
в общем - задержка была не больше секунды между нажатием клавиши и ее воспроизведением, скажем так. Причем, если запросы идут подряд - то стабильная задержка, если какое-то время запросов не было, а потом пошли - то в начале задержка бОльшая - видимо, пока там ipfw всех остальных запинает, чтобы дать дорогу самой приоритетной очереди, должно пройти время :) Канал тогда был 128К, загружен/перегружен на все 200% (иногда запросы dns отваливались по таймауту, когда слишком много народу по http лезло)...
вот...