My Shiny Weblog!

За да реализираме една SCADA система, най-напред трябва да помислим за комуникацията с различни видове PLC. На пазара за контролери се срещат най-различни производители, предлагащи уреди с най-различни характеристики и десетки комуникационни протоколи. В почти всички случаи данните, които трябва да четем от контролера са малко по обем, в сравнение с паметта на съвременните компютри. Традиционно комуникацията с контролерите е трудна, понеже те могат да бъдат разпръснати на голяма територия. Този проблем е довел до използването през годините на най-различни комуникационни протоколи и преносни среди – голяма част от които изглеждат доста глупаво от съвременна гледна точка. Но тъй като в повечето случаи става дума за производствени процеси – на никой не му и минава през ума да променя каквото и да било. Тоест, принудени сме да работим при тези условия. Когато започнем работа, всякакви предположения за марката контролер и комуникационния протокол, след време ще се окажат неверни (по законите на Мърфи). Можем да се сблъскаме с всичко – от 9600 bps RS232 връзка, с ASCII протокол, до ISO върху Industrial Ethernet. Често пъти библиотеките за комуникация с контролерите не са с отворен код (за щастие при мен случая не е този). Можем да се надяваме, че те предлагат някакъв C интерфейс, който ние да ползваме от някакъв външна програма. Една от първите ни задачи е да реализираме универсален интерфейс към контролерите, който да ни позволява да четем и пишем в тях, без значение каква марка са и какъв протокол използват. Лично аз, дълго време живеех с убеждението, че е най-добре просто да използвам асинхронна комуникация с event loop. Това щеше да работи, ако “драйверите” за различните видове контролери се държаха добре и не променяха настройките на подаваните им файлови дескриптори. За съжаление, това е прекалено оптимистично предположение. Повечето контролери са ужасно бавни, в сравнение със съвременните процесори. Данните могат да се точат “дълго време”, а буферирането в ядрото може да забави получаването им от програмата. Понеже комуникацията се очаква да бъде в “реално време”, а реализацията на различните специфични протоколи върху TCP/IP например, е сложна – можем да очакваме, че голяма част от тези драйвери ползват блокираща, синхронна комуникация. Очевидно блокирането на event loop при отпадане на контролер не е добра идея (особено ако работим със стотици контролери). След обстоен анализ на ситуацията и кратка справка с някои исторически системи, аз се спрях на Reactor pattern за решаване на този проблем. Тъй като искаме да пишем на Ruby, нашата Reactor pattern реализация е EventMachine. За да я ползваме, трябва да напишем Ruby bindings за драйверите на контролерите. Това е доста досадна и неблагодарна работа, но за щастие разполагаме с Extending Ruby главата от Programming Ruby. След няколко дни писане имаме работещи Test::Unit::TestCase(s), които събират данни от контролерите. Как обаче да използваме нашия binding с EventMachine? В общия случай имаме клас PLC, в който има един гаден метод, например fetch, реализиран на C, който може да блокира. EventMachine ни дава метод defer, той приема два аргумента – процедури. Първата процедура е блокираща, тя се изпълнява на отделен thread в реактора, а втората е callback – извиква се с резултата от изпълниение на първата процедура (изпълнява се извън реактора). EventMachine ни дава възможност да работим с нишки индиректно, като по този начин си спестяваме всичките проблеми свързани с директното им използване. Ето една примерна конструкция с defer:

require 'rubygems'
require 'eventmachine'

# Контролер
class PLC

   # Голям, блокиращ C метод
   def fetch
      "result"
   end

end

plc = PLC.new

EM.run do

   # Тази процедура ще изпълняваме в реактора, на отделна нишка
   # Ако всичко е наред, ще четем през една секунда паметта на контролера
   op = proc { sleep 1; plc.fetch }

   # Тук обработваме резултата, и пускаме следващата операция за четене
   cb = proc { |result| puts result; EM.defer(op, cb) }

   # Пускаме първата операция
   EM.defer(op, cb)

end

Естествено, за да работи всичко това, блокиращата операция трябва да има разумен timeout. Той зависи силно от вида контролер, комуникационния протокол и наблюдавания производствен процес. При мен този timeout е от порядъка на 5 секунди. Тъй като EventMachine е реализиран на C/C++, нашия драйвер за контролера също е писан на C, можем да очакваме, че закъсненията от използването на Ruby – динамичен език от високо ниво, са минимални. Гаранции за това обаче няма, много е важно всички компоненти да бъдат тествани много подробно, преди да бъдат пуснати в експлоатация. Официално, системата която аз разработвам се пише на Ruby, но реално зад всеки един ред код на Ruby стоят между 10 и 100 реда код на C. За съжаление, това в случая е неизбежно. Прочетените от контролерите данни отразяват състоянието на реалните обекти, които участват в производствения процес. Връзката между обекти и контролери е основополагаща за всички подобни системи – важно е да имаме максимално гъвкави методи за описание на тази връзка. За целта използваме DSL, който лесно може да бъде реализиран на Ruby. След като имаме добре дефинирани обекти, техните състояния и събитията, които водят до промяната им, можем да започнем да мислим за визуализацията им. За подобна система, би било много глупаво да не използваме Web-базирана технология. Тъй като изображенията на обектите са инженерни чертежи, които трябва да бъдат скалируеми, не можем да ползваме нищо друго, освен SVG. Във всяко едно SVG изображение има определено количество графични обекти. Всеки графичен обект може да бъде в едно от няколко изброени състояния, което се променя във времето. За да визуализираме графиката използваме WebKit прозорец. Този прозорец се създава с помощта на QtRuby, като за целта (леко) се променя WebKit конфигурацията. За да следим измененията на състоянията на обектите във времето трябва да използваме, някакъв вид асинхронна комуникация с WebKit. Тъй като събитията се случват на сървъра, използването на XMLHttpRequest заявки (по-известни като AJAX) не е достатъчно. Клиентът няма как да знае кога дадено събитие се е случило, за да пусне заявката. Разбира се, можем да ползва polling, но е далеч по-елегантно комуникацията да бъде асинхронна. Това което ни трябва е известно, като Reverse AJAX, HTTP Server Push или Comet). За да реализираме каквото и да било Web-приложение, трябва да имаме HTTP сървър. Естествено, той може да бъде нещо съвсем отделно и външно за системата, но тъй като така или иначе, ние имаме работещ EventMachine event loop, че даже и реактор, за комуникация с контролерите – ориентираме се към търсене на EventMachine-базиран HTTP сървър. Както може да се очаква, някой преди нас е написал такъв, казва се Thin. Можем ли да използваме Thin и EventMachine за Comet комуникация с WebKit? Върху този върпос е размишлявал и автора на Thin. Той е написал един Ruby gem, който се казва Pusher и върши точно това което ни трябва. Благодарение на тези технологии, можем да обединим функционалността на HTTP сървъра, Comet сървъра, и модула за комуникация с контролерите. Разбира се, това е просто възможност за интеграция, в някои случаи не е разумно да се прави. Възможно е да “сглобяваме” SVG документите динамично, при всички случаи е трябва да имаме някакво Web приложение на сървъра, което да обслужва заявики към различни URL адреси. Най-удобно за целта можем да използваме Sinatra, или още по-добре Async Sinatra. Вече можем да доставяме SVG документите до клиентите, и да правим асинхронен “push” на съобщения към тях. Това което ще им изпращаме може да бъде XML или JSON съобщение (всъщност може да е всичко). Но най-ефективно от страна на браузера се обработват JSON съобщения, понеже те са просто сериализирани JavaScript обекти. При получаване на JSON съобщение, някакъв JavaScript в браузера трябва да намира елемента от документа, към който се отнася съобщението и да сменя някакви негови атрибути (или да го заменя с друг елемент). В HTML документите тези неща стават много лесно, благодарение на DOM стандарта, както и популярните JavaScript библиотеки от сорта на Prototype, Dojo и т.н., които го разширяват. Тези библиотеки не са много наясно с SVG и различните негови елементи, които могат да се срещнат в документа. Спасението в този случай беше библиотеката Raphaël, тя разширява DOM за SVG документи.

Мисля, че преди време Кнут беше казал, че съвременното програмиране все повече прилича на сглобяване на пъзел. В работата си по този проект, отделих адски много време за проучване на различни, вече реализирани библиотеки и технологии и много малко време за същинско писане на код. Но това не е задължително да бъде лошо.

Заради абсурдните аргументи на криворазбраната екология и фалшивата статистика, светът е на път да изгуби едно от най-великите си открития – крушката на Едисън. В няколко магазина ми обясняват, как тези крушки вече нямало да се произвеждат и за това трябвало да си купя други. От така наречените “енергоспестяващи”, които били по-добри от старите във всяко едно отношение. И така, решихме да си сменим старите с нови, на няколкото места в апартамента, където се ползваха класически крушки. Проблемите не закъсняха:

