Это не корректный подсчет. На самом деле, надо бы как-то оценить энергию импульса, приходящуюся именно на свариваемую зону, а для этого не хватает понимания о величине падения напряжения на ней
У меня в молодости был роскошный советский конденсатор на 10000 мкф, и при заряде до 12 в и коротком замыкании отверткой или чем-нибудь подобным он испускал отличный сноп искр, и достаточно крепко приваривал к себе то, чем делалось короткое замыкание. И ничего с ним не было от такого обращения.
Ток пульсаций протекают через конденсатор продолжительное время, и тепло успевает накапливаться. А тут, короткий импульс, и потом, пока в следующий раз целишься, у конденсатора полно времени, чтобы остыть
В общем, я бы попробовал. Благо цена вопроса копеешная, и в форме материальных затрат, и в форме времени, потраченного на эксперименты
Дозировать энергию импульса легко можно, меняя напряжение, до которого заряжен конденсатор
Что до формы импульса, если большая часть энергии выделяется за время, за которое теплопроводность свариваемого металла не успеет «утащить» существенную энергию, то в первом приближении, казалось бы, на форму наплевать
0.12 Ф — это 120000 мкф, так что я почти угадал :-)
На самом деле, в изначальной статье непонятно, сколько энергии выделяется непосредственно в зоне сварки, а сколько рассеивается в проводах, включая обмотку трансформатора
Что-то мне подсказывает, что если взять электролитический конденсатор микрофарад на 50000-100000, зарядить его вольт до 20 и разрядить на сварочные электроды, плотно прижатые к привариваемой ленте, то получится примерно то, что надо, и без всякой Ардуины.
Процессор работает с памятью не байтами, а кэш-лайнами. Размер кэш-лайна, в зависимости от модели процессора, может быть и 16 байт, а может и 64. И чтобы изменить байт, bool или int64, процессор считывает целый кэш-лайн, меняет в нем данные и записывает назад. Причем не сразу, а когда-нибудь. Поэтому обычная операция присваивание не атомарна.
Атомные операции содержат дополнительные инструкции процессора (инструкции в широком смысле, у интела это может быть префикс к команде), и процессор делает вид, что конкретно эта операция произошла атомарно. Причем на многоядерной/многопроцессорной машине это «деланье вида» включает в себя нетривиальное взаимодействие с другими ядрами/процессорами на предмет синхронизации кэшей.
Поскольку вся эта дополнительная деятельность чего-то стоит, обычное присваивание не атомарно.
Балансировщику трудно заранее определить, какие запросы тяжелые, а какие — нет. Но по длинне очереди необслуженных запросов он может оценить загруженность бакенда.
Операция присваивания не атомарная. И что хуже, глядя с одного ядра CPU, можно подумать, что присваивание уже произошло, а глядя с другого — нет.
Что худшего может произойти в данном конкретном случае, я не знаю, но вообще, если считать присваивание атомарным в многопоточной программе, произойти может очень трудноуловимый баг.
Порядок не принципиален, но лучше бы более-менее поровну дергать все бакенды, а не какой-нибудь «любимый». А то забытый нами бакенд тихо помрет, а мы об этом и не узнаем. А у «любимого» на SSD-ке дырка протрется от натуги.
Как-то безумно, по-моему, защищать булевскую переменную мьютексом при том, что в Go есть atomic exchange, работающий с целыми числами.
В общем и целом, я бы считал для каждого бакенда количество запросов, уже туда отправленных, но с ответами, назад не полученными. И отправлял бы следующий запрос тому бакенду, на котором в данный момент висит меньше необслуженных запросов. А round robin крутил бы лишь при одинаковом их количестве.
1. Можно не качать ничего по просьбе Васи, но отдавать Васе то, что уже скачано
2. Есть контент, который захотят просмотреть очень многие. А есть контент, мало кому нужный. Вероятность того, что кто-нибудь из соседей захочет что-нибудь из популярного я оцениваю, как довольно высокую (ну, скажем, 50%)
3. Можно кешировать только популярный контент, и ненадолго, популярность быстро проходит
Есть проблема с приватностью. Я могу не хотеть, чтобы посторонние люди могли узнать, что на моем устройстве есть такие-то файлы.
Причем проблем тут две. Во-первых, никто, разумеется, не хочет светить, скажем так, не вполне легальным контентом.
Но есть еще и вторая проблема. Посканировав контент на моем устройстве, можно составить мой профиль для таргетирования рекламы. Если учесть, что заодно отслеживаются мои маршруты (ведь предлагается сканировать соседние устройства), можно вообще обо мне довольно много узнать. Кстати, эту информацию можно и не только для рекламы использовать, а для мошенничества, например.
Ток пульсаций протекают через конденсатор продолжительное время, и тепло успевает накапливаться. А тут, короткий импульс, и потом, пока в следующий раз целишься, у конденсатора полно времени, чтобы остыть
В общем, я бы попробовал. Благо цена вопроса копеешная, и в форме материальных затрат, и в форме времени, потраченного на эксперименты
Что до формы импульса, если большая часть энергии выделяется за время, за которое теплопроводность свариваемого металла не успеет «утащить» существенную энергию, то в первом приближении, казалось бы, на форму наплевать
На самом деле, в изначальной статье непонятно, сколько энергии выделяется непосредственно в зоне сварки, а сколько рассеивается в проводах, включая обмотку трансформатора
Энергию импульса, очевидно, можно регулировать, изменяя напряжение, до которого заряжается конденсатор.
Атомные операции содержат дополнительные инструкции процессора (инструкции в широком смысле, у интела это может быть префикс к команде), и процессор делает вид, что конкретно эта операция произошла атомарно. Причем на многоядерной/многопроцессорной машине это «деланье вида» включает в себя нетривиальное взаимодействие с другими ядрами/процессорами на предмет синхронизации кэшей.
Поскольку вся эта дополнительная деятельность чего-то стоит, обычное присваивание не атомарно.
Что худшего может произойти в данном конкретном случае, я не знаю, но вообще, если считать присваивание атомарным в многопоточной программе, произойти может очень трудноуловимый баг.
В общем и целом, я бы считал для каждого бакенда количество запросов, уже туда отправленных, но с ответами, назад не полученными. И отправлял бы следующий запрос тому бакенду, на котором в данный момент висит меньше необслуженных запросов. А round robin крутил бы лишь при одинаковом их количестве.
2. Есть контент, который захотят просмотреть очень многие. А есть контент, мало кому нужный. Вероятность того, что кто-нибудь из соседей захочет что-нибудь из популярного я оцениваю, как довольно высокую (ну, скажем, 50%)
3. Можно кешировать только популярный контент, и ненадолго, популярность быстро проходит
Заметим, что объем мусора должен очень сильно превышать объем того, что я качаю для себя. Боюсь, с эффективностью у такой конструкции будет не очень…
Причем проблем тут две. Во-первых, никто, разумеется, не хочет светить, скажем так, не вполне легальным контентом.
Но есть еще и вторая проблема. Посканировав контент на моем устройстве, можно составить мой профиль для таргетирования рекламы. Если учесть, что заодно отслеживаются мои маршруты (ведь предлагается сканировать соседние устройства), можно вообще обо мне довольно много узнать. Кстати, эту информацию можно и не только для рекламы использовать, а для мошенничества, например.
Как решать эти проблемы, не очень понятно.