Re: [twsocket] Throughput problem with TWSocket over a "long line"
Hello Arno, > I would play with sligtly increased SocketSndBufSize and a BufSize set > to something below like 16/8 and 32/16 kb. TWSocket's property > BufSize actually is the block size and the amount of data copied into > the winsock buffer in a single (winsock) send call. Unfortunately the connection link is busy now and for the next days but I will make more tests whenever I find time. > Increasing > SocketSndBufSize however also decreases the maximum posible sockets > in the system (no problem if you don't need hundreds of sockets at > the same time). Basically I have dedicated machines for both server and client side of my file transfer application so using some system resources is possible if better throughput is gained. However as far as my first test shows it does not make much difference if I also increase the SocketSndBufSize in that scenario. Increasing BufSize makes the biggest change. /Tobias -- NOA Audio Solutions Vertriebsges.m.b.H.Tel: +43-1-5452700 Johannagasse 42/4 Fax: +43-1-545270014 A - 1050 Wien Www: http://www.noa-audio.com -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Throughput problem with TWSocket over a "long line"
Tobias Rapp wrote: > Hello Arno, > >>> By default winsock's send buffer size is 8 kb which is much bigger >>> than TFtpCli's constant BLOCK_SIZE of 1460 bytes. So one condition >>> described in the article is not true since a single send call in >>> TFtpCli does not fill the whole underlying winsock send buffer. >>> I realy wonder why disabling Nagle doesn't help? >> >> Same applies to WSocket's internal send buffer that has a block size >> of 1460 as well. So if you haven't increased BufSize of TWSocket >> a single send call does never fill the whole underlying winsock send >> buffer. > > That's exactly the thing I'm doing at the moment: I increase the > BufSize of TWSocket from 1460 bytes to 1MB. The throughput increases > from 1.2MB/s to more than 7MB/s. Ahh, I was thinking that you increased winsock's send buffer size. With a BufSize > winsock send buffer you risc to fullfill the error conditions described in the article... I would play with sligtly increased SocketSndBufSize and a BufSize set to something below like 16/8 and 32/16 kb. TWSocket's property BufSize actually is the block size and the amount of data copied into the winsock buffer in a single (winsock) send call. Increasing SocketSndBufSize however also decreases the maximum posible sockets in the system (no problem if you don't need hundreds of sockets at the same time). > > As far as I understand Nagle=off only would help me if I would like to > send small packets (< MCU) at a very high rate. But that is not the > case: I want to deliver large files (> 3GB). > > When I look at the IP traffic with Wireshark I see something like this > in the case where TWSocket.BufSize=1460 : > > Client->Server 1448 bytes > Client->Server 12 bytes > Server->Client ACK > Client->Server 1448 bytes > Client->Server 12 bytes > Server->Client ACK > > > And in the case where TWSocket.BufSize=1MB : > > Client->Server 1448 bytes > Client->Server 1448 bytes > Client->Server 1448 bytes > // previous line repeated 10-30 times > Server->Client ACK > Client->Server 1448 bytes > Client->Server 1448 bytes > Client->Server 1448 bytes > // previous line repeated 10-30 times > Server->Client ACK > > So shall I explicitly add a call setsockopt() that increases the socket send buffer dramatically (>1MB)? >>> Use WSocket option SocketSndBufSize instead, it will the call >>> setsockopt() internally. I think that 1 MB is much too big, since >>> this memory is allocated from kernel memory which is not an endless >>> resource. > > SocketSndBufSize property is read-only, at least in my version of > WSocket.pas (V5.25). > > /Tobias > > > -- > NOA Audio Solutions Vertriebsges.m.b.H.Tel: +43-1-5452700 > Johannagasse 42/4 Fax: +43-1-545270014 > A - 1050 Wien Www: http://www.noa- > audio.com -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Throughput problem with TWSocket over a "long line"
Hello Arno, >> By default winsock's send buffer size is 8 kb which is much bigger >> than TFtpCli's constant BLOCK_SIZE of 1460 bytes. So one condition >> described in the article is not true since a single send call in >> TFtpCli does not fill the whole underlying winsock send buffer. >> I realy wonder why disabling Nagle doesn't help? > > Same applies to WSocket's internal send buffer that has a block size > of 1460 as well. So if you haven't increased BufSize of TWSocket > a single send call does never fill the whole underlying winsock send > buffer. That's exactly the thing I'm doing at the moment: I increase the BufSize of TWSocket from 1460 bytes to 1MB. The throughput increases from 1.2MB/s to more than 7MB/s. As far as I understand Nagle=off only would help me if I would like to send small packets (< MCU) at a very high rate. But that is not the case: I want to deliver large files (> 3GB). When I look at the IP traffic with Wireshark I see something like this in the case where TWSocket.BufSize=1460 : Client->Server 1448 bytes Client->Server 12 bytes Server->Client ACK Client->Server 1448 bytes Client->Server 12 bytes Server->Client ACK And in the case where TWSocket.BufSize=1MB : Client->Server 1448 bytes Client->Server 1448 bytes Client->Server 1448 bytes // previous line repeated 10-30 times Server->Client ACK Client->Server 1448 bytes Client->Server 1448 bytes Client->Server 1448 bytes // previous line repeated 10-30 times Server->Client ACK >>> So shall I explicitly add a call setsockopt() that increases the >>> socket send buffer dramatically (>1MB)? >> Use WSocket option SocketSndBufSize instead, it will the call >> setsockopt() internally. I think that 1 MB is much too big, since >> this memory is allocated from kernel memory which is not an endless >> resource. SocketSndBufSize property is read-only, at least in my version of WSocket.pas (V5.25). /Tobias -- NOA Audio Solutions Vertriebsges.m.b.H.Tel: +43-1-5452700 Johannagasse 42/4 Fax: +43-1-545270014 A - 1050 Wien Www: http://www.noa-audio.com -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Throughput problem with TWSocket over a "long line"
Arno Garrels wrote: > Tobias Rapp wrote: > >> http://support.microsoft.com/default.aspx?scid=kb;en-us;823764 > > By default winsock's send buffer size is 8 kb which is much bigger > than TFtpCli's constant BLOCK_SIZE of 1460 bytes. So one condition > described in the article is not true since a single send call in > TFtpCli does not fill the whole underlying winsock send buffer. > I realy wonder why disabling Nagle doesn't help? Same applies to WSocket's internal send buffer that has a block size of 1460 as well. So if you haven't increased BufSize of TWSocket a single send call does never fill the whole underlying winsock send buffer. >> >> So shall I explicitly add a call setsockopt() that increases the >> socket send buffer dramatically (>1MB)? > > Use WSocket option SocketSndBufSize instead, it will the call > setsockopt() internally. I think that 1 MB is much too big, since > this memory is allocated from kernel memory which is not an endless > resource. > > --- > Arno Garrels [TeamICS] > http://www.overbyte.be/eng/overbyte/teamics.html > > > What is your opinion about >> that? >> >> /Tobias >> >> >> -- >> NOA Audio Solutions Vertriebsges.m.b.H.Tel: +43-1-5452700 >> Johannagasse 42/4 Fax: +43-1-545270014 >> A - 1050 Wien Www: http://www.noa- >> audio.com -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Throughput problem with TWSocket over a "long line"
Tobias Rapp wrote: > http://support.microsoft.com/default.aspx?scid=kb;en-us;823764 By default winsock's send buffer size is 8 kb which is much bigger than TFtpCli's constant BLOCK_SIZE of 1460 bytes. So one condition described in the article is not true since a single send call in TFtpCli does not fill the whole underlying winsock send buffer. I realy wonder why disabling Nagle doesn't help? > > So shall I explicitly add a call setsockopt() that increases the > socket send buffer dramatically (>1MB)? Use WSocket option SocketSndBufSize instead, it will the call setsockopt() internally. I think that 1 MB is much too big, since this memory is allocated from kernel memory which is not an endless resource. --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html What is your opinion about > that? > > /Tobias > > > -- > NOA Audio Solutions Vertriebsges.m.b.H.Tel: +43-1-5452700 > Johannagasse 42/4 Fax: +43-1-545270014 > A - 1050 Wien Www: http://www.noa- > audio.com -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Throughput problem with TWSocket over a "long line"
Hello Wilfried, >> Looks like >> http://support.microsoft.com/default.aspx?scid=kb;en-us;823764 is wrong >> in my special case or the system is automagically increasing the > > Can you resent the URL please ? It seems dead here. http://support.microsoft.com/default.aspx?scid=kb;en-us;823764 It's the link to the MSDN page titled "Slow performance occurs when you copy data to a TCP server by using a Windows Sockets API program" that is referred to in the WSocket.pas unit (see comment line that starts with "Jun 03, 2005 V5.18"). /Tobias -- NOA Audio Solutions Vertriebsges.m.b.H.Tel: +43-1-5452700 Johannagasse 42/4 Fax: +43-1-545270014 A - 1050 Wien Www: http://www.noa-audio.com -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Throughput problem with TWSocket over a "long line"
Hello Tobias, > Looks like > http://support.microsoft.com/default.aspx?scid=kb;en-us;823764 is wrong > in my special case or the system is automagically increasing the Can you resent the URL please ? It seems dead here. --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Throughput problem with TWSocket over a "long line"
Hi SZ, > Ok I think the problem is in sliding windows then. Make sure the receiving > client/server has a large sliding window. There is a way to calculate it but > I am not sure of the exact formula. Something related with the round trip > times and bandwidth. Sliding windows _should_ be explained in wikipedia. Yes, the sliding window property of TCP/IP is adjusted. Please have a look at my initial posting and you'll find out that I compared the throughput of ICS FTP demo server to that of the Indy10 FTP demo server on the same computer using the same connection. Today I have found out that the problem is solved for this special case when increasing the BufSize of tWSocket to large values (around 1MB gives a throughput of ~7.7MB/s). Now my question is if it is a good idea to use such big buffers for file transfers in general. /Tobias -- NOA Audio Solutions Vertriebsges.m.b.H.Tel: +43-1-5452700 Johannagasse 42/4 Fax: +43-1-545270014 A - 1050 Wien Www: http://www.noa-audio.com -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Throughput problem with TWSocket over a "long line"
Ok I think the problem is in sliding windows then. Make sure the receiving client/server has a large sliding window. There is a way to calculate it but I am not sure of the exact formula. Something related with the round trip times and bandwidth. Sliding windows _should_ be explained in wikipedia. Regards, SZ - Original Message - From: "Tobias Rapp" <[EMAIL PROTECTED]> To: "ICS support mailing" Sent: Tuesday, January 16, 2007 2:56 PM Subject: Re: [twsocket] Throughput problem with TWSocket over a "long line" > Hi SZ, > >> I think your problem should be in the message pump. What do you use >> for that in your thread? When I switched to GetMessage from >> PeekMessage, I was WOW! > > I use TWSocket's MessageLoop() function in my threaded application which > uses GetMessage() internally. And Wilfried's test programm uses no > threads at all. > > But the basic thing was not that I cannot reach more throughput than > 1.2MB/s at all. If I use two computers in my intranet I easily gain a > throughput of more than 20MB/s (disc IO included). It was a special case > that I had a problem with: When TCP/IP connection is going through an > ATM line (high round trip times). > > /Tobias > > > -- > NOA Audio Solutions Vertriebsges.m.b.H.Tel: +43-1-5452700 > Johannagasse 42/4 Fax: +43-1-545270014 > A - 1050 Wien Www: http://www.noa-audio.com > > -- > To unsubscribe or change your settings for TWSocket mailing list > please goto http://www.elists.org/mailman/listinfo/twsocket > Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Throughput problem with TWSocket over a "long line"
Hi SZ, > I think your problem should be in the message pump. What do you use > for that in your thread? When I switched to GetMessage from > PeekMessage, I was WOW! I use TWSocket's MessageLoop() function in my threaded application which uses GetMessage() internally. And Wilfried's test programm uses no threads at all. But the basic thing was not that I cannot reach more throughput than 1.2MB/s at all. If I use two computers in my intranet I easily gain a throughput of more than 20MB/s (disc IO included). It was a special case that I had a problem with: When TCP/IP connection is going through an ATM line (high round trip times). /Tobias -- NOA Audio Solutions Vertriebsges.m.b.H.Tel: +43-1-5452700 Johannagasse 42/4 Fax: +43-1-545270014 A - 1050 Wien Www: http://www.noa-audio.com -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Throughput problem with TWSocket over a "long line"
I think your problem should be in the message pump. What do you use for that in your thread? When I switched to GetMessage from PeekMessage, I was WOW! Regards, SZ - Original Message - From: "Tobias Rapp" <[EMAIL PROTECTED]> To: "ICS support mailing" Sent: Tuesday, January 16, 2007 12:16 PM Subject: Re: [twsocket] Throughput problem with TWSocket over a "long line" > Hi Wilfried, > >> You find on my site a few programs to test performance with TWSocket. > > I have found the PerformanceTest project and tested it. In the first run > it also gave the well-known value of ~1.2MB/s. Then I digged into > TWSocket's Send() function and found the BufSize property. After > changing the BufSize to 1MB (I have read the warning about setting it > larger than SocketSndBufSize in the comments but wanted to try myself) I > got rates of ~7.7MB/s - what an improvement! > > Looks like > http://support.microsoft.com/default.aspx?scid=kb;en-us;823764 is wrong > in my special case or the system is automagically increasing the > socket's send buffer behind the scenes. When I read the socket send > buffer size with getsockopt() while the transfer is running it remains > at 8192 bytes, though. > > So shall I explicitly add a call setsockopt() that increases the socket > send buffer dramatically (>1MB)? What is your opinion about that? > > /Tobias > > > -- > NOA Audio Solutions Vertriebsges.m.b.H.Tel: +43-1-5452700 > Johannagasse 42/4 Fax: +43-1-545270014 > A - 1050 Wien Www: http://www.noa-audio.com > > -- > To unsubscribe or change your settings for TWSocket mailing list > please goto http://www.elists.org/mailman/listinfo/twsocket > Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Throughput problem with TWSocket over a "long line"
Hi Wilfried, > You find on my site a few programs to test performance with TWSocket. I have found the PerformanceTest project and tested it. In the first run it also gave the well-known value of ~1.2MB/s. Then I digged into TWSocket's Send() function and found the BufSize property. After changing the BufSize to 1MB (I have read the warning about setting it larger than SocketSndBufSize in the comments but wanted to try myself) I got rates of ~7.7MB/s - what an improvement! Looks like http://support.microsoft.com/default.aspx?scid=kb;en-us;823764 is wrong in my special case or the system is automagically increasing the socket's send buffer behind the scenes. When I read the socket send buffer size with getsockopt() while the transfer is running it remains at 8192 bytes, though. So shall I explicitly add a call setsockopt() that increases the socket send buffer dramatically (>1MB)? What is your opinion about that? /Tobias -- NOA Audio Solutions Vertriebsges.m.b.H.Tel: +43-1-5452700 Johannagasse 42/4 Fax: +43-1-545270014 A - 1050 Wien Www: http://www.noa-audio.com -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Throughput problem with TWSocket over a "long line"
Hello Tobias, You find on my site a few programs to test performance with TWSocket. --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz Monday, January 15, 2007, 16:33, Tobias Rapp wrote: >> To improve performance you can make your packets equal to the MTU, or >> switch Nagle off. There are some notes on Microsoft site about this. If >> you search for Nagle on MSDN you will find a lots information about >> that. They dont encourage to switch it off but in some cases (maybe >> yours) it is better. Note that you have to switch it of at both ends. > I tested it with Nagle=off but without singnificant changes. > Then I had the idea to capture the IP traffic that occurs when > delivering the file with the ICS/Indy FTP servers. There is one big > difference: > - When delivering the file with ICS FTP server the server sends 2 IP > packets (1448 + 600 bytes data) and then seems to wait for ACK. Note > that I did not switch Nagle off in that test. > - When delivering the file with Indy10 FTP server the server sends many > IP packets (up to 60 packets of 1448 bytes each) until the first ACKs > arrive. > Are there any socket options regarding that behaviour? >> The ICS demo programs are not specifically written to improve speed. >> They are written to give a as mutch as possible clear for newcomers. A >> PII300 CPU can easy saturate a 100 mbps network with TWSocket. > My data delivery application uses some specific XML protocol for talking > with the client which is implemented in a tWSocket-derived component. I > just wanted to make sure it is not something in my socket that slows > down data throughput significantly and thus made a test with the 'plain' > FTP server component as found in the ICS FTP demo server project. > /Tobias > -- > NOA Audio Solutions Vertriebsges.m.b.H.Tel: +43-1-5452700 > Johannagasse 42/4 Fax: +43-1-545270014 > A - 1050 Wien Www: http://www.noa-audio.com -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Throughput problem with TWSocket over a "long line"
> To improve performance you can make your packets equal to the MTU, or > switch Nagle off. There are some notes on Microsoft site about this. If > you search for Nagle on MSDN you will find a lots information about > that. They dont encourage to switch it off but in some cases (maybe > yours) it is better. Note that you have to switch it of at both ends. I tested it with Nagle=off but without singnificant changes. Then I had the idea to capture the IP traffic that occurs when delivering the file with the ICS/Indy FTP servers. There is one big difference: - When delivering the file with ICS FTP server the server sends 2 IP packets (1448 + 600 bytes data) and then seems to wait for ACK. Note that I did not switch Nagle off in that test. - When delivering the file with Indy10 FTP server the server sends many IP packets (up to 60 packets of 1448 bytes each) until the first ACKs arrive. Are there any socket options regarding that behaviour? > The ICS demo programs are not specifically written to improve speed. > They are written to give a as mutch as possible clear for newcomers. A > PII300 CPU can easy saturate a 100 mbps network with TWSocket. My data delivery application uses some specific XML protocol for talking with the client which is implemented in a tWSocket-derived component. I just wanted to make sure it is not something in my socket that slows down data throughput significantly and thus made a test with the 'plain' FTP server component as found in the ICS FTP demo server project. /Tobias -- NOA Audio Solutions Vertriebsges.m.b.H.Tel: +43-1-5452700 Johannagasse 42/4 Fax: +43-1-545270014 A - 1050 Wien Www: http://www.noa-audio.com -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Throughput problem with TWSocket over a "long line"
Hello Tobias, > TCP/IP connection with high round trip times and small packet sizes If packets are < max MCU then Nagle will come in and will wait a while to see if you want to send a packet again. Nagle does this to try to concat packets to a larger one to fit into the max packet size. Specially if you use a command / ack protocol and packets are very small this will slow down a lot. Typically 4..5 packets per second in that case. To improve performance you can make your packets equal to the MTU, or switch Nagle off. There are some notes on Microsoft site about this. If you search for Nagle on MSDN you will find a lots information about that. They dont encourage to switch it off but in some cases (maybe yours) it is better. Note that you have to switch it of at both ends. oh hes: it is the TcpNoDelay option you have to switch on in TWSocket. > ~ 1.18 MB/s when using my application > ~ 1.2 MB/s when using the ICS FTP demo server > ~ 6.5 MB/s when using the Indy10 FTP demo server The ICS demo programs are not specifically written to improve speed. They are written to give a as mutch as possible clear for newcomers. A PII300 CPU can easy saturate a 100 mbps network with TWSocket. --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Throughput problem with TWSocket over a "long line"
Hello Tobias, Do you see any CPU overload server side during transfert ? regards. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Throughput problem with TWSocket over a "long line"
Hello Dod, > Are you using ICS in sync or async mode ? I'm using ICS in async (event driven) mode in my application. The file is sent in fragments of 256KB in the OnDataSent event handler. > Do yo use same buffer and write-to-disk as Indy ? When comparing ICS and Indy I did not use my application but the standard FTP server examples that came with both component packages and thus I'm not sure what buffering technique is used inside the Indy FTP server component (it seems to be quite complex when looking at it's source). The FTP client used for comparing both applications was the standard MS commandline FTP client on Windows2003 (BTW: the serving application was also run on Windows2003 in all cases). > Do you use multi-threading or not ? I use multi-threading (each client has a separate thread) in my application but I know that the ICS FTP server does not use multi-threading. > Is it binary or text file (I guess it is text file as you said "long > line" in the subject ? It is a binary file of 128MB random data that I used for delivery. The "long line" in the subject is bad translation and should be corrected to "long cable", I think. Tobias -- NOA Audio Solutions Vertriebsges.m.b.H.Tel: +43-1-5452700 Johannagasse 42/4 Fax: +43-1-545270014 A - 1050 Wien Www: http://www.noa-audio.com -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Throughput problem with TWSocket over a "long line"
Hello Tobias, Are you using ICS in sync or async mode ? Do yo use same buffer and write-to-disk as Indy ? Do you use multi-threading or not ? Is it binary or text file (I guess it is text file as you said "long line" in the subject ? Regards. TR> I have a throughput/performance problem using the latest stable version TR> of the ICS package. When using a TWSocket derived application over an TR> TCP/IP connection with high round trip times and small packet sizes (it TR> is an 155 MBit ATM line) the throughput is very low. To check, if there TR> is a general problem in my application I also checked the throughput TR> with the FTP Server example and further with an FTP Server example from TR> the Indy10 component package. TR> The results for delivering a file over the line was: TR> ~ 1.18 MB/s when using my application TR> ~ 1.2 MB/s when using the ICS FTP demo server TR> ~ 6.5 MB/s when using the Indy10 FTP demo server TR> What can I do to improve the throughput in my application? Are there any TR> known tweaks? TR> I'd like to avoid changing to Indy because I like the clear and simple TR> structured sources of ICS. TR> Please share your thoughts, TR> Tobias TR> -- TR> NOA Audio Solutions Vertriebsges.m.b.H.Tel: +43-1-5452700 TR> Johannagasse 42/4 Fax: +43-1-545270014 TR> A - 1050 Wien Www: http://www.noa-audio.com -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] Throughput problem with TWSocket over a "long line"
Hi! I have a throughput/performance problem using the latest stable version of the ICS package. When using a TWSocket derived application over an TCP/IP connection with high round trip times and small packet sizes (it is an 155 MBit ATM line) the throughput is very low. To check, if there is a general problem in my application I also checked the throughput with the FTP Server example and further with an FTP Server example from the Indy10 component package. The results for delivering a file over the line was: ~ 1.18 MB/s when using my application ~ 1.2 MB/s when using the ICS FTP demo server ~ 6.5 MB/s when using the Indy10 FTP demo server What can I do to improve the throughput in my application? Are there any known tweaks? I'd like to avoid changing to Indy because I like the clear and simple structured sources of ICS. Please share your thoughts, Tobias -- NOA Audio Solutions Vertriebsges.m.b.H.Tel: +43-1-5452700 Johannagasse 42/4 Fax: +43-1-545270014 A - 1050 Wien Www: http://www.noa-audio.com -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
