hmhmmm
yeah … i’m using the cli since i didn’t yet set up a python environment on the cloud machine and just wanted do a “fast test” … which ironically the official cli seems to be not the ideal tool for 
but why would adding 6 byte to an archive take longer than a few ms …? (and why is the slow operation the default …? shouldn’t the default be fast and powerful … while the cheaper and slower one be hidden behind a flag…?)
What is this archive?
Million dollar question.
we’re at 30 minutes … not sure i should still expect success for this
I think of it as a folder that holds 1 or more uploaded chunk addresses, file names, metadata.
Where is this, on the network, on my disk or ?
On the network, to my knowledge everything upload even a single file via the cli gets it’s own archive and it is slow to create.
Is this what was once called the datamap?
but since i still only upload 3 chunks with cli (which uses the archive) this means it’s a data-struct that gets generated client side, then serialized to a bytestream … which then gets chunked and uploaded …
does the cli/API upload serialized RUST objects when uploading archives? or is it the bytes of a in-memory gzip or so?
No, even a single chunk public data goes into an archive using the cli. (I think) team should confirm, I am really just starting to wrap my head around this.
let me bring this a bit back to topic
interesting how slow the price reacts when people don’t buy/sell in one go but slowly trade in 5-10k ANT volumes … and not the 50-100k in one go moves xD …
@dirvine how about simply dropping the archive function for now … stripping out not needed functionality and that’s not adding any functionality; just complexity (and some saving maybe … on large data blobs that can be compressed well)
Just catching up on the thread, but this echos back to the QUIC issue still, imo.
I’ve had recent uploads that have failed due to taking out my wifi - as in all hosts on the network, while the wifi router gasps for life…
I can’t imagine calls to the smart contract are causing that. I can imagine those calls not getting through though.
The whole angle where it works better in a data centre also plays into this theory.
true … we were told “a lot of stuff was changed - it’s silly to focus on the 4MB” … it never was revisited in any public test … the window size @neo suggested never was tested … and the network stopped working for me with introduction of the 4MB chunks … and since then i can participate at best via vps …
Please no… that’s a key data structure for CLI and AntTP! 
For me, archives haven’t been much slower than any other chunk being uploaded. They’re all slow! Ha!
I think there has been more research around it, but pretty much this.
Imo, there is something fundamentally not right at the lower level, that is knocking everything else off.
I am not sure we have a QUIC issue, if you look at the go impl, it went with a much higher max window than the rust one.
I am not sure here guys as it seems if some clients are working well in some configs then that is the change here between working and not working. I mean at the client, not at the node or chunk size or anything, but looks like the client somehow as that is outside the network and looking in. So if some are working and some not then I think we need to consider why.
There may be many more optimisations on the node, I think we all feel that, but this upload issue seems fragile at the client side.
Do you think something else would be capable of dropping my wifi? Honestly, I’ve never seen that before, which makes me think something isn’t right there.
Until I added a MikroTik router, hosting nodes would do similar things.
The router isn’t the worst either - the fritz box routers are relatively premium for ISP provided jobbies.
Edit: note that the wifi router isn’t doing NAT - the mikrotik is. The wifi router is literally only doing wifi.
Edit2: interesting thread too: Big file upload problem - discussion
No need. If you don’t want to use it you don’t have to. I was using my own structure for this but have switched to using Archive for compatibility - which as you can see from Southside’s upload means people don’t have to use dweb to upload a website that can be viewed in dweb.
Maybe the Python API doesn’t allow you to ignore the Archive yet, but it will be there. It has to be!
all good - python is awesome as always 
was just using the cli
