W32 to AIX performance

W32 to AIX performance

[Michael Mauger]

I'm currently using GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2006-05-02 
on XP.  

I use an up-to-date cygwin ssh to connect to both Solaris and AIX machines 
without problems using RSA keys.  Under the DOS console and cygwin's RXVT it 
works as expected.

Starting an `M-x shell' and then invoking ssh within the comint buffer to a 
Solaris machine works great.  Tramp using the sshx method to the Solaris box 
works as well.

Doing the same with the AIX box however is problematic.  Under comint, the 
response is so slow that it is unusable.  For example, more than a minute to 
`ls' an empty directory and get the next prompt.  The output does not come 
slowly, but rather all appears at the end of a long wait.  Tramp using sshx is 
unusable because it times out.  In fact, under Emacs, any interaction with the 
AIX box exhibits this behavior.  

I would assume that I had done something wrong, except that the same config 
interacts with Solaris seamlessly.  Google and the list archives yielded 
little.  Has anyone else experienced this?  Are there settings on either the 
AIX or W32 side that I can change to impact this?  I'm willing to debug this 
some but need some hints as to what to do and look for.  

This is becoming important to me since much of my development for the next six 
months will be on AIX rather than Solaris and vi aint cuttin' it!  

TIA

Re: W32 to AIX performance

[Kim F. Storm]

Michael Mauger <mmaug@yahoo.com> writes:

> I'm currently using GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2006-05-02 
> on XP.  
>
> I use an up-to-date cygwin ssh to connect to both Solaris and AIX machines 
> without problems using RSA keys.  Under the DOS console and cygwin's RXVT it 
> works as expected.
>
> Starting an `M-x shell' and then invoking ssh within the comint buffer to a 
> Solaris machine works great.  Tramp using the sshx method to the Solaris box 
> works as well.
>
> Doing the same with the AIX box however is problematic.  Under comint, the 
> response is so slow that it is unusable.  For example, more than a minute to 
> `ls' an empty directory and get the next prompt.  The output does not come 
> slowly, but rather all appears at the end of a long wait.  

Does setting process-adaptive-read-buffering to nil help?

>                                                            Tramp using sshx is 
> unusable because it times out.  In fact, under Emacs, any interaction with the 
> AIX box exhibits this behavior.  

Is Emacs non-responsive when this happens, or using a lot of CPU?

Can you use a debugger to see what emacs is doing when it is waiting for
output from the AIX box?

You may have to interrupt the execution several times and make a backtrace
to see if there is a specific point where emacs is stuck.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: W32 to AIX performance

[Michael Mauger]

--- "Kim F. Storm" wrote:

> Michael Mauger writes:
> 
> > I'm currently using GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2006-05-02 
> > on XP.  
> >
> > I use an up-to-date cygwin ssh to connect to both Solaris and AIX machines 
> > without problems using RSA keys.  Under the DOS console and cygwin's RXVT it 
> > works as expected.
> >
> > Starting an `M-x shell' and then invoking ssh within the comint buffer to a 
> > Solaris machine works great.  Tramp using the sshx method to the Solaris box 
> > works as well.
> >
> > Doing the same with the AIX box however is problematic.  Under comint, the 
> > response is so slow that it is unusable.  For example, more than a minute to 
> > `ls' an empty directory and get the next prompt.  The output does not come 
> > slowly, but rather all appears at the end of a long wait.  
> 
> Does setting process-adaptive-read-buffering to nil help?
> 

Nope.  Same behavior

> >                                                            Tramp using sshx is 
> > unusable because it times out.  In fact, under Emacs, any interaction with the 
> > AIX box exhibits this behavior.  
> 
> Is Emacs non-responsive when this happens, or using a lot of CPU?
> 

No, Emacs is still responsive; cursor is blinking, no CPU usage.

> Can you use a debugger to see what emacs is doing when it is waiting for
> output from the AIX box?
> 
> You may have to interrupt the execution several times and make a backtrace
> to see if there is a specific point where emacs is stuck.
> 

I'm building a debug version now.  I'll report my findings once I can test.

Re: W32 to AIX performance

[Michael Mauger]

Michael Mauger <mmaug <at> yahoo.com> writes:

> 
> --- "Kim F. Storm" wrote:
> 
> > Michael Mauger writes:
> > 
> > > I'm currently using GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2006-
05-02 
> > > on XP.  
> > >
> > > I use an up-to-date cygwin ssh to connect to both Solaris and AIX 
machines 
> > > without problems using RSA keys.  Under the DOS console and cygwin's RXVT 
it 
> > > works as expected.
> > >
> > > Starting an `M-x shell' and then invoking ssh within the comint buffer to 
a 
> > > Solaris machine works great.  Tramp using the sshx method to the Solaris 
box 
> > > works as well.
> > >
> > > Doing the same with the AIX box however is problematic.  Under comint, 
the 
> > > response is so slow that it is unusable.  For example, more than a minute 
to 
> > > `ls' an empty directory and get the next prompt.  The output does not 
come 
> > > slowly, but rather all appears at the end of a long wait.  
> > 
> > Does setting process-adaptive-read-buffering to nil help?
> > 
> 
> Nope.  Same behavior
> 
> > >                                                            Tramp using 
sshx is 
> > > unusable because it times out.  In fact, under Emacs, any interaction 
with the 
> > > AIX box exhibits this behavior.  
> > 
> > Is Emacs non-responsive when this happens, or using a lot of CPU?
> > 
> 
> No, Emacs is still responsive; cursor is blinking, no CPU usage.
> 
> > Can you use a debugger to see what emacs is doing when it is waiting for
> > output from the AIX box?
> > 
> > You may have to interrupt the execution several times and make a backtrace
> > to see if there is a specific point where emacs is stuck.
> > 
> 
> I'm building a debug version now.  I'll report my findings once I can test.
> 

