Unexpectedly large effect on transfer speeds when on wifi #649
Comments
|
The project has been compromised because of LimeWire acquisition and it uploads your files to its cloud. Use PairDrop.net instead. |
|
This issue was posted a few days before that massive change, so perhaps
it's still relevant to those of us using a self-hosted old version. But I
don't think we will get an answer.
…On Thu, May 1, 2025 at 7:04 AM yash-711 ***@***.***> wrote:
*yash-711* left a comment (SnapDrop/snapdrop#649)
<#649 (comment)>
The project has been compromised because of LimeWire acquisition and it
uploads your files to its cloud. Use PairDrop.net instead.
#663 <#663>
—
Reply to this email directly, view it on GitHub
<#649 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACXLCUODAYIKYLZPIGAOITT24GTNDAVCNFSM6AAAAABWFVXBCGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNBUGEYTGNZQGQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
sad to see a great tool ruined with all other same type of tools like sharedrop.io and file.io |
|
It is sad but the owner also has the right to do whatever he wants with his
code. He was kind enough to provide the source code under an open license
and even make docker compose files so I just host my own instance. So its
not a big deal, I hope he got some money for his work. 👍
…On Thu, May 1, 2025 at 13:30 yash-711 ***@***.***> wrote:
*yash-711* left a comment (SnapDrop/snapdrop#649)
<#649 (comment)>
sad to see a great tool ruined with all other same type of tools like
sharedrop.io and file.io
—
Reply to this email directly, view it on GitHub
<#649 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACXLCUPJLDDDP4QK3E6G36T24IAXFAVCNFSM6AAAAABWFVXBCGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNBUGY3TQOBRHA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Continued from #414.
Thank you for this amazing and free tool, but I found that using wifi has a strange and unexpectedly large effect on the transfer speeds.
Here is some info about my first test:
This 2.7mBps is very slow and unexpected for a local file transfer.
Then I made two more tests:
Putting the windows PC on a gigabit wired connection improves the speed massively - to about 15mBps or 66 seconds.
Putting the iphone on a gigabit wired connection (lol) improves the speed even further - to about 27mBps or 37 seconds. (???)
So, it seems that the theoretical maximum of this tool when using 2 wired gigabit devices via snapdrop.net, is around 27mBps or 216 mbps. This is very good!
But it also seems that the technology suffers a lot when one or both devices are on wifi, even though the wifi conditions are very good and both devices are capable. In this case, transfer of large files is not practical.
What exactly is it with wifi that destroys the transfer speed of this tool? It's not because wifi is only half-duplex (generally only one device can send/receive at the same time on wifi) - we still see a 50% difference between the tests where 1 device or both are wired. So it is not the devices competing for airspace. It seems that wifi is not "reactive" enough or something, which kills the transfer speed.
Can this be improved, or is snapdrop simply not a proper tool to transfer many gigabytes of files where one or both devices are on wifi? Is the underlying technology just bad when it is used on wifi? If this is the case, we could add some benchmarks to the README. When developers come across this tool and read that the file transfer is local, they expect it to max out the connection.
I hope I don't come across as ungrateful, I would just like to contribute and learn something new. Thanks for this amazing tool!
The text was updated successfully, but these errors were encountered: