#1
|
|||
|
|||
OSX Performance and ctrl-C lag...
Comparing ZOC6 and SecureCRT performance when connected the same way is vastly different.
ZOC6 is several times faster vs SecureCRT when displaying rolling output from lets say a large syslog file. The big thing is the difference it takes for ctrl-c to take effect on securecrt is in the order of 100's of seconds longer then ZOC6 (even after changing the send delay options to both 0, which is better then the default of 2). Just for reference. SSH from mac to host 1, host 1 to host 2, host 2 to host 3 BTW SecureCRT - 6.6.0(b247) ZOC6 - 6.24 |
#2
|
|||
|
|||
Hello adudek,
I have submitted your results to development for investigation. I will post any further information here. If you prefer direct e-mail notification, contact support@vandyke.com and include "Attn Brenda - Forum Thread #6149" in the subject.
__________________
Thanks, --Brenda VanDyke Software Technical Support support@vandyke.com (505) 332-5730 |
#3
|
|||
|
|||
Has there been any new development on this?
I have the newest version of securecrt 6.6.1-289 and have the same setup using both ZOC 6.26 and connecting to the same servers. The delay with sending and response to a ctrl-c is horrible. I've set the both line and character send to 0 ms even though this is not recommended due to missing characters on a paste. |
#4
|
|||
|
|||
Hello adudek,
Feature requests are prioritized based on a number of factors, including, but not limited to the number of requests, and the amount of implementation work required. We have received requests for this feature, but it has not yet become a top priority for implementation.
__________________
Thanks, --Brenda VanDyke Software Technical Support support@vandyke.com (505) 332-5730 |
#5
|
|||
|
|||
Hi adudek,
After thinking on this a bit, I think decreasing the character and/or line send delay might have the opposite effect than you desire. That means the information is going so fast, Ctrl-C can't interrupt quick enough to have any measurable effect. What are the results if you increase the character and/or line send delay values?
__________________
Thanks, --Brenda VanDyke Software Technical Support support@vandyke.com (505) 332-5730 |
#6
|
|||
|
|||
according to Bocks it seems like it is reverse of what you are saying.
from bocks on an way earlier post: http://forums.vandyke.com/showthread.php?t=811 "When you add a line or character send delay, you are effectively slowing down the transfer rate of the data. This allows the buffer to keep up with both the incoming and outbound data (by which I mean the rate at which and application pulls data from the buffer.) The line send delay is usefull if the system processes a line at a time, and only a small delay is needed. By using a character send delay, you can dramatically affect the overall transmission speed because the delay is used after each and every character is sent." Not seeing any real improvement. 0 ms -5 sec wait, 118 sec for result 1 ms - 5 sec wait, 99 sec for result 10 ms - 5 sec wait, 82 sec for result 50 ms - 5 sec wait, 124 sec for result 100 ms - 5 sec wait, 106 sec for result 250 ms - 5 sec wait, 89 sec for result If I remember correctly, setting the delay helps when pasting large amt of lines to sesssion. I had problems a while back when pasting a config to a router, some lines would be corrupted.. http://forums.vandyke.com/showthread.php?t=2929 Also, I'm not sure why incoming data will case an issue with an out going command. Your reference is correct. Also, the inbound and outbound performance of ZOC and Iterm is 2 orders of magnitude better... Unfortunately this has been an ongoing problem for awhile (at least since 5.0 beta). |
#7
|
|||
|
|||
Hi adudek,
You're right, sorry, I did think your complaint was slowness when using "Ctrl-C" to cancel a large paste. Now that I've re-read the entire thread I see you are talking about using "Ctrl-C" to interrupt received data.
__________________
Thanks, --Brenda VanDyke Software Technical Support support@vandyke.com (505) 332-5730 |
#8
|
|||
|
|||
Correct..
Aaron |
#9
|
|||
|
|||
Any update on this? This is almost a show stopper for me.
|
#10
|
|||
|
|||
Hello Aaron,
Sorry, there is no change in status at this time. As previously posted, feature requests are prioritized based on a number of factors, including, but not limited to the number of requests, and the amount of implementation work required. We have received requests for this feature, but it has not yet become a top priority for implementation. When there is a change in status, we will post in this thread.
__________________
Thanks, --Brenda VanDyke Software Technical Support support@vandyke.com (505) 332-5730 |
#11
|
|||
|
|||
This is not a priority?
This is a basic operation that needs to be supported. This is a DAY 0 Feature that needs to be there. If you cannot send a ctrl C sequence when you are getting input what is the point of the software? |
#12
|
|||
|
|||
Hello Aaron,
Please contact us at support@vandyke.com, so I can make the latest build available to you. If e-mailing from an account other than the one used to create your download account, please let me know the e-mail address on the download account. Please include "Attn Brenda - Forum Thread #6149" in the subject line.
__________________
Thanks, --Brenda VanDyke Software Technical Support support@vandyke.com (505) 332-5730 |
![]() |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Display Modes | |
|
|