RE: [Vacm-general] Slow EMP handling

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

The download log code erases the log as it downloads it.. the log in the
hardware is meant to be a mailbox and not general storage.. so everytime
an entry is downloaded it is deleted, so once the log download is
complete, the log should be empty until something puts an entry in it :)
-san


-----Original Message-----
From: vac...@li...
[mailto:vac...@li...] On Behalf Of 'Ard van
Breemen'
Sent: Wednesday, July 25, 2001 8:09 AM
To: vac...@li...
Subject: Re: [Vacm-general] Slow EMP handling

On Wed, Jul 25, 2001 at 04:28:45PM +0200, 'Ard van Breemen' wrote:
> On Wed, Jul 25, 2001 at 03:21:29PM +0200, 'Ard van Breemen' wrote:
> > 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.
> Allright...
> Debugging using tcpdump and ethereal.
> My system send a byte to the portmaster.
> 1.37 ms later the portmaster acks.
> 53 ms later the portmasters sends a packet containing data.
> Usually 1 byte as a reaction from my system. But sometimes up to 29
bytes.
> But always 53 ms...
> As if something was nagging... Or at least some timer seems to be
involved...
It get's worse:
Enabled all emp debugging (like DEBUG_TRANS),
the download still takes long, but other actions are currently fast.
Refresh of the node will fail the first time. As if it tries to
reconnect
with a connection still open.  The second time it works (maybe the
connection is closed due to the failure of opening it :) ).

Anyway:
ard@c24574:/net/home/ard$ time vash -c localhost -u blum -p frub -x 'ipc
localhost emp:chassis_status:rs0'
EMP:124:JOB_STARTED
EMP:124:CSTATUS:YES:NO:NO:NO:NO:YES:NO:NO:NO:NO:NO:YES:NO:NO:NO
EMP:124:JOB_COMPLETED

real    0m0.818s
user    0m0.000s
sys     0m0.000s
ard@c24574:/net/home/ard$ time vash -c localhost -u blum -p frub -x 'ipc
localhost emp:chassis_status:rs0'
EMP:127:JOB_STARTED
EMP:127:CSTATUS:YES:NO:NO:NO:NO:YES:NO:NO:NO:NO:NO:YES:NO:NO:NO
EMP:127:JOB_COMPLETED

real    0m0.528s
user    0m0.000s
sys     0m0.000s

The .5 s is median. It either takes .5 s or .8 s.

The download_log takes about the same time, but that is probably cached?
-- 
<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/

_______________________________________________
Vacm-general mailing list
Vac...@li...
http://lists.sourceforge.net/lists/listinfo/vacm-general