![]() ![]() I'd hope that on any reasonable network, this should not make any difference, as both application push data to the socket as quick as possible, so the network layer should have no reason to delay packets. While PuTTY transfer tools do not (PuTTY itself does). This is likely because WinSCP disables Nagle's algorithm on the socket, That helps in certain cases to achieve a better throughput. Though WinSCP employs some optimizations on top of the PuTTY code, particularly larger internal and network buffers. So there should not be any difference in an encryption algorithm selected. I would be happy to test more, but don't know what to test, try and monitor. Pscp: window scaling status: disabled(-2) Winscp: window scaling status: unknown (-1) Other tests: ctcp (de)activated - no change It seems that this is somehow caused by PuTTY waiting for the ACK instead of just sending some more packets (what WinSCP does). WinSCP instead does ACKs for much older packets, thus generating more packets in flight and higher throughput, as it seems not to wait for an ACK until sending the next packets. After inspecting packets, the style is more like. Here pscp also has a lower speed than winscp! VPN SFTP pscp.exe 1 2 180 (4)=copy from office laptop to datacenter server. Here are some data: link protocol software source target max speed (kb/s) It turns out that using rsync (Unison) via SSH (plink.exe) or pscp.exe is 70% slower than copying with WinSCP (SCP or SFTP) in (1)->(2) direction.ĭownloading has the same speeds for both. I tested this over OpenVPN tunnel and via port forwarding to (2). At least in terminal.Īnd for the Marble Mouse Trackball there is a separate article with a lot of config details.Įnable middle mouse for all users by changing the default value in /usr/share/glib-2.0/schemas/.gschema.Uploading from my Windows PC (1) to my Ubuntu machine (2) in another city using PuTTY tools is slow. However, now I can use the unixish copy paste with mark and middle mouse button. Just install using CLI with sudo apt-get install gpointing-device-settings The very annoying malfunction of a missing 3rd mouse button (touch pad, Marble Mouse) can actually be fixed with the May be different for Lubuntu etc.) Section "InputClass" To fix the terminal issue I successfully put the following lines into my nf: However, here is a solution (partly resembling a wrap up of my predecessors): Unix style copy paste in the terminal not working. I had the same issues using Ubuntu 14.10 and earlier: Otherwise, in case you do not need/want to install wine, the first method is preferable. I prefer this second method, since the copy paste works always, do not need the middle button simulation and, the sherry in the top of the cake, it NEVER hangs (occasionally PuTTY for Windows hangs on some winXP installations). Since Wine handles com ports by having a link to the device (ie /dev/ttyUSB0), in the ~/.wine/dosdevices folder, this link would be created as follows, in order to update your wine profile configs: ln -s /dev/ttyUSB0 ~/.wine/dosdevices/com1 (I prefer this method since I do not need to change distro setting like Xorg, only Wine settings in order to connect to console serial ports): Identifier "middle button emulation class" This change has disabled emulation of the middle mouse button by clicking the left and right mouse buttons) I needed to enable it manually:Įnabling the middle mouse button emulation adding this to nf snippet: Section "InputClass" (The latest version of evdev, version 2.5, changed the default for the middle mouse button emulation code. Since using Linux Mint distro, I had not this middle button simulation activated. This is solved using either one of 2 methods:Ĭlicking in both Touchpad buttons I simulated the middle button. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |