Aye, there’s been no attempt at optimisation of such things at all yet. We’ll get there thougH!
So much of an upload is the payment coordination, so I’d hope to see a big boost in perf here as we get DBCs integrated
Yes I think you are correct, however I would take these results with a huge pinch of salt. That spreadsheet was only to compare the speeds I got with various versions of sn_node on a baby-fleming running on one internal machine.
it’s a useful pinch of salt though!
These were single runs with normal browsing etc going on in the background and I suspect mean little unless they were repeated several times and averaged.
Wait for network split.
No luck for me too yet.
this was where data got lost last time right?
help!!!
Finally found the admin pwd for this router - what ports do I need to forward?? .
Probably in the OP but they dont jump out at me immediately.
You can forward any, you’d just need tp specify them when starting your node, eg
./target/release/sn_node --public-addr <public ip>:<some port> --local-addr <lan IP>:<same port> --hard-coded-contacts '["138.68.187.212:34518"]'
for the curious current node mem load is pretty good. highest is ~280mb, avg is much closer to 100.
(We’ll see with a split if things change wildly)
Seeing the trace for my put, and this comment, it is kind of confusing. Is the network calculating price for each chunk being uploaded? Does this mean that someone could run out of tokens in the middle of uploading a large file and lose all their funds (gaining nothing)?
Why wouldn’t the entire price be checked up front and paid for a single time?
When I try to join, the join process starts OK and once it went through a few cycles with 3 minutes re-trials. After that I have gotten:
[sn_node] ERROR 2021-06-18T17:45:10.510039609+03:00 [src/bin/sn_node.rs:143] Encountered a timeout while trying to join the network. Please try again later.
… sooner.
But does this mean, that my connectivity is okay and I am eligible to run a node?
Well, upload seems completely borked for me now but download is working nicely:
$ time safe cat safe://hyryyyyjhxs65mpjyt9ihttd54b67fap7uq6s3cmbrjb5gswb3anwurkxyy > 1.flac
real 1m39,382s
user 0m53,041s
sys 0m30,060s
size 67.5MiB
$ time safe cat safe://hygoyeymnywejbhhx6jkw5nhsd19ggtgxs4q6kwongyeo5jk9ap5x1e1p9h > 1.png
real 0m2,637s
user 0m0,926s
sys 0m0,450s
size 910KiB
Node is still trying to join, occasionally timing out but no other error messages so far.
Download really impressive Sounds like PUT not even looked at yet. Really interested to see if data maintains after network splits.
It will be soon. Right now self encryption streams chunks to the network 1 at a time. That means the network allocates cost as they go. A ton of work.
We will change SE to chunks all data locally, then pay for the whole set of names at once and then upload. So you will see better stats, i.e.
- Preparing data
- Encrypting data
- Getting payment costs
- creating store contracts
- Paying for all data
- uploading all data
It will give a better understanding of what upload speed means too. Right now folk may compare our upload with some server based thing, but here in Safe it’s a different beast and needs to do a lot more. In any case this process will dramatically improve soon. Dbc are a big part of this and will help immensely
Thx Maidsafe devs
Happy happy joy joy
Last time it was crash.
In previous runs data loss probably happened (but I’m not sure about it).
i cannot cat anything more after 1.png
1.flac and waterfall slo mo are giving a neterror: could not GET etc
Error: NetDataError: Failed to GET Public Blob: SelfEncryption(Storage("Generic error(Failed to obtain any response)"))
to be precise.
With lots of such messages before:
[sn_client::connections::messaging] ERROR 2021-06-18T18:12:17.275143000 [C:\User s\runneradmin\.cargo\registry\src\github.com-1ecc6299db9ec823\sn_client-0.61.1\s rc\connections\messaging.rs:439] Timeout while waiting for response to client re quest w/ id 87e3f438..: Elapsed(())
seems the network is ded