Судя по цифрам - Misalignment. В первом случае некорректное смещение начальных блоков и во время теста вместо 1 блока каждый раз читается/пишется 2 соседних.
Срочная доставка конверта с документами из Новосибирска на Камчатку.
СДЭК до использования ML: отвозит в аэропорт Новосибирска, откуда прямой рейс на Камчатку, срок доставки - 2-5 дней.
СДЭК под управлением ML: везет из Новосибирска в Красноярск, откуда нет прямого рейса и теперь не знает что делать дальше. Видимо, вручил конверт курьеру, а кожаный мешок отказывается на своей легковушке ехать с Красноярска на Камчатку. Отправлено 15.01, сегодня 26.01 и документы где-то на складе в Красноярске с неизвестной дальнейшей судьбой.
Транслировать веб-камеру: Разрешено
Видеть веб-камеры других участников: Запрещено
В такой конфигурации ученик будет видеть всех модераторов (учителей), но не будет видеть других учеников. Своя картинка у ученика отображаться будет при включенной камере.
Будет. Кодировка UTF-8, формат ASCII. Находим в интернете любой онлайн-конвертер native2ascii и получаем текст вида \u041f\u0440\u0438\u0432\u0435\u0442, EvgenySerd!
Сильно зависит от того, пользуются ли веб-камерами учителя и ученики или нет. Например, используется около 80 Мбит/с когда ~200 учеников только слышат преподавателя, задают вопросы голосом и видят презентацию и около 300 Мбит/с на вечерних родительских собраниях (где-то 50 человек в разных комнатах), когда все видят всех и у части включена камера. Увеличение трафика вызывает и демонстрация экрана вместо презентации. У нашего сервера 2 гигабитных канала от местных провайдеров, чего более чем достаточно, т.к. пользователи тоже местные, а наземный (подводный) линк в глобал с Камчатки только один.
Мне кажется, проблема тут не в процессорах, а в прерываниях и очередях на сетевой карте. Есть готовое решение для балансировки BBB — Scalelite
Greenlight мы сами не используем, это только для других школ. Сами создаем конференции BBB только в Moodle как раз из-за сквозной авторизации (учитель видит учеников по имени и фамилии).
Не поделитесь, как в zabbix получаете информацию о количестве активных пользователей?
Jitsi стримит 720p в 3 потока: 720p, 360p и 180p. Остальные клиенты выбирают из этих трех исходя из своих возможностей. Качество звука в Jitsi мне не понравилось вообще. Лучший звук из всех протестированных решений был в MCU Vinteo (вроде кодек opus). Там отчетливо была слышна разница между USB-микрофонами разной ценовой категории.
Про звук и презентацию в онлайн-обучении согласен. Учителя сами к этому пришли, картинка нужна только младшим классам и специфическим предметам типа иностранных языков. Видео учеников отчасти позволяет контролировать заинтересованность, но намного эффективнее давать простой тест в Moodle сразу по окончании урока, чем весь урок вглядываться в лица учеников.
Да, правильней менять права с запретом на исполнение.
Что касается записи в директорию, то при обновлении тем/плагинов он заменяет файлы и ему нужны права на запись существующих файлов.
В моем случае CPU это старенький Xeon X5650 (2,6 ГГц), поэтому при 4 vCPU постоянная загруженность была более 80%. Два ядра привели бы к явным тормозам. Администрирование — Отчеты — Тест производительности у меня показывает 80 баллов даже когда на портале более 200 пользователей (чем меньше баллов, тем лучше). Что касается ОЗУ, то 4 ГБ явно мало, сейчас используется около 12ГБ, СУБД разрешено активно использовать память.
Надо включить в конфиге сервера «пользователь заходит заблокированным» (это описано в статье), а на пользователей со статусом «заблокирован» распространяются настройки раздела «Управление пользователями» — «Заблокировать участников». Ставим «Видеть вэб-камеры других участников» в «Заблокировано» и камеры пользователей видит только модератор. Каждого пользователя отдельно можно разблокировать и назначать ведущим. В обоих случаях его камеру увидят другие участники.
Да, именно BigBlueButtonBN использовался для интеграции BBB в Moodle.
В конце марта во время тестирования просили учителей включить всем веб-камеры. На трафике 250 мбит/с нагрузка на 2xXeon X5650 была не более 20%. К сожалению, в BBB нет инструментов сервера, которые позволили бы видеть количество подключившихся. В апреле в среднем на сервере работало 200-250 учеников одновременно, нагрузка на процессор не превышала 15%.
С аудио и видео BBB работает в режиме прокси, каждый поток аудио и видео просто рассылается всем клиентам. Это накладывает ограничение на количество одновременно включенных камер. Никакого Simulcast в нем нет, если каждый из 20 участников транслирует 500 кбит/с поток с камеры и в настройках комнаты всем разрешено видеть всех (например, родительское собрание), то в каждого клиента летит 19 видеопотоков по 500 кбит/с, которые клиентское устройство должно декодировать и показать пользователю.
В плане трансляции видео от каждого ученика интересней Zoom и Jitsi, которые поддерживают Simulcast. Каждый клиент транслирует на сервер видео минимум в 2 потока: например, основной в 500 кбит/с и дополнительный в 128 кбит/с, а на стороне клиента уже выбирается с какого именно потока воспроизводить видео в зависимости от места в раскладке на экране. Это значительно снижает требования к мощности клиентских устройств.
В BBB мы в основном пользовались режимом в котором все видят модератора (учителя), модератор видит всех, а друг друга ученики не видят, чтобы не нагружать устройства учеников.
Судя по цифрам - Misalignment. В первом случае некорректное смещение начальных блоков и во время теста вместо 1 блока каждый раз читается/пишется 2 соседних.
Срочная доставка конверта с документами из Новосибирска на Камчатку.
СДЭК до использования ML: отвозит в аэропорт Новосибирска, откуда прямой рейс на Камчатку, срок доставки - 2-5 дней.
СДЭК под управлением ML: везет из Новосибирска в Красноярск, откуда нет прямого рейса и теперь не знает что делать дальше. Видимо, вручил конверт курьеру, а кожаный мешок отказывается на своей легковушке ехать с Красноярска на Камчатку. Отправлено 15.01, сегодня 26.01 и документы где-то на складе в Красноярске с неизвестной дальнейшей судьбой.
Hyper-threading — это технология компании Intel.
У AMD многопоточность называется Simultaneous Multithreading (SMT)
А можно сделать такой же тест, но в vdbench и с включенной компрессией, дедупликацией и кэшем?
Видеть веб-камеры других участников: Запрещено
В такой конфигурации ученик будет видеть всех модераторов (учителей), но не будет видеть других учеников. Своя картинка у ученика отображаться будет при включенной камере.
\u041f\u0440\u0438\u0432\u0435\u0442, EvgenySerd!Greenlight мы сами не используем, это только для других школ. Сами создаем конференции BBB только в Moodle как раз из-за сквозной авторизации (учитель видит учеников по имени и фамилии).
Не поделитесь, как в zabbix получаете информацию о количестве активных пользователей?
Про звук и презентацию в онлайн-обучении согласен. Учителя сами к этому пришли, картинка нужна только младшим классам и специфическим предметам типа иностранных языков. Видео учеников отчасти позволяет контролировать заинтересованность, но намного эффективнее давать простой тест в Moodle сразу по окончании урока, чем весь урок вглядываться в лица учеников.
Что касается записи в директорию, то при обновлении тем/плагинов он заменяет файлы и ему нужны права на запись существующих файлов.
Да, именно BigBlueButtonBN использовался для интеграции BBB в Moodle.
В конце марта во время тестирования просили учителей включить всем веб-камеры. На трафике 250 мбит/с нагрузка на 2xXeon X5650 была не более 20%. К сожалению, в BBB нет инструментов сервера, которые позволили бы видеть количество подключившихся. В апреле в среднем на сервере работало 200-250 учеников одновременно, нагрузка на процессор не превышала 15%.
С аудио и видео BBB работает в режиме прокси, каждый поток аудио и видео просто рассылается всем клиентам. Это накладывает ограничение на количество одновременно включенных камер. Никакого Simulcast в нем нет, если каждый из 20 участников транслирует 500 кбит/с поток с камеры и в настройках комнаты всем разрешено видеть всех (например, родительское собрание), то в каждого клиента летит 19 видеопотоков по 500 кбит/с, которые клиентское устройство должно декодировать и показать пользователю.
В плане трансляции видео от каждого ученика интересней Zoom и Jitsi, которые поддерживают Simulcast. Каждый клиент транслирует на сервер видео минимум в 2 потока: например, основной в 500 кбит/с и дополнительный в 128 кбит/с, а на стороне клиента уже выбирается с какого именно потока воспроизводить видео в зависимости от места в раскладке на экране. Это значительно снижает требования к мощности клиентских устройств.
В BBB мы в основном пользовались режимом в котором все видят модератора (учителя), модератор видит всех, а друг друга ученики не видят, чтобы не нагружать устройства учеников.
Мы использовали только HTML5 клиент, он был включен принудительно в настройках (attendeesJoinViaHTML5Client=true,
moderatorsJoinViaHTML5Client=true).