Greetings, I'm a true believer in samba and attempt to induct most people in my workgroup into using it to map/mount drives to get thier work done. There are two factions in the work group: those like me who prefer samba and a direct mount, and those who prefer an X windows session to run emacs or the SUN common desktop environment (also an X derivative). We all use some variation of Windows (95/NT3.5/NT4.0) to access our UNIX box. However, it seems lately (especially in the afternoons) the performance via the samba mount is very slow; I type a key in the editor and it takes about 2 seconds for it to come back. I do not see this degradation when connecting to the same machine through an xterm window or using the vi editor, i.e., the slowness comes via the mounting I believe. Is there a way to tell why there is such a vast difference in performance and/or to tune samba or the UNIX machine (it is a SUN SPARC). Would NFS cause this slowness as well? Unfortunately our NIS department does not support samba; we (in development) have to do it ourselves. Thanks very much Robin J. Cox MCI Colorado Springs, CO
A non-text attachment was scrubbed... Name: not available Type: text Size: 1285 bytes Desc: not available Url : http://lists.samba.org/archive/samba/attachments/19971023/3d52ddec/attachment.bat
On Thu, 23 Oct 1997, Robin J. Cox wrote:> However, it seems lately (especially in the afternoons) the > performance via the samba mount is very slow; I type a key in > the editor and it takes about 2 seconds for it to come back. > > I do not see this degradation when connecting to the same > machine through an xterm window or using the vi editor, i.e., > the slowness comes via the mounting I believe.Samba is a file serving system - it allows you to access file and printers which are located on another computer. In your case, this means the application software is running on your Windows PC's CPU and RAM, but the files are on the Samba server. When you press a key, it is received and handled by the application program running on your Windows machine. Samba has nothing to do with it. The X Windows System, as well as telnet, are remote user interface systems. The application software runs in the CPU and RAM of the remote machine, and only the user interface runs on your Windows PC. When you press a key, it is transmitted over the network to the x client program running on the server, which then sends the display updates over the network to your PC. If you are finding that using X is faster than using Samba, it is because the Sun server is able to process your session faster than your Windows PC is, despite the fact that the network sits in your path twice. The fact that you are even comparing software running in Windows and software running in SunOS/Solaris seems to suggest that you are using different software than the group of users using X. Does this make for a fair comparison in this context? Are the other users perhaps using some kind of Windows emulation such as WABI to run the same application as you do, but running on the Sun and displayed using X? Sound like your PCs need to be upgraded (or the Sun downgraded, depending on how you look at it) Regards ---------------------------------------------------------------|-----|-- Louis Mandelstam Tel +27 83 229-0712 Symphony /|\ /|\ Linux systems integration http://sr.co.za Research { } { } Johannesburg, South Africa mailto:louis@sr.co.za (Pty)Ltd {___} {___}
On Thu, 23 Oct 1997, Louis Mandelstam wrote:> On Thu, 23 Oct 1997, Robin J. Cox wrote: > > > However, it seems lately (especially in the afternoons) the > > performance via the samba mount is very slow; I type a key in > > the editor and it takes about 2 seconds for it to come back.the delay between pressing a key and the time taken for it to sent back over a network has nothing to do with the fact that the key has been pressed, is stored in a key buffer, will be received at the other end, and will be processed. the results of those key presses may take some time to become apparent... [i watch vt320 terminal users here keeping their finger down on the "up" key for a few seconds, when using pine. this causes them some embarrassment when the vt320 issues, several seconds late, a continuous stream of loud beeps. the best one is when they press ctrl-S instead of ctrl-X, and then keep pressing keys...] luke