On a 1 Gb LAN, when I run server with "uftp 20GBfinger.txt", the file transfers to client as expected with no problems but it is very slow for large files. If I then run server command "uftp -R 800000 20GBfinger.txt", the file still transfers as expected and much faster; however now during the transfer, VoIP phones, security cameras, etc on the same LAN reboot and/or become unusable.
I tried setting Bandwidth Management rules on my router for UDP port 1044, but it appears the UFTP traffic doesn't go through the router (which makes sense). And I only have unmanaged switches at this time, so don't think I can control that at the switch-level.
I'm looking in the man pages and experimenting with -H, -M, and -P to try to find a way to not flood those other devices, but so far no luck. Can you suggest a way to keep those devices working during the UFTP transfer?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When using the -R option, the sender transmits at exactly that rate, regardless of any other traffic on the network.
You can either set the rate lower so as not to disturb other traffic, or you can instead use -C tfmcc which uses a congestion control scheme. When using TFMCC, the sender will tend to back off aggressively in the presense of other traffic, so you may end up with lower transmissions speeds.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just tried "uftp -C tfmcc 20GBfinger.txt" and also "uftp -C tfmcc:min=100000:init=400000:max=80000 20GBfinger.txt". Both results were similar to running "uftp -R 800000 20GBfinger.txt". Transfer rates were around 800 Mbps and VoIP and cameras froze up as soon as the file began to transfer in each test.
I also tried "uftp -R 800000 20GBfinger.txt -H <hex client="" id="">", attempting to see if a unicast transfer might not cause this issue, but I still got the same results.</hex>
I'm curious why only these certain devices are feezing up while the UFTP server and clients (Windows 10) remain functional. Perhaps it has to do with the ENC bits in the IP header that you mention in the man page; maybe the phones and cameras don't support this and that's the cause of why they freeze?
After the announcement phase, does UFTP continue to broadcast to all devices on the network, even during the transfer phase? If so, could that be flooding these devices and causing them to freeze? And further, if so, is there any way to use a client list to avoid broadcasting to all devices on the LAN (unless they're in thet list)?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, Dennis. Just checking back in. Pending any other recommendations, I will probably plan to just move the VoIPs and cameras into another subnet. I'm still not sure why these devices are being affected or why TFMCC doesn't seem to improve the issue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, Dennis -
On a 1 Gb LAN, when I run server with "uftp 20GBfinger.txt", the file transfers to client as expected with no problems but it is very slow for large files. If I then run server command "uftp -R 800000 20GBfinger.txt", the file still transfers as expected and much faster; however now during the transfer, VoIP phones, security cameras, etc on the same LAN reboot and/or become unusable.
I tried setting Bandwidth Management rules on my router for UDP port 1044, but it appears the UFTP traffic doesn't go through the router (which makes sense). And I only have unmanaged switches at this time, so don't think I can control that at the switch-level.
I'm looking in the man pages and experimenting with -H, -M, and -P to try to find a way to not flood those other devices, but so far no luck. Can you suggest a way to keep those devices working during the UFTP transfer?
When using the -R option, the sender transmits at exactly that rate, regardless of any other traffic on the network.
You can either set the rate lower so as not to disturb other traffic, or you can instead use -C tfmcc which uses a congestion control scheme. When using TFMCC, the sender will tend to back off aggressively in the presense of other traffic, so you may end up with lower transmissions speeds.
I just tried "uftp -C tfmcc 20GBfinger.txt" and also "uftp -C tfmcc:min=100000:init=400000:max=80000 20GBfinger.txt". Both results were similar to running "uftp -R 800000 20GBfinger.txt". Transfer rates were around 800 Mbps and VoIP and cameras froze up as soon as the file began to transfer in each test.
I also tried "uftp -R 800000 20GBfinger.txt -H <hex client="" id="">", attempting to see if a unicast transfer might not cause this issue, but I still got the same results.</hex>
I'm curious why only these certain devices are feezing up while the UFTP server and clients (Windows 10) remain functional. Perhaps it has to do with the ENC bits in the IP header that you mention in the man page; maybe the phones and cameras don't support this and that's the cause of why they freeze?
After the announcement phase, does UFTP continue to broadcast to all devices on the network, even during the transfer phase? If so, could that be flooding these devices and causing them to freeze? And further, if so, is there any way to use a client list to avoid broadcasting to all devices on the LAN (unless they're in thet list)?
Hi, Dennis. Just checking back in. Pending any other recommendations, I will probably plan to just move the VoIPs and cameras into another subnet. I'm still not sure why these devices are being affected or why TFMCC doesn't seem to improve the issue.