• Нови осветителни тела – Енергоспестяващите крушки имат различна форма от старите, в най-общия случай са по-големи. За това е твърде възможно да се наложи смяна на перфектно работещо, старо осветителното тяло. Като правило в електротехниката, всички нови продукти са по-скъпи и с по-ниско качество от старите. Попаднах на осветително тяло за баня, чиято изолация против влага представлява силиконова лентичка с дебелина един милиметър. Въпросната лентичка ми падна на главата докато монтирах тялото. Естествено вероятността да ни убие тока в банята нараства многократно без тази лентичка. Цената на крушката и въпросното “осветително тяло” въобще не искам да коментирам. Монтажа е труден поради меката пластмаса, нискокачествените дюбели и “гениалното” откритие на съвременната инженерна мисъл – винтове в пластмаса.

• На тъмно в тоалетната – Енергоспестяващите крушки започват да светят с пълната си сила минута-две след запалването си. Понеже обикновено си върша работата в тоалетната точно за една-две минути, лампата започва да свети силно веднага след като изляза от тоалетната и тръгна да я гася. Това ме принуждава или да държа лампата светната, или…да пикая на тъмно. Понеже предпочитам първия вариант, новата крушка се превръща от енергоспестяваща, в енергоразхищаваща – със старата бих плащал по-малка сметка за ток.

• Мигане – Енергоспестяващата крушка в кухнята мига. Поне трима експерти в електротехниката не можаха да отговорят на въпроса, защо крушката в кухнята мига. Понеже тя е с два ключа, предполагаше се, че по някакъв начин веригата се затваря за кратко през самата крушка и глимките на ключовете. Лампата тръгва да светка, и веднага след това гасне заради нищожния ток, който минава през глимките. Резултатът е мигане. Тази теория пропадна – след махането на глимките лампата все още мига. В момента разработвам теории свързани с военните, Wi-Fi/GSM мрежи и извънземни. Естествено подобен проблем е невъзможен с обикновена крушка.

• Цветове – Енергоспестяващите крушки се продават с най-различни и необичайни цветове. Нормалните хора обикновено си купуват крушки, които светят в някакъв вид “топло бяло”. Новите крушки могат и да докарат някакъв вид “топло бяло”, но цвета им е силно зависим от възрастта, времето на светене и това преди колко време са запалени.

• Издържливост – Енергоспестяващите крушки се рекламират като издържливи, опаковката им е покрита с различни видове проценти, неясно от къде взети. Изваждайки крушката от кутията забелязах, че пише да не се пипа с пръсти. Очевидно пипането с пръсти и намалява живота. Естествено пипането с пръсти не единственото нещо, което може да нацапа една осветителна крушка. Много се съмнявам, че тази крушка, която не издържа на пипане с пръсти би издържала налепените по нея насекоми, влезнали през евтиното, китайско, нехереметично осветително тяло, за период от 5 години. Най-старата енергоспестяваща крушка вкъщи издържа 1 година, от рекламирани на опаковката 5 години.

И така, крайната цел на тази “велика технология”, дълги години раздухвана и раздувана от различни видове “зелени”, е да се вземат парите на крайния потребител. Тези крушки няма да направят живота ни по-евтин, нито по-лесен, нито по-добър – за по-екологичен да не говорим.

Как да симулирам Siemens Simatic S7 контролер? На този въпрос се опитвах да си отговоря от известно време, без да имам опит в областта на PLC контролерите. Трябваше ми нещо много просто, един TCP порт, на който да чета паметта на контролера през определено време. Понеже документацията по темата ми се стори малко и лоша, ето как става.

• Намираме, изтегляме и инсталираме Siemens Step7 Professional 5.4 на компютър с Windows XP Professional (не работи с Home Edition). Има го в Emule.
• Изтегляме и инсталираме NetToPLCSim на същия компютър.
• Стартираме SIMATIC Manager и отваряме примерния проект PROJECT-ETHERNET_en.
• Избираме SIMATIC 400(1)
• Цъкаме на иконката Simulation On/Off.
• Избираме Select CPU access mode.
• Избираме примерния проект за Entry point.
• Избираме Ethernet модула на първия контролер (SIMATIC 400(1)) и OK.
• Включваме контролера (местим човката от STOP на RUN в CPU прозореца).
• Стартираме NetToPLCSim.exe.
• Натискаме Start за да тръгне сървъра (ако дава грешка – убиваме Step7 процеса, който слуша на TCP port 102).
• Теглим и компилираме Libnodave на UNIX компютър.
• Изпълняваме testISO_TCP, като за параметър подаваме IP адреса на Windows компютъра.

Ако всичко е наред, нулите от паметта на контролера ще се визуализират в прозореца на NetToPLCSim, както и в UNIX терминала. С помощта на Libnodave можем да разработваме програми, които наблюдават/управляват мрежи от Simatic контролери без да използваме софтуер на Siemens. А описаната тук технология ни позволява да тестваме такива програми, без да имаме хардуер на Siemens.

