Well, I’m not the best expert on the forum, but actually, the latency is counting since our nodes enters in competition in term of response, that includes the lag between the satellittes and your geolocalization, between your connection and the relay of your ISP, then the ethernet cable between the router and your device, then your own hardware performances, including mostly the disk latency (that’s why some SNO are using SSD cache or more dangerously the RAM cache, or both, but it also increases the risk of data corruption/wearing another disk). So, I think a attached disk directly (by SATA/SAS) to the node device is still the fastest. A disk connected remotely is a very bad thing in I/O performances and reliability for such node activities, I think its highly not recommanded by the Storj staff because it could be more risky.
But, in worst case, you won’t be disqualified for high latency (except if it responds by a timeout when auditing/uptime checking happens), you’ll lose the race when download and uploads are showing “canceled” in the logs, so it will decrease the rate of succeeded upload/download traffic (thus your chances to receive and send the pieces). That means other nodes have been faster than you, and it doesn’t require more nodes to collect the piece for the resiliency/the customer.
Node requirements as posted in the blog, also asked as checkboxes when you fulfil the form for your node on https://storj.io/sign-up-node-operator/ :
Minimum Recommended Storage Node Requirements:
- A minimum of one (1) processor core dedicated to each storage node service
- A minimum of 500 GB with no maximum of available space per node
- 2 TB of bandwidth available per month; unlimited preferred
- 5 Mbps bandwidth upstream
- 25 Mbps bandwidth downstream
- Online and operational 99.3 % of the time per month (MAX total downtime of 5 hours monthly)
Preferred Storage Node Requirements:
- A minimum of one (1) processor core dedicated to each node service
- A minimum of 8 TB and a maximum of 24 TB of available space per node
- 16+ TB of unmetered bandwidth available per month; unlimited preferred
- 100 Mbps bandwidth upstream
- 100 Mbps bandwidth downstream
- Online and operational 99.5% of the time per month
About the pieces and node “latency” competition:
When a file is uploaded to the network, it’s first broken into 256 MB segments. The 256 MB segments are encrypted client side by the Uplink client, then broken up into 95 erasure-coded pieces. The Uplink client requests 95 storage nodes to which it will stream the pieces from the Satellite. The Satellite performs a statistical analysis of the nodes and then returns the list of 95 nodes to the Uplink client. The Uplink client attempts to upload the 95 pieces but stops after 80 of the pieces are uploaded. Even though the Satellite returns the best 95 storage nodes, the Uplink client further optimizes for the fasted 80. Of those 80 pieces, only 29 are actually needed to recover the file based on the Reed-Solomon erasure coding scheme.
Subsequently, when the Uplink client attempts to retrieve the segment while downloading the file, it requests the segment from the Satellite. The Satellite performs a statistical analysis of the nodes holding the segment pieces and returns a list of 35 nodes. The Uplink client requests the pieces held by the 35 nodes, but stops after receiving 29 pieces from the fastest 29 nodes.
You can also look that article who articles how many pieces are sent to the nodes and how many are required before the “race finishes” for the slowest nodes: https://storj.io/blog/2019/01/reputation-matters-when-it-comes-to-storage-nodes/