Re: [UDT] UDT Resource Usage

[Ben P. <ben...@ra...>]

Hi,

Thanks for getting back to me. The increased buffer size certainly 
explains the differences in memory usage.

Unfortunately I haven't had time to further investigate the CPU usage 
yet although I can confirm that I was using 2.2.

Thanks a lot for your help,

Ben Page


Yunhong Gu wrote:
> 
> 
> Hi, Ben,
> 
> As you know that UDT was designed for high speed networks, the default 
> protocol buffer size (40MB) is much larger than the common system socket 
> settings. You can use "UDT::setsockopt" to modify the protocol buffer size.
> 
> E.g.,
> UDT::setsockopt(client, 0, UDP_RCVBUF, new int(1000000), sizeof(int));
> 
> When NO_BUSY_WAITING is enabled, UDT should not use much CPU time, so 
> that was strange. Are you using version 2.2 or 2.1? If you are using 
> 2.1, can you give a try of 2.2? I just tested it on my Windows XP 
> machine, and it costed about 2% CPU when sending data at 100Mb/s.
> 
> Thanks,
> Gu
> 
> Yunhong Gu, Research Scientist
> 
> National Center for Data Mining
> University of Illinois at Chicago
> SEO 700, M/C 249, 851 S Morgan St
> Chicago, IL 60607-7045
> T (312) 413-9576
> F (312) 355-0373
> 
> On Tue, 17 Jan 2006, Ben Page wrote:
> 
>> Hello,
>>
>> I am currently evaluating the use of UDT for a new internet-based 
>> application I am working on. I have had good success integrating your 
>> library with my code but have noticed that when running the new 
>> version of my application with UDT the CPU usage jumps to near 100% 
>> and the memory usage is also greatly increased.
>>
>> While I understand that UDT is designed for high-bandwidth wide-area
>> networks and mine is an Internet-based application I would be interested
>> in any insight you might have into the highly resource-intensive
>> performance I have noticed.
>>
>> I am currently building UDT using the Visual Studio solution file
>> available with the latest release ( in which the NO_BUSY_WAIT flag is
>> set). I am using a statically-linked version of the library but apart
>> from that have made no changes to the build settings.
>>
>> The problem is more obvious when sending data than receiving. I'd be
>> really grateful if you could provide any insight into what I could be
>> doing wrong or where I should look while trying to fix the problem.
>>
>> Very Best Regards,
>>
>> Ben Page
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
>> files
>> for problems?  Stop!  Download the new AJAX search engine that makes
>> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
>> _______________________________________________
>> UDT-general mailing list
>> UDT...@li...
>> https://lists.sourceforge.net/lists/listinfo/udt-general
>>


-- 
Ben Page
Software Engineer
Rawflow Inc | 2nd Floor | The Old Pump House | 19 Hooper Street | London 
E1 8BU | United Kingdom

Tel:		+44 (0)20 7183 2222
Mobile:		+44 (0)7985 938 682
Fax:		+44 (0)20 7481 4343
URL:		www.rawflow.com