Just re-tried my big 35.7GB upload again, and it worked
Trying to download it now.
Itās public if anyone else wants to try:
mixtral-8x7b-instruct-v0.1.Q6_K.gguf af4c83f1c16fbc213661f808a9fb1654a0a433617889d61a310ec3c86cec631b
Just re-tried my big 35.7GB upload again, and it worked
Trying to download it now.
Itās public if anyone else wants to try:
mixtral-8x7b-instruct-v0.1.Q6_K.gguf af4c83f1c16fbc213661f808a9fb1654a0a433617889d61a310ec3c86cec631b
Right now, we dont start uploading until all chunks are done. But chunks themselves is a streaming process, so we could well start uploads before chunking is finished, eg.
Itās not an optimisation weāll get into yet though, I think.
Something very wrong here. It downloads without error but is only 1.8K!
time safe files download mixtral-8x7b-instruct-v0.1.Q6_K.gguf af4c83f1c16fbc213661f808a9fb1654a0a433617889d61a310ec3c86cec631b
Logging to directory: "/home/peter/.local/share/safe/client/logs/log_2024-01-31_13-41-30"
Built with git version: a15b141 / main / a15b141
Instantiating a SAFE client...
Trying to fetch the bootstrap peers from https://sn-testnet.s3.eu-west-2.amazonaws.com/network-contacts
Connecting to the network with 43 peers
š Connected to the Network Downloading "mixtral-8x7b-instruct-v0.1.Q6_K.gguf" from af4c83f1c16fbc213661f808a9fb1654a0a433617889d61a310ec3c86cec631b with batch-size 16
Saved "mixtral-8x7b-instruct-v0.1.Q6_K.gguf" at /home/peter/Downloads/mixtral-8x7b-instruct-v0.1.Q6_K.gguf
real 0m23.035s
user 0m2.368s
sys 0m1.225s
$ safe -V
sn_cli 0.89.29
Wow, SafeNetwork compression is legit ā The Weissman score here must be off-the-charts!
Seems to have worked? Itās trying to verify now, so I guess it finished all the chunk uploading?
Hmm⦠I started the upload forgetting to make it public, and this only partially completed. I then re-uploaded remaining chunks with -p, but it seems it didnāt apply that to the whole file, so perhaps itās part private and part public?
Iāll see if re-chunking and uploading from scratch helps with that.
yeah, shall be.
just give it sometime to complete the verification
as long as the head chunk got uploaded when -p
is set, all chunks will then become accessable.
so there is no part private and part public
.
Iām running Windows 10 and I had the same issue with Windows deleting my safe executable downloads a while back. Iāve now been running safe.exe
and safenode.exe
successfully by creating a directory exclusion from antivirus scans in Windows Security.
To do it, I went through the Virus and Threat Protection - Virus and Threat Protection Settings - Manage Settings - Add or Remove Exclusions - Add an Exclusion
page in Windows Security.
I added an exclusion for the C:Users\<user>\safe
directory, my default for safe
downloads. Microsoft Defender Antivirus really doesnāt like safe.exe
and safenode.exe
.
Ok, not sure what the issue is in that case. Iām downloading it successfully so far, with 4gb downloaded, so not sure why happybeing canāt download the full file.
Is the āHead chunkā the first, or last to be uploaded?
tried to download it as well, which gives downloading a data_map contains 16 chunks and then downloading 73202 chunks.
ā ² [00:00:33] [########################################] 16/16
ā “ [00:00:33] [########################################] 16/16
ā [00:00:00] [----------------------------------------] 0/73202
ā [00:00:00] [----------------------------------------] 0/73202
seems it is ok?
could you give me the log of that 1.8K download? thx
itās randomized
, could be in any position
I was too positive there, itās just the same.
I also just thought that other testers using Windows might have had a problem with the safe.exe file, but didnāt report it, just stopped testing.
Thatās why I sent a message to @chriso that Windows treats this file as a Trojan, I checked Windows Security - Protection History, all attempts to run the client
are marked as:
Blocked threat - serious status
Detected: Trojan:Win32/Wacatac.B!ml
Status: quarantine
These files will be deleted automatically.
Date: 31.01.2024 10:39
Details: This program is dangerous and executes the commands of the attacker.
Applies to items:
file: C:\Users\gggg\safe\safe.exe
Iām not sure, but I donāt think itās enough to add an exclusion in the Windows security settings, because in a future network less advanced users will see the error and stop using SafeNet.
I downloaded the latest version of the client and reuploaded a directory several times (at first 19 chunks were failing).
17 chunks have been uploaded successfully eventually, but despite numerous attempts, two chunks still cannot be uploaded.
The last log
log_2024-01-31_15-22-02.zip (58.9 KB)
Honestly, this is the first Iāve heard about this issue. Thanks for the information.
I think weāre going to need to look into this. I guess we need to determine first of all, why does the OS flag our binaries, then what we can do it about it.
Might need to get in touch with Microsoft somehow.
After looking at RAM use a little more it seems to be released. the two nodes I lost were at ~3GB RAM when they got booted but I have others that got near there too and then dropped way back down.
So it would seem that if there is enough room for spikes it will level out again.
Are the faster and larger uploads just a bigger burden to bear?
Seems itās failing to report the error at the end of the log, and saving the file regardless. See:
safe-client.zip (32.5 KB)
shall be ok now.
can have a re-upload.
yeah, could be a reason for it.
the better performed client does encouraging quite more uploads than previous testnet runs.