Unexpectedly large effect on transfer speeds when on wifi #649
Description
Activity
The project has been compromised because of LimeWire acquisition and it uploads your files to its cloud. Use PairDrop.net instead.
#663- 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: ***@***.***>Reacted by yash-711
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: ***@***.***>Reacted by zhzhang
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!