Well, I'm not seeing much of note.  I've got a debug version of Emacs running 
under GDB.  I set a breakpoint on Fsignal and am using C-g to get control in 
GDB (if I should be doing this in another way, please let me know...)

In Shell mode waiting for a DOS command to complete:

Breakpoint 3, Fsignal (error_symbol=23757473, data=23693313) at eval.c:1606
1606      register struct handler *allhandlers = handlerlist;
(gdb) bt
#0  Fsignal (error_symbol=23757473, data=23693313) at eval.c:1606
#1  0x01025552 in Ffuncall (nargs=3, args=0x82f7c0) at eval.c:2907
#2  0x0115a9b4 in Fbyte_code (bytestr=19151275, vector=19151332, maxdepth=24)
    at bytecode.c:694
#3  0x01025ca7 in funcall_lambda (fun=19151244, nargs=0, arg_vector=0x82f9d4)
    at eval.c:3091
#4  0x010256e6 in Ffuncall (nargs=1, args=0x82f9d0) at eval.c:2950
#5  0x01024ffd in apply1 (fn=24203081, arg=23693313) at eval.c:2649
#6  0x01157f90 in Fcall_interactively (function=24203081, 
    record_flag=23693313, keys=23752708) at callint.c:412
#7  0x010151dd in Fcommand_execute (cmd=24203081, record_flag=23693313, 
    keys=23693313, special=23693313) at keyboard.c:9759
#8  0x01008c1e in command_loop_1 () at keyboard.c:1791
#9  0x010230fc in internal_condition_case (bfun=0x10078b4 <command_loop_1>, 
    handlers=23757449, hfun=0x1007330 <cmd_error>) at eval.c:1476
#10 0x0100763a in command_loop_2 () at keyboard.c:1328
#11 0x01022b56 in internal_catch (tag=23751705, 
    func=0x100761b <command_loop_2>, arg=23693313) at eval.c:1214
#12 0x010075ed in command_loop () at keyboard.c:1307
#13 0x01007101 in recursive_edit_1 () at keyboard.c:1000
#14 0x01007237 in Frecursive_edit () at keyboard.c:1061
#15 0x01003a8b in main (argc=2, argv=0xf441e8) at emacs.c:1794

---Type <return> to continue, or q <return> to quit---
Lisp Backtrace:
"signal" (0x16a82a1)
"keyboard-quit" (0x1698801)
"call-interactively" (0x1714f49)
(gdb)

I then connect to the remote machine using CYGWIN's ssh and do a "ls".  While 
waiting for the results to appear, I C-g and get a backtrace.  I continue and 
still have to wait for the remote output.

Breakpoint 3, Fsignal (error_symbol=23757473, data=23693313) at eval.c:1606
1606      register struct handler *allhandlers = handlerlist;
(gdb) bt
#0  Fsignal (error_symbol=23757473, data=23693313) at eval.c:1606
#1  0x01025552 in Ffuncall (nargs=3, args=0x82f7c0) at eval.c:2907
#2  0x0115a9b4 in Fbyte_code (bytestr=19151275, vector=19151332, maxdepth=24)
    at bytecode.c:694
#3  0x01025ca7 in funcall_lambda (fun=19151244, nargs=0, arg_vector=0x82f9d4)
    at eval.c:3091
#4  0x010256e6 in Ffuncall (nargs=1, args=0x82f9d0) at eval.c:2950
#5  0x01024ffd in apply1 (fn=24203081, arg=23693313) at eval.c:2649
#6  0x01157f90 in Fcall_interactively (function=24203081, 
    record_flag=23693313, keys=23752708) at callint.c:412
#7  0x010151dd in Fcommand_execute (cmd=24203081, record_flag=23693313, 
    keys=23693313, special=23693313) at keyboard.c:9759
#8  0x01008c1e in command_loop_1 () at keyboard.c:1791
#9  0x010230fc in internal_condition_case (bfun=0x10078b4 <command_loop_1>, 
    handlers=23757449, hfun=0x1007330 <cmd_error>) at eval.c:1476
#10 0x0100763a in command_loop_2 () at keyboard.c:1328
#11 0x01022b56 in internal_catch (tag=23751705, 
    func=0x100761b <command_loop_2>, arg=23693313) at eval.c:1214
#12 0x010075ed in command_loop () at keyboard.c:1307
#13 0x01007101 in recursive_edit_1 () at keyboard.c:1000
#14 0x01007237 in Frecursive_edit () at keyboard.c:1061
#15 0x01003a8b in main (argc=2, argv=0xf441e8) at emacs.c:1794

---Type <return> to continue, or q <return> to quit---
Lisp Backtrace:
"signal" (0x16a82a1)
"keyboard-quit" (0x1698801)
"call-interactively" (0x1714f49)
(gdb) c
Continuing.

Does this help?  Any ideas?  Anything else I should be doing?

Thanks.

Re: W32 to AIX performance

[Kim F. Storm]

Michael Mauger <mmaug@yahoo.com> writes:

> Well, I'm not seeing much of note.  I've got a debug version of Emacs running 
> under GDB.  I set a breakpoint on Fsignal and am using C-g to get control in 
> GDB (if I should be doing this in another way, please let me know...)

That is not the way to get control back to GDB.

You should "stop" the execution, typically by hitting C-z in gdb.

or you could run gdb inside Emacs:

- open a file in src, e.g. src/process.c

- M-x gdb

- it will typically suggest to debug emacs

- r 

- use the <STOP> icon in the tool-bar to stop the inferior emacs.

- use <GO> to continue.