Не обичам да изхвърлям работещи компютри. Всъщност и неработещи не обичам да изхвърлям. Дори не знам дали има някакъв начин човек да изхвърли правилно стар компютър в българия – казано по друг начин – да го рециклира. Всичките ми неработещи части са събрани в кашони и от години пълнят мазета и тавани. С работещите историята е подобна. Докато разчиствахме къщата в Мездра попаднах на двата ми стари сървъра, които от 2-3 години стоят там и събират прах и паяжини. Спомних си, че те всъщност когато ги складирах там, те си работеха, при това си работеха нормално. Единия е HP NetServer e45, а другия HP Vectra VL6.

По-интересен е първия, той е произведен през 1995 година, има Pentium II 266Mhz процесор, 64Mb EDO RAM с ECC (4 памети по 8Mb) и AT дъно/захранване. Бил съм я оставил с някакъв 6.4Gb Seagate хард диск, има си и някакъв CD-ROM. Много се изненадах онзи ден, когато тази машина проработи. От чиста спортна злоба реших да я изпробвам. Пуснах прахосмукачката, отворих кутията и изчистих всички паяжини, хлебарки и мухи отвътре и отвън. Включих монитор и клавиатура и натиснах копчето. Вентилаторите забръмчаха и монитора запали, BIOS-а се оплака, че не си помни датата. Съдейки по количеството излезнали боклуци отвътре реших, че няма шанс да работи и го оставих така. Мамка му, тръгна. Излезе OpenBSD boot loader и започна да зарежда ядрото, с един характерен звук. Спомних си, че този Seagate е един от най-шумните дискове, които някога съм имал, за това го бях ръгнал на тази машина. Явно освен, че е шумен, е издържлив. След като зареди ядото тръгна да маунтва файлова система, но се усети, че има проблем – BIOS-а твърди, че 1995 година, а файловата система е от 2007, значи явно е поне 2007, сложи някаква измислена дата през 2007 и тръгна. Това ме изненада и продължих да го бъзикам. Извадих си оригиналните дискове с OpenBSD 4.4 и тръгнах да го инсталирам. Бях сигурен, че няма начин този CD-ROM да работи. И пак сгреших. Това е един изключително стар CD-ROM, който в никой случай не е повече от 4 скоростен. Още преди да “изхвърля” машината го бях отписал, защото много трудно четеше дискове. Има една подробност обаче – дисковете, които четеше трудно бяха записвани на CD-R. Дисковете, с които го пробвах сега бяха печатани на машина. За пореден път се убеждавам, че няма лош CD-ROM – има лоши дискове. Една от многото причини да ползвам OpenBSD е тази – човек може да го инсталира на всякаква машина, без никаква подготовка и за не повече от 10 минути. Независимо от OpenBSD версията и независимо от годините на машината. Паснаха си като дупе и гащи, ядрото съвсем спокойно може да работи в 6-8 мегабайта памет. Останалата е свободна, при зареждане на няколко необходими демона, използваната памет отива до към 32, което е половината. С прости кръчмарски сметки се вижда, че при един нормален pf.conf тази машина може да бъде чудесен рутер. Има 4 PCI слота, което значи 4 мрежови карти. С мрежовите карти естествено си има тънкости, човек не може да ръгне четири RTL8139 и да очаква машината да работи. Трябват хубави LAN карти, които да не товарят процесора. Май най-доброто в това отношение е 3com 905, с цел да кърпя един друг рутер си бях купил 5 такива от ebay за 10$. Освен, че драйвера им спестява mbuf копиране, имат хардуерно смятане на ip, tcp, udp контролните суми. Сигурен съм, че с такива карти работи добре. Чудя се обаче дали може да издържи една PCI 802.11a/b/g карта. Мисля да го изпробвам и да го ползвам като AP. Реално погледнато, на тази машина няма какво да й се счупи. Проблем може да се появи от три места – хард диск, кондензатори, захранване. Хард диска мога винаги да го разкарам и да сложа един DOM. Умните хора от HP преди 14 години са сетили, че кондензаторите на дънната платка биха могли да създадат проблеми. По тази причина, те са изведени на отделна платка, която се включва в дънната платка близо до процесора. По този начин на дъното няма нито един кондензатор. Ако машината стане нестабилна или кондензаторите се подуят, човек може да я смени с нова или просто да хване поялника и да смени кондензаторите, безопасно, без да скапе машината. Естествено същото може да се направи и със захранването. Този компютър може да работи и още 14 години, направен е както трябва, на пук на капитализма, финансовата криза и “зелените”.

