Hi,
During the last week or so I am checking if UFTP can help me send big amount of data to large number of clients.
File range from 2GB to 100 GB, using 1gbit interfaces, LANs and Ethernet switch.
Using UFTP version 4.10.1, no encryption.
While testing I noticed that UFTP is having trouble with retransmit NACKs.
No matter if I am using block size 1300 or Jumbo frame with block size 8800, I get the same results.
Sending starts relatively good with an average speed of 300 Mbit and less than 1% NACKs.
And from the second pass forward the speed slows dramatically to 50 Mbit and less.
In the end I get an average speed rete of 120 Mbit to 1300 MTU and 200 Mbit to 8800 MTU
If I use fix rate (500 Mbit or even lower 150 Mbit).
uftp -B 104857600 -R X -r 2:0.01:15 -s 50 -M … -I … -H …
the first pass goes well again and I get about 1% of NACKs or less depending on the rate I choose.
And from the second pass and forward the number of NACKs for each section decrease only by 10% or so. (if I get 50000 NACKs on section 1 in the first pass, second pass I will get 45000 NACKs, third 4100 NACKs …).
So eventually for every fix rate speed I choose I will get longer sending time then using tfmcc.
How come the completion pass fail to complete the info with fix rate and the tfmcc taking longer time than expected – using only tenth of the bandwidth available?
Why the completion passes receive so many NACKs back after the first pass got a lot of better results?
Thank you very much.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Given the size of these files, it's possible that there's a large amount of time spent seeking to the proper portion of the file to read/write the relevant blocks after the first pass.
Are you using traditional spinning hard disks on either side or are all using an SSD?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Given the size of these files, it's possible that there's a large amount
of time spent seeking to the proper portion of the file to read/write the
relevant blocks after the first pass.
Are you using traditional spinning hard disks on either side or are all
using an SSD?
Hi,
During the last week or so I am checking if UFTP can help me send big amount of data to large number of clients.
File range from 2GB to 100 GB, using 1gbit interfaces, LANs and Ethernet switch.
Using UFTP version 4.10.1, no encryption.
While testing I noticed that UFTP is having trouble with retransmit NACKs.
No matter if I am using block size 1300 or Jumbo frame with block size 8800, I get the same results.
uftp -B 104857600 -C tfmcc -r 2:0.01:15 -s 50 -M … -I … -H …
uftpd -B 104857600 -c 20971520 -U … -D … -I … -M …
Sending starts relatively good with an average speed of 300 Mbit and less than 1% NACKs.
And from the second pass forward the speed slows dramatically to 50 Mbit and less.
In the end I get an average speed rete of 120 Mbit to 1300 MTU and 200 Mbit to 8800 MTU
If I use fix rate (500 Mbit or even lower 150 Mbit).
uftp -B 104857600 -R X -r 2:0.01:15 -s 50 -M … -I … -H …
the first pass goes well again and I get about 1% of NACKs or less depending on the rate I choose.
And from the second pass and forward the number of NACKs for each section decrease only by 10% or so. (if I get 50000 NACKs on section 1 in the first pass, second pass I will get 45000 NACKs, third 4100 NACKs …).
So eventually for every fix rate speed I choose I will get longer sending time then using tfmcc.
How come the completion pass fail to complete the info with fix rate and the tfmcc taking longer time than expected – using only tenth of the bandwidth available?
Why the completion passes receive so many NACKs back after the first pass got a lot of better results?
Thank you very much.
Given the size of these files, it's possible that there's a large amount of time spent seeking to the proper portion of the file to read/write the relevant blocks after the first pass.
Are you using traditional spinning hard disks on either side or are all using an SSD?
SSD both client and server.
בתאריך שבת, 4 באפר׳ 2020 ב-23:27 מאת Dennis Bush dennisbush@users.sourceforge.net:
SSD both client and server.