Only 2 Miners assigned for Large Files. about cess HOT 17 CLOSED

Because there is an upper limit to the number of random selections, within this limit, as many as possible, three miners who meet the conditions will be randomly selected. When uploading large files, the number of miners who meet the conditions decreases, which reduces the probability of selecting three miners who meet the conditions within the number of times.
code:
https://github.com/CESSProject/cess/blob/0.6.1-space-prove/c-pallets/file-bank/src/functions.rs#L291

from cess.

I see, so the primary criterion is they should have enough available space. But keeping an upper limit makes larger files to get uploaded forever and suppose there is not even 1 miner that can store a big chunk of data, that file will never get uploaded to the miners. In fact, in my opinion, there should not be any upper limit on the number of miners assigned and the file should be segmented so that its able to be stored on at least some number of miners. Right now I'm not sure why is this upper limit set, If you could explain this a little, it will be helpful in understanding. Thanks.

from cess.

Because these tasks need to be completed in one block within 6 seconds. So there's no way to keep selecting.

from cess.

I still didn't get a clear picture. Why the task has to be completed in one block? By the way if the miners fail to store the files, new miners are selected. So I wonder how come there is no way to keep selecting?

from cess.

Rules for blockchain transactions in the substrate framework

from cess.

Well, unfortunately this doesn't answer my doubt clearly.
Currently, when a user uploads file it takes hours and hours to distribute it to the miners. And during this time a number of times miners are reassigned due to failed attempts to deliver the segment to the miner. Then how come these tasks has to be completed in one block? Only selecting number of minsers can be done within a block.

from cess.

Go and learn about the blockchain foundation built by the substrate framework.

from cess.

Wao this is your answer. That's of great help.

from cess.

And this is very rude of you and unprofessional.

from cess.

Sorry, my English is not good, so when I finally saw your answer, I thought it solved your confusion

from cess.

I have already told you that this must be done within a block, and you have to delve into it yourself, still unable to understand. I really don't know what else to tell you. A transaction must be executed within a block, which is the rule.

from cess.

https://docs.substrate.io/learn/transaction-lifecycle/

https://docs.substrate.io/learn/transaction-types/

from cess.

My point is why only up to 3 miners are selected, why can't we select number of minsers dynamically based on the file size. If a bigger file is uploaded it should be distributed to even more miners so that miners with less storage space can also store it's segments and easier to find miners who meet the criteria and larger files won't take forever to upload.

from cess.

Because the allocation quantity is determined based on the current fragment size and segment size. The current segment size is 16Mib and will be divided into three fragments. It is not related to the size of the file itself, we consider it based on recoverability, with three being the optimal number

from cess.

So any solution for larger files that takes very long to get distributed to the miners?

from cess.

The current reassignment process has some bugs that will be fixed in 0.7.0 and will be resolved by improving the accuracy of random selection, rather than increasing the number of random selections.

from cess.

Okay waiting for 0.7.0 then.

from cess.