udt-general — UDT General Discussion

[UDT] cc.h:683: error: =?windows-1252?Q?=91=5F=5Fint64=92_does_not?= =?windows-1252?Q?_name_a_type?=

[Franz P. <f....@fz...>]

Hi,

I just downloaded the udt3-sources, and I am getting the following=20
errors when compiling (fyi: udtperf is a self-written tool we use for=20
udt-testing and includes "cc.h"):



make -C  app all
make[1]: Entering directory `/home/xxx/programme/udt3_mod/app'
g++ -Wall -DLINUX -I../src -O2 -finline-functions -DIA32  udtperf.cpp -c
../src/ccc.h:195: warning: =91class CCCVirtualFactory=92 has virtual=20
functions but non-virtual destructor
cc.h:683: error: =91__int64=92 does not name a type
cc.h: In member function =91virtual void CGTP::init()=92:
cc.h:603: error: =91m_llLastRecvPkt=92 was not declared in this scope
cc.h: In member function =91virtual void CGTP::onPktReceived()=92:
cc.h:629: error: =91m_llLastRecvPkt=92 was not declared in this scope




As a very quick and dirty workaround I made the following change in cc.h=20
from __int64 to long long int which solves the above errors:




*** udt3/app/cc.h       2006-03-13 17:53:25.000000000 +0100
--- udt3_mod/app/cc.h   2006-05-29 11:07:27.000000000 +0200
***************
*** 680,686 ****
      double m_dRequestRate;

      timeval m_LastGCTime;
!    __int64 m_llLastRecvPkt;
      int m_iLastRcvLoss;
      int m_iRTT;

--- 680,686 ----
      double m_dRequestRate;

      timeval m_LastGCTime;
!    long long int m_llLastRecvPkt;
      int m_iLastRcvLoss;
      int m_iRTT;





Now compilation works, but I get the following error when linking (I=20
don't know wether it is related to the above error):





make -C  app all
make[1]: Entering directory `/home/xxx/programme/udt3_mod/app'
g++ udtperf.o -o udtperf -L../src -ludt -lstdc++ -lpthread -lm -ldl
udtperf.o: In function `CGTP::onPktReceived()':
udtperf.cpp:(.gnu.linkonce.t._ZN4CGTP13onPktReceivedEv[CGTP::onPktReceive=
d()]+0x17a):=20
undefined reference to `CGTP::m_iGTPPktType'
collect2: ld returned 1 exit status
make[1]: *** [udtperf] Error 1
make[1]: Leaving directory `/home/xxx/programme/udt3_mod/app'
make: *** [app.all] Error 2




In our udtperf.cpp the CCCFactory<CGTP> class is instantiated like this=20
(which works well for all other CCCFactory objects):

UDT::setsockopt(client,0,UDT_CC,new=20
CCCFactory<CGTP>,sizeof(CCCFactory<CGTP>));}




Another quick and dirty workaround solves the linking error:

*** udt3/app/cc.h       2006-03-13 17:53:25.000000000 +0100
--- udt3_mod/app/cc.h   2006-05-29 11:07:27.000000000 +0200
***************
*** 668,674 ****
      void requestRate(int mbps)
      {
         CPacket pkt;
!       pkt.pack(0x111, const_cast<void*>((void*)&m_iGTPPktType), &mbps,=20
sizeof(int));

         sendCustomMsg(pkt);
      }
--- 668,674 ----
      void requestRate(int mbps)
      {
         CPacket pkt;
!       pkt.pack(0x111, const_cast<void*>((void*)m_iGTPPktType), &mbps,=20
sizeof(int));

         sendCustomMsg(pkt);
      }








I compile on a dual-core Pentium4, Suse 10.0, Kernel version=20
2.6.16.7-smp (vanilla), gcc version 4.0.2, glibc version 2.3.5



Please apologize for any clumsy code style as I am a C++-novice. Any=20
suggestions for a cleaner/more elegant solution are appreciated.

Thank you very much,

Franz Petri.

Re: [UDT] UDT-reliability issue (contd.. from the forrum)

[Yunhong Gu <yu...@la...>]

Hi, Sanjay,

It is hard for me to guess the problem given the limited information. We 
have used UDT to transfer much larger files. In rare situation, connection 
broken may happen due to timeout (one side does not receive any packets 
for a long time).

If your network bandwidth is very low (say, < 1Mbps), this may happen more 
often, because a conection may cause longer delay of packets delivery. The 
current setting of connection-broken timeout value is between 30 sec and 3 
minutes, depending on network RTT.

You may try to use a larger timeout value (see ./src/core.cpp, 
CUDT::rcvhandler).

In addition, make usre that the firewall between A and B will not 
intentially break the connection.

Thanks
Yunhong

Yunhong Gu, Ph.D., 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 Wed, 26 Apr 2006, Sanjay Upadhyay wrote:

> Hi,
> Sorry to post here, since on forums I wasnt able to.
> I have problems in transferring large files. one thing I missed to inform, was that always the conection is from a client behind nat to a server.
>
> | A |  --->  {NAT} ---> [B]
> here A is the client sending a file to B server, using the UDT library.
> in such a situation at higher file sizes,  any one of the situation comes..
>
> 1) A keeps sending.. recvfile exits saying "connection is lost"
> 2) B keeps recieving.. sendfile exits saying "connection is lost"
>
> I have tried to figure out in side the code, but it isnt easy for me :)
> any help will be appreciated.
>
> For communications where A and B are locally connected (without a NAT) the communication is fairly good... I have tested from 1MB to 300 MB 10 times each.
>
> thanking you
> Sanjay Upadhyay
>
>
> Sanjay Upadhyay
> Mobile +91-9231683108
> AIM/Yahoo/Hotmail (Screen Name) - saneax
> ICQ 76529342
> SKYPE glowfriend
>
> ---------------------------------
> New Yahoo! Messenger with Voice. Call regular phones from your PC and save big.

[UDT] UDT-reliability issue (contd.. from the forrum)

[Sanjay U. <san...@ya...>]

Hi,
Sorry to post here, since on forums I wasnt able to.
I have problems in transferring large files. one thing I missed to inform, was that always the conection is from a client behind nat to a server.

| A |  --->  {NAT} ---> [B] 
here A is the client sending a file to B server, using the UDT library.
in such a situation at higher file sizes,  any one of the situation comes..

1) A keeps sending.. recvfile exits saying "connection is lost"
2) B keeps recieving.. sendfile exits saying "connection is lost"

I have tried to figure out in side the code, but it isnt easy for me :)
any help will be appreciated.

For communications where A and B are locally connected (without a NAT) the communication is fairly good... I have tested from 1MB to 300 MB 10 times each.

thanking you
Sanjay Upadhyay


Sanjay Upadhyay
Mobile +91-9231683108
AIM/Yahoo/Hotmail (Screen Name) - saneax
ICQ 76529342
SKYPE glowfriend
		
---------------------------------
New Yahoo! Messenger with Voice. Call regular phones from your PC and save big.

Re: [UDT] about "UDT::select"

[Yunhong Gu <yu...@la...>]

in udt project properties, C/C++ -> Code Generation, select Runtime 
Library to "Multi-threaded Debug DLL (/MDd)"

Or, you can check out the most recent code from sourceforge CVS.

Thanks
Yunhong

On Fri, 7 Apr 2006, XU, Lizhen wrote:

> Hello!
>
> I've been using UDT on Windows-XP recently. I found it easy to use. But when
> I use the function "UDT::select" in my program(on MS visual
> studio.net2003),  I got a run-time error :
> *****************************************
> Debug Assertion Failed!
> Program: e:\try.cpp
> File: dbgheap.c
> Line: 1132
>
> Expression: _CrtIsValidHeapPointer(pUserData)
> ******************************************
>
> We cannot find where the problem is. Could you please kindly take the bother
> to have a look at this and help to find out the reason? Look forward to your
> help! Thanks a million.
>
> Best,
>
> Leslie
>
> The source code file is as follows:
>
> ////////////////////////////////////////////////////////////////////
> #include <iostream>
> #include <udt.h>
>
>
> using namespace std;
>
> using namespace UDT;
>
> int main()
> {
>
> UDTSOCKET serv2 = UDT::socket(AF_INET, SOCK_STREAM, 0);
> sockaddr_in my_addr2;
> my_addr2.sin_family = AF_INET;
> my_addr2.sin_port = htons(22222);
> my_addr2.sin_addr.s_addr = INADDR_ANY;
>
> cout<<"server open: "<<serv2<<endl;
> if (UDT::ERROR == UDT::bind(serv2, (sockaddr*)&my_addr2, sizeof(my_addr2)))
> {
>  cout << "bind: " << UDT::getlasterror().getErrorMessage();
>  return 0;
> }
> UDT::listen(serv2, 10);
>
> int namelen;
> sockaddr_in their_addr;
>
> UDTSOCKET recver = UDT::accept(serv2, (sockaddr*)&their_addr, &namelen);
> if(UDT::ERROR != recver)
>  cout<<"new client coming..."<< recver <<endl;
>
> timeval tv;
> UDSET tempfds;
>
> tv.tv_sec = 2;
> tv.tv_usec = 0;
>
> UD_ZERO(&tempfds);
> UD_SET(recver, &tempfds);
>
> if( UD_ISSET(recver, &tempfds))
>  cout<<"yes!"<<endl;
> bool done = false;
> int i = 0;
>
> Sleep(5000);
> while(!done)
> {
>  int res = UDT::select(0, &tempfds, NULL, NULL, &tv);
>
>  if(res == 0 && res != (UDT::ERROR))
>  {
>   cout<<++i<<": "<<"time out!"<<endl;
>   tv.tv_sec = 2;
>   tv.tv_usec = 0;
>   UD_ZERO(&tempfds);
>   UD_SET(recver, &tempfds);
>   continue;
>  }
>  else if( UD_ISSET(recver, &tempfds) )
>  {
>   cout<<"good!"<<endl;
>   done = true;
>  }
>  else
>  {
>   cout<<"what's up?"<<endl;
>   break;
>  }
>
> }
> UDT::close(serv2);
> return 0;
> }
>
> ///////////////////////////////////////////////////////////////////////
>

[UDT] about "UDT::select"

[XU, L. <xul...@gm...>]

Hello!

I've been using UDT on Windows-XP recently. I found it easy to use. But whe=
n
I use the function "UDT::select" in my program(on MS visual
studio.net2003),  I got a run-time error :
*****************************************
Debug Assertion Failed!
Program: e:\try.cpp
File: dbgheap.c
Line: 1132

Expression: _CrtIsValidHeapPointer(pUserData)
******************************************

We cannot find where the problem is. Could you please kindly take the bothe=
r
to have a look at this and help to find out the reason? Look forward to you=
r
help! Thanks a million.

Best,

Leslie

The source code file is as follows:

////////////////////////////////////////////////////////////////////
#include <iostream>
#include <udt.h>


using namespace std;

using namespace UDT;

int main()
{

 UDTSOCKET serv2 =3D UDT::socket(AF_INET, SOCK_STREAM, 0);
 sockaddr_in my_addr2;
 my_addr2.sin_family =3D AF_INET;
 my_addr2.sin_port =3D htons(22222);
 my_addr2.sin_addr.s_addr =3D INADDR_ANY;

 cout<<"server open: "<<serv2<<endl;
 if (UDT::ERROR =3D=3D UDT::bind(serv2, (sockaddr*)&my_addr2, sizeof(my_add=
r2)))
 {
  cout << "bind: " << UDT::getlasterror().getErrorMessage();
  return 0;
 }
 UDT::listen(serv2, 10);

 int namelen;
 sockaddr_in their_addr;

 UDTSOCKET recver =3D UDT::accept(serv2, (sockaddr*)&their_addr, &namelen);
 if(UDT::ERROR !=3D recver)
  cout<<"new client coming..."<< recver <<endl;

 timeval tv;
 UDSET tempfds;

 tv.tv_sec =3D 2;
 tv.tv_usec =3D 0;

 UD_ZERO(&tempfds);
 UD_SET(recver, &tempfds);

 if( UD_ISSET(recver, &tempfds))
  cout<<"yes!"<<endl;
 bool done =3D false;
 int i =3D 0;

 Sleep(5000);
 while(!done)
 {
  int res =3D UDT::select(0, &tempfds, NULL, NULL, &tv);

  if(res =3D=3D 0 && res !=3D (UDT::ERROR))
  {
   cout<<++i<<": "<<"time out!"<<endl;
   tv.tv_sec =3D 2;
   tv.tv_usec =3D 0;
   UD_ZERO(&tempfds);
   UD_SET(recver, &tempfds);
   continue;
  }
  else if( UD_ISSET(recver, &tempfds) )
  {
   cout<<"good!"<<endl;
   done =3D true;
  }
  else
  {
   cout<<"what's up?"<<endl;
   break;
  }

 }
 UDT::close(serv2);
 return 0;
}

///////////////////////////////////////////////////////////////////////

Re: [UDT] about rendezvous connection setup

[Yunhong Gu <yu...@la...>]

Hi,

You can modify the ./app/appclient.cpp a little bit to use this feature.

In ./appclient.cpp

first, use setsockopt to enable the rendezvous connection mode:

UDT::setsockopt(client, 0, UDT_RENDEZVOUS, new bool(true), sizeof(bool));

second, use bind to set an explict port number. You can copy and paste=20
this part of code from appserver.cpp.

Now it is done. You can use "appclient ip1 port1" and "appclient ip2=20
port2" to connect to each other.

UDT does not provide a rendezvous server implementation, so how to decide=
=20
the ip address and port number depends on specific applications.

Thanks
Yunhong



On Fri, 31 Mar 2006, Mercury wrote:

> I want study how to use UDT,but I only care for rendezvous connection set=
up.
Can you provides a DEMO for rendezvous connection setup.



thank you very much!


--
=3D=3D=3D=3D=3D=3D=3DMercury=3D=3D=3D=3D=3D=3D=3D
__________________
=A9=C7=A9=A5=A9=B6 ; `=A3=AE =A9=C7=A9=A4=A9=B6` .~`=A3=AE
=A9=C3=A9=A5=A9=A7=A9=B1=A9=E8=A9=B7=A9=C3=A9=A5=A9=A6 =A9=E7=A9=A5 ` ;=A3=
=AE
=A9=C1=A9=A4=A9=A7=A9=C7=A9=EC=A9=C8=A9=C7=A9=A5=A9=A7;/ =A9=EC =A8t=A1=D0=
=A8A=A1=EE.=A8@
=A9=BB=A9=A5=A9=BC=A9=BB=A9=DC=A9=BF=A9=B8=A9=A5=A9=BF/=A9=A7=A9=DF

[UDT] about rendezvous connection setup

[Mercury <cod...@gm...>]

SSB3YW50IHN0dWR5IGhvdyB0byB1c2UgVURULGJ1dCBJIG9ubHkgY2FyZSBmb3IgcmVuZGV6dm91
cyBjb25uZWN0aW9uIHNldHVwLgpDYW4geW91IHByb3ZpZGVzIGEgREVNTyBmb3IgcmVuZGV6dm91
cyBjb25uZWN0aW9uIHNldHVwLgoKCgp0aGFuayB5b3UgdmVyeSBtdWNoIQoKCi0tCj09PT09PT1N
ZXJjdXJ5PT09PT09PQpfX19fX19fX19fX19fX19fX18Kqceppam2IDsgYKOuIKnHqaSptmAgLn5g
o64KqcOppamnqbGp6Km3qcOppammIKnnqaUgYCA7o64KqcGppKmnqcep7KnIqceppamnOy8gqewg
qHSh0KhBoe4uqEAKqbuppam8qbup3Km/qbippam/L6mnqd8K

RE: [UDT] UDT Resource Usage (again) + Bug in socket creation

[Chen X. <xd...@es...>]

Hi Yunhong,

Yes, it does resolve the high CPU usage problem. Thank you very much!

Regards,
Xudong

-----Original Message-----
From: Yunhong Gu [mailto:yu...@la...] 
Sent: Thursday, March 16, 2006 11:14 AM
To: Chen Xudong
Cc: udt...@li...
Subject: RE: [UDT] UDT Resource Usage (again) + Bug in socket creation



Xudong,

Thank you very much for tracing down the problem. I modified the 
sndHandler to let it wait until an ACK comes in that special situation.

The updated core.cpp is attached. I will update the CVS in the next 
several hours.

Let me know if this fixes the problem.

Yunhong


On Wed, 15 Mar 2006, Chen Xudong wrote:

> Hi Yunhong,
>
> I spent more time debugging sndHandler. Now I know how exactly the problem
> occurs: the sndHandler thread is waiting for ACK, but because it is
actively
> running in a loop, ACK does not get chance to come in (possible due to
both
> sides are on the same machine).
>
> (I did not notice the problem during connection, but saw it seriously
during
> sending. Maybe you got different thread scheduling so you observed
> differently.)
>
> Here is the situation:
> - When start to send short text (say 10 bytes), CSndBuffer::addBuffer
> creates a single block kept by m_pCurrSendBlk, and m_iCurrBufSize is 10.
> - Then inside the while loop of sndHandler, the call to
CSndBuffer::readData
> successfully obtains the only block. CSndBuffer::m_pCurrSendBlk is then
set
> to NULL, but CSndBuffer::m_iCurrBufSize remains 10.
> - sndHandler then comes to another iteration of the while loop.
> CSndBuffer::readData is called again, but this time it returns 0 since
> CSndBuffer::m_pCurrSendBlk has been set to NULL during last iteration.
> - CSndBuffer::getCurrBufSize is then called. It returns 10 because
> CSndBuffer::m_iCurrBufSize is still 10 (not yet ACKed). It thus loses a
> chance to wait in the background for more data.
> - Eventually the sndHandler thread does not wait for anything but continue
> to the next while iteration. This goes on and on and the CPU is occupied
by
> this active thread.
>
> Here again are the key lines in core.cpp:
> 0972:   while (!self->m_bClosing)
> 1047:         if (0 == (payload =
> self->m_pSndBuffer->readData(&(datapkt.m_pcData), self->m_iPayloadSize,
> datapkt.m_iMsgNo)))
> /// above "if" is false for first time but true subsequently
> 1050:            if (0 == self->m_pSndBuffer->getCurrBufSize())
> /// above "if" is always false because ACK does not get chance to come in;
> this causes the thread lose a chance to become background
> 1075:            continue;
>
> Possible solution:
> Need a proper way to put sndHandler thread into background in such case.
> Maybe to wait for ACK if no data to send. Such wait will put sndHandler
> thread into sleep.
>
> Workaround:
> I took suggestions from Pascal (Pas...@gn...) by adding Sleep(1)
> inside the loop (just before the continue that is after
> self->m_pSndBuffer->getCurrBufSize). It did work. I think the Sleep puts
the
> sndHandler thread into background and thus ACK can come in.
>
> Regards,
> Xudong
>
> PS: You're right on overlapped IO. Pardon me I did not study on its usage
as
> in your documentation.
>
> -----Original Message-----
> From: Yunhong Gu [mailto:yu...@la...]
> Sent: Wednesday, March 15, 2006 1:33 PM
> To: Chen Xudong
> Cc: udt...@li...
> Subject: RE: [UDT] UDT Resource Usage (again) + Bug in socket creation
>
>
> I checked and tested your code.
>
> 1. I noticed the high CPU problem before connection (and a little after
> connection). The reason is that it seems SO_RCVTIMEO does not work on
> Windows when receiving from a local address. Adding a "Sleep(1)" at line
> 665 of core.cpp can solve the problem.
>
> 2. I didn't notice any high CPU problem after the connection is
> established.
>
> 3. when using overlapped IO, you cannot reuse the same buffer for sending.
> Because in overlapped IO, UDT does not duplicate user buffer but read data
> from the user buffer directly. If the user buffer is written before the
> sending is finished, unexpected problem can happen.
>
> 4. the const char* problem is fixed, thanks.
>
> Yunhong
>
>
> On Tue, 14 Mar 2006, Chen Xudong wrote:
>
>> Hi Yunhong,
>>
>> Forgot to mention that the high CPU usage problem was observed for
>> rendezvous connection and both sides were on the same machine.
>> I hence created a standalone rendezvous connection test program as
> attached.
>> I tried it with UDT 3.0 with observations below. Hasn't had time to try
> with
>> UDT 2.3 yet.
>>
>> Usage: peer self_ip self_port peer_ip peer_port
>> For example:
>> Start peer A as "peer localhost 10000 localhost 20000".
>> Start peer B as "peer localhost 20000 localhost 10000".
>> Type some text at one peer and each line is supposed to appear at the
> other
>> peer.
>> Type an empty line to exit the program.
>>
>> In peer.cpp two compilation switches are defined:
>> MODE: 0 means using SOCK_DGRAM and message IO (sendmsg/recvmsg);
>>      1 means using SOCK_STREAM and regular IO (send/recv without handle);
>>      2 means using SOCK_STREAM and overlapped IO (send/recv with handle
>> given).
>> MSGSIZE: 0 means using default UDT_MSS.
>>         1 means using customized UDT_MSS as in original appclient test
>> program.
>>
>> Observations:
>>
>> For MODE 0 & 1 (message IO & regular IO):
>> - Sending peer occupies high CPU (more than 90%) for several seconds
> before
>> the text appears at the other peer,
>> - and it continuously occupies CPU for more seconds.
>> - Sometimes it occupies even longer until the socket is broken.
>>
>> For MODE 2 (overlapped IO):
>> - Sending peer occupies CPU in the same pattern,
>> - but more seriously the text does never appear at the other peer.
>>
>> For all MODE:
>> - Setting UDT_MSS or not leads to the same behavior.
>> - Compiling in Debug or Release leads to the same behavior.
>>
>> Also found another issue:
>> The sendmsg API is defined with "char *" parameter. "const char *" should
> be
>> more appropriate.
>>
>> Thanks.
>>
>> Regards,
>> Xudong
>>
>> -----Original Message-----
>> From: Yunhong Gu [mailto:yu...@la...]
>> Sent: Tuesday, March 14, 2006 1:45 PM
>> To: Chen Xudong
>> Cc: udt...@li...
>> Subject: Re: [UDT] UDT Resource Usage (again) + Bug in socket creation
>>
>>
>>
>> Hi, Xudong,
>>
>> Thanks for the information, especially the silly bug in 3.0. I have
>> updated the CVS.
>>
>> As to the first problem, I just couldn't reproduce it on my machine
>> (windows XP pro, dual xeon, VS 2003). I attached the source code I am
>> using on my machine in this email, can you give them a try and let me
know
>> if the problem is still there. Please use release version when you
compile
>> them.
>>
>> Please let me know the throughput, CPU percentage and CPU type.
>>
>> Thanks,
>> Yunhong
>>
>>
>> On Tue, 14 Mar 2006, Chen Xudong wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> I also observed high CPU usage at the sending side. This occurred for
> both
>>> UDT 2.3 and UDT 3.0 on Windows and it happened every time. I had tried
to
>>> step into UDT 3.0 while it was busy and found out the code was iterating
>>> inside the while loop in CUDT::sndHandler. Following shows the important
>>> lines in core.cpp that execution looped around.
>>>
>>> 0972:   while (!self->m_bClosing)
>>>
>>> 1047:         if (0 == (payload =
>>> self->m_pSndBuffer->readData(&(datapkt.m_pcData), self->m_iPayloadSize,
>>> datapkt.m_iMsgNo)))
>>>
>>> 1050:            if (0 == self->m_pSndBuffer->getCurrBufSize())
>>>
>>> 1072:               self->m_ullTimeDiff = 0;
>>>
>>> 1075:            continue;
>>>
>>> I compiled the UDT library using NO_BUSY_WAITING but without CUSTOM_CC.
>>>
>>>
>>>
>>> BTW, there is a bug in your UDT 3.0 code in CUDTUnited::newSocket in
>>> api.cpp.
>>>
>>> 0155:   if ((type != SOCK_STREAM) || (type != SOCK_DGRAM))
>>>
>>> 0156:      throw CUDTException(5, 3, 0);
>>>
>>> "||" should be changed to "&&". This bug causes all programs to fail
>> because
>>> a socket can never be created.
>>>
>>>
>>>
>>> Thanks & Regards,
>>>
>>> Xudong
>>>
>>>
>>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
> that extends applications into web and mobile media. Attend the live
webcast
> and join the prime developer group breaking into this new coding
territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> UDT-general mailing list
> UDT...@li...
> https://lists.sourceforge.net/lists/listinfo/udt-general
>

Re: [UDT] OSX compilation errors

[Yunhong Gu <yu...@la...>]

Hi Ben,

Yes, it is because the endianess problem. UDT does not translate byte 
order of application data, so if you want to transfer data between 
machines with different endianess, you need to modify the application a 
little bit to do the conversion by yourself.

The sendfile and recvfile exchange the file size information, which is an 
integer value that needs the conversion in this case.

UDT only translates its own packet header and control information in order 
to communicate between different systems.

Thanks
Yunhong


On Wed, 15 Mar 2006, Ben Roeder wrote:

> I have changed the socket buffers, and have been doing some experiments,
> used sysctl -w kern.ipc.maxsockbuf=
>
> I have 2 osx machines, I can using the test tools ( sendfile and
> recvfile ) I can transfer on the same machine.
> ie sendfile
> and
> recvfile 127.0.01 9000 ./iso goo.iso
>
>> From one osx machine to the other I have some problems but am looking
> into that, ruled out any layer2 problems, so am looking further into it.
>
> More interestingly I have two Linux machines and get good speeds between
> them, esp in High BDP enviroments ( 150ms +), however using the same
> version of the code, from osx to linux and linux to osx I get
> Segmentation fault :-(. I guess this could be a Big Endian Little Endian
> problem. The sendfile end is the end that seg faults each time.
>
> I have tested with appserver and appclient and that does work osx to
> linux and linux to osx, so I am guessing the bug is in sendfile, any
> thoughts ?
>
> regards
> Ben Roeder
>
> Yunhong Gu wrote:
>>
>> Yes, this is a known issue too (I should have add a known issue list...)
>>
>> The reason is that UDT tries to allocate a rather large socket buffer
>> (setsockopt) that OS X does not support. On Linux or Windows, they will
>> set the socket buffer to the maximum system value; however, OS X will
>> return error.
>>
>> So the solution is, you can either change your system parameter to allow
>> larger socket buffer size (at least 20MB), or set UDT option (UDT_SNDBUF
>> and UDT_RCVBUF) to smaller values (e.g., 64KB). See the commented
>> setsockopt lines in appserver and appclient for examples.
>>
>> Thanks
>> Yunhong
>>
>>
>> On Wed, 15 Mar 2006, Ben Roeder wrote:
>>
>>> Hi Yunhong,
>>> Thanks for that, I now can compile the 2.3 under OS X
>>> The issue I am now seeing is
>>> ./recvfile 10.99.4.70  9000 ./iso.iso iso.iso
>>> connect: Connection setup failure: unable to create/configure UDP
>>> socket: No buffer space available.
>>>
>>> I am looking into it, but is this also a known issue, or am I the only
>>> person on Os X. I remember it used to compile and work before xmas
>>>
>>> regards
>>> Ben Roeder
>>>
>>> Yunhong Gu wrote:
>>>
>>>>
>>>>
>>>> in ./src/channel.cpp, around line 66, remove
>>>>
>>>>  #define socklen_t int
>>>>
>>>> for BSD.
>>>>
>>>> OS X has started to use socklen_t instead of int.
>>>>
>>>> There may be more problem, if so, in ./src/Makefile
>>>>
>>>> use
>>>>  $(C++) -dynamiclib -o libudt.dylib -lstdc++ -lpthread -lm $^
>>>> to replace the original "libtool ..." line.
>>>>
>>>> Thanks,
>>>> Yunhong
>>>>
>>>>
>>>> On Wed, 15 Mar 2006, Ben Roeder wrote:
>>>>
>>>>> Hi,
>>>>> Is anyone else compiling for OSX at the moment ?
>>>>> I am getting errors with version 2.3
>>>>> I am compiling on a powerPC machine running tiger
>>>>> the xcode version is 2.0
>>>>> xcode IDE 514.0
>>>>> xcode core 515.0
>>>>> tool support 514.0
>>>>>
>>>>> I am compiling with gcc in a terminal
>>>>> gcc is
>>>>> Usage: powerpc-apple-darwin8-gcc-4.0.0
>>>>> The make flags are as follows
>>>>> make -e os=BSD arch=POWERPC
>>>>>
>>>>> I see the following error, is this known issue ?
>>>>> channel.cpp is version 1.20
>>>>> ~/projects/udt2 ben$ make -e os=BSD arch=POWERPC
>>>>> make -C  src all
>>>>> g++ -fPIC -Wall -DBSD -finline-functions  -DTRACE -DNO_BUSY_WAITING
>>>>> -mcpu=powerpc channel.cpp -c
>>>>> channel.cpp: In member function `int CChannel::recvfrom(CPacket&,
>>>>> sockaddr*) const':
>>>>> channel.cpp:301: error: invalid conversion from 'int*' to 'socklen_t*'
>>>>> channel.cpp:301: error:   initializing argument 6 of 'ssize_t
>>>>> recvfrom(int, void*, size_t, int, sockaddr*, socklen_t*)'
>>>>> channel.cpp: In member function `int CChannel::getSndBufSize()':
>>>>> channel.cpp:344: error: invalid conversion from 'int*' to 'socklen_t*'
>>>>> channel.cpp:344: error:   initializing argument 5 of 'int
>>>>> getsockopt(int, int, int, void*, socklen_t*)'
>>>>> channel.cpp: In member function `int CChannel::getRcvBufSize()':
>>>>> channel.cpp:357: error: invalid conversion from 'int*' to 'socklen_t*'
>>>>> channel.cpp:357: error:   initializing argument 5 of 'int
>>>>> getsockopt(int, int, int, void*, socklen_t*)'
>>>>> channel.cpp: In member function `void
>>>>> CChannel::getSockAddr(sockaddr*) const':
>>>>> channel.cpp:380: error: invalid conversion from 'int*' to 'socklen_t*'
>>>>> channel.cpp:380: error:   initializing argument 3 of 'int
>>>>> getsockname(int, sockaddr*, socklen_t*)'
>>>>> channel.cpp: In member function `void
>>>>> CChannel::getPeerAddr(sockaddr*) const':
>>>>> channel.cpp:391: error: invalid conversion from 'int*' to 'socklen_t*'
>>>>> channel.cpp:391: error:   initializing argument 3 of 'int
>>>>> getpeername(int, sockaddr*, socklen_t*)'
>>>>> make[1]: *** [channel.o] Error 1
>>>>> make: *** [src.all] Error 2
>>>>>
>>>>> same version is fine on debian sarge
>>>>> regards
>>>>> Ben Roeder
>>>>>
>>>>>
>>>>> -------------------------------------------------------
>>>>> This SF.Net email is sponsored by xPML, a groundbreaking scripting
>>>>> language
>>>>> that extends applications into web and mobile media. Attend the live
>>>>> webcast
>>>>> and join the prime developer group breaking into this new coding
>>>>> territory!
>>>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>>>>>
>>>>> _______________________________________________
>>>>> UDT-general mailing list
>>>>> UDT...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/udt-general
>>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.Net email is sponsored by xPML, a groundbreaking scripting
>>>> language
>>>> that extends applications into web and mobile media. Attend the live
>>>> webcast
>>>> and join the prime developer group breaking into this new coding
>>>> territory!
>>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>>>> _______________________________________________
>>>> UDT-general mailing list
>>>> UDT...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/udt-general
>>>
>>>
>>> --
>>> -------------------------------------------------------
>>> Sohonet ltd                    http://www.sohonet.co.uk
>>> Tel:+44(0)20 7079 2440           Fax:+44(0)20 7079 2441
>>> Sup:+44(0)20 7079 2449           Aus:+61(0)42 1427 226
>>> Taking digital sound and vision to the world since 1995
>>> -------------------------------------------------------
>>>
>>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
>> that extends applications into web and mobile media. Attend the live
>> webcast
>> and join the prime developer group breaking into this new coding territory!
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> UDT-general mailing list
>> UDT...@li...
>> https://lists.sourceforge.net/lists/listinfo/udt-general
>
>
>

