UDT Frequent Asked Questions |
3. Why can't I reach the expected high throughput with Gigabit NIC?
4. Why does the data sending always cost 99% of the CPU time?
5. Can you give me some hints in tuning the performance?
6. How do I use a fixed port number at server side?
7. Can I modify the options at any phase of UDT?
8. Does UDT care about the byte order conversion between different platforms?
9. Why can't the UDT connection be set up? Why listen or connect call dead?
10. Is the UDT connection secure?
14. Is UDT only suitable for bulk data?
15. What's the relationship between UDT and SABUL?
The
main purpose of UDT is to provide a high performance transfer interface to
distributed data
intensive applications over a wide area network, where TCP seldom works well for
efficiency and fairness reasons.
There is no explicit standard to determine when to use TCP and when to use UDT.
Generally speaking, if you are not satisfied with TCP's performance, UDT is
probably what you need, especially in high speed networks where a small number of bulk sources share the abundant bandwidth.
Yes, you can do it. But please be aware that your application may use a large amount of bandwidth and may be regarded as attack or improper use of network by ISPs and firewalls. In addition, UDT's impact on the Internet is not comprehensively tested yet.
There
are many factors that can affect the throughput, especially for Gigabit NICs.
First of all, you need to test it using some other benchmark tools like IPerf. They will give you
the highest performance for the current configuration. If UDT has
similar performance, then UDT is all right, and you need to tune your network
settings.
If UDT's performance is much lower than the performance obtained from the benchmark, then
modify the UDT options.
Finally, your applications affect the transfer speed. Any data
intensive applications can cost substantial CPU time in computing and memory
replication, which will affect UDT's performance. Try to test the throughput
with the example application in the UDT SDK.
That is
because the data sending uses a busy waiting timer. Don't worry about it, if
there is no data to be sent, the sending thread will be blocked. If there is
work other than data transfer to do in the application, the data sending thread
will generally be given a lower priority so that the other work will still be done.
However, it is important to have a high precision timer without busy waiting. We would
appreciate it if anyone can contribute such a timer to this free software.
Please read the Configuration section of the UDT Tutorial for the answer. The default parameter should work fine for most cases.
The parameter that affects the performance most is UDP buffer size. Try to tune them if the default does not work well.
Please refer to API reference: open.
No, currently the options can only be set up before the connection is up (before listen or connect is called).
No, the application should care about the conversion itself. However, UDT does work between different platforms even with different byte orders.
The
most likely reason is that at least one of the server or client sides has
multiple addresses, and UDT is bound to an address different from what you use
in the application. To solve the problem, explicitly set the UDT_ADDR option.
There can be other reasons, such as domain name lookup failure. Try to use an
explicit IP address if possible.
No. If you need a secure connection, you should add other mechanisms onto UDT in the application.
Packet loss can be caused by a busy receiver. For example, if there is large block memory copy, arriving packets will be dropped because the CPU does not have enough time to process them. Try to avoid large block copy during data receiving and try to use blocking receiving to alleviate the problem.
Yes.
The peer side will detect the broken connection with the timeout mechanism. However, it (the peer side) will not throw out any exceptions or signals until you call any UDT methods, when you will get a connection broken exception.
No, UDT can transfer a data buffer from 1 single byte to multiple tera-bytes, as long as your system can provide enough resources.
UDT removes the TCP connection from SABUL and enhances the congestion/flow control.