chapter127, ベンチマーク機能とブロックチェーンの融合

いつもお世話になっております。

 いつもお話しさせていただいております方が、SIM+生体認証にブロックチェーンを融合させた実験に成功したとのことで、にっこりでした。

 こちらは、ドライブの測定結果ですね。危なそうなドライブについて型番およびセクタの位置で事前に知ることができるだけでも、データの復旧率が跳ね上がります。そして、量産されているドライブについては、その故障個所が似ております

 それゆえに、RAIDを構築しても、同じ型番および近い製造日で組むため、壊れてしまいます。同じ場所が同じタイミングで壊れる可能性が高いのですから、これでは、RAIDであってもデータを保護できません。

chapter99, MSVCビルド版を分離します

いつもお世話になっております。

MSVCビルド版(Windows)のみ、新しい機能(ベンチマークと故障予測)を結合させ、GUIを変えて(軽量GUIで「応答なし」を防ぎます)、ビルドいたします。まず、きちんと動くかどうかも知りたいので、お試しです。とはいっても、Windows版としては、これをきちんとリリースできる段階まで仕上げます

MSVCでビルドしたときに限り、この軽量GUIになるようにマクロを設定いたします。なお、その他のコンパイラの場合(MinGW, g++, clang)はQtになります。

移植の面からみるととても面倒そうですが……、実はどのみち、ドライブの制御部分については……OS別(Windows, Linux, OSX)に全部書かなくてはならない(^^;という状況です。そして、自粛の都合で時間もありますので、ここは頑張ってみようと考えております。

chapter22, We will port this blockchain to the latest core

We are currently working on porting this blockchain to a new core.

Please wait for a while as we will adjust it to synchronize with the old core.

Drive failure predictions will be implement into this new core. In this way, even if the drive failure prediction don’t work, if the old the blockchain works, system of money transfer can be maintained.

CriticalSection has been fixed! Thanks

Thank you for the great analysis. (https://www.atomminer.com/)

This time, IPV6 is enabled as standard, and the placement of CriticalSection is changed.

Next time, we will implement RPC thread pool and verify with testnet.

In order to prevent deadlocks, we would like to put a mechanism like the message queue implemented in Windows.

The RPCs that need to proceed after processing has been processed reliably are like SendMessage, and if there are no problems asynchronously by accumulating in the queue with RPCs are processed efficiently with a mechanism like PostMessage.

Also, if we consider only the PostMessage part instead of thinking about the scope of CriticalSection, it can prevent deadlock even if it is complicated.

We will fix CriticalSections that classified according to the RPC processing issued by the mining pool

We will fix CriticalSections that classified according to the RPC processing issued by the mining pool.
※ Ultimately, CriticalSection is expected to be narrowed down to one.

As for this processing part, FIXME was attached, and it was operating abnormally with PoMP of NOMP.

This time, YiiMP PoW had a problem, so I decided to go back to the original CriticalSection and see what it was.
However, if it is this, it will not work with NOMP.
Therefore, it will be divided by the macro of the compiler.

As an improvement method,
I think that this RPC itself will be like this as Windows PostMessage, so that it will be issued one by one after being accumulated.
※ The current situation is similar to SendMessage that some of them do not work.

In addition, if this improvement is implemented, all RPCs will be affected, so I think that it will be released after testing with testnet.