Другата машина също тръгна, но тя е на Pentium II 333Mhz с 256Mb PC133 SDRAM произведен 1998 година. На пръв поглед много си приличат, но тук вече някои неща са икономисани и кондензаторите са си разхвърляни по дъното. Има USB, интересно дали мога да я науча да зарежда от USB mass storage. За разлика от новите компютри и тук нещата са изпипани. Спойките примерно са си от “мръсните”, с олово вътре. Кутията е с дебела ламарина, цялата конструкция е стабилна и удобна за ползване. Мога да се хвана на бас, че от новите “зелени” машини с RoHS спойки след 11 години и спомен няма да е останал.

Тези компютри ги купих някъде около 2003 година, на старо, имаха 3 месеца гаранция. Бях си направил сметка, че ако си изработят тези три месеца ще съм на печалба от тях. Ползвах ги 4 години и май мога още.

Преди време си взех тази WLAN карта, защото имаше поддръжка за Linux и Mac OS X. Лошото беше, че не успях да я подкарам в KisMAC. Преди няколко дни с радост установих, че са сложили драйвер за нея. Тръгна без ядове в KisMAC trunk r319 с USB RT73 device. Очевидно е с някакъв Ralink чип. За целта обаче трябва да се махнат “официалните” драйвери на D-Link. Повече информация по въпроса има тук. Върши очудващо добра работа за auth/deauth активни DoS атаки срещу WPA, докато в същото време вградената карта стои в пасивен режим. KisMAC си работи чудесно с двете карти едновременно, при чупене на WEP могат да се ползват заедно, като активната прави packet injection. Доста приятни занимания (в стил прееби другарчето) за мрачен неделен следобед.

През последните няколко дни тока мигна някъде около 50 пъти в нашия квартал. Имаше и няколко по-дълги спирания за по час и нещо. Бате Бойко Борисов вчера май по този повод тръгна да плаши ЧЕЗ. Ако оправи тока, както почисти и улиците спасението е само едно – здрав UPS. Аз естествено си имам такова животно, но е прекалено старо, а и слабо за нашата чуплива електропреносна мрежа – APC 1000VA, набор 1995 година. Работи чудесно и няма земна сила, която да може да ме накара да го махна. С две машини държи някъде около 45 минути, обаче с 3 машини и монитор максимум 15 минути. Най-лесното решение ми се стори да си купя още един и да ги вържа един след друг. Търсих нещо евтино от порядъка на 2000VA и се спрях на този – Mustek PowerMust, в момента струва 274 лева в MallBG. Понеже от много време се глезя само с APC, очаквах да получа някаква боклучива стока. Останах приятно изненадан, добър продукт са докарали. За тези пари няма как човек да иска повече. Има RS-232 и USB интерфейс, а на диска с драйвери са споменати доста операционни системи, дори FreeBSD. Не че ще ги ползвам, но самият факт, че производителите са се сетили за не използващите Windows потребители ме радва. Също така в кутията имаше пълен комплект кабели, включително и USB кабел (който в принтерите на HP липсва примерно). Имам и картонена гаранционна карта за попълване и изпращане по пощата – APC имат същите, явно се опитват да ги конкурират. Хваля ги малко прибързано де, още не съм тествал как ще се държи при спрян ток, което най-много ме интересува. Чудя се дали не е по-добре да разпределя компютрите между двата UPS-а и да ги вържа успоредно. По този начин ще спестя едно преобразуване DC-AC при спрян ток.

Направи ми силно впечатление, че голяма част от лекциите на вчерашния OpenFest бяха насочени към скалируемост. Това е една много важна тема за всички съвременни интернет приложения. Използването в последните години на многоядрени процесори я прави още по-важна. Под скалируема програма (или алгоритъм) в най-общия случай разбираме програма, която има възможност за паралелна работа – било то на много процесори, много ядра или на много отделни компютри. Естествено не всички програми могат да бъдат скалируеми. Има алгоритми, които са подходящи за паралелна работа и такива, които не са. Имам чуството, че в последните години има разни тенденции всички изчисления да се бутат в посока на паралелност. Което до голяма степен е продиктувано от многоядрените процесори и невъзможността, или по-скоро нежеланието на Intel да разработва по-бързи едноядрени процесори. Тук може би много хора няма да са съгласни с мен, за това ще почна от далече с малко история.

