Chia плоттинг без ssd

Chia plotting basics

— February 22, 2021

Introduction

First it is important to know that there are two very different parts of being a Chia farmer. There is creating the plots or plotting and then there is farming the plots. In this post we are going to focus on the process of creating your plots. The types of machines and storage space are very different than the types of hardware you ultimately want to use to farm. You can see some example farming rigs on our very useful repository wiki.

We initially recommend that you try plotting with what you have around. The only caution about that is that you want to limit the amount of plots you create that use your internal/consumer grade SSD as the temporary space. SSDs have very different wear lives and we have detailed information on SSD endurance.

You really never need to plot a plot with a k size larger than 32. Those who do plot larger are either doing them to show off (and we encourage this for fun) or to optimally fill the open space on a specific drive. A k32 will take up 101.3 GiB of space once completed but will need a total of 239 GiB of temporary space as it is being created. A single k32 plotting process never needs more than 239 GiB of space. One needs to be careful here as 239 gibibytes uses 1024 as its divisor where GB or gigabytes uses 1000 as the divisor. That means you will need 256.6 GB of temporary space and the final plot file will take 108.8 GB. A k32 plot can be done by one expert we know in just under 4 hours, but most experts are creating plots in 5 hours and most folks average around 9-12 hours.

Creating a plot is a process that will take RAM, CPU cycles, IO to your disks and it will use them differently in each of the four phases of plotting. Everyone wants a magic “right” answer or to use AI to figure out the optimal plotting strategy for their machine. However almost every machine is different along one of these parameters so you just have to try. Longer term we will be able query your machine and make some recommendations but that is not today. You really will have to test. And no, the experts in the various Keybase channels don’t know your best settings either.

Getting going

The first phase generates all of your proofs of space by creating seven tables of cryptographic hashes and saving them to your temporary directory. Phase 2 back-propagates through the hashes, phase 3 sorts and algorithmically compress these hashes in the temporary directory while starting to build the final file and phase 4 completes the file and moves it into your final plot destination.

One of the major bottlenecks is usually the total sustained write speed of the disk underneath your temporary directory. We recommend used datacenter SSD if you really want to go fast and not sacrifice consumer SSDs making plots. NVMe is faster than SAS and SAS is faster than SATA. This PC World overview of storage technologies can explain these acronyms and the differences. TBW, or terabytes written, is generally how SSD drive life is measured. One k32 writes 1.8TiB in non-bitfield mode and 1.6 TiB with bitfield enabled. More on bitfield in a moment.

Making the single fastest plot isn’t generally the best plotting strategy however. Often you’re getting amazing speed because you’re using the turbo core of that multi core processor. The folks who plot the most have shown that you should measure in TB (TiB if you’re old school like us) per day. The way to get the maximum TB/day is to plot lots of plots in parallel. Some of the top plotters use datacenter SSDs. Some use SAS drives. Raid 0 is often very handy to tie together a couple of small fast drives into one say 2TB partition so you could fit 5 k32 temporary spaces on that one virtual RAID drive.

All of that said, for my personal plotting I use a 2017 iMac and a 12TB Western Digital external drive on USB 3.0 for both temporary and final directory, and I get a k32 about every 10 hours.

Good assumptions

There are some good rules of thumb for now. These can change as we will be returning to making some plotting speed improvements after launch. First we need to explain bitfield versus no bitfield plotting. Originally, the plotter did not use bitfield back sorting. The bitfield back sort is theoretically faster than not using the bitfield and we already know that it saves 12% of total writes but requires more RAM. We have a hunch we can speed bitfield up 10% and make it work on more processors but that’s not in there yet. What we do know is that, as long as you’re ok with the 12% more total writes, no bitfield will work faster when SSD or fast SAS is your temporary directory. If your temporary directory is on a regular HDD, like mine is, bitfield is 20% faster than no bitfield. Older CPUs may not see the speed increase as much as noted above.

