Miguel,
Did you read my message?
1. The changes I suggested do NOT take away anything from what you
just tried to explained, yet again. We understand that FTP will work
faster with 64kb, and we have no problem if you set it to 64kb (in
the FTP code).
2. We understand and agree that 1400 wa
I test actual cvs and it runs very high.
Why other developers, don't want to test it with 64k buffer ?
I'm working in other way.
I was creating method at client class to access buffers, and then
each protocol, can uses his own needed. How I explain in previous mails.
for example FTP uses 64k by
Ron,
just to clarify, old 1400 bytes was not a buffer size, rather a chunk size
telling how many bytes read/write from/to a socket in a single operation, as
you can see, old code has loops which read/write until a timeout and/or
requested size is matched or exceeded.
Best regards.
Maurilio.
Ron
Maurilio, Miguel,
<<<
> 1. Indeed we should not ASSUME any size, we should either:
>
> - Find if there's a way to QUERY, what's the O/S buffer size.
>
yes, there is, it is getsockopt(), which can tell you how big are OS
default
buffers.
>>>
Miguel, please correct core implementation to u
On Tue, 1 Apr 2008, Maurilio Longo wrote:
> undefined in all of my headers.
I'm sorry. You're right. I thought I had seen on GCC, but I was wrong.
Atte.
Vic
-
Check out the new SourceForge.net Marketplace.
It's the be
Ron,
Ron Pinkas wrote:
> Miguel, Maurilio,
>
> I see you guys going in circles. :-)
>
yes :)
> 1. Indeed we should not ASSUME any size, we should either:
>
> - Find if there's a way to QUERY, what's the O/S buffer size.
>
yes, there is, it is getsockopt(), which can tell you how big are
Miguel, Maurilio,
I see you guys going in circles. :-)
I believe I can summarize the input from both of you to this:
1. Miguel: It's unsafe to ASSUME that default buffer is 1.4kb or
higher - if it's smaller a GPF trap exists.
2. Miguel: Performance could be optimized if we are ALLOWED bigger
What buffer uses your system by default ?
The actual code only increases the buffer if is lower than 64Kb
If in your case it is higher it not will be modified.
Can you test actual CVS please, and say me if now is more or less quick ?
Best regards,
Miguel Angel Marchuet
Maurilio Longo escribió:
Miguel Angel Marchuet wrote:
> The buffer was never 1.4 Kb. Just read the buffer 8Kb of 1.4 in 1.4 Kb.
This is just what I'm saying since the beginning, we were using OS provided
buffer reading/writing it in 1.4Kb chunks.
> This was a very serious mistake, because the system has never guaranteed
Alexander,
for sure!
Best regards.
Maurilio.
Alexander S.Kresin wrote:
> Miguel,
>
>> Is needed to establish a buffer size more bigger than you can read to have
>> enough
>> time to read all meanwhile data transfers. If the buffer had the same size
>> as we read
>> then we always lost data,
Maurilio before operated by chance, because the buffer actual default system is
8Kb windows, and just luckily it worked in most
cases.
Has tested performance with the new configuration ?
In my test is much much much faster now.
Please test it before change the code.
The buffer was ne
> don't hardcode 64Kb buffers inside inet.c, don't set any kind of buffer there,
> simply use what the OS has as default buffer and do 1.4Kb reads/writes as it
> was before (BTW, previous code worked for everyone for several years, so it
> cannot be so bad).
>
> Then, inside ftp code, or your own
Miguel,
> Is needed to establish a buffer size more bigger than you can read to have
> enough
> time to read all meanwhile data transfers. If the buffer had the same size as
> we read
> then we always lost data, because in the time between readings, the buffer is
> filling
> without being able
Miguel Angel Marchuet wrote:
> FTP needs to establish 64 buffer size for use readings of 32 for not
> lost data entries.
>
_You_ think that ftp needs 64Kb, instead this number could be not enough on a
gigaethernet or a 10gigaethernet, so, why don't you try to set a 1Mb buffer? a
10Mb buffer? What
Miguel,
I'm sorry I cannot make my english better than this, so I try one more time
before giving up with this issue:
don't hardcode 64Kb buffers inside inet.c, don't set any kind of buffer there,
simply use what the OS has as default buffer and do 1.4Kb reads/writes as it
was before (BTW, previo
>
> My point is:
>
> before: we were using OS provided buffers (which you can retrieve with
> getsockopt()) and read/write to/from it at 1.4Kb max per operation; we did not
> care to set socket buffers since OS uses a default size (maybe you have 8Kb
> default, mine could be bigger or smaller) wh
Miguel,
here what I get:
(E:\repos2\xharbour\source\vm)if not exist os2\gcc_mt\. md os2\gcc_mt
make[3]: Entering directory `/repos2/xharbour/source/vm/os2/gcc'
gcc -I. -I../../include -I../../../../include -DHB_OS_OS2 -Wall -fsigned-char -O
../../inet.c: In function `s_inetRecvInternal':
../../in
Miguel,
yes, I follow what you're saying.
My point is:
before: we were using OS provided buffers (which you can retrieve with
getsockopt()) and read/write to/from it at 1.4Kb max per operation; we did not
care to set socket buffers since OS uses a default size (maybe you have 8Kb
default, mine c
Please try with CVS now
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketp
Miguel Angel Marchuet wrote:
> I put 64k because is the best default option for FTP transfers, is the
> same value
> that is used at FileZilla for example.
>
> You can change dynamically now this value using
>
> InetSetSndBufSize( pSocket, nSizeSendBuffer )
> InetSetRcvBufSize( pSocket, n
Vicente,
undefined in all of my headers.
Maurilio.
Vicente Guerra wrote:
> On Tue, 1 Apr 2008, Miguel Angel Marchuet wrote:
>> Can you verify were is in gcc this declaration
>> #define SOCKET_ERROR(-1)
>> I don't use gcc compiler, is possible gcc is buggy or needs some include.
>> if
before this modification,
the default real buffer was 8kb
but wrongly Inet only uses hard coded 1,4kb
and client.prg only was using 1kb of 8kb
Please, can you test now speed ?
Is possible that other protocols don't need
32kb at transfers, but it don't reduce speed.
Now we only use 32kb of 64
Vicente Guerra escribió:
> On Tue, 1 Apr 2008, Miguel Angel Marchuet wrote:
>> Can you verify were is in gcc this declaration
>> #define SOCKET_ERROR(-1)
>> I don't use gcc compiler, is possible gcc is buggy or needs some include.
>> if it doesn't exists at gcc then, please add this def
On Tue, 1 Apr 2008, Miguel Angel Marchuet wrote:
> Can you verify were is in gcc this declaration
> #define SOCKET_ERROR(-1)
> I don't use gcc compiler, is possible gcc is buggy or needs some include.
> if it doesn't exists at gcc then, please add this define only under gcc
> compiler
I put 64k because is the best default option for FTP transfers, is the same
value
that is used at FileZilla for example.
You can change dynamically now this value using
InetSetSndBufSize( pSocket, nSizeSendBuffer )
InetSetRcvBufSize( pSocket, nSizeReciveBuffer )
Remember that be
Can you verify were is in gcc this declaration
#define SOCKET_ERROR(-1)
I don't use gcc compiler, is possible gcc is buggy or needs some include.
if it doesn't exists at gcc then, please add this define only under gcc compiler
#define SOCKET_ERROR(-1)
Best regards,
Migu
OS/2 GCC after this change:
gcc -I. -I../../include -I../../../../include -DHB_OS_OS2 -Wall -fsigned-char
-O2 -DTCPV40HDRS -DSIMPLEX -c ../../inet.c -oinet.o
../../inet.c: In function `hb_socketConnect':
../../inet.c:355: error: `SOCKET_ERROR' undeclared (first use in this function)
../../inet.c:3
Miguel,
I think it would be more 'correct' not to force 64K buffers, but simply give
the possibility to change the default value (which the OS sets).
Do you agree?
Maurilio.
PS. If there was a hard-coded limit before, well, it was 'wrong' as well.
Miguel Angel Marchuet wrote:
> 2008-04-01 12:4
28 matches
Mail list logo