RE: [UDT] UDT Resource Usage (again) + Bug in socket creation

[Yunhong Gu <yu...@la...>]

Xudong,

Thank you very much for tracing down the problem. I modified the sndHandler 
to let it wait until an ACK comes in that special situation.

The updated member function is attached. I will update the CVS in the next 
several hours.

Let me know if this fixes the problem.
Yunhong


> On Wed, 15 Mar 2006, Chen Xudong wrote:
>
>> Hi Yunhong,
>> 
>> I spent more time debugging sndHandler. Now I know how exactly the problem
>> occurs: the sndHandler thread is waiting for ACK, but because it is 
>> actively
>> running in a loop, ACK does not get chance to come in (possible due to both
>> sides are on the same machine).
>> 
>> (I did not notice the problem during connection, but saw it seriously 
>> during
>> sending. Maybe you got different thread scheduling so you observed
>> differently.)
>> 
>> Here is the situation:
>> - When start to send short text (say 10 bytes), CSndBuffer::addBuffer
>> creates a single block kept by m_pCurrSendBlk, and m_iCurrBufSize is 10.
>> - Then inside the while loop of sndHandler, the call to 
>> CSndBuffer::readData
>> successfully obtains the only block. CSndBuffer::m_pCurrSendBlk is then set
>> to NULL, but CSndBuffer::m_iCurrBufSize remains 10.
>> - sndHandler then comes to another iteration of the while loop.
>> CSndBuffer::readData is called again, but this time it returns 0 since
>> CSndBuffer::m_pCurrSendBlk has been set to NULL during last iteration.
>> - CSndBuffer::getCurrBufSize is then called. It returns 10 because
>> CSndBuffer::m_iCurrBufSize is still 10 (not yet ACKed). It thus loses a
>> chance to wait in the background for more data.
>> - Eventually the sndHandler thread does not wait for anything but continue
>> to the next while iteration. This goes on and on and the CPU is occupied by
>> this active thread.
>> 
>> Here again are the key lines in core.cpp:
>> 0972:   while (!self->m_bClosing)
>> 1047:         if (0 == (payload =
>> self->m_pSndBuffer->readData(&(datapkt.m_pcData), self->m_iPayloadSize,
>> datapkt.m_iMsgNo)))
>> /// above "if" is false for first time but true subsequently
>> 1050:            if (0 == self->m_pSndBuffer->getCurrBufSize())
>> /// above "if" is always false because ACK does not get chance to come in;
>> this causes the thread lose a chance to become background
>> 1075:            continue;
>> 
>> Possible solution:
>> Need a proper way to put sndHandler thread into background in such case.
>> Maybe to wait for ACK if no data to send. Such wait will put sndHandler
>> thread into sleep.
>> 
>> Workaround:
>> I took suggestions from Pascal (Pas...@gn...) by adding Sleep(1)
>> inside the loop (just before the continue that is after
>> self->m_pSndBuffer->getCurrBufSize). It did work. I think the Sleep puts 
>> the
>> sndHandler thread into background and thus ACK can come in.
>> 
>> Regards,
>> Xudong
>> 
>> PS: You're right on overlapped IO. Pardon me I did not study on its usage 
>> as
>> in your documentation.
>> 
>> -----Original Message-----
>> From: Yunhong Gu [mailto:yu...@la...]
>> Sent: Wednesday, March 15, 2006 1:33 PM
>> To: Chen Xudong
>> Cc: udt...@li...
>> Subject: RE: [UDT] UDT Resource Usage (again) + Bug in socket creation
>> 
>> 
>> I checked and tested your code.
>> 
>> 1. I noticed the high CPU problem before connection (and a little after
>> connection). The reason is that it seems SO_RCVTIMEO does not work on
>> Windows when receiving from a local address. Adding a "Sleep(1)" at line
>> 665 of core.cpp can solve the problem.
>> 
>> 2. I didn't notice any high CPU problem after the connection is
>> established.
>> 
>> 3. when using overlapped IO, you cannot reuse the same buffer for sending.
>> Because in overlapped IO, UDT does not duplicate user buffer but read data
>> from the user buffer directly. If the user buffer is written before the
>> sending is finished, unexpected problem can happen.
>> 
>> 4. the const char* problem is fixed, thanks.
>> 
>> Yunhong
>> 
>> 
>> On Tue, 14 Mar 2006, Chen Xudong wrote:
>> 
>>> Hi Yunhong,
>>> 
>>> Forgot to mention that the high CPU usage problem was observed for
>>> rendezvous connection and both sides were on the same machine.
>>> I hence created a standalone rendezvous connection test program as
>> attached.
>>> I tried it with UDT 3.0 with observations below. Hasn't had time to try
>> with
>>> UDT 2.3 yet.
>>> 
>>> Usage: peer self_ip self_port peer_ip peer_port
>>> For example:
>>> Start peer A as "peer localhost 10000 localhost 20000".
>>> Start peer B as "peer localhost 20000 localhost 10000".
>>> Type some text at one peer and each line is supposed to appear at the
>> other
>>> peer.
>>> Type an empty line to exit the program.
>>> 
>>> In peer.cpp two compilation switches are defined:
>>> MODE: 0 means using SOCK_DGRAM and message IO (sendmsg/recvmsg);
>>>      1 means using SOCK_STREAM and regular IO (send/recv without handle);
>>>      2 means using SOCK_STREAM and overlapped IO (send/recv with handle
>>> given).
>>> MSGSIZE: 0 means using default UDT_MSS.
>>>         1 means using customized UDT_MSS as in original appclient test
>>> program.
>>> 
>>> Observations:
>>> 
>>> For MODE 0 & 1 (message IO & regular IO):
>>> - Sending peer occupies high CPU (more than 90%) for several seconds
>> before
>>> the text appears at the other peer,
>>> - and it continuously occupies CPU for more seconds.
>>> - Sometimes it occupies even longer until the socket is broken.
>>> 
>>> For MODE 2 (overlapped IO):
>>> - Sending peer occupies CPU in the same pattern,
>>> - but more seriously the text does never appear at the other peer.
>>> 
>>> For all MODE:
>>> - Setting UDT_MSS or not leads to the same behavior.
>>> - Compiling in Debug or Release leads to the same behavior.
>>> 
>>> Also found another issue:
>>> The sendmsg API is defined with "char *" parameter. "const char *" should
>> be
>>> more appropriate.
>>> 
>>> Thanks.
>>> 
>>> Regards,
>>> Xudong
>>> 
>>> -----Original Message-----
>>> From: Yunhong Gu [mailto:yu...@la...]
>>> Sent: Tuesday, March 14, 2006 1:45 PM
>>> To: Chen Xudong
>>> Cc: udt...@li...
>>> Subject: Re: [UDT] UDT Resource Usage (again) + Bug in socket creation
>>> 
>>> 
>>> 
>>> Hi, Xudong,
>>> 
>>> Thanks for the information, especially the silly bug in 3.0. I have
>>> updated the CVS.
>>> 
>>> As to the first problem, I just couldn't reproduce it on my machine
>>> (windows XP pro, dual xeon, VS 2003). I attached the source code I am
>>> using on my machine in this email, can you give them a try and let me know
>>> if the problem is still there. Please use release version when you compile
>>> them.
>>> 
>>> Please let me know the throughput, CPU percentage and CPU type.
>>> 
>>> Thanks,
>>> Yunhong
>>> 
>>> 
>>> On Tue, 14 Mar 2006, Chen Xudong wrote:
>>> 
>>>> Hi,
>>>> 
>>>> 
>>>> 
>>>> I also observed high CPU usage at the sending side. This occurred for
>> both
>>>> UDT 2.3 and UDT 3.0 on Windows and it happened every time. I had tried to
>>>> step into UDT 3.0 while it was busy and found out the code was iterating
>>>> inside the while loop in CUDT::sndHandler. Following shows the important
>>>> lines in core.cpp that execution looped around.
>>>> 
>>>> 0972:   while (!self->m_bClosing)
>>>> 
>>>> 1047:         if (0 == (payload =
>>>> self->m_pSndBuffer->readData(&(datapkt.m_pcData), self->m_iPayloadSize,
>>>> datapkt.m_iMsgNo)))
>>>> 
>>>> 1050:            if (0 == self->m_pSndBuffer->getCurrBufSize())
>>>> 
>>>> 1072:               self->m_ullTimeDiff = 0;
>>>> 
>>>> 1075:            continue;
>>>> 
>>>> I compiled the UDT library using NO_BUSY_WAITING but without CUSTOM_CC.
>>>> 
>>>> 
>>>> 
>>>> BTW, there is a bug in your UDT 3.0 code in CUDTUnited::newSocket in
>>>> api.cpp.
>>>> 
>>>> 0155:   if ((type != SOCK_STREAM) || (type != SOCK_DGRAM))
>>>> 
>>>> 0156:      throw CUDTException(5, 3, 0);
>>>> 
>>>> "||" should be changed to "&&". This bug causes all programs to fail
>>> because
>>>> a socket can never be created.
>>>> 
>>>> 
>>>> 
>>>> Thanks & Regards,
>>>> 
>>>> Xudong
>>>> 
>>>> 
>>> 
>> 
>> 
>> 
>> 
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
>> that extends applications into web and mobile media. Attend the live 
>> webcast
>> and join the prime developer group breaking into this new coding territory!
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> UDT-general mailing list
>> UDT...@li...
>> https://lists.sourceforge.net/lists/listinfo/udt-general
>

