🚀 go-pugleaf

Phil wrote:

> if (!ReadFile(hcomm, xbyte, 1, &ibytes, &overlapped))

You read one byte at a time. Why don't you read all bytes available in 
the queue?

> while ((!ibytes) &&
>             (clock() < (int)timeout) &&
>             ((ierr == ERROR_IO_PENDING) ||
>             (ierr == ERROR_IO_INCOMPLETE)))

You don't need to put this in a while loop and why don't you use
WaitForSingleObject() with the overlapped struct event to get your timeout?

I personnaly do something like this:

if(!ReadFile(hCom,buffer,numbyte,&BytesRead,&OvlRead))
{
    if(GetLastError() == ERROR_IO_PENDING)
    {
      if(WaitForSingleObject(OvlRead.hEvent,5000))
      {
         BytesRead = 0;
      }
      else
      {
         GetOverlappedResult(hCom,&OvlRead,&BytesRead,false);
         OvlRead.Offset += BytesRead;
      }
    }
    else BytesRead = 0;
}

HTH
Michel
-- 
----------------------------------------
Michel Leunen
mailto: see my homepage.
C++Builder, BCC5.5.1 Web site:
http://www.leunen.com/
----------------------------------------

Hi Phil,

> I'm have an application that communicates with an embedded controller
> via the serial port, either directly with a serial cable or via
> modem.
> 
> When I'm connected directly with a serial cable the communications
> work fine.  At a baudrate of 19200 I can send/receive 100 messages
> per sec.  But when I connect with a modem at 19200 the communications
> slow down significantly.  I'm only able to send/receive about 8
> messages per sec.  Of course I didn't expect to match the speed of a
> direct connection, but I'm off by more than a factor of 10.
> 
> I am using overlapped communications.  The delay seems to be in the 
> GetOverlappedResut( ) of my GetChar() routine.  I added some debug 
> statements,  and the GetOverlappedResult( ) functions takes about 150
> ms to return when I use a modem.  Can anyone advise me in how to
> speed this up.
> 

