Page 4 of 14
Re: KolibriOS на производстве
Posted: Sun Dec 23, 2007 12:33 pm
by ДедОк
Нормально тестят...
Между прочим, пока эта птичка взувает Винду по полной...
Контора обычная, занимается разработкой и внедрением систем АСУ ТП а тетим, частично у себя, частично на полигоне одного предприятия...
Re: KolibriOS на производстве
Posted: Sun Dec 23, 2007 2:52 pm
by Ghost
А количество процессов/потоков в винде было такое же как в Колибри?
Re: KolibriOS на производстве
Posted: Sun Dec 23, 2007 9:59 pm
by ДедОк
Да... всё жрущее, сканирующее, вынюхивающее, звучащее, и.т.п. было предварительно удалено из автозагрузки, потом комп был перезагружен...
Re: KolibriOS на производстве
Posted: Mon Dec 24, 2007 7:21 pm
by SHREDER
Как вам такой тест. Компилируется 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 получателя.
Re: KolibriOS на производстве
Posted: Mon Dec 24, 2007 10:41 pm
by Gluk
"Ну и посмотрите реакцию сетевого стека на DoS атаки" - повторяю свой вопрос, где в Колибри работающий сетевой стэк?
Re: KolibriOS на производстве
Posted: Tue Dec 25, 2007 11:59 am
by Heavyiron
Gluk, повторяю ответ
- на некоторых компах стек работает.
Re: KolibriOS на производстве
Posted: Tue Dec 25, 2007 6:31 pm
by Gluk
а какие претензии могут быть к стэку которого практически нет? 0_о
Re: KolibriOS на производстве
Posted: Tue Dec 25, 2007 6:51 pm
by Veliant
Это почему нет? на 05** вполне прилично он работал
Re: KolibriOS на производстве
Posted: Tue Dec 25, 2007 8:20 pm
by Gluk
"Это почему нет? на 05** вполне прилично он работал" - потому что сейчас - 07**
Re: KolibriOS на производстве
Posted: Wed Dec 26, 2007 12:26 am
by ДедОк
ну, ..
1. Мы решили не проводить сравнительные тесты, на языках более высокого уровня, чем Ассемблер, поскольку это может приводить к искажённым результатам, посльку это ещё будет и борьба компиляторов...
2. Мы пока будем пользоваться портом RS232, и MODBUS протоколом, и вопрос DoS атак пока не актуален...
к моменту перехода на ТСР, надеюсь, ситуация с сеткой у Колибри улучшится...
Re: KolibriOS на производстве
Posted: Thu Dec 27, 2007 4:24 pm
by Gluk
""У меня она правда падает очень часто" - где отчеты о падениях? или ты не желаешь чтобы ситуация была изменена и потому утаиваешь причины падения?" - ответа не последовало, за сим предполагаю что ось у товарища Шредера не падала более пары раз, и то по его вине, след. состоятельность аргумента "падучести" ставится под сомнение..
Re: KolibriOS на производстве
Posted: Sun Dec 30, 2007 1:54 am
by ДедОк
есть результаты тестов на энергопотребление, и устойчивость к сбоям по питанию
энегопотребление Колибри в целом в 2.13 раза ниже чем у Виндовс, выбросы тока потребления (пики) в 3.5 раза ниже! В результате сбои в программном обеспечении у Виндовс наступают при понижении напряжения питания на 21% а Колибри держит ещё вплоть до 35%!, также перерывы в электропитании приводящие к гибели системы,у Колибри в 1,37 раза больше (зависит от запущеных приложений) Наши программисты очень довольны результатами этих и предыдущих испытаний, и будут рекомендовать начать исследования пригодности Колибри для создания SCADA систем на программном уровне...
Re: KolibriOS на производстве
Posted: Sun Dec 30, 2007 3:59 pm
by Ghost
Интересно услышать мысли как такое получается (про устойчивость к падению и скачкам напряжения), и был ли эксперимент идеальным (одна и таже система? или две одинаковые по параметрам....)?
Re: KolibriOS на производстве
Posted: Mon Dec 31, 2007 2:31 am
by ДедОк
Ghost
Ну, тестим на специальном компе с управляемым БП... Система каждый раз после сбоя заливается с резервного носителя.(DVD), для Колибри - дискета...
причиной такой разницы, является то, что Колибри гораздо меньше потребляет энергии в целом, при работе с приложениями, а также, из за того, что её ядро проще, не содержит модулей анализа кода, загружает куда меньшее количество информации в процессе работы... это приводит к пониженному энергопотреблению, и значительно меньшим выбросам потребляемого тока. Проводник никогда не бывает идеальным, высокое потребление тока вызывает просадки напряжения что при пониженном питании приводит к понижению напряжения ниже порога переключения затворов транзисторов процессора... а это крах системы, особенно если она сама себя постоянно вылизывает, и анализирует...
В Коос это чаще приводит к ошибкам или зависанию отдельных активных процессов, которые как правило спокойно убиваются после восстановления питания. Винда умирает сразу, и наглухо...
но в обоих случаях это защитывалось сбоем...
Кстати от одного автономщика: этой оси на автономных системах цены нет! Батареи автономных систем прежде всего изнашиваются из-за выбросов тока(это своего рода КЗ, приводящее к усиленному износу батареи), кроме того, система позволяет разряжать батарею куда более глубоко, а это очень важный фактор для правильной жизни батарей. По общим подсчётам время автономного питания систем с Коос в качестве оси можно было бы увеличить почти в 3 раза! при этом сам срок службы батареи увеличился бы почти в 2 раза! делайте выводы, Господа...
Re: KolibriOS на производстве
Posted: Fri Jan 11, 2008 11:36 pm
by SHREDER
Ну конечно система ядро которой почти ничего не делает (посравнению с мастодонтами UNIX, Win32) не так загружает процессор и энергопотребление меньше. Но если запустить некий ресурсоемкий пользовательский софт я думаю все эти приимущества тут же улитучатся. Вообще ядро надо как-то усилить хотя бы минимальными проверками целостности и т.п. Только не асме это делать лет 5 минимум.