Re: [UDT] OSX compilation errors

[Ben R. <ben...@so...>]

I have changed the socket buffers, and have been doing some experiments,
used sysctl -w kern.ipc.maxsockbuf=

I have 2 osx machines, I can using the test tools ( sendfile and
recvfile ) I can transfer on the same machine.
ie sendfile
and
recvfile 127.0.01 9000 ./iso goo.iso

From one osx machine to the other I have some problems but am looking
into that, ruled out any layer2 problems, so am looking further into it.

More interestingly I have two Linux machines and get good speeds between
them, esp in High BDP enviroments ( 150ms +), however using the same
version of the code, from osx to linux and linux to osx I get
Segmentation fault :-(. I guess this could be a Big Endian Little Endian
problem. The sendfile end is the end that seg faults each time.

I have tested with appserver and appclient and that does work osx to
linux and linux to osx, so I am guessing the bug is in sendfile, any
thoughts ?

regards
Ben Roeder

Yunhong Gu wrote:
> 
> Yes, this is a known issue too (I should have add a known issue list...)
> 
> The reason is that UDT tries to allocate a rather large socket buffer
> (setsockopt) that OS X does not support. On Linux or Windows, they will
> set the socket buffer to the maximum system value; however, OS X will
> return error.
> 
> So the solution is, you can either change your system parameter to allow
> larger socket buffer size (at least 20MB), or set UDT option (UDT_SNDBUF
> and UDT_RCVBUF) to smaller values (e.g., 64KB). See the commented
> setsockopt lines in appserver and appclient for examples.
> 
> Thanks
> Yunhong
> 
> 
> On Wed, 15 Mar 2006, Ben Roeder wrote:
> 
>> Hi Yunhong,
>> Thanks for that, I now can compile the 2.3 under OS X
>> The issue I am now seeing is
>> ./recvfile 10.99.4.70  9000 ./iso.iso iso.iso
>> connect: Connection setup failure: unable to create/configure UDP
>> socket: No buffer space available.
>>
>> I am looking into it, but is this also a known issue, or am I the only
>> person on Os X. I remember it used to compile and work before xmas
>>
>> regards
>> Ben Roeder
>>
>> Yunhong Gu wrote:
>>
>>>
>>>
>>> in ./src/channel.cpp, around line 66, remove
>>>
>>>  #define socklen_t int
>>>
>>> for BSD.
>>>
>>> OS X has started to use socklen_t instead of int.
>>>
>>> There may be more problem, if so, in ./src/Makefile
>>>
>>> use
>>>  $(C++) -dynamiclib -o libudt.dylib -lstdc++ -lpthread -lm $^
>>> to replace the original "libtool ..." line.
>>>
>>> Thanks,
>>> Yunhong
>>>
>>>
>>> On Wed, 15 Mar 2006, Ben Roeder wrote:
>>>
>>>> Hi,
>>>> Is anyone else compiling for OSX at the moment ?
>>>> I am getting errors with version 2.3
>>>> I am compiling on a powerPC machine running tiger
>>>> the xcode version is 2.0
>>>> xcode IDE 514.0
>>>> xcode core 515.0
>>>> tool support 514.0
>>>>
>>>> I am compiling with gcc in a terminal
>>>> gcc is
>>>> Usage: powerpc-apple-darwin8-gcc-4.0.0
>>>> The make flags are as follows
>>>> make -e os=BSD arch=POWERPC
>>>>
>>>> I see the following error, is this known issue ?
>>>> channel.cpp is version 1.20
>>>> ~/projects/udt2 ben$ make -e os=BSD arch=POWERPC
>>>> make -C  src all
>>>> g++ -fPIC -Wall -DBSD -finline-functions  -DTRACE -DNO_BUSY_WAITING
>>>> -mcpu=powerpc channel.cpp -c
>>>> channel.cpp: In member function `int CChannel::recvfrom(CPacket&,
>>>> sockaddr*) const':
>>>> channel.cpp:301: error: invalid conversion from 'int*' to 'socklen_t*'
>>>> channel.cpp:301: error:   initializing argument 6 of 'ssize_t
>>>> recvfrom(int, void*, size_t, int, sockaddr*, socklen_t*)'
>>>> channel.cpp: In member function `int CChannel::getSndBufSize()':
>>>> channel.cpp:344: error: invalid conversion from 'int*' to 'socklen_t*'
>>>> channel.cpp:344: error:   initializing argument 5 of 'int
>>>> getsockopt(int, int, int, void*, socklen_t*)'
>>>> channel.cpp: In member function `int CChannel::getRcvBufSize()':
>>>> channel.cpp:357: error: invalid conversion from 'int*' to 'socklen_t*'
>>>> channel.cpp:357: error:   initializing argument 5 of 'int
>>>> getsockopt(int, int, int, void*, socklen_t*)'
>>>> channel.cpp: In member function `void
>>>> CChannel::getSockAddr(sockaddr*) const':
>>>> channel.cpp:380: error: invalid conversion from 'int*' to 'socklen_t*'
>>>> channel.cpp:380: error:   initializing argument 3 of 'int
>>>> getsockname(int, sockaddr*, socklen_t*)'
>>>> channel.cpp: In member function `void
>>>> CChannel::getPeerAddr(sockaddr*) const':
>>>> channel.cpp:391: error: invalid conversion from 'int*' to 'socklen_t*'
>>>> channel.cpp:391: error:   initializing argument 3 of 'int
>>>> getpeername(int, sockaddr*, socklen_t*)'
>>>> make[1]: *** [channel.o] Error 1
>>>> make: *** [src.all] Error 2
>>>>
>>>> same version is fine on debian sarge
>>>> regards
>>>> Ben Roeder
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.Net email is sponsored by xPML, a groundbreaking scripting
>>>> language
>>>> that extends applications into web and mobile media. Attend the live
>>>> webcast
>>>> and join the prime developer group breaking into this new coding
>>>> territory!
>>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>>>>
>>>> _______________________________________________
>>>> UDT-general mailing list
>>>> UDT...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/udt-general
>>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by xPML, a groundbreaking scripting
>>> language
>>> that extends applications into web and mobile media. Attend the live
>>> webcast
>>> and join the prime developer group breaking into this new coding
>>> territory!
>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>>> _______________________________________________
>>> UDT-general mailing list
>>> UDT...@li...
>>> https://lists.sourceforge.net/lists/listinfo/udt-general
>>
>>
>> -- 
>> -------------------------------------------------------
>> Sohonet ltd                    http://www.sohonet.co.uk
>> Tel:+44(0)20 7079 2440           Fax:+44(0)20 7079 2441
>> Sup:+44(0)20 7079 2449           Aus:+61(0)42 1427 226
>> Taking digital sound and vision to the world since 1995
>> -------------------------------------------------------
>>
>>
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> UDT-general mailing list
> UDT...@li...
> https://lists.sourceforge.net/lists/listinfo/udt-general

Re: [UDT] OSX compilation errors

[Yunhong Gu <yu...@la...>]

Yes, this is a known issue too (I should have add a known issue list...)

The reason is that UDT tries to allocate a rather large socket buffer 
(setsockopt) that OS X does not support. On Linux or Windows, they will 
set the socket buffer to the maximum system value; however, OS X will 
return error.

So the solution is, you can either change your system parameter to allow 
larger socket buffer size (at least 20MB), or set UDT option (UDT_SNDBUF 
and UDT_RCVBUF) to smaller values (e.g., 64KB). See the commented 
setsockopt lines in appserver and appclient for examples.

Thanks
Yunhong


On Wed, 15 Mar 2006, Ben Roeder wrote:

> Hi Yunhong,
> Thanks for that, I now can compile the 2.3 under OS X
> The issue I am now seeing is
> ./recvfile 10.99.4.70  9000 ./iso.iso iso.iso
> connect: Connection setup failure: unable to create/configure UDP socket: No 
> buffer space available.
>
> I am looking into it, but is this also a known issue, or am I the only person 
> on Os X. I remember it used to compile and work before xmas
>
> regards
> Ben Roeder
>
> Yunhong Gu wrote:
>> 
>> 
>> in ./src/channel.cpp, around line 66, remove
>> 
>>  #define socklen_t int
>> 
>> for BSD.
>> 
>> OS X has started to use socklen_t instead of int.
>> 
>> There may be more problem, if so, in ./src/Makefile
>> 
>> use
>>  $(C++) -dynamiclib -o libudt.dylib -lstdc++ -lpthread -lm $^
>> to replace the original "libtool ..." line.
>> 
>> Thanks,
>> Yunhong
>> 
>> 
>> On Wed, 15 Mar 2006, Ben Roeder wrote:
>> 
>>> Hi,
>>> Is anyone else compiling for OSX at the moment ?
>>> I am getting errors with version 2.3
>>> I am compiling on a powerPC machine running tiger
>>> the xcode version is 2.0
>>> xcode IDE 514.0
>>> xcode core 515.0
>>> tool support 514.0
>>> 
>>> I am compiling with gcc in a terminal
>>> gcc is
>>> Usage: powerpc-apple-darwin8-gcc-4.0.0
>>> The make flags are as follows
>>> make -e os=BSD arch=POWERPC
>>> 
>>> I see the following error, is this known issue ?
>>> channel.cpp is version 1.20
>>> ~/projects/udt2 ben$ make -e os=BSD arch=POWERPC
>>> make -C  src all
>>> g++ -fPIC -Wall -DBSD -finline-functions  -DTRACE -DNO_BUSY_WAITING 
>>> -mcpu=powerpc channel.cpp -c
>>> channel.cpp: In member function `int CChannel::recvfrom(CPacket&, 
>>> sockaddr*) const':
>>> channel.cpp:301: error: invalid conversion from 'int*' to 'socklen_t*'
>>> channel.cpp:301: error:   initializing argument 6 of 'ssize_t 
>>> recvfrom(int, void*, size_t, int, sockaddr*, socklen_t*)'
>>> channel.cpp: In member function `int CChannel::getSndBufSize()':
>>> channel.cpp:344: error: invalid conversion from 'int*' to 'socklen_t*'
>>> channel.cpp:344: error:   initializing argument 5 of 'int getsockopt(int, 
>>> int, int, void*, socklen_t*)'
>>> channel.cpp: In member function `int CChannel::getRcvBufSize()':
>>> channel.cpp:357: error: invalid conversion from 'int*' to 'socklen_t*'
>>> channel.cpp:357: error:   initializing argument 5 of 'int getsockopt(int, 
>>> int, int, void*, socklen_t*)'
>>> channel.cpp: In member function `void CChannel::getSockAddr(sockaddr*) 
>>> const':
>>> channel.cpp:380: error: invalid conversion from 'int*' to 'socklen_t*'
>>> channel.cpp:380: error:   initializing argument 3 of 'int getsockname(int, 
>>> sockaddr*, socklen_t*)'
>>> channel.cpp: In member function `void CChannel::getPeerAddr(sockaddr*) 
>>> const':
>>> channel.cpp:391: error: invalid conversion from 'int*' to 'socklen_t*'
>>> channel.cpp:391: error:   initializing argument 3 of 'int getpeername(int, 
>>> sockaddr*, socklen_t*)'
>>> make[1]: *** [channel.o] Error 1
>>> make: *** [src.all] Error 2
>>> 
>>> same version is fine on debian sarge
>>> regards
>>> Ben Roeder
>>> 
>>> 
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
>>> language
>>> that extends applications into web and mobile media. Attend the live 
>>> webcast
>>> and join the prime developer group breaking into this new coding 
>>> territory!
>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>>> _______________________________________________
>>> UDT-general mailing list
>>> UDT...@li...
>>> https://lists.sourceforge.net/lists/listinfo/udt-general
>>> 
>> 
>> 
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
>> that extends applications into web and mobile media. Attend the live 
>> webcast
>> and join the prime developer group breaking into this new coding territory!
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> UDT-general mailing list
>> UDT...@li...
>> https://lists.sourceforge.net/lists/listinfo/udt-general
>
> -- 
> -------------------------------------------------------
> Sohonet ltd                    http://www.sohonet.co.uk
> Tel:+44(0)20 7079 2440           Fax:+44(0)20 7079 2441
> Sup:+44(0)20 7079 2449           Aus:+61(0)42 1427 226
> Taking digital sound and vision to the world since 1995
> -------------------------------------------------------
>
>

