Во-первых, речь идет о не серверном п.о., судя по тестированию на клиентском ноутбуке
Ну почему сразу не о серверном? Если у разработчика есть большой набор унаследованной инфраструктуры, то ситуация когда ноутбук мощнее сервера вполне себе реальна. А если дело в ОС, то WinServer 2003/2008 вполне нормально живут на ноутбуках. Я некоторое время пользовался ноутами под управлением данных операционных систем.
90+ потоков меня несколько смущают, но все-же это вполне реальный сценарий. Например файловый I/O может быть синхронным, тогда для уменьшения негативных эффектов из-за временно заблокированных на дисковых операциях процессов/потоков имеет смысл держать большой пул.
Как студент определит, тут проблем меньше. Например, поступают на то направление которое ближе к существующим интересам. Но и в рамках интересной специальности всегда существуют неинтересные для конкретного студента предметы.
Вот у меня минимум двое одногруппников работают по рабочим специальностям, слесарь и сварщик. Сомневаюсь, что они используют теормех и физику в работе, а сколько ночей не спал ради их курсовиков и даже дипломов…
Вторым предложением Вы объяснили почему они работают по рабочим специальностям и почему им не нужно то, чего они не знают.
А проблемы с требованиями решаемы — менеджеры зависимостей не вчера придумали
А хотя бы один реальный пример в реальной жизни существует? Да и сколько уйдет ресурсов на построение и оценку точности такого графа зависимостей?
А как студент определит, понадобиться ли ему этот курс в будущем или нет?
Да даже гарантированы ситуации, когда интересный студенту курс будет явно или неявно требовать знаний, которые даются на неинтересном курсе. Как разрешать эту ситуацию?
Я вот в свое время думал, что мне глубокие знания мат.анализа и методов ЦОС не понадобятся, а сейчас вот несколько неуютно чувствую себя, когда знаний явно не хватает для понимания некоторых нюансов задач коллег из совместного проекта. А желание понимать есть, так как это позволит более целостно взглянуть на решаемые задачи и предлагать более эффективные методы решения для задач из моей области. Коллеги конечно консультируют в сложных вопросах, да и учебники никто не отменял, но неуютность сохраняется…
Как ни странно, но Нива — одна из удачных машин ВАЗа. У нас в семье было две 31-х нивы, на одной из них я ездил больше года. Да и с учетом соотношения цена/проходимость у нивы практически нет конкурентов (Только вот ВАЗ все повышает и повышает цены...).
Японцы кстати тоже с этим согласны и нивы вполне покупают, как недорогие машины с очень хорошей проходимостью.
P.S. Все вышесказанное является личным мнением автора и ни в коем случае не оправдывает методы работы ВЦИОМ.
В принципе да. У Вас вполне ограниченный круг задач и это абсолютно нормально! У меня тоже круг задач ограничен.
Фортран, например, очень активно используется в научных расчетах, как в России, так и за рубежом (На хабре где-то была информация, что Intel на компиляторах Fortran зарабатывает больше, чем на компиляторах С/С++).
Без понимания оптики сложно работать с серьезной фото и видеотехникой.
Дифуры — это моделирование динамических систем.
«Взгляды Аристотеля» — это классическая ошибка преподавания философии, когда на протяжении года в этот курс пихают зубрежку чужих трактатов вместо упора на развитие умения думать, анализировать и говорить у студентов (Мне повезло, у нас не было зубрежки, а был упор на семинары. Я сходу не вспомню идеи великих философов по их именам, но не смотря на это я считаю, что правильно поставленный курс философии у программистов должен быть обязательно).
Схемотехника нужна для тех, кто связан с разработкой электроники, а для программистов основы данного направления помогут понять почему частота CPU больше не растет и сколько же может пройти сигнал за 1 такт CPU.
Черчение может помочь читать и рисовать различные схемы.
Да, далеко не всем это все нужно, но как определить нужны ли данные знания до тех пор, пока они не понадобятся?
Тогда возникнет другая проблема, чем занять 80% тех, кто пришли только ради корочек. Пока я видел только примеры, когда доступность полных лекционных материалов понижала эффективность обучения, так как не заинтересованные в знаниях во первых мешали остальным, а во вторых терялась возможность вложить в них хоть какие-нибудь знания через моторную память (все-таки многие, когда пишут запоминают лучше).
А отчислить 80% корочников и оставить желающих получать знания по понятным причинам не получится.
Проблема малого числа специалистов из промышленности в ВУЗах частично из этой-же области. Ну кому захочется тратить свое время и нервы в случае, когда подавляющему большинству студентов знания откровенно не нужны, а нужна лишь халява на экзамене.
Если стационарный телефон предоставляется нормальным оператором, то основное его преимущество — это надежность. По этому параметру ни один сотовый телефон даже близко не сравниться с стационарным.
У стационарного телефона не может сесть батарея. Если на АТС есть питание, то стационарный телефон работает, даже если у вас электричества уже неделю нет.
У стационарного телефона не может быть перегружена базовая станция. АТС внутри городов сейчас чаще поддерживают коммутацию всех номеров (Пример: В новогодние праздники звонки по стационарному телефону внутри города у меня проходили всегда, сотовый телефон нередко превращался в тыквуне звонящий агрегат).
Зона покрытия. Если стационарный телефон есть, значит до него протянут провод. Если есть сотовый телефон, то это ничего не значит. В районе моей работы в пределах сотни метров прямой видимости уровень сигнала скачет от 0 до максимального. Два соседних кабинета с окнами в одну сторону: В одном кабинете сотовый работает, в другом работает только как часы (время показывает).
А из личного опыта у нас в доме стационарные телефоны за 23 года не работали только по причинам частичного выгорания кабелей из-за двух пожаров. Сотовые телефоны не работают по различным причинам гораздо чаще.
Подождите!
Вы спросили "… Оба на испытательном сроке. Один выполнил задание за 1 неделю, второй задание такой же сложности и трудоемкости выполнил за 1.5 недели. З/п они получат одинаковую?", что скорее понимается как зарплата за испытательный срок, а не после испытательного срока.
В этой трактовке ответы pavelsh и yuretsz звучат вполне логично. За испытательный срок получат одинаковую зарплату, а вот после либо один будет уволен, либо другой повышен, либо что-то еще, но уже с компенсацией соответствующей реальным знаниям и опыту.
А еще у Utel после объединения с РТ сломался определитель регионов в спамилке и начал валом приходить спам от всяких метро в Ижевске, Самаре, сейчас вот пришла реклама Бинбанка в Екатеринберге и при этом во всем этом спаме телефоны не Пермские указаны. Еще всякие лотереи рекламируются, но уже с местными телефонами и короткими номерами.
А раньше только местный, Утеловский, спам приходил, но в гораздо меньшем объеме.
Да, пожалуй термин «купил» тут не подходит. Утел принадлежал Связьинвесту, который реорганизовали через Ростелеком.
Но то, что Утел до РТ работал значительно лучше это факт. В Перми, например, личный кабинет уже два месяца показывает неизвестно что, но не информацию о тарифах и балансе. Правда несколько радует сломавшийся шейпер, но его наверняка починят одним из первых…
Проблема в том, что РТ купил много лет существующую на Урале компанию Уралсвязьинформ(Utel) и началась такая свистопляска. И сколько ждать другую, нормальную, компанию неизвестно…
По 10GE получили 4310.62 Mbit/sec. Эффективность всего 43%.
Или я что-то проглядел и у них канал не 10GE был, а только сетевые карты 10GE?
Note that this means that we didn't loose a single bit on this path for the duration of the transmission!
Не путайте потери в линии связи с потерями IP-пакетов, которые не дошли.
Дамп трафика не смотрел, но события перегрузки там явно были, иначе почему эффективность такая низкая?
Если интересно, то завтра я приеду с дачи к нормальному интернету и могу проанализировать приведенные дампы.
А, ну так все-таки имеются более опытные коллеги? Это хорошо.
Интересно, только кто это без меня на моих тестовых серверах настройки крутил… Не подскажите, как это узнать? :)
А опытные коллеги естественно есть, но и у Вас наверное тоже.
Я у Вас спрашивал, решали ли Вы подобные задачи. Вы однозначно сказали что нет. Привести пример решенных задач Вы не захотели.
То есть до вас уже понемногу дошло, что сам по себе RTT уже не является проблемой для TCP. Отлично — всегда рад, когда удалось результативно ткнуть другого носом в матчасть.
Достаточно вспомнить, что задача TCP — обеспечение надежной доставки по ненадежной сети ( rfc2.ru/793.rfc ) и сразу же становится ясно, что проблема с матчастью у другой стороны, раз приходится отдельно указывать на то, что IP пакет может и не дойти.
Все ваше дальнейшее жонглирование словами является не более чем теорией, которая от практики бывает отличается. Судя по всему именно по этому Вы привели пример, который зашкаливает по своей абсурдности и чрезвычайной редкости в реальных условиях («Но если у нас прямая оптика с 10G трансиверами между двумя подключенными по 10G машинами, то потерь не будет.»).
Мораль. Учите матчасть. Без знания матчасти вас никогда не допустят до серьезных железок. И не надо спорить с профессионалами по темам, в которых вы не обладаете абсолютно никакими знаниями.
Мораль — приводите аргументы, а не слова.
А мораль номер 2 — не надо оценивать уровень по своему знанию теории. Другие люди могут не только матчасть знать, но и на практике решать подобные задачи.
Может, мне надо предоставить воспроизводимое доказательство 2+2=4? Мне очень тяжко разговаривать с человеком, который начитался давно устаревшей матчасти и не понимает текущего состояния вещей.
У меня эта «давно устаревшая матчасть» вполне себе успешно работает в двух городах. И работает благодаря знанию этой «давно устаревшей матчасти».
В результате мы опять же возвращаемся к необходимости подтверждения своих слов.
А знаете, чем отличается старое оборудование/ПО от современного? Правильно — старые свитчи давали большую задержку, а на старом ПО был низкий размер окна (в статье поправлено).
Пример про 930Мбит/с был получен на вполне себе 5-и летнем оборудовании, которое я ни при каких условиях не могу назвать новым. Только про стандартные настройки я ошибся. Буфера и максимальный размер окна там подкручены в соответствии с каналами и RTT.
А вот это уже профнепригодность.
Глобальные сети без потерь существуют? Если нет, то напомните пожалуйста, как TCP понижает скорость отправки когда обнаруживает на перегрузку? И какие из этого следуют результаты в итоговой пропускной способности.
каким образом я получил, что размера окна в 120мб хватит для полной утилизации 10G линка с RTT 100мс.
А Вы знаете для чего его хватит? Его хватит только для того, чтобы гарантировать что размер окна не станет ограничивать темп передачи данных. А это справедливо только в сетях без потерь, которых в реальной жизни на больших расстояниях не бывает. По этому в статьях про настройки окон и буферов нигде не обсуждается процент потерь пакетов (из-за перегрузки оборудования, переполнения буферов, shared-канала где то в uplink'е итд. — это не важно), а там где он учитывается там все становится не так радужно и однозначно. Появляются всякие графики красивые и не очень и делаются интересные выводы…
Вывод: если возникает задача постороения территориально распределенной сети, имеет смысл поручить это человеку, который хоть что-то знает про TCP, без обид :)
Ну то есть Вам поручать такую задачу нельзя. Как говориться без обид.
А я к сожалению нет. Да и ведущие университеты мира(из США) тоже нет. По этому, как говориться, или воспроизводимое подтверждение или признание поражения. Мне жаль, что пришлось скатиться до личностей.
Вы название хотя бы одной из этих компаний/проектов слышали раньше помимо EMC?
Про университетско-научные-суперкомпьютерные слышал. Да и о некоторых других тоже.
Имелось в виду, что падением битрейта TCP из-за RTT все пренебрегают, проблема вовсе не в этом.
Все, кто с этим не сталкивался и ровно до тех пор, пока не столкнуться.
Читаем: «Much better. And in fact now we're getting a full 1.9-2Mbps on our WAN link.», где Вы в этой статье увидели про высокоскоростные линии связи большой протяженности?
В вашей цитате английским по белому написано «LAN». На современном оборудовании получить в гигабитном LAN 300Мбит/с — это надо ОЧЕНЬ постараться. Вот прямо сейчас прогнал iperf между двумя серверами в соседних здания — 930Мбит. На одном RedHat 5, на втором openSUSE 12.1, настройки по умолчанию.
Про окна я знаю, но этот механизм с ростом скорости и RTT начинает работать только хуже. И большие окна с SACK тоже не панацея.
Я Вам привел реальный пример эффективности стандартных протоколов на междугородней линии связи, а Вы мне все про LAN рассказываете. Разница в том-же RTT на 4 порядка!
Первое печально… Жалко людей, которые не имея своего опыта ввязываются в вопросы, которыми в последнее время активно занимаются как компании, так и университеты.
А китайцы с америкосами похоже решили очередной частный случай. Частное решение для наших задач есть и у нас, а вот общего решения похоже пока не предвидится. Если оно конечно возможно :)
Кстати такого-же рода передачи сверхбольших объемов данных уже были, но между США и Европой. Те это не первое решение конкретной проблемы.
Дык и там оно не вполне соответствует действительности. Очень большое окно плюс минимальные потери плюс SACK на случай потерь = один TCP поток без проблем сможет забить 10G линк с RTT, скажем, 100мс. А сильно больше по океанской оптике и не встретить.
Вы на практике это реализовывали? Если да, то напишите пожалуйста статью, как Вам это удалось. Я серьезно.
Повторюсь — ИСКЛЮЧИТЕЛЬНО редко. Практически никогда. Единичные компании могут задействовать его для единичных потоков данных, но не более того.
Понятия не имею, что внутри этих железок для репликации, но наружу из них может торчать и FC и обычный 10GE c iSCSI и NFS с CIFS'ом.
И дело там в том, что скорость репликации падает,
А почему она падает? Не по той-ли причине, о которой мы рассуждаем? Если рассинхронизацию в 5мс по причине скорости света еще можно допустить, то ухудшение эффективности использования канала может существенно повысить время перекачивания данных.
А если из практики подключения хранилищ данных от EMC, то в случае клиента в соседней стойке, протокола NFC и канала 1GE все упирается в канал, а когда до клиента 5мс RTT, то и NFS и CIFS дают где-то 100-200-300Мбит/с даже на больших файлах (после файлов в 4Гб тестировать стало лень, так как и так все понятно).
Ну почему сразу не о серверном? Если у разработчика есть большой набор унаследованной инфраструктуры, то ситуация когда ноутбук мощнее сервера вполне себе реальна. А если дело в ОС, то WinServer 2003/2008 вполне нормально живут на ноутбуках. Я некоторое время пользовался ноутами под управлением данных операционных систем.
90+ потоков меня несколько смущают, но все-же это вполне реальный сценарий. Например файловый I/O может быть синхронным, тогда для уменьшения негативных эффектов из-за временно заблокированных на дисковых операциях процессов/потоков имеет смысл держать большой пул.
Вторым предложением Вы объяснили почему они работают по рабочим специальностям и почему им не нужно то, чего они не знают.
А хотя бы один реальный пример в реальной жизни существует? Да и сколько уйдет ресурсов на построение и оценку точности такого графа зависимостей?
Да даже гарантированы ситуации, когда интересный студенту курс будет явно или неявно требовать знаний, которые даются на неинтересном курсе. Как разрешать эту ситуацию?
Я вот в свое время думал, что мне глубокие знания мат.анализа и методов ЦОС не понадобятся, а сейчас вот несколько неуютно чувствую себя, когда знаний явно не хватает для понимания некоторых нюансов задач коллег из совместного проекта. А желание понимать есть, так как это позволит более целостно взглянуть на решаемые задачи и предлагать более эффективные методы решения для задач из моей области. Коллеги конечно консультируют в сложных вопросах, да и учебники никто не отменял, но неуютность сохраняется…
Японцы кстати тоже с этим согласны и нивы вполне покупают, как недорогие машины с очень хорошей проходимостью.
P.S. Все вышесказанное является личным мнением автора и ни в коем случае не оправдывает методы работы ВЦИОМ.
Фортран, например, очень активно используется в научных расчетах, как в России, так и за рубежом (На хабре где-то была информация, что Intel на компиляторах Fortran зарабатывает больше, чем на компиляторах С/С++).
Без понимания оптики сложно работать с серьезной фото и видеотехникой.
Дифуры — это моделирование динамических систем.
«Взгляды Аристотеля» — это классическая ошибка преподавания философии, когда на протяжении года в этот курс пихают зубрежку чужих трактатов вместо упора на развитие умения думать, анализировать и говорить у студентов (Мне повезло, у нас не было зубрежки, а был упор на семинары. Я сходу не вспомню идеи великих философов по их именам, но не смотря на это я считаю, что правильно поставленный курс философии у программистов должен быть обязательно).
Схемотехника нужна для тех, кто связан с разработкой электроники, а для программистов основы данного направления помогут понять почему частота CPU больше не растет и сколько же может пройти сигнал за 1 такт CPU.
Черчение может помочь читать и рисовать различные схемы.
Да, далеко не всем это все нужно, но как определить нужны ли данные знания до тех пор, пока они не понадобятся?
А отчислить 80% корочников и оставить желающих получать знания по понятным причинам не получится.
Проблема малого числа специалистов из промышленности в ВУЗах частично из этой-же области. Ну кому захочется тратить свое время и нервы в случае, когда подавляющему большинству студентов знания откровенно не нужны, а нужна лишь халява на экзамене.
У стационарного телефона не может сесть батарея. Если на АТС есть питание, то стационарный телефон работает, даже если у вас электричества уже неделю нет.
У стационарного телефона не может быть перегружена базовая станция. АТС внутри городов сейчас чаще поддерживают коммутацию всех номеров (Пример: В новогодние праздники звонки по стационарному телефону внутри города у меня проходили всегда, сотовый телефон нередко превращался в
тыквуне звонящий агрегат).Зона покрытия. Если стационарный телефон есть, значит до него протянут провод. Если есть сотовый телефон, то это ничего не значит. В районе моей работы в пределах сотни метров прямой видимости уровень сигнала скачет от 0 до максимального. Два соседних кабинета с окнами в одну сторону: В одном кабинете сотовый работает, в другом работает только как часы (время показывает).
А из личного опыта у нас в доме стационарные телефоны за 23 года не работали только по причинам частичного выгорания кабелей из-за двух пожаров. Сотовые телефоны не работают по различным причинам гораздо чаще.
Вы спросили "… Оба на испытательном сроке. Один выполнил задание за 1 неделю, второй задание такой же сложности и трудоемкости выполнил за 1.5 недели. З/п они получат одинаковую?", что скорее понимается как зарплата за испытательный срок, а не после испытательного срока.
В этой трактовке ответы pavelsh и yuretsz звучат вполне логично. За испытательный срок получат одинаковую зарплату, а вот после либо один будет уволен, либо другой повышен, либо что-то еще, но уже с компенсацией соответствующей реальным знаниям и опыту.
А раньше только местный, Утеловский, спам приходил, но в гораздо меньшем объеме.
Но то, что Утел до РТ работал значительно лучше это факт. В Перми, например, личный кабинет уже два месяца показывает неизвестно что, но не информацию о тарифах и балансе. Правда несколько радует сломавшийся шейпер, но его наверняка починят одним из первых…
Или я что-то проглядел и у них канал не 10GE был, а только сетевые карты 10GE?
Не путайте потери в линии связи с потерями IP-пакетов, которые не дошли.
Дамп трафика не смотрел, но события перегрузки там явно были, иначе почему эффективность такая низкая?
Если интересно, то завтра я приеду с дачи к нормальному интернету и могу проанализировать приведенные дампы.
Интересно, только кто это без меня на моих тестовых серверах настройки крутил… Не подскажите, как это узнать? :)
А опытные коллеги естественно есть, но и у Вас наверное тоже.
Я у Вас спрашивал, решали ли Вы подобные задачи. Вы однозначно сказали что нет. Привести пример решенных задач Вы не захотели.
Достаточно вспомнить, что задача TCP — обеспечение надежной доставки по ненадежной сети ( rfc2.ru/793.rfc ) и сразу же становится ясно, что проблема с матчастью у другой стороны, раз приходится отдельно указывать на то, что IP пакет может и не дойти.
Все ваше дальнейшее жонглирование словами является не более чем теорией, которая от практики бывает отличается. Судя по всему именно по этому Вы привели пример, который зашкаливает по своей абсурдности и чрезвычайной редкости в реальных условиях («Но если у нас прямая оптика с 10G трансиверами между двумя подключенными по 10G машинами, то потерь не будет.»).
Мораль — приводите аргументы, а не слова.
А мораль номер 2 — не надо оценивать уровень по своему знанию теории. Другие люди могут не только матчасть знать, но и на практике решать подобные задачи.
У меня эта «давно устаревшая матчасть» вполне себе успешно работает в двух городах. И работает благодаря знанию этой «давно устаревшей матчасти».
В результате мы опять же возвращаемся к необходимости подтверждения своих слов.
Пример про 930Мбит/с был получен на вполне себе 5-и летнем оборудовании, которое я ни при каких условиях не могу назвать новым. Только про стандартные настройки я ошибся. Буфера и максимальный размер окна там подкручены в соответствии с каналами и RTT.
Глобальные сети без потерь существуют? Если нет, то напомните пожалуйста, как TCP понижает скорость отправки когда обнаруживает на перегрузку? И какие из этого следуют результаты в итоговой пропускной способности.
А Вы знаете для чего его хватит? Его хватит только для того, чтобы гарантировать что размер окна не станет ограничивать темп передачи данных. А это справедливо только в сетях без потерь, которых в реальной жизни на больших расстояниях не бывает. По этому в статьях про настройки окон и буферов нигде не обсуждается процент потерь пакетов (из-за перегрузки оборудования, переполнения буферов, shared-канала где то в uplink'е итд. — это не важно), а там где он учитывается там все становится не так радужно и однозначно. Появляются всякие графики красивые и не очень и делаются интересные выводы…
Ну то есть Вам поручать такую задачу нельзя. Как говориться без обид.
А я к сожалению нет. Да и ведущие университеты мира(из США) тоже нет. По этому, как говориться, или воспроизводимое подтверждение или признание поражения. Мне жаль, что пришлось скатиться до личностей.
Про университетско-научные-суперкомпьютерные слышал. Да и о некоторых других тоже.
Все, кто с этим не сталкивался и ровно до тех пор, пока не столкнуться.
Читаем: «Much better. And in fact now we're getting a full 1.9-2Mbps on our WAN link.», где Вы в этой статье увидели про высокоскоростные линии связи большой протяженности?
В вашей цитате английским по белому написано «LAN». На современном оборудовании получить в гигабитном LAN 300Мбит/с — это надо ОЧЕНЬ постараться. Вот прямо сейчас прогнал iperf между двумя серверами в соседних здания — 930Мбит. На одном RedHat 5, на втором openSUSE 12.1, настройки по умолчанию.
Про окна я знаю, но этот механизм с ростом скорости и RTT начинает работать только хуже. И большие окна с SACK тоже не панацея.
Я Вам привел реальный пример эффективности стандартных протоколов на междугородней линии связи, а Вы мне все про LAN рассказываете. Разница в том-же RTT на 4 порядка!
А китайцы с америкосами похоже решили очередной частный случай. Частное решение для наших задач есть и у нас, а вот общего решения похоже пока не предвидится. Если оно конечно возможно :)
Кстати такого-же рода передачи сверхбольших объемов данных уже были, но между США и Европой. Те это не первое решение конкретной проблемы.
Вы на практике это реализовывали? Если да, то напишите пожалуйста статью, как Вам это удалось. Я серьезно.
Можно посмотреть на udt.sourceforge.net/poweredby.html и оценить на сколько единичные решения у EMC и остальных проектов по списку.
Понятия не имею, что внутри этих железок для репликации, но наружу из них может торчать и FC и обычный 10GE c iSCSI и NFS с CIFS'ом.
А почему она падает? Не по той-ли причине, о которой мы рассуждаем? Если рассинхронизацию в 5мс по причине скорости света еще можно допустить, то ухудшение эффективности использования канала может существенно повысить время перекачивания данных.
А если из практики подключения хранилищ данных от EMC, то в случае клиента в соседней стойке, протокола NFC и канала 1GE все упирается в канал, а когда до клиента 5мс RTT, то и NFS и CIFS дают где-то 100-200-300Мбит/с даже на больших файлах (после файлов в 4Гб тестировать стало лень, так как и так все понятно).