Returning to the rules, here are a few. Never touch the stripe size of 65536. No one has found a speed up over that value and we are likely removing it from the options list. (Update: as of 3/11/21 stripe size has been removed as an option.) You almost never want to use any bucket values other than 128. Less buckets requires more RAM for each plotting process. 64 buckets requires twice the RAM.

As far as number of threads are concerned you are generally going to want 2 to 4. More than 4 seems to have diminishing returns and 2 threads is a lot better than 1. More threads also require a bit more memory to successfully complete a plot. The threading is only used in phase 1 currently.

As of Chia 1.0.4, RAM requirements are almost identical between bitfield and no bitfield. This is a chart of the various RAM choices assuming a k32 with 128 buckets and 2 to 4 threads:

RAM MiB:	Minimum	Medium	Maximum
Bitfield	900	2640	3400
No Bitfield	900	2640	3400

Below minimum your plot will fail. Medium is enough RAM that you’ll get most speed improvements, but not all. This is useful when you’re trying to get more plotting processes parallel and have limited RAM. Using anything over the maximum is wasting RAM as you will not plot any faster. We are pretty certain of the minimums and maximums but there is community debate about the medium values. We’ll update this chart accordingly as we have better data.

Mastering plotting

Most people start plotting from the GUI. You can successfully complete a couple of plots in parallel from there to get the hang of things. As people choose to get more serious they migrate to the command line. It is worth noting that Windows suffers 5-10% slower plot times versus MacOS or Linux for now.

Once you get some experience you will probably want to know how to create more and more plots in parallel. Luckily we have a replay on YouTube of our cocktails with plotting experts. They had much to share about their various approaches. Some used servers and datacenter SSD, some bought used servers and SAS drives for temporary directories, some expand their consumer/gaming machines, and some focused on lots of smaller used machines. Many of them have compiled a spreadsheet of reference plotting hardware with plot speeds to help get you thinking about any hardware you might want to change or acquire and see how your plotting results measure up.

As you start parallel plotting you need to be careful to not over allocate memory when you are plotting. If you cause your operating system to swap, you are not going to be happy with your outcome. You don’t have to be as careful with thread count.

It is also a very common plotting strategy to plot on say your gaming machine and then move your plots to a Raspberry Pi 4 with a lot of USB ports. All you need is your same 24 word mnemonic on both machines. Alternatively you can just run a remote harvester on your Pi and have it connect to your gaming machine where you are running node and farmer and only have your private keys on one machine.

Learning more

Everyone trying to create plots should read through our repository FAQ. It really does answer 90% of the questions you might have about plotting (and farming.)

Once you have read the FAQ, you’ll find a supportive community in these channels on our public Keybase channels.

Keybase Channel	Topic
#beginner	For those questions you are afraid to ask
#testnet	For all things testnet — an intermediate skill level
#plotting-hardware	The expert plotters are here. Hardware, software and plotting strategy

Thanks

@pyl, @kiwihaitch, @psydafke, and @storage_jm all helped out on this post. The mistakes are mine. Should something need to be updated I will edit and post the errata down here.

Updates

As of Chia version 1.0.4, RAM min/med/max values have been updated.

Источник

Плотинг Chia на HDD без использования SSD

1001rapid

Бывалый

1001rapid

Бывалый

olegsh2

Местный житель

что за волшебные переходники? ЮСБ хаб?) ну они питание потянут с юсб порта — так что хз выдержит ли) ну можно конечно 3.5 винты с своим питальником — если на рапсбери делают то на ноуте думаю тоже можно )