Re: [UDT] OSX compilation errors

[Yunhong Gu <yu...@la...>]

in ./src/channel.cpp, around line 66, remove

  #define socklen_t int

for BSD.

OS X has started to use socklen_t instead of int.

There may be more problem, if so, in ./src/Makefile

use
  $(C++) -dynamiclib -o libudt.dylib -lstdc++ -lpthread -lm $^
to replace the original "libtool ..." line.

Thanks,
Yunhong


On Wed, 15 Mar 2006, Ben Roeder wrote:

> Hi,
> Is anyone else compiling for OSX at the moment ?
> I am getting errors with version 2.3
> I am compiling on a powerPC machine running tiger
> the xcode version is 2.0
> xcode IDE 514.0
> xcode core 515.0
> tool support 514.0
>
> I am compiling with gcc in a terminal
> gcc is
> Usage: powerpc-apple-darwin8-gcc-4.0.0
> The make flags are as follows
> make -e os=BSD arch=POWERPC
>
> I see the following error, is this known issue ?
> channel.cpp is version 1.20
> ~/projects/udt2 ben$ make -e os=BSD arch=POWERPC
> make -C  src all
> g++ -fPIC -Wall -DBSD -finline-functions  -DTRACE -DNO_BUSY_WAITING 
> -mcpu=powerpc channel.cpp -c
> channel.cpp: In member function `int CChannel::recvfrom(CPacket&, sockaddr*) 
> const':
> channel.cpp:301: error: invalid conversion from 'int*' to 'socklen_t*'
> channel.cpp:301: error:   initializing argument 6 of 'ssize_t recvfrom(int, 
> void*, size_t, int, sockaddr*, socklen_t*)'
> channel.cpp: In member function `int CChannel::getSndBufSize()':
> channel.cpp:344: error: invalid conversion from 'int*' to 'socklen_t*'
> channel.cpp:344: error:   initializing argument 5 of 'int getsockopt(int, 
> int, int, void*, socklen_t*)'
> channel.cpp: In member function `int CChannel::getRcvBufSize()':
> channel.cpp:357: error: invalid conversion from 'int*' to 'socklen_t*'
> channel.cpp:357: error:   initializing argument 5 of 'int getsockopt(int, 
> int, int, void*, socklen_t*)'
> channel.cpp: In member function `void CChannel::getSockAddr(sockaddr*) 
> const':
> channel.cpp:380: error: invalid conversion from 'int*' to 'socklen_t*'
> channel.cpp:380: error:   initializing argument 3 of 'int getsockname(int, 
> sockaddr*, socklen_t*)'
> channel.cpp: In member function `void CChannel::getPeerAddr(sockaddr*) 
> const':
> channel.cpp:391: error: invalid conversion from 'int*' to 'socklen_t*'
> channel.cpp:391: error:   initializing argument 3 of 'int getpeername(int, 
> sockaddr*, socklen_t*)'
> make[1]: *** [channel.o] Error 1
> make: *** [src.all] Error 2
>
> same version is fine on debian sarge
> regards
> Ben Roeder
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> UDT-general mailing list
> UDT...@li...
> https://lists.sourceforge.net/lists/listinfo/udt-general
>

[UDT] OSX compilation errors

[Ben R. <ben...@so...>]

Hi,
Is anyone else compiling for OSX at the moment ?
I am getting errors with version 2.3
I am compiling on a powerPC machine running tiger
the xcode version is 2.0
xcode IDE 514.0
xcode core 515.0
tool support 514.0

I am compiling with gcc in a terminal
gcc is
Usage: powerpc-apple-darwin8-gcc-4.0.0
The make flags are as follows
make -e os=BSD arch=POWERPC

I see the following error, is this known issue ?
channel.cpp is version 1.20
~/projects/udt2 ben$ make -e os=BSD arch=POWERPC
make -C  src all
g++ -fPIC -Wall -DBSD -finline-functions  -DTRACE -DNO_BUSY_WAITING 
-mcpu=powerpc channel.cpp -c
channel.cpp: In member function `int CChannel::recvfrom(CPacket&, 
sockaddr*) const':
channel.cpp:301: error: invalid conversion from 'int*' to 'socklen_t*'
channel.cpp:301: error:   initializing argument 6 of 'ssize_t 
recvfrom(int, void*, size_t, int, sockaddr*, socklen_t*)'
channel.cpp: In member function `int CChannel::getSndBufSize()':
channel.cpp:344: error: invalid conversion from 'int*' to 'socklen_t*'
channel.cpp:344: error:   initializing argument 5 of 'int 
getsockopt(int, int, int, void*, socklen_t*)'
channel.cpp: In member function `int CChannel::getRcvBufSize()':
channel.cpp:357: error: invalid conversion from 'int*' to 'socklen_t*'
channel.cpp:357: error:   initializing argument 5 of 'int 
getsockopt(int, int, int, void*, socklen_t*)'
channel.cpp: In member function `void CChannel::getSockAddr(sockaddr*) 
const':
channel.cpp:380: error: invalid conversion from 'int*' to 'socklen_t*'
channel.cpp:380: error:   initializing argument 3 of 'int 
getsockname(int, sockaddr*, socklen_t*)'
channel.cpp: In member function `void CChannel::getPeerAddr(sockaddr*) 
const':
channel.cpp:391: error: invalid conversion from 'int*' to 'socklen_t*'
channel.cpp:391: error:   initializing argument 3 of 'int 
getpeername(int, sockaddr*, socklen_t*)'
make[1]: *** [channel.o] Error 1
make: *** [src.all] Error 2

same version is fine on debian sarge
regards
Ben Roeder

RE: [UDT] UDT Resource Usage (again) + Bug in socket creation

[Chen X. <xd...@es...>]

Addition to the workaround:
By adding Sleep(1) into sndHandler, although CPU usage drops to low level,
but variable delays are observed in my case.

I think a proper solution is better. I'm not sure if this happens only on
local machine. I haven't tried with two machines yet.

Regards,
Xudong

-----Original Message-----
From: Chen Xudong [mailto:xd...@es...] 
Sent: Wednesday, March 15, 2006 6:20 PM
To: 'Yunhong Gu'
Cc: udt...@li...; xd...@es...
Subject: RE: [UDT] UDT Resource Usage (again) + Bug in socket creation

Hi Yunhong,

I spent more time debugging sndHandler. Now I know how exactly the problem
occurs: the sndHandler thread is waiting for ACK, but because it is actively
running in a loop, ACK does not get chance to come in (possible due to both
sides are on the same machine).

(I did not notice the problem during connection, but saw it seriously during
sending. Maybe you got different thread scheduling so you observed
differently.)

Here is the situation:
- When start to send short text (say 10 bytes), CSndBuffer::addBuffer
creates a single block kept by m_pCurrSendBlk, and m_iCurrBufSize is 10.
- Then inside the while loop of sndHandler, the call to CSndBuffer::readData
successfully obtains the only block. CSndBuffer::m_pCurrSendBlk is then set
to NULL, but CSndBuffer::m_iCurrBufSize remains 10.
- sndHandler then comes to another iteration of the while loop.
CSndBuffer::readData is called again, but this time it returns 0 since
CSndBuffer::m_pCurrSendBlk has been set to NULL during last iteration.
- CSndBuffer::getCurrBufSize is then called. It returns 10 because
CSndBuffer::m_iCurrBufSize is still 10 (not yet ACKed). It thus loses a
chance to wait in the background for more data.
- Eventually the sndHandler thread does not wait for anything but continue
to the next while iteration. This goes on and on and the CPU is occupied by
this active thread.

Here again are the key lines in core.cpp:
0972:   while (!self->m_bClosing)
1047:         if (0 == (payload =
self->m_pSndBuffer->readData(&(datapkt.m_pcData), self->m_iPayloadSize,
datapkt.m_iMsgNo)))
/// above "if" is false for first time but true subsequently
1050:            if (0 == self->m_pSndBuffer->getCurrBufSize())
/// above "if" is always false because ACK does not get chance to come in;
this causes the thread lose a chance to become background
1075:            continue;

Possible solution:
Need a proper way to put sndHandler thread into background in such case.
Maybe to wait for ACK if no data to send. Such wait will put sndHandler
thread into sleep.

Workaround:
I took suggestions from Pascal (Pas...@gn...) by adding Sleep(1)
inside the loop (just before the continue that is after
self->m_pSndBuffer->getCurrBufSize). It did work. I think the Sleep puts the
sndHandler thread into background and thus ACK can come in.

Regards,
Xudong

PS: You're right on overlapped IO. Pardon me I did not study on its usage as
in your documentation.