Преди няколко години компанията Intel претърпя една “пълна промяна”. Изведнъж те илязоха с нов сайт, ново лого, нова визия и нови имена на процесорите. Не знам до колко хората са запознати с причините за тази промяна – те са няколко. Intel претърпяха три огромни провала, струващи им милиарди долари и ако не бяха направили тези промени – те просто щяха да фалират. Първият голям провал, за който говоря се нарича Pentium 4 или по-точно NetBurst. Има достатъчно много статии на тема защо тази технология е лоша, не мисля да пиша поредната такава. Друг провал на Intel – много скъп и болезнен, се нарича Itanium, 64 битовата архитектура, която в момента всички трябваше да ползваме (поне според маркетинговия отдел на Intel). Основната идея там е компилатора да решава кои инструкции могат да се изпълняват паралелно, като на практика по-този начин постигаме скалируемост без промени в кода на програмите. За съжаление написването на такъв компилатор се оказа, че не е по силите на съвременните създатели на компилатори. Друга причина да се провали Itanium естествено е несъвместимоста му с 32 битовата архитектура на Intel. Всъщност последната голяма болка на Intel е, че след толкова много години не успя да изхвърли x86 архитектурата, която толкова много хора с право мразят.

Многоядрените процесори спасиха Intel и Core архитектурата. Това им беше единствения шанс за измъкване от блатото и те го използваха умело. До голяма степен е логично, вместо да вдигат производителността на процесорите (което се оказа трудно) те вдигат бройката им. На пръв поглед – нищо толкова драматично. По този начин обаче те прехвърлят топката за производителността на писачите на софтуер. Това е доста хитър ход, и от гледна точка на техологиите и от бизнес гледна точка. Пакетирането на няколко чипа в един пакет е лесно и евтино, не се иска проектиране на нови архитектури или драматични промени на процеса за производство. Всички програми, които се скалират добре работят бързо на новите процесори – законът на Мур е в действие (до голяма степен). Единственият проблем са добрите стари програми, които работят само на един процесор и не могат да се скалират. На Intel не им остана нищо друго, освен да обвинят за тях писачите на софтуер. Това и направиха, също така отделиха милиони долари за обучение и разработка – как да работим с нишки, как да пишем код, който работи добре на новите процесори и т.н. Тази кампания е толкова обширна, че стигна и до България. В момента Intel има лаборатория по паралелни изчисления в ИМИ-БАН, която има за цел да обучи универститетските преподаватели. Те трябва да знаят как се работи с новите процесори и какво да преподават на студентите. Опитват се да ни учат, че това е бъдещето и, че скоро няма да има съвременен, бърз, едноядрен процесор.

Трудно ми е да повярвам в това. Многоядрените процесори вършат много добра работа в сферата на web hosting услугите, виртуализацията на сървъри, паралелната компилация, суперкомпютрите и т.н. Глупаво е обаче да се мисли, че всяка задача и всяка програма може да бъде докарана до там, че да работи добре с паралелни изчисления. В крайна сметка цялата тази тенденция може да се окаже поредния провал на Intel. Лично за себе си мога да кажа, че през последната 1 година за всяка програма, която писах стоеше много силно въпроса – да ползвам ли много процеси (или нишки) или да не ползвам. Отговорът на този въпрос е – зависи. Има много случаи, където е лесно, обосновано и ефективно да се ползват. Има много случаи, където е трудно, глупаво и бавно да се ползват паралелни изчисления. Често пъти е много трудно да се даде отговор на този въпрос навреме – преди да се напише програмата и да си проличи. Продиктуван от бизнес или пък технологични проблеми в Intel, този въпрос ще ни мъчи в следващите няколко години поне. Обаче не бива да изпадаме в крайности, трябва добре да обмисляме всеки конкретен проблем преди да се впуснем в писане на нишки, процеси, споделени памети и т.н.

Тези дни с големи усилия реших и последните проблеми с новата ми компютърна конфигурация. С гордост заявявам, че в момента пиша на нея. Освен нещата от онзи ден, възникнаха още досадни спънки. Старото захранване свърши добра работа, нямаше проблеми с ATX-EATX конвертора и машината тръгна уж нормално. Започна да зарежда FreeBSD stage1 loader и по някое време зависна. Рестартирах и се озовах пред един черен екран. Машината просто не подкарваше видео картата, монитора даваше, че няма сигнал. Не четеше диска, което значи, че не висеше някъде на ниво BIOS. След няколко рестарта монитора запали и BIOS-а изгря със гениалното съобщение, че дъното не било правилно овърклокнато. Изпсувах, защото никъде по никакъв начин не съм казвал, че искам да ми се овърклолва каквото и да било. Не съм геймър, нито овърклокър и еднобитовите грешки в паметта могат да ми костват цял ден работа, не съм си намерил здравето на улицата, че да си ги причинявам сам съзнателно и доброволно. Започнах да ровя из настройките и да търся от къде да махна всички подобни глупости. След извесно време мисля, че успях. Машината продължи да се държи нестабилно и накрая се оказа, че черният екран ми излиза при почти всякакви настройки. При всяко ново подобно съобщение настройките се връщаха в by default вид и трябваше да почвам от начало. Цъкайки повече от час установих, че потегля само в DDR2-400 режим на паметта. Пуснах един memtest, паметта си работеше нормално. Напълно погрешно предположих, че проблемът е в BIOS-а. Забелязах, че в режима на работа на паметта има някакъв нов термин – Ganged mode. Никъде не намерих точна дефиниция на това нещо, но според контекста в който се ползва ми се струва, че трябва да значи двуканален режим. Както и да е, след като пробвах какво ли не се оказа, че единият DIMM памет е лош. Когато него го няма всичко върви нормално в DDR2-800 режим. В дъното на всички тези проблеми и губене на време пак стои великата капиталистическо-китайска икономия. Производителя на дъното е спестил говорителчето (за което има очертано място, просто не е лепнато там) разчитайки, че на кутията ще има. Естествено производителя на кутията е разчитал, че на дъното трябва да има говорителче. Дори най-старите BIOS имплементации си имаха морзов код по който можеше да се познае, че има проблем с паметта, когато не могат да запалят монитора. Сигурен съм, че и този BIOS нещо се е опитвал да ми каже. Но няма кой да изписка.

