steffenmand

no, no no. 
 
You're overlooking the really important part here: SYMMETRICAL. that's 10Gb up and down!  

Yup, seems kind of weird.
 
However, there are cases where this makes sense. For instance, if you have multiple volumes/partitions on the single disk. Changing the label doesn't make sense in this case.
 
However, if it's the only partition/volume, then it would make sense to update it. 
I've included the suggestion.
 
https://stablebit.com/Admin/IssueAnalysis/24913

Will try to get a screenshot of a maxed out upload and download at the same time

Just wanted to share how awesome stablebit makes my google drive connection As soon as i can get the same in download i couldn't ask for more! Really an awesome application!

youre right, we have a lot of providers here with more popping up all the time. increases the bandwidth and prices for everyone. i think our government set a goal that everyone in te country must have access to 100 mbit by 2020.
When a future beta includes this change im gonna grab a nice screenshot to promote stablebit a bit, it is really awesome and A LOT more stable than all other options available.
 
hope it makes it in soon ;-)

The change of partial chunk size is all i wanted This will make it possible to utilize the speeds in download as well! The partial read is just great, but the 2mb chunk size just made it slow down the connection incredibly much!
 
Scandinavia has really good internet, especially as we got fiber connections coming up all over the country (Denmark here). Being a small country has its benefits as its cheaper to get the cables everywhere!
 
Stablebit truly shows its power here, and it works incredibly well! - as soon as the download can get its speeds up

Hi,
 
I noticed that after a write thread finishes the upload verification downloads the content to check if its correct. however while it downloads no new upload threads are started - shouldnt it start uploading the next chunk, while it downloads and checks the former one? Guess you are using some sort of queue system and that the file could just be added to the queue if it needs to be reuploaded.
 
Any specific reason why it runs like this? could imagine a little more speed if it can continue upload meanwhile

They did respond, but it's ... well more of "developer" stuff. However, the outlook is good. (basically, it looks like the calls per second are within acceptable values).  
 
It looks like Alex hasn't had a chance to respond (they replied on Wednesday... so really bad timing, basically). But hopefully, the ball is actually rolling!

Excatly what i wanted :-D let my speed be unleashed!
 
hopefully this will make it to amazon as well when you get the answers from them as well :-)

Yeah, it's basically just a flip of a switch if this works. All providers use a common infrastructure for chunking.

Specifically, scales better than Amazon's able to accommodate for (because they're not throttling on the server side properly).  

Me too, that's the way that I read it initially also. But the difference in allowed bandwidth would be huge if I'm wrong, so I really want to avoid any potential misunderstandings.
 
As for larger chunks, It's possible to utilize larger chunks, but keep in mind, the size of the chunk controls the latency of read I/O. So if you try to read anything on the cloud drive that's not stored locally, that's an automatic download of at least the chunk size before the read can complete. And we have to keep read I/O responsive in order for the drive's performance to be acceptable.
 
In my testing a 1MB limit seemed like a good starting point in order to support a wide variety of bandwidths.
 
But yeah, if you're utilizing something like Amazon S3 (which has no limits I assume) and you have a Gigabit connection, you should be able to use much larger chunks in theory. I'll explore this option in future releases.

Thanks for being so open :-)
 
Regarding their limits i read their term "a client instance" as an user connection and not a representation of your application!
Should their limits limit the amount of threads, could it not be possible to allow larger chunk size on amazon? like 5 mb chunks or maybe even 10mb.
Sitting on a 1 gbit line i would love to be able to utilize the fastest speed possible. Then rather have large chunks and more threads than smaller chunks and less threads.
 
But hopefully they will get you on track for the final release so we can get some purchases going for stablebit :-)

I'm pretty sure the limits are quite high. I'm getting around 33 mb/s with netdrive (which is far inferior to Stablebit Cloud Drive). I think the issue must be around the max amount of threads and therefore the amount of api calls due to each thread making calls.
 
Thank god it was more people than me who showed an interest in getting Stablebit up and running which hopefully will lead to them starting to reply!
 
All in all, your product is awesome

Really sad.. have you done some fixes to get your status changed again?
 
Guess one of the major issues could be the thousands of api calls due to the small chunk size and multiple threads. This could be solved by increasing the chunk size and limiting the amount of threads.
 
Look forward to reading the details about as this is really sad news for me :-( Stablebit Cloud Drive really is a great upcoming product and the cheap cloud space would really make it awesome product so it is both a loss for amazon and you as well!