-----Original Message-----
From: Yunhong Gu [mailto:yu...@la...] 
Sent: Wednesday, March 15, 2006 1:33 PM
To: Chen Xudong
Cc: udt...@li...
Subject: RE: [UDT] UDT Resource Usage (again) + Bug in socket creation


I checked and tested your code.

1. I noticed the high CPU problem before connection (and a little after 
connection). The reason is that it seems SO_RCVTIMEO does not work on 
Windows when receiving from a local address. Adding a "Sleep(1)" at line 
665 of core.cpp can solve the problem.

2. I didn't notice any high CPU problem after the connection is 
established.

3. when using overlapped IO, you cannot reuse the same buffer for sending. 
Because in overlapped IO, UDT does not duplicate user buffer but read data 
from the user buffer directly. If the user buffer is written before the 
sending is finished, unexpected problem can happen.

4. the const char* problem is fixed, thanks.

Yunhong


On Tue, 14 Mar 2006, Chen Xudong wrote:

> Hi Yunhong,
>
> Forgot to mention that the high CPU usage problem was observed for
> rendezvous connection and both sides were on the same machine.
> I hence created a standalone rendezvous connection test program as
attached.
> I tried it with UDT 3.0 with observations below. Hasn't had time to try
with
> UDT 2.3 yet.
>
> Usage: peer self_ip self_port peer_ip peer_port
> For example:
> Start peer A as "peer localhost 10000 localhost 20000".
> Start peer B as "peer localhost 20000 localhost 10000".
> Type some text at one peer and each line is supposed to appear at the
other
> peer.
> Type an empty line to exit the program.
>
> In peer.cpp two compilation switches are defined:
> MODE: 0 means using SOCK_DGRAM and message IO (sendmsg/recvmsg);
>      1 means using SOCK_STREAM and regular IO (send/recv without handle);
>      2 means using SOCK_STREAM and overlapped IO (send/recv with handle
> given).
> MSGSIZE: 0 means using default UDT_MSS.
>         1 means using customized UDT_MSS as in original appclient test
> program.
>
> Observations:
>
> For MODE 0 & 1 (message IO & regular IO):
> - Sending peer occupies high CPU (more than 90%) for several seconds
before
> the text appears at the other peer,
> - and it continuously occupies CPU for more seconds.
> - Sometimes it occupies even longer until the socket is broken.
>
> For MODE 2 (overlapped IO):
> - Sending peer occupies CPU in the same pattern,
> - but more seriously the text does never appear at the other peer.
>
> For all MODE:
> - Setting UDT_MSS or not leads to the same behavior.
> - Compiling in Debug or Release leads to the same behavior.
>
> Also found another issue:
> The sendmsg API is defined with "char *" parameter. "const char *" should
be
> more appropriate.
>
> Thanks.
>
> Regards,
> Xudong
>
> -----Original Message-----
> From: Yunhong Gu [mailto:yu...@la...]
> Sent: Tuesday, March 14, 2006 1:45 PM
> To: Chen Xudong
> Cc: udt...@li...
> Subject: Re: [UDT] UDT Resource Usage (again) + Bug in socket creation
>
>
>
> Hi, Xudong,
>
> Thanks for the information, especially the silly bug in 3.0. I have
> updated the CVS.
>
> As to the first problem, I just couldn't reproduce it on my machine
> (windows XP pro, dual xeon, VS 2003). I attached the source code I am
> using on my machine in this email, can you give them a try and let me know
> if the problem is still there. Please use release version when you compile
> them.
>
> Please let me know the throughput, CPU percentage and CPU type.
>
> Thanks,
> Yunhong
>
>
> On Tue, 14 Mar 2006, Chen Xudong wrote:
>
>> Hi,
>>
>>
>>
>> I also observed high CPU usage at the sending side. This occurred for
both
>> UDT 2.3 and UDT 3.0 on Windows and it happened every time. I had tried to
>> step into UDT 3.0 while it was busy and found out the code was iterating
>> inside the while loop in CUDT::sndHandler. Following shows the important
>> lines in core.cpp that execution looped around.
>>
>> 0972:   while (!self->m_bClosing)
>>
>> 1047:         if (0 == (payload =
>> self->m_pSndBuffer->readData(&(datapkt.m_pcData), self->m_iPayloadSize,
>> datapkt.m_iMsgNo)))
>>
>> 1050:            if (0 == self->m_pSndBuffer->getCurrBufSize())
>>
>> 1072:               self->m_ullTimeDiff = 0;
>>
>> 1075:            continue;
>>
>> I compiled the UDT library using NO_BUSY_WAITING but without CUSTOM_CC.
>>
>>
>>
>> BTW, there is a bug in your UDT 3.0 code in CUDTUnited::newSocket in
>> api.cpp.
>>
>> 0155:   if ((type != SOCK_STREAM) || (type != SOCK_DGRAM))
>>
>> 0156:      throw CUDTException(5, 3, 0);
>>
>> "||" should be changed to "&&". This bug causes all programs to fail
> because
>> a socket can never be created.
>>
>>
>>
>> Thanks & Regards,
>>
>> Xudong
>>
>>
>

RE: [UDT] UDT Resource Usage (again) + Bug in socket creation

[Chen X. <xd...@es...>]

Hi Yunhong,

I spent more time debugging sndHandler. Now I know how exactly the problem
occurs: the sndHandler thread is waiting for ACK, but because it is actively
running in a loop, ACK does not get chance to come in (possible due to both
sides are on the same machine).

(I did not notice the problem during connection, but saw it seriously during
sending. Maybe you got different thread scheduling so you observed
differently.)

Here is the situation:
- When start to send short text (say 10 bytes), CSndBuffer::addBuffer
creates a single block kept by m_pCurrSendBlk, and m_iCurrBufSize is 10.
- Then inside the while loop of sndHandler, the call to CSndBuffer::readData
successfully obtains the only block. CSndBuffer::m_pCurrSendBlk is then set
to NULL, but CSndBuffer::m_iCurrBufSize remains 10.
- sndHandler then comes to another iteration of the while loop.
CSndBuffer::readData is called again, but this time it returns 0 since
CSndBuffer::m_pCurrSendBlk has been set to NULL during last iteration.
- CSndBuffer::getCurrBufSize is then called. It returns 10 because
CSndBuffer::m_iCurrBufSize is still 10 (not yet ACKed). It thus loses a
chance to wait in the background for more data.
- Eventually the sndHandler thread does not wait for anything but continue
to the next while iteration. This goes on and on and the CPU is occupied by
this active thread.

Here again are the key lines in core.cpp:
0972:   while (!self->m_bClosing)
1047:         if (0 == (payload =
self->m_pSndBuffer->readData(&(datapkt.m_pcData), self->m_iPayloadSize,
datapkt.m_iMsgNo)))
/// above "if" is false for first time but true subsequently
1050:            if (0 == self->m_pSndBuffer->getCurrBufSize())
/// above "if" is always false because ACK does not get chance to come in;
this causes the thread lose a chance to become background
1075:            continue;

Possible solution:
Need a proper way to put sndHandler thread into background in such case.
Maybe to wait for ACK if no data to send. Such wait will put sndHandler
thread into sleep.

Workaround:
I took suggestions from Pascal (Pas...@gn...) by adding Sleep(1)
inside the loop (just before the continue that is after
self->m_pSndBuffer->getCurrBufSize). It did work. I think the Sleep puts the
sndHandler thread into background and thus ACK can come in.

Regards,
Xudong

PS: You're right on overlapped IO. Pardon me I did not study on its usage as
in your documentation.

-----Original Message-----
From: Yunhong Gu [mailto:yu...@la...] 
Sent: Wednesday, March 15, 2006 1:33 PM
To: Chen Xudong
Cc: udt...@li...
Subject: RE: [UDT] UDT Resource Usage (again) + Bug in socket creation


I checked and tested your code.

1. I noticed the high CPU problem before connection (and a little after 
connection). The reason is that it seems SO_RCVTIMEO does not work on 
Windows when receiving from a local address. Adding a "Sleep(1)" at line 
665 of core.cpp can solve the problem.

2. I didn't notice any high CPU problem after the connection is 
established.

3. when using overlapped IO, you cannot reuse the same buffer for sending. 
Because in overlapped IO, UDT does not duplicate user buffer but read data 
from the user buffer directly. If the user buffer is written before the 
sending is finished, unexpected problem can happen.

4. the const char* problem is fixed, thanks.

Yunhong


On Tue, 14 Mar 2006, Chen Xudong wrote:

> Hi Yunhong,
>
> Forgot to mention that the high CPU usage problem was observed for
> rendezvous connection and both sides were on the same machine.
> I hence created a standalone rendezvous connection test program as
attached.
> I tried it with UDT 3.0 with observations below. Hasn't had time to try
with
> UDT 2.3 yet.
>
> Usage: peer self_ip self_port peer_ip peer_port
> For example:
> Start peer A as "peer localhost 10000 localhost 20000".
> Start peer B as "peer localhost 20000 localhost 10000".
> Type some text at one peer and each line is supposed to appear at the
other
> peer.
> Type an empty line to exit the program.
>
> In peer.cpp two compilation switches are defined:
> MODE: 0 means using SOCK_DGRAM and message IO (sendmsg/recvmsg);
>      1 means using SOCK_STREAM and regular IO (send/recv without handle);
>      2 means using SOCK_STREAM and overlapped IO (send/recv with handle
> given).
> MSGSIZE: 0 means using default UDT_MSS.
>         1 means using customized UDT_MSS as in original appclient test
> program.
>
> Observations:
>
> For MODE 0 & 1 (message IO & regular IO):
> - Sending peer occupies high CPU (more than 90%) for several seconds
before
> the text appears at the other peer,
> - and it continuously occupies CPU for more seconds.
> - Sometimes it occupies even longer until the socket is broken.
>
> For MODE 2 (overlapped IO):
> - Sending peer occupies CPU in the same pattern,
> - but more seriously the text does never appear at the other peer.
>
> For all MODE:
> - Setting UDT_MSS or not leads to the same behavior.
> - Compiling in Debug or Release leads to the same behavior.
>
> Also found another issue:
> The sendmsg API is defined with "char *" parameter. "const char *" should
be
> more appropriate.
>
> Thanks.
>
> Regards,
> Xudong
>
> -----Original Message-----
> From: Yunhong Gu [mailto:yu...@la...]
> Sent: Tuesday, March 14, 2006 1:45 PM
> To: Chen Xudong
> Cc: udt...@li...
> Subject: Re: [UDT] UDT Resource Usage (again) + Bug in socket creation
>
>
>
> Hi, Xudong,
>
> Thanks for the information, especially the silly bug in 3.0. I have
> updated the CVS.
>
> As to the first problem, I just couldn't reproduce it on my machine
> (windows XP pro, dual xeon, VS 2003). I attached the source code I am
> using on my machine in this email, can you give them a try and let me know
> if the problem is still there. Please use release version when you compile
> them.
>
> Please let me know the throughput, CPU percentage and CPU type.
>
> Thanks,
> Yunhong
>
>
> On Tue, 14 Mar 2006, Chen Xudong wrote:
>
>> Hi,
>>
>>
>>
>> I also observed high CPU usage at the sending side. This occurred for
both
>> UDT 2.3 and UDT 3.0 on Windows and it happened every time. I had tried to
>> step into UDT 3.0 while it was busy and found out the code was iterating
>> inside the while loop in CUDT::sndHandler. Following shows the important
>> lines in core.cpp that execution looped around.
>>
>> 0972:   while (!self->m_bClosing)
>>
>> 1047:         if (0 == (payload =
>> self->m_pSndBuffer->readData(&(datapkt.m_pcData), self->m_iPayloadSize,
>> datapkt.m_iMsgNo)))
>>
>> 1050:            if (0 == self->m_pSndBuffer->getCurrBufSize())
>>
>> 1072:               self->m_ullTimeDiff = 0;
>>
>> 1075:            continue;
>>
>> I compiled the UDT library using NO_BUSY_WAITING but without CUSTOM_CC.
>>
>>
>>
>> BTW, there is a bug in your UDT 3.0 code in CUDTUnited::newSocket in
>> api.cpp.
>>
>> 0155:   if ((type != SOCK_STREAM) || (type != SOCK_DGRAM))
>>
>> 0156:      throw CUDTException(5, 3, 0);
>>
>> "||" should be changed to "&&". This bug causes all programs to fail
> because
>> a socket can never be created.
>>
>>
>>
>> Thanks & Regards,
>>
>> Xudong
>>
>>
>

RE: [UDT] UDT Resource Usage (again) + Bug in socket creation

[Yunhong Gu <yu...@la...>]

I checked and tested your code.