Иначе машината е много добра, като производителност. Всъщност тази конфигурация е интересна с няколко неща. Първото е, че това е първият ъпгрейд при който не вдигам клока на процесор – стария ми беше на 2.0 Ghz, този също е на толкова. Паметта е точно два пъти по-бърза, а ядрата са четири броч. Човек лесно би си помислил, че тази конфигурация ще работи кажи-речи 4 пъти по-бързо от старата. Това разбира се не е вярно. Реално погледнато на този процесор ще могат да работят 4 нишки едновременно. Всички процеси работещи с по една нишка ще се работят със същата скорост, както и на старата машина. Все пак добрият стар UNIX, както и доброто ново FreeBSD са достатъчно добре направени така, че да изцедят колкото се може повече от един такъв многоядрен процесор. За многото нишки в криптографията в kernel mode вече писах. Дисковете ми работят с нормалната си скорост благодарение на тях. Всъщност в момента имам 3 закачени криптирани диска, това прави общо 12 kernel threads, по 4 за всеки диск, или по 1 на диск, на процесорно ядро. Това ни най-малко не смущава системата, трансферите са много бързи във всички посоки. Сложих си KDE 4.1, до момента не бях работил с нищо повече от 3.5. Определено графичната среда е станала много по-използваема. След като си сложих подходящите шрифтове започна да ми харесва (проблемът с шрифтовете явно е вечен). Нещо което ме дразни и още не съм решил е, че когато комилирам някакъв софтуер през ports, компилацията върви само на едно ядро. Не съм сигурен, че има добро решение на този проблем към момента, но смятам да потърся. Работата с няколко операционни системи в QEMU не би трябвало да е проблем на тази машина. Това съм го пробвал с две ядра. С четири е по-интересно, защото можеш да пуснеш три guests без да пречиш на host-а особено много. В този режим на работа ще се чуствам почти като на mainframe от края на миналия век.

Днес направих неуспешен опит да си сменя дънна платка, процесор и памет на основната ми машина. Старата ми машина беше с Asus A8V Deluxe дъно, AMD Athlon 64 3200+ процесор и 1 GB RAM. Новата трябва да бъде с Asus M3A78 Pro дъно, AMD Phenom 9350e процесор и 4 GB RAM.

Сблъсках се с няколко проблема – изключително идиотски и досадни за решаване. Понеже и стария и новия процесор имат почти еднакво TDP, около 65W, бях решил да ползвам стария ми радиатор за пасивно охлаждане. Той представлява едно огромно медно, 700 грамово чудовище на Thermaltake. Струваше доста пари преди години, сигурно и сега струва толкова. Първата задача беше да го отлепя от процесора. След като махнах щипката която го държи се оказа, че е залепнал яко за процесора – може би заради скапана термопаста. Дърпах, бутах – не отлепя. От някакъв сайт научих една цака, за която не бях чувал преди. За да се отлепи радиатора лесно – трябва да се нагрее до работната си температура. Взех сешоара и го загрях доста, започна леко да ми пари на пръстите. След което леко го размърдах и той започна да се отлепя. След няколко минути успях да го отлепя целия без да счупя нищо. Последва неприятна изненада – разопаковах новото дъно и видях, че няма как да го монтирам там. Всъщност Socket 939 (стария) и Socket AM2+ (новия) са почти еднакви. Процесорите се различават само в пиновете. Някой гений обаче е решил да смени окачването на пластмасата, която държи радиатора. Старата се държи с два болта за дъното, а новата с четири. По този случай няма как да се монтира старо охлаждане на ново дъно. Това е толкова глупаво, че просто се чудя как да го коментирам. Подобно нещо може да се направи само с една единствена цел – печалба. Производителите на хардуер прецакват всичките си клиенти, които така или иначе няма къде да ходят – ще трябва да си платят допълнително. Сега ако искам да имам пасивно охлаждане ще трябва да отида да си купя още 700 грама мед, абсолютно същите като старите, но този път с друга пластмаса за окачване. Помислих малко, дръпнах една дебела псувня на близки и роднини по женска линия на половината китайски народ и монтирах стандартния радиатор и вентилатор (тези дето си вървят с процесора). По този начин си осигурих още доста децибели шум в стаята, и друг проблем – какво да правя със стария радиатор.

