steffenmand

Detach and then reattach choosing the new cache drive

Thanks for your thorough explaination. but no its not a hardware issue. running enterprise level gear in a top end datacenter. the latency is based on google response times and not the internet itself

You are not counting the thread response time into the equation. The delay you get there will end up giving you slower responses. In my case that is 2500-2800 ms. Ie. i lose 2,5 second per verification. But ofc. if you work with very few threads it is the case, but with a high amount of threads you cant really increase it further without getting throttling

But as far as i saw the new upload thread doesnt start before the old one was verified - am i wrong here?

If data is lost by the provider it can fuck up - but most can be recovered then using chkdsk - it just takes a long time when you have a lot stored

i think you mean mbit :-P Yes. It all depends on the response time you have. Speed is not the issue, it's my response time to google's servers You're just lucky to be closer. Plus i got upload verification on, that also cuts off speeds on uploads I get around 2500-2800 ms response time pr. thread and then instant download. So the less calls and the bigger download would do wonders for me

and this is what would fix it! people using 100 MB chunks are usually high bandwidth users, so forcing minimum download of 20 MB or more should be fine! right now we just have a bottleneck with the response times slowing down downloads. i would go for for 100 mb downloads anyway

Look at my Edit, i did acknowledge it was there - remember so as well - but they removed in an update or two later (updates almost every other day back then). Yes, but that was with a use-case of partial downloads in mind. I do remember them highlighting issues with responsiveness as being the reason why we couldn't go above 20 MB, but the limitations of max amount of reads pr. day. pr file. is of course a valid argument as well. Was unaware that they kept it for the remaining providers. Remember saying that those block sizes should be intended for high bandwidth use ie. minimal download of 50 MB-> 100MB. Still think that is the case today. In general the desire is to allow high bandwidth to utilize speeds. The bottleneck today is the responsetime pr. thread causing speed to massively drop! A good solution is 100 MB chunks = minimal download atleast of 20 MB, again a lot of "if that then that" I will reach out to Christopher about getting my old feature back on track

Would also love a feature to make a "raid" over cloud accounts. Would also make it possible to utilize multiple gdrive accounts to increase the thread count or just avoid throttling in general. Plus its a great protection vs data corruption. But ofc. it would require more bandwidth, but for high-end 1 gbit or 10 gbit users that shouldnt make a big difference

We never had bigger chunks than 20 MB (me who early on pushed for higher blocks than 1 MB) EDIT: Or actually we did, but they removed it within no time. If it really was a provider issue, it should be an easy "if that then that" solution as they know what provider we are building drives on Their worries was the drive being not responsive as chunks would take time to download - which wouldnt be the case with the right setup Just seeing the limitations now from using that block size as both servers and internet get faster as well as the data getting bigger and bigger

Recently got 10 gbit internet with my server, however are seeing that the maximum size of 20 MB in blocks are causing speeds to be limited around 40 MB/s due to the response time delays pr. thread Would love to request that it gets possible to increase the block size further, to acommodate increasing internet speeds over the coming years. maybe a 50 MB block size and ofc. a warning showcasing that high internet speeds are required (just like with the minimal download size)

Its all cores! Goes completely bananas and makes the server unresponsive and leaves me fighting to cancel pinning. Got 12 drives divided on 5 accounts. Some of them made with pre-release - dont know if that effects it ? Will try to do as asked. Must add that i didnt have the issue 5 months ago! Something which came with newer versions

So the massive CPU usage can not be avoided ? My server ends up a cluster fuck as 12 drives pretty much are pinning all the time as when one finishes a new one begins. I got this error on multiple cpu's both xeon , i7-7700 and now i7-8700K

Disabled pinning and the problem is gone - so the cpu usage is most definately related to the pinning feature. so until solved i will have to live without pinning enabled

Do you have multiple drives on multiple accounts ? (i got 12 drives on 5 accounts) Usually goes crazy bananas right after it starts pinning. The rest of the time it is like you say - less than 5%. Upload, Download whatever - only with the pinning it goes crazy!