все ссд в наличии оказались не больше 256 гигов, по этому приходится плотить на HDD ((( неужели разработчикам было трудно сделать больше вариантов размеров плотов? или это специально сделано чтобы SSD хотябы 256 и меньше оставили обывателям, а не скупали?

и еще в настройках программы есть вот такая функцияПосмотреть вложение 192879 для чего она нужна и как работает? я в начале подумал что при создании плота будут файлы разбиты на 2-ва диска, но у меня это не сработало, кто знает зачем нужен второй ВРЕМЕННЫЙ каталог?

AlxRuleZ

Пляшущий с бубном

Решил что может нужна отдельная тема для тех кто плотит на самих HDD, плюс поделюсь своими результатами и проблемой с которой столкнулся.
В общем, чем покупать дорогой SSD на один гиг, решил что лучше купить 7 маловместительных жестких дисков и плотить на них то же количество плотов в день что и на SSD, по цене тоже, плюс SSD не изнашиваеться.

Плочу на двух компах:
на слабеньком компе с ( виндовс 7, FX-8300 и 8 гиг оперативы), стоит 2 HDD, (частота вращения 7200, 32мб буффер) плот на каждом диске создаеться за — 16 часов,

На компютере помощнее (виндовс 10, Rayzen 1600af, 16 гиг оперативы) стоит 5 HDD, в среднем плот на одном диске создается за 28-35! часов. То есть в два раза дольше. При этом сам комп не нагружен.

Жесткие диски одинаковы, на компе где райзен — оператива загружена на 70% , проц в среднем на 10%-20%. Сами диски тоже не сильно загружены, меньше чем на 50%:

Ядер ставлю 4 потока, оперативы по стандарту 3390 мб, файл подкачки большой, в чем может быть проблема?
Подозреваю что может из-за того что я использую все 6 портов сата — в них может быть узкое место, так как когда во время плотинга подключаю седьмой жесткий через юсб и копирюю плоты с него, то скорость заметно падает, хочу заказать себе переходник PCI-e to Sata, может если жесткие подключать чере PCI-e то нагрузка распределиться?

Источник

Плотинг Chia на HDD без использования SSD

websmith

Свой человек

djaze

Новичок

Сделал RAID0 из 3 1Тб винтов 7200 об/мин (встроенный контроллер на материнке GIGABYTE B460M D3H). CPU i9 10 ядер, 20 потоков (Intel Core i9-10850K). 32 Гб ОЗУ DDR4 2666МГц (Kingston ValueRAM). Временные папки на SSD SATA, две SSD NVM и RAID0. Засеиваются 4 плота параллельно, на каждый плот выделил по 5 потоков, 7Гб ОЗУ.

Время создания плотов:
1. SSD SATA 23382 cек (6,49 час) 1000 ГБ SSD-накопитель Samsung 870 EVO
2. 1ый SSD NVMe 21929 сек (6,09 час) 1024 ГБ SSD M.2 накопитель A-Data XPG GAMMIX S11 Pro
3. 2ой SSD NVMe 22082 сек (6,13 час) 1024 ГБ SSD M.2 накопитель A-Data XPG GAMMIX S11 Pro
4. RAID0 32675 сек (9,07 час)

websmith

Свой человек

Foxter333

Свой человек

Ubuntu server, RAID 0 из 4х винтов 2тб 7200об
Конфиг — Зион w3520, ОЗУ 8гб, Китай-мать с SATA2

Скорость плоттинга в одного примерно 8ч+ (cpu 8 потоков, 64 корзины и 7888 озу), из крайних результатов — 28882сек и 29612сек
RAID 0 вполне себе годная тема

видел на просторах пример плоттинга на множестве слабых тушках по цене мешочка семяк. тч параллелить/плоттить можно всяко и сеять террабайты в сутки за сравнительно не большие вложения

Я мысленно уже готов зарядить MacPro 5.1 с потенциалом в 6 HDD и серверным процом в 12потоков)

Foxter333

Свой человек

gaunt

Свой человек

Ubuntu server, RAID 0 из 4х винтов 2тб 7200об
Конфиг — Зион w3520, ОЗУ 8гб, Китай-мать с SATA2

Скорость плоттинга в одного примерно 8ч+ (cpu 8 потоков, 64 корзины и 7888 озу), из крайних результатов — 28882сек и 29612сек
RAID 0 вполне себе годная тема

видел на просторах пример плоттинга на множестве слабых тушках по цене мешочка семяк. тч параллелить/плоттить можно всяко и сеять террабайты в сутки за сравнительно не большие вложения

Я мысленно уже готов зарядить MacPro 5.1 с потенциалом в 6 HDD и серверным процом в 12потоков)

Лучше раздели на 2 райд0, на каждый свою папку темп для двух батников.
Программа так устроена, что на 1, 2 и 3 фазе, может работать только один темп.
Причем похоже, на чтение либо на запись.
Т.е. диск ещё какое-то время работает — освобождая кэш.
В сумме, работаю оба диска, один на полной скорости, второй нет. Но за счет времени на опорожнение кэша, происходит выигрыш.
Два диска в райд0 одним батником, дают твои секунды+-8часов на плот. И это ай5 2500К 4ггц.
Та же машина, два батника на два темпа, те же 2 диска, 12 часов на два плота. +-6 часов на плот.

Пока не хватает одного винта, для 2 райд0.
Думаю, время уменьшится до 4-5 часов двумя темп на двух разных Райд0.

Больше скажу — сделай пожалуйста и отпишись.
Интересно подтвердить предположение.

Foxter333

Свой человек

Лучше раздели на 2 райд0, на каждый свою папку темп для двух батников.
Программа так устроена, что на 1, 2 и 3 фазе, может работать только один темп.
Причем похоже, на чтение либо на запись.
Т.е. диск ещё какое-то время работает — освобождая кэш.
В сумме, работаю оба диска, один на полной скорости, второй нет. Но за счет времени на опорожнение кэша, происходит выигрыш.
Два диска в райд0 одним батником, дают твои секунды+-8часов на плот. И это ай5 2500К 4ггц.
Та же машина, два батника на два темпа, те же 2 диска, 12 часов на два плота. +-6 часов на плот.

Пока не хватает одного винта, для 2 райд0.
Думаю, время уменьшится до 4-5 часов двумя темп на двух разных Райд0.

Больше скажу — сделай пожалуйста и отпишись.
Интересно подтвердить предположение.

Все что тут написано — предположения и я очень сильно сомневаюсь в их корректности)
1. Темп работает всегда и везде — не важно какая фаза и сколько потоков и какие еще параметры
2. В аппаратном RAID Linux все данные пишутся в параллель, все чекал и мониторил iostat (буст до 500+мбс — как SSD епта)
3. В моем конфиге особо не разбежишься, ограничения по ЦПУ и ОЗУ — максимум можно сделать 2 джобы со сдвигом 3-4часа, чутка будет лучше но RAID лагать не будет (это вам не Винда глючная)
4. у тебя выигрыш идет из-за проца, фазы 2-4 одноядерные и там частота на ядро очень важна