Следващият проблем беше със захранването. Не бях съобразил за глупостта наречена EATX. Старата ми машина нямаше PCIe, нещо което, както тогава, така и сега, смятам за абсолютно безполезно. До този момент не съм чул за никакъв хардуер, освен геймърски видео карти, който да се включва на PCIe шината. Съответно старата ми машина си беше с 20 пиново ATX захранване. Благодарение на ненужната ми PCIe шина, новата ми машина е с 24 пиново EATX захранване. Монтирал съм две подобни машини преди време и по принцип знам за този проблем. В случая обаче не го съобразих. Това което ще ми реши проблема е един елементарен конвертор от 20 пина към 24 пина. Цялата тази идея ми е непонятна – защо по дяволите са ни четирите допълнителни пина, като на тях имаме пак същите добре познати напрежения – +3.3V, +5V, +12V и земя. Така наречения конвертор просто взема тези напрежения от пинове 1, 4 и 10 на ATX кабела. Явно е направено с цел разни откачалки – овърклокъри и геймъри да си вземат супер скъпи захранвания, на които тези допълнителни пинове са отделени и стабилизирани от самото захранване. Не виждам кой нормален човек би ползвал тези неща за нормална работа. Моята видеокарта е вградена и най-вероятно никога нищо няма да включа на PCIe шината. Дъното обаче си иска тока там и няма да тръгне без него – в понеделник ще ходя да търся конвертор.

Хардуерната индустрия не спира да бълва нови и все по-безполезни функционалности. Примерно на новото дъно имам още – 6 аудио изхода, 1 коаксиален изход, HDMI (за сметка на това нямам DVI, а имам конвертор HDMI-DVI), огромно количество USB портове (за сметка на това нямам сериен или паралелен порт). Естествено нямам 5+1 (или 7+1?) колонки, защото мисля, че не са ми необходими – 2+1 ми вършат добра работа. За какво ми е това HDMI? Никога няма да го ползвам – аз не съм си купил видео, а компютър. Сериен порт е много полезно да имам, защото на него може да се пусне kernel debugging. Също така на него се връзва една камара апаратура и стар хардуер, който аз ползвам от време на време. Въобще производителите мислят само за някакъв клас средностатистически потребители, които в общи линий са достатъчно неграмотни за да си купуват каквото им се предлага. Гледат просто да е шарено и ново. Естествено когато попитат продавача – “на този компютър ще ми тръгне ли най-новия филм/игра?”, отговорът трябва да бъде “да”. Много неприятна работа, тази тенденция винаги я е имало, но до скоро човек можеше да си купи и истински неща, без всичките тези “екстри”. В момента за тези пари това е невъзможно.

Днес след чакане от около 2 месеца, моят Apple MacBook най-накрая беше ремонтиран. Проблемът му беше ето този, или както ми беше обяснено от разбирачи на Apple – дефектирал Top Case. Този проблем е доста масов и се отстранява гаранционно от Apple без много шум. За съжаление в България трябваше да се преборя с няколко типично български, сервизни идиотщини за да получа нов Top Case. В последствие се оказа, че той върви заедно с клавиатура и trackpad. За това в момента съм с нова клавиатура. Най-напред в сервиза ми обясниха колко трудно се доставяли тези части от Унгария и как унгарците били несериозни. После се оказа, че сервиза излиза в отпуска. В последствие стана ясно, че по някакви причини, преди да излязат в отпуска не са ми поръчали частта. Както и да е, важното е, че все пак накрая я смениха. Чудя се обаче колко ли време ще издържи новата. Според моите наблюдения, този Top Case е абсолютно същия като стария. Само след няколко затваряния на пластмасата се вижда къде точно лепне капака. Освен това бях предупреден да внимавам като го разнасям, защото задната част се крепяла на някакви щифтове. Понеже си използвам лаптопа доста интензивно, чудя се колко ли клавиатури ще сменя за тези 2 години, през които ми важи гаранцията.