slowdown tcp transfer under Windows 10 64bits

[Alain1533 2]

Alright, I'll prepare the code and do the test tomorrow morning

Merci

 

[Guest]

8 minutes ago, Alain1533 said:

Alright, I'll prepare the code and do the test tomorrow morning

Just few things, in that particular packet code handling might be a difference in execution time that might lead to this, what do come to mind here scenarios like these

1) Are you using Sleep(1) ! because sleep 1 is in fact most the time is sleep(15) or sleep(16) , and having the IDE opened on the device will make it Sleep(1), why because if the code processing is taking 2ms then it will make sense of these 13ms

2) What is the fate of the data of that packet, been zipped ?, i remember a bug with the IDE been shipped with unoptimized zip binary for only 64bit, or are you sending the data to DB, also here might be difference in the DB engine for 64bit vs 32bit... etc , in other words are you using 3rd-party library here ?

 

Just food for thoughts.

[Alain1533 2]

No I don't use sleep

The data is binary data, on the PC side it comes from a memory Mapper file. in fact, it is a Byte buffer.

No, i don't use 3rd-party library, only overbyte

 

On the other hand, it is a real time timer which tests every 2 ms if the PLC has finished sending its DBs, if so, it will send its data again, and so on, I will make you a zip of the drivers

 

 

[FPiette 384]

Warning: to much logging or display will drastically slow down network I/O.

It is better to log in memory (TMemoryStream) during the execution and save to a file if needed at the end of program.

 

[Angus Robertson 574]

I've just written a new TIcsInetAlive component, will be in SVN shortly, it measures the round time for ping and HTTP requests, and these are my results from Windows 10 over FTTC to a London data centre where Microsofts hosts this domain. 

 

08:31:24  Check Alive Ping to www.msftconnecttest.com (13.107.4.52) took 5 msecs
08:31:24  Check Alive to http://www.msftconnecttest.com/connecttest.txt (13.107.4.52) took 16 msecs
08:31:49  Check Alive Ping to ipv6.msftconnecttest.com ([2a01:111:2003::52]) took 5 msecs
08:31:49  Check Alive to http://ipv6.msftconnecttest.com/connecttest.txt ([2a01:111:2003::52]) took 15 msecs

 

Note HTTP is the complete lookup DNS, connect, get a page, close cycle, not just send and receive a packet. I'm only timing with ticks, not performance counter, but I believe ticks are reasonably accurate in modern versions of Windows.

 

Angus

 

[Alain1533 2]

Bonjour,

Sorry, but I'm very busy today.

I found where the time to wait came from, I use a Timer component in order
to cycle the requests, 1 Emission / Reception every 2 ms at the miximum,

otherwise the PLc is out of order.

 

This timer uses "Synchronize" to call a "Callback" which signals the timer,
and that's what was taking time.

 

What is strange is that it does not pose a problem with a Windows 10 32bits.
I specify that this is not the standard component of the VCL but one of our components.

So, now I use a Thread which controls the start of the Send / Receive cycle
and which at the end of the loop waits a fixed time of 2ms before resuming
another Send / Receive cycle.

 

This time is adjustable, it uses "TStopwatch" to measure the time.

On my simulator it works perfectly, on a machine with Windows 32bits or Windows 64 bits,
we will do the tests with the real PLC.

 

So the problem was not with the ICS components, which gives us complete satisfaction on all our machines.

We'll see tomorrow

thank you very much for your help

 

Alain

 

Edited January 26, 2021 by Alain1533