1. I noticed the high CPU problem before connection (and a little after 
connection). The reason is that it seems SO_RCVTIMEO does not work on 
Windows when receiving from a local address. Adding a "Sleep(1)" at line 
665 of core.cpp can solve the problem.

2. I didn't notice any high CPU problem after the connection is 
established.

3. when using overlapped IO, you cannot reuse the same buffer for sending. 
Because in overlapped IO, UDT does not duplicate user buffer but read data 
from the user buffer directly. If the user buffer is written before the 
sending is finished, unexpected problem can happen.

4. the const char* problem is fixed, thanks.

Yunhong


On Tue, 14 Mar 2006, Chen Xudong wrote:

> Hi Yunhong,
>
> Forgot to mention that the high CPU usage problem was observed for
> rendezvous connection and both sides were on the same machine.
> I hence created a standalone rendezvous connection test program as attached.
> I tried it with UDT 3.0 with observations below. Hasn't had time to try with
> UDT 2.3 yet.
>
> Usage: peer self_ip self_port peer_ip peer_port
> For example:
> Start peer A as "peer localhost 10000 localhost 20000".
> Start peer B as "peer localhost 20000 localhost 10000".
> Type some text at one peer and each line is supposed to appear at the other
> peer.
> Type an empty line to exit the program.
>
> In peer.cpp two compilation switches are defined:
> MODE: 0 means using SOCK_DGRAM and message IO (sendmsg/recvmsg);
>      1 means using SOCK_STREAM and regular IO (send/recv without handle);
>      2 means using SOCK_STREAM and overlapped IO (send/recv with handle
> given).
> MSGSIZE: 0 means using default UDT_MSS.
>         1 means using customized UDT_MSS as in original appclient test
> program.
>
> Observations:
>
> For MODE 0 & 1 (message IO & regular IO):
> - Sending peer occupies high CPU (more than 90%) for several seconds before
> the text appears at the other peer,
> - and it continuously occupies CPU for more seconds.
> - Sometimes it occupies even longer until the socket is broken.
>
> For MODE 2 (overlapped IO):
> - Sending peer occupies CPU in the same pattern,
> - but more seriously the text does never appear at the other peer.
>
> For all MODE:
> - Setting UDT_MSS or not leads to the same behavior.
> - Compiling in Debug or Release leads to the same behavior.
>
> Also found another issue:
> The sendmsg API is defined with "char *" parameter. "const char *" should be
> more appropriate.
>
> Thanks.
>
> Regards,
> Xudong
>
> -----Original Message-----
> From: Yunhong Gu [mailto:yu...@la...]
> Sent: Tuesday, March 14, 2006 1:45 PM
> To: Chen Xudong
> Cc: udt...@li...
> Subject: Re: [UDT] UDT Resource Usage (again) + Bug in socket creation
>
>
>
> Hi, Xudong,
>
> Thanks for the information, especially the silly bug in 3.0. I have
> updated the CVS.
>
> As to the first problem, I just couldn't reproduce it on my machine
> (windows XP pro, dual xeon, VS 2003). I attached the source code I am
> using on my machine in this email, can you give them a try and let me know
> if the problem is still there. Please use release version when you compile
> them.
>
> Please let me know the throughput, CPU percentage and CPU type.
>
> Thanks,
> Yunhong
>
>
> On Tue, 14 Mar 2006, Chen Xudong wrote:
>
>> Hi,
>>
>>
>>
>> I also observed high CPU usage at the sending side. This occurred for both
>> UDT 2.3 and UDT 3.0 on Windows and it happened every time. I had tried to
>> step into UDT 3.0 while it was busy and found out the code was iterating
>> inside the while loop in CUDT::sndHandler. Following shows the important
>> lines in core.cpp that execution looped around.
>>
>> 0972:   while (!self->m_bClosing)
>>
>> 1047:         if (0 == (payload =
>> self->m_pSndBuffer->readData(&(datapkt.m_pcData), self->m_iPayloadSize,
>> datapkt.m_iMsgNo)))
>>
>> 1050:            if (0 == self->m_pSndBuffer->getCurrBufSize())
>>
>> 1072:               self->m_ullTimeDiff = 0;
>>
>> 1075:            continue;
>>
>> I compiled the UDT library using NO_BUSY_WAITING but without CUSTOM_CC.
>>
>>
>>
>> BTW, there is a bug in your UDT 3.0 code in CUDTUnited::newSocket in
>> api.cpp.
>>
>> 0155:   if ((type != SOCK_STREAM) || (type != SOCK_DGRAM))
>>
>> 0156:      throw CUDTException(5, 3, 0);
>>
>> "||" should be changed to "&&". This bug causes all programs to fail
> because
>> a socket can never be created.
>>
>>
>>
>> Thanks & Regards,
>>
>> Xudong
>>
>>
>

RE: [UDT] UDT Resource Usage (again) + Bug in socket creation

[LeBlanc, P. \(C. Bathurst\) <Pas...@gn...>]

Hi Yunhong, Xudong,

If it is of any help, I have seen the same in my application.  I send
about 1.5kbyte per second divided in 2-3 separate send() and it is
enough to keep the cpu at 100%.  I had also traced the cpu usage to the
thread handling CUDT::sndHandler.  If I recall correctly, everything is
default except the socket used to accept() that is set as non blocking.
I know this is not a solution but I tried adding a Sleep(1) in the loop
in CUDT::sndHandler and cpu dropped back to normal values.

Thanks,
Pascal



-----Original Message-----
From: udt...@li...
[mailto:udt...@li...] On Behalf Of Chen
Xudong
Sent: March 14, 2006 6:30 AM
To: 'Yunhong Gu'
Cc: xd...@es...
Subject: RE: [UDT] UDT Resource Usage (again) + Bug in socket creation


Hi Yunhong,

Forgot to mention that the high CPU usage problem was observed for
rendezvous connection and both sides were on the same machine. I hence
created a standalone rendezvous connection test program as attached. I
tried it with UDT 3.0 with observations below. Hasn't had time to try
with UDT 2.3 yet.

Usage: peer self_ip self_port peer_ip peer_port
For example:
Start peer A as "peer localhost 10000 localhost 20000".
Start peer B as "peer localhost 20000 localhost 10000".
Type some text at one peer and each line is supposed to appear at the
other peer. Type an empty line to exit the program.

In peer.cpp two compilation switches are defined:
MODE: 0 means using SOCK_DGRAM and message IO (sendmsg/recvmsg);
      1 means using SOCK_STREAM and regular IO (send/recv without
handle);
      2 means using SOCK_STREAM and overlapped IO (send/recv with handle
given).
MSGSIZE: 0 means using default UDT_MSS.
         1 means using customized UDT_MSS as in original appclient test
program.

Observations:

For MODE 0 & 1 (message IO & regular IO):
- Sending peer occupies high CPU (more than 90%) for several seconds
before the text appears at the other peer,
- and it continuously occupies CPU for more seconds.
- Sometimes it occupies even longer until the socket is broken.

For MODE 2 (overlapped IO):
- Sending peer occupies CPU in the same pattern,
- but more seriously the text does never appear at the other peer.

For all MODE:
- Setting UDT_MSS or not leads to the same behavior.
- Compiling in Debug or Release leads to the same behavior.

Also found another issue:
The sendmsg API is defined with "char *" parameter. "const char *"
should be more appropriate.

Thanks.

Regards,
Xudong

-----Original Message-----
From:=20
Sent: Tuesday, March 14, 2006 1:45 PM
To: Chen Xudong
Cc: udt...@li...
Subject: Re: [UDT] UDT Resource Usage (again) + Bug in socket creation



Hi, Xudong,

Thanks for the information, especially the silly bug in 3.0. I have=20
updated the CVS.

As to the first problem, I just couldn't reproduce it on my machine=20
(windows XP pro, dual xeon, VS 2003). I attached the source code I am=20
using on my machine in this email, can you give them a try and let me
know=20
if the problem is still there. Please use release version when you
compile=20
them.

Please let me know the throughput, CPU percentage and CPU type.

Thanks,
Yunhong


On Tue, 14 Mar 2006, Chen Xudong wrote:

> Hi,
>
>
>
> I also observed high CPU usage at the sending side. This occurred for=20
> both UDT 2.3 and UDT 3.0 on Windows and it happened every time. I had=20
> tried to step into UDT 3.0 while it was busy and found out the code=20
> was iterating inside the while loop in CUDT::sndHandler. Following=20
> shows the important lines in core.cpp that execution looped around.
>
> 0972:   while (!self->m_bClosing)
>
> 1047:         if (0 =3D=3D (payload =3D
> self->m_pSndBuffer->readData(&(datapkt.m_pcData),=20
> self->self->m_iPayloadSize,
> datapkt.m_iMsgNo)))
>
> 1050:            if (0 =3D=3D self->m_pSndBuffer->getCurrBufSize())
>
> 1072:               self->m_ullTimeDiff =3D 0;
>
> 1075:            continue;
>
> I compiled the UDT library using NO_BUSY_WAITING but without=20
> CUSTOM_CC.
>
>
>
> BTW, there is a bug in your UDT 3.0 code in CUDTUnited::newSocket in=20
> api.cpp.
>
> 0155:   if ((type !=3D SOCK_STREAM) || (type !=3D SOCK_DGRAM))
>
> 0156:      throw CUDTException(5, 3, 0);
>
> "||" should be changed to "&&". This bug causes all programs to fail
because
> a socket can never be created.
>
>
>
> Thanks & Regards,
>
> Xudong
>
>

RE: [UDT] UDT Resource Usage (again) + Bug in socket creation

[Chen X. <xd...@es...>]

Hi Yunhong,

Forgot to mention that the high CPU usage problem was observed for
rendezvous connection and both sides were on the same machine.
I hence created a standalone rendezvous connection test program as attached.
I tried it with UDT 3.0 with observations below. Hasn't had time to try with
UDT 2.3 yet.

Usage: peer self_ip self_port peer_ip peer_port
For example:
Start peer A as "peer localhost 10000 localhost 20000".
Start peer B as "peer localhost 20000 localhost 10000".
Type some text at one peer and each line is supposed to appear at the other
peer.
Type an empty line to exit the program.

In peer.cpp two compilation switches are defined:
MODE: 0 means using SOCK_DGRAM and message IO (sendmsg/recvmsg);
      1 means using SOCK_STREAM and regular IO (send/recv without handle);
      2 means using SOCK_STREAM and overlapped IO (send/recv with handle
given).
MSGSIZE: 0 means using default UDT_MSS.
         1 means using customized UDT_MSS as in original appclient test
program.

Observations:

For MODE 0 & 1 (message IO & regular IO):
- Sending peer occupies high CPU (more than 90%) for several seconds before
the text appears at the other peer,
- and it continuously occupies CPU for more seconds.
- Sometimes it occupies even longer until the socket is broken.

For MODE 2 (overlapped IO):
- Sending peer occupies CPU in the same pattern,
- but more seriously the text does never appear at the other peer.

For all MODE:
- Setting UDT_MSS or not leads to the same behavior.
- Compiling in Debug or Release leads to the same behavior.

Also found another issue:
The sendmsg API is defined with "char *" parameter. "const char *" should be
more appropriate.

Thanks.

Regards,
Xudong

-----Original Message-----
From: Yunhong Gu [mailto:yu...@la...] 
Sent: Tuesday, March 14, 2006 1:45 PM
To: Chen Xudong
Cc: udt...@li...
Subject: Re: [UDT] UDT Resource Usage (again) + Bug in socket creation



Hi, Xudong,

Thanks for the information, especially the silly bug in 3.0. I have 
updated the CVS.

As to the first problem, I just couldn't reproduce it on my machine 
(windows XP pro, dual xeon, VS 2003). I attached the source code I am 
using on my machine in this email, can you give them a try and let me know 
if the problem is still there. Please use release version when you compile 
them.

Please let me know the throughput, CPU percentage and CPU type.

Thanks,
Yunhong


On Tue, 14 Mar 2006, Chen Xudong wrote:

> Hi,
>
>
>
> I also observed high CPU usage at the sending side. This occurred for both
> UDT 2.3 and UDT 3.0 on Windows and it happened every time. I had tried to
> step into UDT 3.0 while it was busy and found out the code was iterating
> inside the while loop in CUDT::sndHandler. Following shows the important
> lines in core.cpp that execution looped around.
>
> 0972:   while (!self->m_bClosing)
>
> 1047:         if (0 == (payload =
> self->m_pSndBuffer->readData(&(datapkt.m_pcData), self->m_iPayloadSize,
> datapkt.m_iMsgNo)))
>
> 1050:            if (0 == self->m_pSndBuffer->getCurrBufSize())
>
> 1072:               self->m_ullTimeDiff = 0;
>
> 1075:            continue;
>
> I compiled the UDT library using NO_BUSY_WAITING but without CUSTOM_CC.
>
>
>
> BTW, there is a bug in your UDT 3.0 code in CUDTUnited::newSocket in
> api.cpp.
>
> 0155:   if ((type != SOCK_STREAM) || (type != SOCK_DGRAM))
>
> 0156:      throw CUDTException(5, 3, 0);
>
> "||" should be changed to "&&". This bug causes all programs to fail
because
> a socket can never be created.
>
>
>
> Thanks & Regards,
>
> Xudong
>
>

Re: [UDT] UDT Resource Usage (again) + Bug in socket creation

[Yunhong Gu <yu...@la...>]

Hi, Xudong,

Thanks for the information, especially the silly bug in 3.0. I have 
updated the CVS.

As to the first problem, I just couldn't reproduce it on my machine 
(windows XP pro, dual xeon, VS 2003). I will send you the source code I am 
using on my machine in a seperate email, can you give them a try and let 
me know if the problem is still there. Please use release version when you 
compile them.

Please let me know the throughput, CPU percentage and CPU type.

Thanks,
Yunhong

Yunhong Gu, Ph.D., 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, 14 Mar 2006, Chen Xudong wrote:

> Hi,
>
>
>
> I also observed high CPU usage at the sending side. This occurred for both
> UDT 2.3 and UDT 3.0 on Windows and it happened every time. I had tried to
> step into UDT 3.0 while it was busy and found out the code was iterating
> inside the while loop in CUDT::sndHandler. Following shows the important
> lines in core.cpp that execution looped around.
>
> 0972:   while (!self->m_bClosing)
>
> 1047:         if (0 == (payload =
> self->m_pSndBuffer->readData(&(datapkt.m_pcData), self->m_iPayloadSize,
> datapkt.m_iMsgNo)))
>
> 1050:            if (0 == self->m_pSndBuffer->getCurrBufSize())
>
> 1072:               self->m_ullTimeDiff = 0;
>
> 1075:            continue;
>
> I compiled the UDT library using NO_BUSY_WAITING but without CUSTOM_CC.
>
>
>
> BTW, there is a bug in your UDT 3.0 code in CUDTUnited::newSocket in
> api.cpp.
>
> 0155:   if ((type != SOCK_STREAM) || (type != SOCK_DGRAM))
>
> 0156:      throw CUDTException(5, 3, 0);
>
> "||" should be changed to "&&". This bug causes all programs to fail because
> a socket can never be created.
>
>
>
> Thanks & Regards,
>
> Xudong
>
>

[UDT] UDT Resource Usage (again) + Bug in socket creation

[Chen X. <xd...@es...>]

Hi,

 

I also observed high CPU usage at the sending side. This occurred for both
UDT 2.3 and UDT 3.0 on Windows and it happened every time. I had tried to
step into UDT 3.0 while it was busy and found out the code was iterating
inside the while loop in CUDT::sndHandler. Following shows the important
lines in core.cpp that execution looped around.

0972:   while (!self->m_bClosing)

1047:         if (0 == (payload =
self->m_pSndBuffer->readData(&(datapkt.m_pcData), self->m_iPayloadSize,
datapkt.m_iMsgNo)))

1050:            if (0 == self->m_pSndBuffer->getCurrBufSize())

1072:               self->m_ullTimeDiff = 0;

1075:            continue;

I compiled the UDT library using NO_BUSY_WAITING but without CUSTOM_CC.

 

BTW, there is a bug in your UDT 3.0 code in CUDTUnited::newSocket in
api.cpp.

0155:   if ((type != SOCK_STREAM) || (type != SOCK_DGRAM))

0156:      throw CUDTException(5, 3, 0);

"||" should be changed to "&&". This bug causes all programs to fail because
a socket can never be created.

 

Thanks & Regards,

Xudong

[UDT] Re: Meaning of m_issthresh

[Harald s. <sc...@rv...>]

Hi Yunhong,
thank you very much for your quick respond. This make sence.
I'm slowly beginning to understand how UDT's CCC work.
By,
Harald



Am Montag, den 13.03.2006, 10:51 -0600 schrieb Yunhong Gu:
> Harald,
>=20
> YOu are right. I was assuming an infinite ssthresh at the beginning but=
=20
> forgot to check it in the later slow start phases.
>=20
> The ACKAction() should like this:
>     virtual void ACKAction()
>     {
>        if (m_bSlowStart)
>        {
>           m_dCWndSize +=3D 1.0;
>=20
>           if (m_dCWndSize >=3D m_issthresh)
>              m_bSlowStart =3D false;
>        }
>        else
>           m_dCWndSize +=3D 1.0/m_dCWndSize;
>     }
>=20
> and the initial m_issthresh should be a large value.
>=20
> Thanks
> Yunhong
>=20
>=20
> On Mon, 13 Mar 2006, Harald schwier wrote:
>=20
> > Hello Yunhong,
> > Thank you for your answer.
> > I've transfered 10GB of data in our testnet. The router is configured
> > to create a delay off 100ms and to drop every 1000000 Paket.
> >
> > Slow start should double the congestion window every RTT until it
> > reaches ssthresh. Because of  m_issthresh =3D 2; (cc.h line 34) i
> > expected that UDT-tcp did not perform slow start at the beginning
> > of the connection. But the measurement shows that the connection
> > performs slow start. Have i misunderstood the meaning of m_issthresh?
> >
> > I've attached the measured data transfer.
> > Bye,
> >
> >
> > Am Freitag, den 10.03.2006, 14:14 -0600 schrieb Yunhong Gu:
> >> Hi, Harald,
> >>
> >> Thanks for your comment.
> >>
> >> In CTCP, your connection probably didn't see any packet loss, so the=
 cwnd
> >> simply continue to increase with slow start. Can you verify this?
> >>
> >> You are right about the Scalable TCP implementation, after 38, it st=
ill
> >> needs slow start. I have fixed this and will update the CVS soon.
> >>
> >> Thanks
> >> Yunhong
> >>
> >> On Fri, 10 Mar 2006, Harald schwier wrote:
> >>
> >>> Hello,
> >>> i'm a little unsecure about the meaning of the value "m_issthresh",
> >>> which is initialized in cc.h ( class CTCP ). I thought that it is
> >>> the initial slow start threshhold, but although it is initialized
> >>> with "2", udt (ccc CTCP) performs slow start up to an arbitrary
> >>> high congestion window.
> >>>
> >>> Second, udt is very slow if i use UDT-scalable (high RTT).
> >>> UDT-Scalable uses TCP at a Congestion Window below 38.
> >>> After that it updates the congestion window according to CW=3DCW+0.=
01,
> >>> which means a very slow increase at low Congestion Windows (That's =
why
> >>> scalable is called scalable :-) ). At a RTT of 100ms UDT-scalable
> >>> needs 120 seconds to fully utilise a Gigabit Link.
> >>> I think that scalable should perform slow start after the connectio=
n is
> >>> established.
> >>>
> >>> Third, I think that UDT is GREAT WORK!!!
> >>>
> >>> Bye,
> >>> Harald
> >>>
> >>>
> >>>
> > Mit freundlichen Gr=C3=BC=C3=9Fen,
> > Harald Schwier
> >
> >
> > --=20
> > Dipl.-Ing. Harald Schwier          D-30159 Hannover
> > Lehrgebiet Rechnernetze            Schlosswender Str. 5
> > RRZN, Universit=C3=A4t Hannover         Tel: +49 (511) 762 7919081
> > Fachbereich Informatik
> >
> >
> >
Mit freundlichen Gr=C3=BC=C3=9Fen,
Harald Schwier


--=20
Dipl.-Ing. Harald Schwier          D-30159 Hannover
Lehrgebiet Rechnernetze            Schlosswender Str. 5
RRZN, Universit=C3=A4t Hannover         Tel: +49 (511) 762 7919081
Fachbereich Informatik

Re: [UDT] Error in app/cc.h (CScalableTCP)

[Yunhong Gu <yu...@la...>]

Yes, you are right. Thanks for leting me know this. I will fix this 
problem and update the CVS.

Yunhong

On Fri, 3 Mar 2006, Harald schwier wrote:

> Hello,
> i thing there is a bug in Scalable TCP congestion control.
> In ACKAction the Congestion Window is updated by:
> m_dCWndSize += 0.01 * m_dCWndSize;  (Line 140)
>
> According to
> http://datatag.web.cern.ch/datatag/pfldnet2003/papers/kelly.pdf
> this should look like:
> m_dCWndSize += 0.01;
>
> Bye,
> Harald
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> UDT-general mailing list
> UDT...@li...
> https://lists.sourceforge.net/lists/listinfo/udt-general
>

[UDT] Error in app/cc.h (CScalableTCP)

[Harald s. <sc...@rv...>]

Hello,
i thing there is a bug in Scalable TCP congestion control.
In ACKAction the Congestion Window is updated by:
m_dCWndSize += 0.01 * m_dCWndSize;  (Line 140)

According to
http://datatag.web.cern.ch/datatag/pfldnet2003/papers/kelly.pdf
this should look like:
m_dCWndSize += 0.01;

Bye,
Harald

Re: [UDT] UDT with congestion control

[Harald s. <sc...@rv...>]

Hmmmm....
i begin to understand what' s wrong with my measurement.
Where TCP congestion control is implemented only sender-side,
UDT uses control comunication between sender and receiver.
I had activated the CCC only at the sender side.

Perhaps i should have a deeper look at the documentation
befor asking the mailing list.... :-(


Bye
Harald



Am Freitag, den 03.03.2006, 08:21 +0100 schrieb Harald schwier:
> Hello Yunhong,
>=20
> Thank you for your answer.
> I have also tried the scalable, hstcp and BIC congestion contol
> algorithms as they are defined in cc.h.
> Every time i get a performance of 0.2 MB/s.
>=20
> For example, i activated scalable with:
> UDT::setsockopt(client,0,UDT_CC,newCCCFactory<CScalableTCP>,sizeof(CCCF=
actory<CScalableTCP>));
> Is there anything more to do? What may be the reason for the poor
> Performance?
>=20
> Thanks in advance,
> Harald
>=20
>=20
> > Hi, Harald,
> >=20
> > Once you uncomment the -DCUSTOM_CC option, the default UDT congestion=
=20
> > control algorithm will not be used any more.
> >=20
> > Default window size in UDT is 16 packets and it will not change unles=
s you=20
> > assign a new congestion control algorithm.
> >=20
> > Once you specify CTCP, you are using TCP's AIMD algorithm, which usua=
lly=20
> > does not work well for long distance links (you mentioned that RTT is=
=20
> > 100ms).
> >=20
> > Thanks
> > Yunhong
> >=20
> >=20
> > On Thu, 2 Mar 2006, Harald schwier wrote:
> >=20
> > > Hello,
> > > i'm doing some performance tests with UDT. Without changing
> > > any options, appclient shows 950 MB/s (1GB Ethernet, RTT about 100m=
s).
> > >
> > > After i uncomment the -DCUSTOM_CC compile option in ./src/Makefile
> > > and recompile the library the Performance goes down to 1.7 MB/s wit=
hout
> > > changing any Options in appclient.
> > >
> > > When i change the socket options with:
> > > UDT::setsockopt(client,0,UDT_CC,newCCCFactory<CTCP>,sizeof(CCCFacto=
ry<CTCP>));
> > > the performance goes down to 0.2 MB/s.
> > >
> > > UDT 2.3
> > > Compiled with: make -e os=3DLINUX arch=3DAMD64
> > >
> > > What may be the reason for the poor performance???
> > >
> > > Thanks in advance,
> > > Harald
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by xPML, a groundbreaking scripting =
language
> > > that extends applications into web and mobile media. Attend the liv=
e webcast
> > > and join the prime developer group breaking into this new coding te=
rritory!
> > > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720=
&dat=3D121642
> > > _______________________________________________
> > > UDT-general mailing list
> > > UDT...@li...
> > > https://lists.sourceforge.net/lists/listinfo/udt-general
> > >
> Mit freundlichen Gr=C3=BC=C3=9Fen,
> Harald Schwier
>=20
>=20
Mit freundlichen Gr=C3=BC=C3=9Fen,
Harald Schwier


--=20
Dipl.-Ing. Harald Schwier          D-30159 Hannover
Lehrgebiet Rechnernetze            Schlosswender Str. 5
RRZN, Universit=C3=A4t Hannover         Tel: +49 (511) 762 7919081
Fachbereich Informatik