Разбирать свой конфиг я не стану, тч сорян)

gaunt

Свой человек

Это где выигрыш?
Второй комп ай5 3хххК, 4ггц, с одной свежей барракудой, льет плот за 8 часов. Точно также, как ай5 2500К на райд0 в однопоток.
Не хочешь разбирать, твоё дело.
Винда хоть и глючная, да райд разбирается/собирается тремя кликами.
Выигрыш на двух дисках/райд0, идет за счет чередования запросов и уменьшения времени задержки.
Светодиод хдд тупо горит ровно.
Вот и всё.
Есть ещё приход от уменьшения количества корзин, если память позволяет.
Растут участки чисто последовательного чтения , меньше рандомного.

Но один райд, выигрыша против свежих 200мб/с дисков, практически не дает.

websmith

Свой человек

GoFrenDiy

Бывалый

Оказалось, что моя GA-EP43-S3L не умеет сама рейды создавать и я полез же изучать вендовские средства. Чот промазал и создал сначала составной том. При записи информации на этот том из 2х500 гиг у меня сначала идёт запись на 1 диск, потом на второй. Думал было переделать, но. В отличии от чередующегося, здесь, минимум, 4 плота складываются физически на 1 диск и только один, как-то там между ними делится. Есть вот у кого информация — если отваливается в этом томе один винт, информация на другом сохраняется? На чередующемся томе (RAID0) если лёг один диск, то лёг и весь рейд. Врят ли я конечно буду заниматься восстановлением плотов, но тем не менее, если при такой сборке тома есть шанс хотя бы половину данных сохранить, то останусь я на таком «диске»

