@sgabay242 said in Advice on how to improve Deadlines:
So how big should a plot size be to generate 8 hour deadlines? 1PB? 2PB? 10PB? does the bus connectivity from SATA/USB and plot size read speed per round has anything to do with achieving better deadlines? I know it helps to rank better at your pool over slow miners, but does it help with your own overall resulting deadlines?
The other interesting discovery is while my plot is read 140TB @ 25/s I'm looking at the pool.poolofd32th.club screen in real-time and I see people finishing submitting their deadlines for the same round in like 1 or 2 seconds, how is this possible???? I wonder if is WAN network latency involved here, and some of this miners are very close to the pool server, say ASIA, and I'm very far AMERICA?
As an experiment, I'm looking to convert my miner to Ubuntu and use GPU CreepMiner written in C++, in theory Linux can proceses threads faster than Windows and C++ is Faster than Java (jMiner)
Change your miner setting to report all deadlines found. You'll probably notice you have dozens and dozens of deadlines that vary between days to months. If you mean, "how big should a plot size be to generate at least 8 hour deadlines"...well, I'm not even sure how to go about trying to calculate that. I mean, deadlines found on a given plot vary by block. I'm not sure there's even a way to really guarantee such a scenario of happening, regardless of plot size (well, I guess unless someone owned 100% of the network).
For submission, deadlines should be submitted to the pool the instance they are found (+latency), so its completely normal to see miners submitting deadlines a split second after a new block. Yours deadlines should be submitting in the same manner, even if it takes your miner 25 seconds to read your whole plot.
that is not how it works. 1tb doesn't give you deadline 3 and 2TB give you deadline 2.
When the network asks for a deadline it searches every hear drive for the best equation. your plot might have 1 equation that is under 3 months so it will report it. if it finds an equation with 4 month deadline it wont report it.
So the more TB the more chance at having a deadline and more chance for one of them to be under 3 months.
It like a lotory, the more hard drive the more equation the more chance to have a deadline under 3 months.
Or the more hard drives the better chance at having the best deadline to win it.
imho main problem with optimizer to SMR disks was based on ntfs-3g that added fuse layer (read a lot of context switching). It was visible even when I was just copying plot file. The speed on windows (with native ntfs) was 3x.
Using btrfs might be interesting idea, I will try it when building next Linux rig.
ext3 vs ext4 really makes difference. On the ext3 there is no native support for fallocate syscall so default POSIX is used. It makes creating an empty file really slow (something like you have in windows when non-using admin account). My first attempt was with ext3 as I say that there is no need to have unimportant features from ext4. Unfortunately ext3 in the kernel is just emulation inside ext4 code :)
no-barriers makes almost no sense under normal scenarios. My tests shown that we can improve write performance by 2% (when writing to multiple disks at once). So it is not worth more testing but it looks good enough for default.
@stsk87-0 , on that pool you only show .02 Burst deferred payout. The payment would require 1 Burst to send so that's why you didn't get a payout even though they payout once a week.
Also. it ooks like they drop shares after 15 rounds. If I were you, I would switch to @haitch 0-100 pool. They have a lon DL limit for small miners and a long time before payments so you will be able to aquire more than 1 Burst to get a payout. But, you need more HDD space.