Chia版本1.04中的改进，P盘速度更快！缓存更低！

Chia矿机配置购买建议，什么样的电脑能挖CHIA

POC硬盘Chia交流群：467117986

Chia版本1.04 2021-04-12

添加

• 从2021年4月21日左右开始，GUI会通知您该版本将在块高度193,536处停止工作，并会从该块中持续警告您不能使用此版本（或任何更早版本）进行服务器场。这是为了支持升级到事务派生。
• 现在，我们提供巴西葡萄牙语，澳大利亚英语和海盗的翻译。

已变更

• 位域模式下的绘图仪的绘图速度有了很大的提高（比1.0.3快15％），现在所需的临时空间减少了28％（238.3 GiB / 256 GB），并且现在在阶段1中使用其最大内存，仅需要3389MiB用于k32的最佳排序。总写入量也应下降约20％。在几乎所有机器上，我们都希望位域变得一样快或更快。对于早于Nahalem架构的CPU ，位域绘图将不起作用，并且您将不需要使用任何位域。这些CPU通常是在2010年之前设计的。
• srcchia-blockchian中的目录已更改，chia以避免名称空间冲突。
• GUI安装版本已简化为仅依赖其中的一个.spec文件chia/
• 重量证明超时现在可以在config.yaml中配置。
• 现在，在收到初始对等体之后，对等体发现的重试次数会更高。

固定的

• 我们已进行了重大改进和错误修复，以阻止区块链和钱包数据库损坏问题。
• 现在，我们将环境传递到守护程序中，这应该可以解决Windows和MacOS的一些启动错误。
• ARM64 .deb安装程序现在可以在Raspberry Pi OS 64位和Ubuntu 18.04 LTS或更高版本上正常运行。
• 我们在减轻重量的产生和节省方面进行了改进。
• 钱包启动会产生竞争状况，在启动时会输出无害的错误。

Chia团队正在1.04版中对绘图仪进行重大改进。显着的变化包括每个绘图过程所需的内存资源减少了26％，临时存储空间减少了28％。对于许多人来说，这的最终结果将意味着在同一系统上以TB /天为单位绘制输出的显着提高！对于新的绘图系统构建者，这将意味着计算，内存和存储的比率不同。

这是我在1.04 beta版中看到的一些收获的快速示例……在接下来的几周中，我将测试更多的系统。

实际绘图改进的示例

系统	改变	版本1.03	版本1.04
NUC	5→6流程	每天1.31TiB或1.44TB	每天1.62TiB或1.78TB
英特尔服务器系统R2308WFTZSR	27→46流程	每天6.77TiB或7.44TB	每天9.16TiB或10TB
预算构建，Z490	3TB→2TB临时空间（减少$ 100-200）	每天3TB	每天3TB

1.04中的新临时空间和内存要求

K值	DRAM（MiB）	临时空间（GiB）	临时空间（GB）
32	3389	238.3	256
33	7400	430	462
34	14800	900	966
35	29600	1884年	2023年

1.03及更高版本中的旧要求

K值	DRAM（MiB）	临时空间（GiB）	临时空间（GB）
32	4608	332	356
33	9216	589	632
34	18432	1177	1264
35	36864	2355	2529

示例系统和新的构建选项

系统	成本	CPU核心	DRAM（GiB）	温度（GB）	固态硬盘	预期/天
超值桌面	$ 400	4	13.2	1024	1TB	1-2
桌面	$ 700	6	20	1536	2个800GB或1个1.6TB	2-3
桌面	$ 900	8	26.5	2048	2x 1TB，1x 2TB（交错）	3-4
高端台式机	$ 2000	12	39.7	3072	2个1.6 TB	4.5
高端台式机	$ 3000	16	53	4096	5个960GB	5-6
服务器	$ 4000	32	106	8192	3个3.2TB	8-10

错开呢？

错开或延迟以下绘图过程的开始开始，可以帮助最大化计算（CPU），内存（DRAM）和磁盘（临时空间）的利用率，因为绘图过程的不同阶段需要这些资源的数量不同。在具有八个核心的中端台式机系统中，交错安装的主要优点是将八个进程压缩到32GB DDR4中，而无需进程交换（减速）或被杀死（内存不足）。这加快了阶段1的完成时间。内存减少主要是由于绘图过程的阶段2和阶段3是最消耗内存的事实。确保所有进程不在此阶段同时进行，意味着随着时间的流逝更好地共享内存资源。产生了第二个效果，即不将具有多个文件副本的目标磁盘同时从第二个临时目录（-2）移到最终目标目录（-d）时，不打乱目标磁盘。如果用户仅使用单个驱动器，则这很重要，因为硬盘驱动器带宽为〜100-275MB / s（取决于磁盘的容量），并且在使用更高的n值时会延迟后续过程的开始。比1。我们将必须探索新的1.04绘图仪如何在1.04发行后的未来几周内改变惊人的收益。

那超线程呢？

1.04中要探索的另一个要运行的进程比物理硬件CPU内核更多的领域是由于称为超线程的功能而导致的CPU线程数通常是物理内核的2倍。现在可能存在内存不平衡的情况，因为DRAM具有2、16GB，32GB，64GB等多种功能。使用不均衡的DIMM会减少内存带宽。在具有八个进程的八核系统中，仅需要26.5GiB的内存，从而导致系统利用率不足。操作系统使用免费的DRAM进行缓存，如果用户使用的是GUI或台式机版本，则OS的DRAM开销会更高。还有十项流程的额外测试，以查看特定系统是否可以以固定成本提供更高的总输出量，以及将绘图流程超额订购到物理CPU内核是否有真正的好处，并且随着DRAM和临时空间的增加，增加了一个系统的输出量（与构建第二个系统相比）。十个进程的容量也略高于32GB，并且需要进行大量测试以查看是否有可能。

