Абе има джелеза с ускорители, ама то голяма файда няма щото няма библиотеки за тях

Не че съм търсел де, ама досега не съм срещал библеотечка дето да ползва ускорител. То и аз доста внимавам като ги ползвам, защото създават други ядове като применро кво правим като се наложи две или повече нишки да се ускоряват
Още повече на мен основния ми проблем е липсата на памет, затова и всичко ми е стрийм базирано. Демек става или голям блокаж или трябва прекъсвам ускорителите и да ги презареждам. Шетнята в такива случаи е повече, отколкото добре написана софтуерна сметачка.
Ускорителят върши работа ако имаш само една по-специална нишка, както примерно джелязното CRC го ползвам само на едно място а на всички останали софтуерно се смята. Но при TLS-а няма как да стане, пък и там комбинациите са много, оня ден ги броих тия дето мисля да крабна - към 200 сюита са..

предимствата на ускорителите са при голям трафик. на сървърно приложение се вижда файдата. ама там си има и инструментариум (ОС)
другото предимство е, че обикновено са сертифицирани вече.

нишки и пишки е малко като фитки и китки

Уф ти сега ме фърляш в едни размисли... Аз гледам как да мина най-тънко и откъде да скрабна наготово, а ти ми отваряш работа

ST имали някаква библиотечка, може и да си ползват ускорителите. Пробвах да я дръпна от някаква форма дето попълваш ЕГН-то на тъщата и разни други такива и накрая ми отговориха, че до 48 часа щели да ми разгледат молбата.

ми то обикновено не е ядрена физика. пълниш 5 регистъра, казваш му 'ръц' и чакаш малко.
щом имаш нишки. трябва да имаш и семафори или дори мютекси. ама и да нямаш, лясно ще си организираш една чакалка на нишки.

не твърдя, че ще има голяма полза от такива ускорители, обаче.

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

онова е друго, то е по-скоро крипто сторидж + някакъв енджин и малко тампери във вид на серпентинен метален слой.
защото фундаметален въпрос във всяко секюрити е къде си държиш ключовете. ако всеки може да ги докопа, не му трябват никакви шперцове, че да отвори и най-засуканата врата.
и не може да се вдигне никаква скорост, ако ще и да подкараш устойчиво I2C на 1 мегабит.

Е то докато го прекараш през I2C процесора ще го насмята 10 пъти, ако говорим за нещо голямо де, то ясно че ако е някоя въшка по-добре да е нещо специализирано.

Ами спорно е... крипто библиотеките изобщо не са ефективни. Първо се местят напред-назад из паметта, после има хешове, после криптирания.
Ако има хардуерен ускорител от едната страна да му наливаш данни, от другата да излизат готови за пращане ще пести доста. Но проблемът е че комбинациите от операции е много голям при SSL/TLS (над 200) и няма такъв или поне тия ускорители в куртексите не правят всички операции. Те джуркат по една операция, след което трябва да препрограмиш и да пуснеш друга... Като самата логика кога какво да правиш си е също доста тегава.

абе то верно, че има 200 комбинации, ама ако четеш дневните сводки на секюрити аналитиците, ту това било пробито, ту онова било май несигурно... та остават не повече от 5 кубчета, с които не можеш да направиш кой знае колко пермутации.

пък и по принцип се очаква, че въшката ще се свръзва към някоя 'истинска' машина, която релно може да поема много комбинации и да диктува как да се държи въшката. изобщо - договарянето какви кубчета има и в двете страни и кои от тях да се ползват, е задължително, като и двете страни си показват спатиите. та ако въшката може само едно нещо, сървъра ще се нагоди към него. ако друга въшка говори друг диалект, сървъра пак ще се нагласи към него. така че е малко безсмислено да се напъваш да пускаш всички видове кубчета във въшката.

Спорно, спорно - колко да е спорно - все за някой работи помага по 20 пъти:
https://www.wolfssl.com/files/flyers/wolfssl_atmel.pdf

http://www.cnx-software.com/2017/06/13/ ... rity-chip/
Това е с атмелската въшка.

като се замисля, може би за случая на миро това не е чак толкова лоша алтернатива.
поне ще му спести проблема с малкото памет, май.
пък ще стане платформено/чип независимо.

стига скоростта на I2C да не му е пречка

Дедо, аз някои кубчета мога да си спестя, но логиката за работа с кубчета не мога. А пък тя е по-големият гърч.

Гичо, тва е реклама... Сравнение на база М0 и то с незнайно каква имплементация. В сайта на оня Грегор ли беше дето казах че ще го погледна има сравнение на софтуер и там ще видиш че специално за кривите разликите между две имплементации може да са убийствени. Ако са взели калпава версия и я търкалят на М0 кво очакваш с каквото и да го сравняваш ще е бавно. Но пак казвам за мен важното е дали ускорителя прави всичко или не. Файда от една операция нямам...

Няма ли да е по-удачно (от гледна точка на време за разработка и усилия) да си направиш системата двукомпонентна: малките у-ва да комуникират некриптирано до друго у-во което играе ролята на комуникационен гейтуей, а след този гейтуей вече да е криптираната комуникация. Той вече ще може да е с по-сериозен процесор и памет, така че да върви Линукс, където проблемите са решени.

За дадено място с едно или повече от малките у-ва ще трябва да има и по един комуникационен гейтуей.

Може така да замислиш протоколите, че за Линукса да не ти се наложи да пишеш нищо (тоест само да инсталираш и конфигурираш нещо стандартно)!

тц!
Устройствата трябва да комуникират криптирано. При това с чужди сървъри, т.е. нямам никакъв конктрол, нито даже информация какъв ще бъде тоя сървър или сървъри.

Сега се зачетох в темата, извинявай ама какво е чипър