статья, как обычно, примитивно генерированная. "смешалость все... кони, люди..." оболочки, системы...
рекомендация в конце о необходимости свопа и требовании чтоб его размер превышал ram нужно только для гибернации. при гибернации состояние ram записывается в своп.
в остальных вариантах своп нужно делать таким как он нужен :)
aleks-th, если ты в гараж, рассчитанный на десять машин, попытаешься впихунуть 50 машин, на тебя посмотрят как на идиота.
понятна аналогия ?? :)
ПО, которое держит в памяти большие куски редко используемых данных и которые можно скинуть в своп без потери скорости работы проги, говорит лишь о плохой архитектуре ПО.
Valdemar Smörman, о чем и речъ :) если для работы ПО не хватает памяти, то это не хватает памяти.
своп баааальшой костыль, активно используемый своп тормозит работу.
aleks-th, нет ни одного ПО намертво завязанного на своп.
ни одно ПО не знает что в системе есть своп.
ни одно ПО не отличит данные, находящиеся в памяти или лежащие в свопе.
если у тебя не хватает RAM для работы твоего ПО, то это проблемы нехватки RAM, а не работы свопа :)
хотя у меня есть и своп в виде файла и включен модуль z-swap, но сколь не смотрел, никто ими не пользуется :)
TOBris, конечно же !!
да и оптика и любой другой канал связи имеет свой физически определенный предел скорости.
ой не рассказывай "британские ученые узнали..." :) можно всё !! и вайфай с обычных роутореов протягиваил на 50 километров !! причем реально, но есть прикладные тонокости...
PavelSmol, да потому и провайдеры ставят узлы слабее полной теоритической загрузки сети. и продолжают писать "до NNNбс".
и не только провайдеры :)
хочешь стабильного большого канала, есть вариант спец.договора.
PavelSmol, медь 100мбс лишь для примера физического ограничения и отличия от програмного.
ну а дерево PON вообще само по себе отличный пример "ограничения из-за соседей" когда влиять начинает загруженность провайдерского терминала.
проводя аналогию даже на самолет нередко продается больше билетов чем посадочных мест :) тонкие нюансы бизнеса.
PavelSmol, потому и в серъезных, а не маркетинговых, документах пишетца "до NNNNбс" :)
в принципе это скорость связи клиент-провайдер , ограниченная либо физическим каналом (к примеру протянута медяшка 100мбс и тут больше 100мбс не светит) либо тарифом (к примеру тариф 500мбс, но физической линии 500мбс не существует, т.е. до клиента протянута оптика на 1гбс и скорость ограничена програмно).
а дальше скорость зависит от кучи транзитных узлов связи и загруженности онных.
пинать провайдера можно, но бесполезно.
он вместо рекламки покажет юридически правильно оформленный договор, где будет стоять фраза что-то типа "до 1Гб/с" и все твои пинки перенаправит в /dev/null и будет как ни странно прав.
Рамазан Ахриев, если винда загружается, но картинки нет, значит гдето в связке видеокарта-кабель-монитор косяк.
искать косяк только подстановкой заведомо рабочих компонентов. т.е. нужны подменные видеокарта-кабель-монитор.
Drainer_off, еще вариант к первому от алекса - дальность большая. и роутеру не хватает силенок протащить 1гб по нему... попробуй прикинуть длину кабеля.
еще вариант наводки - гдето эзернет проходит рядом с сильно шумящим сетевым кабелем.
и т.д. и т.п.
попробуй воткнуть напрямую в несколько ноутов.
просто у обоих роутеров немного разные приемо-передатчики.
поглощение сигнала пропорционально частоте, т.е. кабеля поглощает 1гбс сильнее 100мбс и устройству не хватает уровня для запуска 1гбс линка.
было дело, знакомые тянули Ethernet кабель до устройства, получилось ~120 метров, т.е. больше рекомендуемых 100 метров. устройство сеть не увидело :( подключили ноут - связь появилась. подсунули свитч - он увидел сеть. так и оставили свитч возле прибора...
utsiye, скажем так. вполне применимо. можно слать пакеты tcp с нагрузкой всего в один байт. они прекрасно пройдут по любой сети до получателя. никаких ограничений на сей трафик нет.
но практически не применяется, ибо оверхед в виде заголовков будет дикий.
это как гонять грузовик для перевозки одного ящика бананов - "можно, но зачем ??"
кстати вполне возможно по мере движения в сети такие пакеты дефрагментируют - т.е. объединят нагрузку нескольких пакетов в одни большой.
из личной практики могу вспомнить, пускали по tcp поток данных modbus rtu (с помощью преобразователя com-ethernet ). он медленный, всего 9600 бит/сек. при этом разделение посылок происходит по времени. И в принципе работало, но периодически косячило.
т.е. по ethernet пересылались чуть ли не считанные байты. но периодически функция пакетирования потока ошибалась и байты разных посылок modbus rtu смешивались.
doexec, а не :) я про другое подумал "мне нужны все письма, в том числе и удаленные". т.е если пользователь удаляет письмо из ящика оно сохраняется в отдельном хранилище.
пофих. главное всех всё устраивает.
сервисы в сумме гемора дешевле железа выходят.
