UDT Frequent Asked Questions |
3. Why I cannot reach the announced high throughput with Gigabit NIC?
4. Why the data sending always cost 99% CPU time?
5. Can you give me some hints in tuning the performance?
6. How to 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 the UDT connection cannot be set up? Why listen or connect call dead?
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 application over wide area network, where TCP seldom works well for
efficiency and fairness reasons.
There is not explicit standard to tell that 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.
Theoretically, you can do it. But it is highly recommended that your application is tested at a private environments before you deploy it into any public network.
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. It is
generally the highest performance for the current configuration. If UDT has
similar performance, then it is all right, and you need to tune your network
settings.
If UDT's performance is much lower than the performance got from the benchmark.
Try to modify UDT options.
Finally, your application may have impacts to 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 the other work will still be done.
However, it is important to have a high precision timer without busy waiting. We
appreciate if anyone can contribute such a timer to this free software.
Please read the Configuration section of UDT Tutorial for 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 connection is up (before listen or connect is called).
No, the application should care about the conversion by itself. However, UDT does work between different platforms even with different byte orders.
The
most possible reason is that at lease one of the server or client side has
multiple addresses, and UDT is bound to an address different from what you use
in the application. To solve the problem, explicitly set UDT_ADDR option.
There can be other reasons such as domain name lookup failure. Try to use
explicitly IP address if possible.
No. If you need 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 has not 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 timer out 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 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.