I think your problem is not the GetOverlappedResult function (but I
agree here with Michel's suggestions) but latency issues. It depends on 
how you're talking with your device. If you do it in the way "command to 
device - wait for answer from device - next command" then the overall 
latency is your problem, not the burst speed of the modem connection. 
The problem here is that you can't do very much in this case
if you don't want to change the way your device communication works. 
This problem is well known and in some protocols like TCP/IP it is 
resolved through some sophisticated algorithms like the sliding 
windows 	technique. You'll find a lot of documentation in the net about 
TCP/IP and maybe you can adapt some of the techniques used here in your 
communication protocol.

Bye,

-- 
Dipl. Ing. Oliver Rutsch
EMail: orutsch@sympatec.com
Sympatec GmbH

"Oliver Rutsch" <orutsch@sympatec.com> wrote in message 
news:4600f62f$1@newsgroups.borland.com...
> Hi Phil,

> I think your problem is not the GetOverlappedResult function (but I
> agree here with Michel's suggestions) but latency issues. It depends on 
> how you're talking with your device. If you do it in the way "command to 
> device - wait for answer from device - next command" then the overall 
> latency is your problem, not the burst speed of the modem connection.

assuming you can bash bits on your embedded controller,
one way to insure that your problem only exists with latency
is to have the controller simply immediately return whatever
it receives, essentially turning it into a loopback connection.
send out a character, measure the round trip time, done.

Michel,

Thank you for your reply.



You wrote:

> You read one byte at a time. Why don't you read all bytes available in the 
> queue?
I understand your point here, and I could change my code to read all of the 
bytes at once, but that is not what is causing the delay.  The delay is 
caused by the call to GetOverlappedResult().  If I do a read of 4 bytes, the 
function is called 4 times.  The first time through, I see the delay at the 
GetOverlappedResult call, but for the next 3 bytes, the ReadFile() is 
successful, so GetOverlappedResult does not get called, and the delay does 
not occur.



> if(!ReadFile(hCom,buffer,numbyte,&BytesRead,&OvlRead))
> {
>    if(GetLastError() == ERROR_IO_PENDING)
>    {
>      if(WaitForSingleObject(OvlRead.hEvent,5000))
>      {
>         BytesRead = 0;
>      }
>      else
>      {
>         GetOverlappedResult(hCom,&OvlRead,&BytesRead,false);
>         OvlRead.Offset += BytesRead;
>      }
>    }
>    else BytesRead = 0;
> }



I tried this approach as well.  Just like before, when I'm connected 
directly with a serial cable the communications are fast.  However, when I 
use my modem, I still see a delay of about 125ms.  However, this time it is 
in the WaitForSingleObject() function.



To me it looks like the delay occurrs when the modem signals to the 
operating system that a byte has arrived.  I'm just not sure if there is a 
way to speed it up.



Phil


"Michel Leunen" <nospam@noreply.be> wrote in message 
news:46004649$1@newsgroups.borland.com...
> Phil wrote:
>
>> if (!ReadFile(hcomm, xbyte, 1, &ibytes, &overlapped))
>
> You read one byte at a time. Why don't you read all bytes available in the 
> queue?
>
>> while ((!ibytes) &&
>>             (clock() < (int)timeout) &&
>>             ((ierr == ERROR_IO_PENDING) ||
>>             (ierr == ERROR_IO_INCOMPLETE)))
>
> You don't need to put this in a while loop and why don't you use
> WaitForSingleObject() with the overlapped struct event to get your 
> timeout?
>
> I personnaly do something like this:
>
> if(!ReadFile(hCom,buffer,numbyte,&BytesRead,&OvlRead))
> {
>    if(GetLastError() == ERROR_IO_PENDING)
>    {
>      if(WaitForSingleObject(OvlRead.hEvent,5000))
>      {
>         BytesRead = 0;
>      }
>      else
>      {
>         GetOverlappedResult(hCom,&OvlRead,&BytesRead,false);
>         OvlRead.Offset += BytesRead;
>      }
>    }
>    else BytesRead = 0;
> }
>
> HTH
> Michel
> -- 
> ----------------------------------------
> Michel Leunen
> mailto: see my homepage.
> C++Builder, BCC5.5.1 Web site:
> http://www.leunen.com/
> ---------------------------------------- 

Oliver,
> I think your problem is not the GetOverlappedResult function (but I
> agree here with Michel's suggestions) but latency issues. It depends on 
> how you're talking with your device. If you do it in the way "command to 
> device - wait for answer from device - next command" then the overall 
> latency is your problem, not the burst speed of the modem connection. The 
> problem here is that you can't do very much in this case
> if you don't want to change the way your device communication works. This 
> problem is well known and in some protocols like TCP/IP it is resolved 
> through some sophisticated algorithms like the sliding windows technique. 
> You'll find a lot of documentation in the net about TCP/IP and maybe you 
> can adapt some of the techniques used here in your communication protocol.

That is how my coummuncications work: send command to device, wait for 
respoonse, send next command...  When you refer to latency, are you 
referring to latency in the phone system, between the modems?

Phil

Stephan,
> assuming you can bash bits on your embedded controller,
> one way to insure that your problem only exists with latency
> is to have the controller simply immediately return whatever
> it receives, essentially turning it into a loopback connection.
> send out a character, measure the round trip time, done.
>
I can connect directly from my PC to the controller using a serial cable, 
and a command/response takes about 10ms at 19200.  Using a modem it takes 
about 125ms.  The code is the same in both cases, which points to an issue 
with my modem connection.  I just don't know if the issue is in the phone 
system or in my  modem setup.

Phil 

Just to follow up, Oliver and Stephan were right on with the latency issue. 
I found an article (nicely titled, "It's the Latency, Stupid"), describing 
modem latency issues.  It looks like I have a modem latency of about 115 ms. 
If anyone is interested, here's a link to the ariticle:
http://rescomp.stanford.edu/~cheshire/rants/Latency.html

Thanks for all your help,
phil 

"Phil" <phil@camusinc.com> wrote in message 
news:460132f4@newsgroups.borland.com...
> Stephan,
>> assuming you can bash bits on your embedded controller,
>> one way to insure that your problem only exists with latency
>> is to have the controller simply immediately return whatever
>> it receives, essentially turning it into a loopback connection.
>> send out a character, measure the round trip time, done.
>>
> I can connect directly from my PC to the controller using a serial cable, 
> and a command/response takes about 10ms at 19200.  Using a modem it takes 
> about 125ms.  The code is the same in both cases, which points to an issue 
> with my modem connection.  I just don't know if the issue is in the phone 
> system or in my  modem setup.

this is all stream of consciousness.... not to be read like a essay.


ok phil, you have the latency.
what I was suggesting before is useful for the next step.
with the embedded controller just back looping the data,
do a burst transmission, such as transmit OX or something 512 times,
and time how long it takes to accomplish this.

there are other factors that can slow down transmission, such as line noise
and line bandwidth. check the AT set, maybe the modems have a
signal quality report?

you could try kicking the baud down to 2400, check the round trip
command/response there

one thing that might be an issue is the embedded controller. you know
the controller uart talks to the pc uart well,
but how is it doing with the modem?

with all the components bolted together, you really need to isolate exactly
where in the chain things are breaking down.

consider, you had it ok when you went puter to embedded controller.
now, you have puter to modem. modem to modem.
modem to embedded controller.

maybe your modem on the embedded controller side can be configure to
loopback mode? that way, you can see the latency in the line itself.

Phil wrote:

>Just to follow up, Oliver and Stephan were right on with the latency issue. 

Ok, so you can try 2 things:

1) Increase your speed to the modem. Something above 56k (such as 96k)
should help some. (The modem can't start sending until the entire
first byte has arrived)

2) If your modem has such a command, turn off data compression, and/or
packets.

If you have 56k modems at both ends, running at 56k between them, the
data will spend less time on the wires. It should be able to step down
(buffer) to your device on the far end. But that data will still come
back to you slowly (19k) but should be less latency (less wire time).

It's a relay race, and it's bad enough that you have one slowpoke at
the far end.  Hobling any of the other team members is only going to
make it worse. Having the other 3 members be as fast as they can, can
only make up so much time.