位域与无位域？

需要进行更多测试，但是在大多数情况下，位域的改进可能会使默认绘图仪更快。较少的数据写入量和改进的排序速度将有助于许多并行处理。社区将在未来几周内发现一些令人兴奋的数据，但是就目前而言，在1.04 beta上完成的大多数测试都是使用启用了位域的（默认）绘图仪设置进行的。

SSD耐久力的影响

1.04绘图仪中的代码改进将每K = 32写入的数据量从1.6TiB（位域）和1.8TiB（-e）减少到估计的1.4TiB（即将推出，现在开始测量！）

对所需的临时SSD的影响

SSD有多种形状和尺寸，用于绘制数据的最佳SSD是数据中心SSD。您将必须根据所获得的硬件，在每个系统的不同数量的驱动器上自己做数学运算。RAID 0中更多具有较小容量的SSD通常会胜过较大型号，因为较小的SSD具有比较大型号更高的IOPS / TB和带宽/ TB。还要考虑物理连接和每个SSD的价格之间的权衡。在计算临时存储空间时，可以将标签容量（下）与临时空间表（上）中的GB列一起使用，或从操作系统显示的内容转换为GiB。

SSD类型	容量
消费者	500GB，1TB，2TB，4TB
数据中心NVMe –超大规模	960、1920、3840GB
企业级SATA最近	480、960GB，1.92、3.84、7.68TB
老企业（2014-2016）	200、400、800、1600GB
旧英特尔（2014-2017）	1TB，2TB，4TB，8TB
企业NVMe读密集型（1 DWPD）	960GB，1.92、3.84、7.68TB
企业NVMe混合使用（3 DPWD）	800GB，1.6、3.2、6.4、12.8 TB

没有关于SSD容量的行业标准。由于来自其他供应商的NAND裸片具有不同的物理尺寸和每个SSD控制器不同的通道，因此不同的供应商可能具有不同大小的SSD。JEDEC标准的32GB裸片不是32GB，不是32GiB，而是更大的，因为存在一定数量的平面，每个平面有擦除块，每个擦除块有NAND页，其中有许多冗余块。尽管没有行业标准，但使用SSD的超大规模数据中心客户和OEM（原始设备制造商）主要是将容量点整合到了上表中。

概括

1.04是一个鼓舞人心的版本，特别是对于那些已经在Chia alpha中看到绘图仪的人。该团队已经走了很长一段路，以使绘图过程所需的资源更少，并且各种形状和大小的硬件都可以更容易地访问它们。我相信未来几周将出现一个新的价值绘图系统，显然是TB / day / $的赢家。同时，请观看Chia参考硬件Wiki，以获得更新的绘图基准！

在幕后发生的事情– 1.04空间代码的Chia证明发生了变化。

对于那些足够勇敢地想要了解绘图代码实际功能以及与1.04相关联的更改的人员，请参阅对绘图性能产生重大影响的更新以及Chia开发人员的评论。我很高兴与Rostislav（最近的更改背后的Chia开发人员）就新的1.04绘图改进进行了交谈。这是为那些想深入了解自己的Rostislav（密匙库上的@cryptoslava）绘图代码的人所做的更改

你们中的某些人可能还记得去年的时间，当绘制ak = 32时需要大约600 GiB的临时空间。9月左右，Mariano实施了一种更好的排序算法，该算法减少了总IO，并提高了性能。大约在同一时间，阶段1发生了变化，我们在写入下一张表后立即开始删除条目元数据（f和C值），而不是将其推迟到阶段2。这导致临时空间减少到大约332 GiB。九月份所做的另一项更改是，一些先前已重写的数据现在已写入新位置。但是，我们将继续使用最大条目大小（这对于就地更新是必需的），即使现在不再需要它也是如此。在当前的更改集中，我经历了所有此类情况，其中条目大小过大，并将其减小到必要的最小值。这带来了RAM使用率和临时空间的减少，但这还不是全部！

罗斯蒂斯拉夫

另一个重大变化是将阶段2和阶段3中的sort_key和new_pos字段的大小从k +1减少到k位。故事与旧的反向传播（第2阶段）算法有关，该算法未使用位域。在这种情况下，一个表中可能有超过2 ^ k个条目，因此有必要为索引它们增加一个额外的位。现在不再需要它，因此多余的位被删除了。由于条目大小被四舍五入为整个字节，因此这种减少对于k = 32个图而言意义重大，例如，可以将阶段3中排序的条目从9个字节减少到8个字节！这些更改还使第3阶段的内存使用效率更高，因为现在与以前相比，我们使用更多的存储桶进行排序。早些时候，该额外位始终为0，并且由于这是最高有效位，它决定了排序的存储区，

有趣的事实：这是第3阶段，之前需要最多的内存来进行排序（并确定所需的最小内存），现在是第1阶段

罗斯蒂斯拉夫

最后，在1.0.3版本中已经包含了另一个更改，但它与最近的更改特别相关，在某些情况下，我们只使用了一半的可用内存缓冲区，而不是全部使用

罗斯蒂斯拉夫