RE: [Vacm-general] Slow EMP handling

[San M. <net...@va...>]

Ard,

Basically an EMP request frame looks like this:

0xa0  <-- frame start
0x20  <-- EMP slave address
0xxx  <-- LUN and NetFn
0xxx  <-- checksum
0x64  <-- EMP application slave address
0xxx  <-- sequence number (goes up by 4)
0xxx  <-- Command
0xx1  <-- Command arg byte 1
0xx2  <-- Command arg byte 2
0xxn  <-- Command arg byte n
0xxx  <-- checksum
0xa5  <-- Frame end

Now after sending each byte you have to wait for an ack (0xa8) from the
hardware.. When the hardware ack's a byte, the *next* byte MUST arrive
Within 2ms, otherwise the hardware thinks there has been a
communications error and *SILENTLY* discards the entire frame. This is
one of the large problems with resynchronization... if we send a few
bytes of the command within the proper 2ms window, then for one reason
or another we send one byte *after* the window, then the remote firmware
will silently toss the frame. We of course don't know this has happened
so as per the EMP spec, when the byte we last sent does not receive an
ack, we resend it and it is acked.. this continues until we send the
frame end character at which point the remote hardware sends us an error
saying the command we sent is invalid because the frame it received was
truncated due to the fact that it tossed the first few bytes due to a
timeout.

  Now... take that behavior, and add the fact that every 2 seconds of
realtime, no matter what is going on the port, the hardware will send a
PING frame (EMP_ACTIVE), and things get even more messy... You can have
a look at emp_driver.c to see just how messy things can get...

Basically, H/W S/W flow control would of made this whole thing a lot
nicer.. but what can you do... sigh..

As for the resynchronizing stuff, if you have the right debugging
compiled in you may see a msg like this:

Driver %s calling detect_protocol because resync required

or something... ;)

For more information on this in terms of debugging, make sure that
TRANS_DEBUG is defined in emp_driver.c (transport debug), and run it...
you might want to log it or something as this will generate a lot of
data when running on multiple nodes

-san


-----Original Message-----
From: 'Ard van Breemen' [mailto:ar...@te...] 
Sent: Wednesday, July 25, 2001 6:21 AM
To: San Mehat
Cc: vac...@li...
Subject: Re: [Vacm-general] Slow EMP handling

On Tue, Jul 24, 2001 at 11:26:11AM -0700, San Mehat wrote:
> As I suspected, it looks like you're having a serial protocol issue..
> The reason that only the cisco boxes are qualified as a *network*
based
> connectivity method for EMP are that they have below 1 ms round trip
> latency on single byte transactions on their raw ports... The EMP
> protocol requires a MAXIMUM latency of 2ms per byte.. otherwise it
will
> timeout the byte (and sometimes the fame). It is VERY difficult to
But how is the byte acked? What happens with modems? If I hook up a
modem, the round trip will probably exceed that 2 ms due to compression
and other stuff. We are after all talking about almost 4 byte-times.
> recover a frame when this occurs, so we end up having to do nasty
> re-synchronizing which doesn't always work...
But if it needs to re-synchronize, it would tell me, right?
It does not say anything about sync...
(Hmmm, see the debugging commented out, recompiling...)
> I would advise going to a rocketport connectivity solution since its
> much cheaper than the cisco method...
Well, another good solution would be a real power-boot :).

-- 
<ar...@te...> Telegraaf Elektronische Media  http://wwwijzer.nl
http://leerquoten.monster.org/ http://www.faqs.org/rfcs/rfc1855.html 
Let your government know you value your freedom. Sign the petition:
http://petition.eurolinux.org/