И кстати! Пипец эти рейды виндовые процессор то кушают! У меня 2х ядерная корюшка на 3 ггц просто от копирования на этот рейд под 30. 40% загружается. Лучше, всё-таки, аппаратный рейд, чтобы отдельная железяка занималась работой по сохранению данных и не мешала жить, в том числе и засеивать на такие вот рейды.

GoFrenDiy

Бывалый

Нет — проблема всех винтов — низкое значение I\O по сравнению с SSD и именно это является узким горлышком здесь, а не скорости линейного чтения. Как одно из решений — GPT раздел и размер кластера 2М. Т.к. файлы с данными достаточно здоровые, то харду нужно меньше совершать операций по их вычитыванию\вписыванию. Если посмотреть на линейные скорости чтения 2хRAID0, то у меня там цифири под 200 мб\с чтения, а во время засева ну 110 было в прыжке. После перехода на 2М GPT часто вижу цифирь в 150 мб\с на чтение, ну и по тестам — было 11 часов на плот, стало 9.5 часа — вот ТУТ цифири показывал. Т.е. даже тут видно, что упора в интерфейс по скорости мб\с у нас нет. А если добавить второй батнег, то даже RAID0 4xHDD не вывозит так, как отдельных 2 рейда 2хHDD.

Далее, как я выше пронаблюдал, программный «рейд» достаточно неплохо отъедает производительности ЦП, Если на многопоточных монстрах этого не видно, то на слабых должно ощущаться и отбирать процессорное время у основной задачи. Наличие любого аппаратного контроллера, пусть даже от интела в южном мосте, точно должно разгрузить основной проц, да и повышение производительности рейда такого будет происходить от повышения количества I\O в секунду, обеспечиваемое внешним процессором.

Foxter333

Свой человек

Нет — проблема всех винтов — низкое значение I\O по сравнению с SSD и именно это является узким горлышком здесь, а не скорости линейного чтения. Как одно из решений — GPT раздел и размер кластера 2М. Т.к. файлы с данными достаточно здоровые, то харду нужно меньше совершать операций по их вычитыванию\вписыванию. Если посмотреть на линейные скорости чтения 2хRAID0, то у меня там цифири под 200 мб\с чтения, а во время засева ну 110 было в прыжке. После перехода на 2М GPT часто вижу цифирь в 150 мб\с на чтение, ну и по тестам — было 11 часов на плот, стало 9.5 часа — вот ТУТ цифири показывал. Т.е. даже тут видно, что упора в интерфейс по скорости мб\с у нас нет. А если добавить второй батнег, то даже RAID0 4xHDD не вывозит так, как отдельных 2 рейда 2хHDD.

Далее, как я выше пронаблюдал, программный «рейд» достаточно неплохо отъедает производительности ЦП, Если на многопоточных монстрах этого не видно, то на слабых должно ощущаться и отбирать процессорное время у основной задачи. Наличие любого аппаратного контроллера, пусть даже от интела в южном мосте, точно должно разгрузить основной проц, да и повышение производительности рейда такого будет происходить от повышения количества I\O в секунду, обеспечиваемое внешним процессором.

GoFrenDiy

Бывалый

GoFrenDiy

Бывалый

Что-то у меня часто появляться начала ошипка. блин. думал это из-за использования 2го темпа, но нет — вернул всё взад и собирается плот на 1м временном диске, но вот сейчас снова вылезло.

Источник