KolibriOS на производстве

Sun Dec 23, 2007 12:33 pm

Нормально тестят...

Между прочим, пока эта птичка взувает Винду по полной...

Контора обычная, занимается разработкой и внедрением систем АСУ ТП а тетим, частично у себя, частично на полигоне одного предприятия...

Sun Dec 23, 2007 2:52 pm

А количество процессов/потоков в винде было такое же как в Колибри?

Sun Dec 23, 2007 9:59 pm

Да... всё жрущее, сканирующее, вынюхивающее, звучащее, и.т.п. было предварительно удалено из автозагрузки, потом комп был перезагружен...

Mon Dec 24, 2007 7:21 pm

Как вам такой тест. Компилируется c tinyc

Code: Select all

#include <stdlib.h>
#include <stdio.h>
#include <malloc.h>

int compare(const void *arg1,const void *arg2);

int main()
{
	long double *array = (long double*)malloc(0xFFFFFF);

	for(int i=0; i<(0xFFFFFF/sizeof(long double)); i++)
	{
	    array[i] = ((long double)rand()*12)/0xFFFFFF;
	}

    qsort(array,0,0xFFFFFF,compare);

	return 0;
}

int compare(const void *arg1,const void *arg2)
{
   long double a = *((long double*)arg1);
   long double b = *((long double*)arg2);
   return a > b;
}

Тест на эффективность работы с памятью, скорее - тест на производительность аппаратуры. По сути это кусок кода (немного обрезанный и упрощенный) из программы занимающейся статистическими испытаниями. В виду отсутвия механизма свопинга и С++ компилятора полный текст с С++ не привожу.

Ну и посмотрите реакцию сетевого стека на DoS атаки. Например - типичный пример флуд атаки - подмену IP адреса отправителя пакета на IP получателя.

Mon Dec 24, 2007 10:41 pm

"Ну и посмотрите реакцию сетевого стека на DoS атаки" - повторяю свой вопрос, где в Колибри работающий сетевой стэк?

Tue Dec 25, 2007 11:59 am

Gluk, повторяю ответ

- на некоторых компах стек работает.

Tue Dec 25, 2007 6:31 pm

а какие претензии могут быть к стэку которого практически нет? 0_о

Tue Dec 25, 2007 6:51 pm

Это почему нет? на 05** вполне прилично он работал

Tue Dec 25, 2007 8:20 pm

"Это почему нет? на 05** вполне прилично он работал" - потому что сейчас - 07**

Wed Dec 26, 2007 12:26 am

ну, ..
1. Мы решили не проводить сравнительные тесты, на языках более высокого уровня, чем Ассемблер, поскольку это может приводить к искажённым результатам, посльку это ещё будет и борьба компиляторов...
2. Мы пока будем пользоваться портом RS232, и MODBUS протоколом, и вопрос DoS атак пока не актуален...

к моменту перехода на ТСР, надеюсь, ситуация с сеткой у Колибри улучшится...

Thu Dec 27, 2007 4:24 pm

""У меня она правда падает очень часто" - где отчеты о падениях? или ты не желаешь чтобы ситуация была изменена и потому утаиваешь причины падения?" - ответа не последовало, за сим предполагаю что ось у товарища Шредера не падала более пары раз, и то по его вине, след. состоятельность аргумента "падучести" ставится под сомнение..

Sun Dec 30, 2007 1:54 am

есть результаты тестов на энергопотребление, и устойчивость к сбоям по питанию
энегопотребление Колибри в целом в 2.13 раза ниже чем у Виндовс, выбросы тока потребления (пики) в 3.5 раза ниже! В результате сбои в программном обеспечении у Виндовс наступают при понижении напряжения питания на 21% а Колибри держит ещё вплоть до 35%!, также перерывы в электропитании приводящие к гибели системы,у Колибри в 1,37 раза больше (зависит от запущеных приложений) Наши программисты очень довольны результатами этих и предыдущих испытаний, и будут рекомендовать начать исследования пригодности Колибри для создания SCADA систем на программном уровне...

Sun Dec 30, 2007 3:59 pm

Интересно услышать мысли как такое получается (про устойчивость к падению и скачкам напряжения), и был ли эксперимент идеальным (одна и таже система? или две одинаковые по параметрам....)?

Mon Dec 31, 2007 2:31 am

Ghost
Ну, тестим на специальном компе с управляемым БП... Система каждый раз после сбоя заливается с резервного носителя.(DVD), для Колибри - дискета...

причиной такой разницы, является то, что Колибри гораздо меньше потребляет энергии в целом, при работе с приложениями, а также, из за того, что её ядро проще, не содержит модулей анализа кода, загружает куда меньшее количество информации в процессе работы... это приводит к пониженному энергопотреблению, и значительно меньшим выбросам потребляемого тока. Проводник никогда не бывает идеальным, высокое потребление тока вызывает просадки напряжения что при пониженном питании приводит к понижению напряжения ниже порога переключения затворов транзисторов процессора... а это крах системы, особенно если она сама себя постоянно вылизывает, и анализирует...

В Коос это чаще приводит к ошибкам или зависанию отдельных активных процессов, которые как правило спокойно убиваются после восстановления питания. Винда умирает сразу, и наглухо...

но в обоих случаях это защитывалось сбоем...

Кстати от одного автономщика: этой оси на автономных системах цены нет! Батареи автономных систем прежде всего изнашиваются из-за выбросов тока(это своего рода КЗ, приводящее к усиленному износу батареи), кроме того, система позволяет разряжать батарею куда более глубоко, а это очень важный фактор для правильной жизни батарей. По общим подсчётам время автономного питания систем с Коос в качестве оси можно было бы увеличить почти в 3 раза! при этом сам срок службы батареи увеличился бы почти в 2 раза! делайте выводы, Господа...

Fri Jan 11, 2008 11:36 pm

Ну конечно система ядро которой почти ничего не делает (посравнению с мастодонтами UNIX, Win32) не так загружает процессор и энергопотребление меньше. Но если запустить некий ресурсоемкий пользовательский софт я думаю все эти приимущества тут же улитучатся. Вообще ядро надо как-то усилить хотя бы минимальными проверками целостности и т.п. Только не асме это делать лет 5 минимум.

KolibriOS на производстве

Who is online