the upload that was failing by 4 chunks went up straight away.
"linuxmint-21.2-mate-64bit.iso" d239d34f77f73f4dc60ef3e8a12ffc87ded440dd886536d5aaaea0b2c15e2963
Among 4 chunks, found 0 already existed in network, uploaded the leftover 4 chunks in 19 seconds
**************************************
* Payment Details *
**************************************
Made payment of 0.000005267 for 4 chunks
Made payment of 0.000000926 for royalties fees
New wallet balance: 99.999201231
ubuntu@safe-hamilton:~/safe/images$
Downloading "Springsteen.zip" from e680de86debc1c15a23728dc2775fe19831884ec35efada11c5161454fb61f6a with batch-size 16
Error downloading "Springsteen.zip": Chunks error Chunk could not be retrieved from the network: 6be1be(01101011)...
How are the nodes organized on that line? Are they XOR -neighbours?
Might be in the eye of beholder, but seems to me, that for both of the holes the graphs taper down from the left to the hole, and then shoot up sharply on the right.
No cigarā¦
But I found that there are no
Did not get a valid response in my logs, but there were
When paying 1 chunks, got error CouldNotSendMoney("Wallet has pre-unconfirmed transactions. Resend, and try again.")
Got new wallet, and it worked!
I wish there was an error message in CLI that would tell what was going on!
Indeed, punishment (by shunning) isnāt necessarily easy. That will be a very interesting phase of testing.
To answer you question, other nodes decide. Exactly how they decide to drop a neighbour and how effective that will be is going to be tricky and interesting to study.
Yeah I think clients cannot be trusted in their evaluation of nodes. Could become an attack. Maybe nodes should make requests from each other somewhat randomly and then somehow vote.
But from what has been said it is basically that when a node is not receiving responses from another node then that other node is removed from its routing table. Not receiving responses could also include too many erroneous replies.
So it will be individual nodes that decide independently and when enough nodes have removed that node then its effectively removed from the network. As David says its a probabilistic network.
What levels of error or lack of response will trigger that removal will be tricky, but Iād say not too much.
The honest node that loses responses from other nodes (ie being shunned) will have the more difficult task of knowing when to restart in order to see if that fixes its problems.
Let me see if I can help to spread some light on this
So its 158,668 x 5/3KB chunks uploaded.
5/3KB due to self encryption splitting into at least 3 chunks
158,668 * 5/3 ==> 264MB
either the average file size is a lot more than 5KB or the 7.34GB is wrong or the number of chunks is wrong
7.34GB ==> 7.34GB / 158,668 ==> 46.26K per chunk and 138.7K per file.
there is 158,668 requests for costs waiting for responses from different places around the world
Lets say 100mS average for a response to return for each prices check (used fr rest of analysis)
that is up to 4.4 hours overall just for price checking
there is 158,668 * 2 (317,336 payments (node pay & royalty pay)
Lets say its the 100mS for each. That is > 4.4 hours and < 8.8 hours for sending payments
there is 158,668 * 5 (793,340) data store requests in batches of 10 chunks (50 data stores) . Assume a degree of async occurs
that is effectively 15,867 lots. Each lot will be >100mS since can still only send one packet at a time
assume 1 second for the 50 data store requests (1 block of chunks).
that is 15,867 seconds (4.4 hours)
And that is on a good day
For the 9GB file - 17,602 chunks
1/2 MB per chunk approx
17,602 price checks
1760 seconds at 100mS each ==> approx 30 minutes
17,602 * 2 payments
time is >30 minutes and < 60 minutes.
data uploads in batches of 10 chunks (50 uploads)
time is >30 minutes for all (plus extra for link upload times which now is not insignificant compared to the approx 50K)
assume 40Mbps upload speed (achieve 6MB/s) gives about 25MB/6MBps (4 seconds) per block
1760 blocks * 4 seconds ==> >120 minutes instead of >30 just because of the data to be uploaded.
I donāt know your upload speeds, so it may take less if you have faster.
Its not so bad when you break it down and perhaps any differences is down to when the upload occurred because of the changing layout of this tiny network and all the churning happening at different rates. This churning rate can vary massively in this tiny testnet
As for the cost, it is quite close to being right since the payment is per chunk.
never mind the 4 that were not getting records had already been killed. moving on 