You claim Tardigrade to be “20% Faster” than your competition, so I compared this in real world.
Uploading 10 GB:
Amazon: 56.284s (uploaded 10.11 GB)
Tardigrade: 809.934s (uploaded 34.43 GB)
Downloading 10 GB:
Amazon: 62.659s (downloaded 10.17 GByte)
Tardigrade 439.691s (downloaded 12.75 GByte)
Deleting one 10 GB file:
Amazon: 0.774s
Tardigrade: 71.774s
Have others compared Tardigrade to Amazon S3?
My tests came to a similar conclusion too, however you can see in the forums that this appears to be an known issue which is being worked on. They are still in beta, of-course.
What strucks me is the time needed to delete files… On any file system, deleting a file is instant because it’s simply about flagging space used by a file as free, it’s not supposed to write all over the file to delete it…
I know there’s a trash on STORJ nodes, so deleted files get moved, but still: unless the trash is on a different drive (but does that ever happen?), it should still be a matter of tenth of seconds for moving a file.
What could possibly take 70s for deleting a file?
Even though it’s still a beta software, I’ll admit it’s a bit concerning ^^’
I’m glad some people test tardigrade as real users though: I’m sure it’s gold info for StorjLabs engineers. Let’s hope they improve performance in the next weeks 
The file is split up in segments of 64MB (default, it can be changed). To delete the file, the uplink has to tell the satellite to delete every segment and it seems to do that in series.
I tested this with 4 different files of sizes 64M, 65M, 128M and 256M.
Deleting 64M file took 1.523s.
Deleting 65M file took 1.728s
Deleting 128M file took 1.728s
Deleting 256M file took 2.847s.
So, it takes time to delete every segment, and they are deleted in series. The uplink program could probably be made such that it issues the delete requests at once, then it would be faster.
I think I read somewhere that it was suggested to return succes to the user immediately and then the satellite can delete the pieces in the background.
I deleted a 3.4GB file and it took 40s
It’s similar to my tests (Got my Tardigrade invite. Decided to run a couple of speed tests) - it took 14-24 seconds to delete a 915MB file.
as i know deletion low speed is known issue, and storj dealing with it.
But it interesting, there shold be always 80 pieces, then time shold be always the same or preaty much same.
Each file is split into 64MB segments, then each segment is split into 80 pieces.
You can set the uplink to use different sized segments though.
Pentium100 already said about segment (currently up 64 MB by default) so you need to multiply 80 by round_up (file size / 64 MB) to get total number of pieces stored on nodes.
Also 80 pieces per segment is only an initial values for freshly uploaded files. It slowly decrease over time until ether file is deleted by owner or hit minimum repair threshold (currently 35 pieces per segment) and satellite begin repair process to restore number of pieces back to initial value (=80 atm).
So actual number of pieces per file also depend on file age and little bit of “luck”/random.
Then satelite shold do it on background, and reply only that it get command. after it can slowly delete it in1h or in 24h, when is more priority things are low.
Yes, i agree satellite should report “completed” back to uplink as soon as it marks all segments used by file for deletion in satellite local database.
And do actual communications with storage nodes for pieces deletion in the background. There is no point for uplink to wait while this process is fully finished. It can take a LOT of time to actually finish as some nodes could be overloaded or even be offline at the moment of file deletion.
@flo interesting, let’s see how this improves when we come closer to production. At the moment the network does not feel fast at all, I also did some testing.
@flo Can you share were you are doing your testing from, what satellite, and what Amazon region? The results on performance can vary a ton based on your connection, and where you are. Sometimes faster, sometimes slower, sometimes on par.
Starting this week we have an entire team devoted to making Storj faster than Amazon S3, and increasing performance to its max. Delete is definitely too slow, and we have some changes in the pipeline to make it faster.
@super3 the server is in Germany, and I’m on the europe-west-1 satellite; S3 region is Germany.
It’s hard to be on par (or even faster) than Amazon if uploading 10 GB requires more than ~34 GB to be uploaded to Tardigrade.
I remember being told that we’re on par with Amazon in the Q3 2019 town hall - I don’t agree 
@flo
Can you describe your setup?
PC? windows, linux? CPU?
Connection?
Router?
Did you uploaded 1 file or it is multiple files?
Does Amazon also encrypted bandwidth?
Your DNS setups? Local dns or Google?
It’s hard to be on par (or even faster) than Amazon if uploading 10 GB requires more than ~34 GB to be uploaded to Tardigrade.
Depends on the your upload bandwidth since the upload is in parallel rather than linear. It can be faster, but it can be definitely harder if you have slower connection.
I remember being told that we’re on par with Amazon in the Q3 2019 town hall - I don’t agree
Well that is because you are correct. Still work to do. 
Has anyone tested uncompressed files vs compressed files when upload to Amazon S3 vs Tardigrade?
I test with random noise files which are incompressible. I see upload speeds of slightly below 250mbit, with gaps in-between the segments on a 500mbit upload connection. Assuming those gaps can be removed by doing DNS and caching on the satellite you’d be looking at an effective upload speed of 80mbit after taking RS inflation rate into account.
Edit: location is the Netherlands, using europe-west-1
Shouldn’t make much of a difference.
