I’m not sure what you mean - there isn’t a queue to join. Each node tries, if it fails tries again after 3 minutes until it is lucky. Who gets in is a matter of chance each time they ask, not how long they’ve been waiting.
Mine get a time out error then I need to restart the joining process as the process is terminated after the timeout error
increasing this value will tell the client to wait longer before giving up on a files get or cat command
Exactly what command are you using to join?
You said something last night about this that I meant to pick you up about and then the waitress arrived and distracted us with her Canadian accent from Stonehaven…
The timeout doesn’t mean your node is no longer waiting to join, it means the network didn’t answer its join request before the time-out period so it gave up and will try again. You probably don’t want to increase that time-out or your node will take longer to give up and try again.
If you wait you should see either further timeouts (because the network isn’t responding) or further join request responses (until it gets in).
I’d have to double check next test net but my logs show the retrying message every 3 minutes the they eather die and the log file stops or they join. The network. But if they don’t join the definatley die
I’m using the safe node join command
That’s different behaviour to me (on Ubuntu 20). What OS and version?
same here ill keep an eye on it but on previous test nets id start safe join command and when i would check the logs stopped on the hour it died so i would restart the safe node join command
Maybe Wikimedia Commons?
There’s a SPARQL query service where you can ask for images of specific sizes etc
I really feel it’s worth restating this all in one place because it’s a pretty amazing observation being made by @Josh - memory usage for a node is ~50MB instead of ~650 MB because maidsafe chose to use musl compiler instead of gcc. Totally incredible.
Interestingly musl binaries are slightly larger when compiling vdash:
-rwxrwxr-x 2 mrh mrh 7143896 Jan 23 13:28 target/release/vdash
-rwxrwxr-x 2 mrh mrh 7664296 Jan 31 16:20 target/x86_64-unknown-linux-musl/release/vdash
Memory and resource use is considerably less with musl (using htop):
VIRT RES SHR
803M 9372 4716 x13 threads (release)
32768 6848 2440 x13 threads (release/musl)
The binary is larger in the latter case because the standard C library is statically linked.