search for: nagle

On Sun, Feb 24, 2002 at 09:04:03AM +0100, Ricardo Galli wrote: > Sorry, didn't explain well. > > Nagle's algorithm (rfc896) buffers user data until there is no pending acks > or it can send a full segment (rfc1122). > > icecast doesn't need it at all, because it already sends large buffers and > the time to send the next buffers is relatively very long. IMO we should be usin...

...ion (int listen_sock) pthread_t thread; struct thread_data *thread_data; static size_t instance_num = 1; + const int flag = 1; thread_data = malloc (sizeof *thread_data); if (!thread_data) { @@ -293,6 +296,11 @@ accept_connection (int listen_sock) return; } + /* Disable Nagle's algorithm on this socket. However we don't want + * to fail if this doesn't work. + */ + setsockopt (thread_data->sock, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof flag); + /* Start a thread to handle this connection. Note we always do this * even for non-threaded plu...

Hi, I was reading that 2.1 introduced an option to disable the nagle algorithm. Is that option still available in 3.2? Gerald

On Mon, 7 Aug 2023, Chris Rapier wrote: > > The broader issue of hiding all potential keystroke timing is not yet fixed. > > Could some level of obfuscation come from enabling Nagle for interactive > sessions that has an associated TTY? Though that would be of limited > usefulness in low RTT environments. I don't like the idea of having a steady > drip of packets as that seems problematic both in terms of code complexity and > network usage. I also don't li...

This time the problem is that the ssh server only sets TCP_NODELAY for interactive (tty) sessions or if X11 forwarding is enabled. Neither of which are true for the use of the sftp subsystem. This hurts upload performance for sftp/sshfs. I'm not sure why this hasn't cropped up earlier. Were there any TCP_NODELAY related changes in the sshd code recently? Is there a reason not to

In certain situations sftp download speed can be much less than that of scp. After many days of trying to find the cause finally I found it to be the tcp nagle algorithm, which if turned off with TCP_NODELAY eliminates the problem. Now I see it being discussed back in 2002, but it still unresolved in openssh-4.2 :( Simple solution would be to add a NoDelay option to ssh which sftp would set. The proprietary ssh seems to already have this option. Attac...

...the client @ 4-4.5 mbps(normal-behavior.png), down to 30-40kbps(bad-behavior.png). Most of the time, SSH stays in this 30-40kbps state for as long as their is data in the TCP queue. ie. during peaks, netstat will show the queue having 90-100k of data waiting to be transmitted. We think that Nagle may be taking effect randomly for some reason. When I 'strace -f ssh user at hostname', I don't see the TCP_NODELAY flag being set so that could certainly be true. I look in the ssh docs and I don't see anything about NoDelay but there use to be something according to O'Rei...

Hi All, I noticed a very weird phenomenon when I'm copying data (200KB image files) to our glusterfs storage. When I run only run client, it copies roughly 20 files per second and as soon as I start a second client on another machine, the copy rate of the first client immediately degrade to 5 files per second. When I stop the second client, the first client will immediately speed up

...ch is sock.diff > > - Added TCP_NODELAY to a nonblocking socket. It is said that it's improve > > performance in Linux. TODO: check Win32 compatibility. > > What's it supposed to do in general? I've had varying success with the > advanced socket options. Turn the Nagle algorithm off, so there it doesn't introduce delays (although it can generate more messages). Should be tested in severeal conditions. <p>> > - Solved a bug in source.c, when checking for recoverable error. It has > > to be done _only_ when result < 0. > > Can I see...

Dear Asterisk People, I am having problems putting a SIP image on a 7970. I was wondering if anyone can help? First problem is the phone is running version Load IDJar70.2-5-47-17.sbn Boot Load ID7970_64054100.bin Version5.0(0.6S) So I did read that you couldn't simply put the latest SIP image on such an old phone and a newer firmware version should be used. I got

When sending a PUT request, the http header may be sent in the first packet when calling con.endheaders(). When we send the first chunk, the kernel may delay the send because the header packet was not acked yet. We have seen PUT requests delayed by 40 milliseconds on the server side during virt-v2v upload to ovirt. Here is example log from current RHEL virt-v2v version, uploading to RHV 4.2.3:

...of the listeners connections and found that Icecast sends many small packets (200-300) bytes. This led me to look at the interrupt rate during peak times. At these times the interrupt rate reaches 10000 interrupts per second. Investigating a bit further I discovered that Icecast is turning off the Nagle algorithm by setting TCP_NODELAY option on the client sockets. This results in many small packets because a packet is sent as soon as possible without combining packets into larger packets. Would it be safe to turn on the Nagle algorithm (by removing the sock_set_nodelay() calls in appropriate plac...

Hello again! Since there was some resistance against adding TCP_NODELAY uncontionally, I've made another patch. The new patch contains the following: * Added a NoDelay yes/no (default no) config option to ssh and sshd * Added -oNoDelay=yes to the ssh command line for sftp. * Changed the sshd subsystem config option syntax from Subsystem name path to Subsystem name options path

I try to start Rmcdr from JGR. The Rmcdr-Windows comes up correctly; but the Menu-Bar in the Rcmdr-Window goes away, if I try to go into the Rmcdr-Window. I hope, someone has a solution. Regards, willi -- 0(049)753124283 privat 0(049)7531882641 büro [[alternative HTML version deleted]]

...ical reasons). That makes it hard to abstract as a "feature" for the R sockets that are supposed to be platform-independent. At least TCP_NODELAY is actually part of POSIX so it is on better footing, and disabling delayed ACK is practically only useful to work around the other side having Nagle on, so I would expect it to be rarely used. This is essentially RFC since we don't have a mechanism for socket options (well, almost, there is timeout and blocking already...) and I don't think we want to expose low-level details so perhaps one idea would be to add something like delay=NA...

I am experiencing an issue that my process does not wake out of a select() call when a single character is received in an input file descriptor when running as a VMware guest. Anyone ever experienced this ? I can run tshark and see the character arrive, but my process does not wake up and see that character. Most times it works - but once in a while it does not. So I made a change on my code -

...ts ACK, the following are the data back and their ACKs. In the first 4-5 iterations, I see no delay at all. Then, in the following iterations, a 40 ms delay starts to happen between packets 3 and 4, that is: the main process delays the ACK to the first packet of the incoming result. So I'd say Nagle is hardly to blame for this. It would be interesting to see how many packets are generated with TCP_NODELAY on. If there are still 6 packets, then we are fine. If we suddenly see a gazillion packets, then TCP_NODELAY does more harm than good. On the other hand, TCP_QUICKACK would surely solve the i...

Hello, I need to finish a small GUI program till friday and I am somewhat stuck. First of all, wxRuby seems to ignore the size request of the frame as defined via XRC (or I''m completly doing the wrong thing!) Second, it complains about the statusbar and doesn''t display it. What am I doing wrong? The files are attached Thank you Ulrich Spoerlein -- PGP Key ID: F0DB9F44

...ne is serializing everything (whether or not the > state machine spreads out the I/O to do writes from the thread calling > nbd_aio_FOO and reads from the reader thread, the two are never run at > once). Rich identified and fixed the culprit - libnbd was not setting TCP_NODELAY (disabling Nagle's algorithm) the way nbd-standalone.c did, which meant that any request that gets split over TCP windowing sizes waits to send the second packet until the ACK for the first has been received by the server. While disabling Nagle's increases network overhead (you are sending more short packet...

Seems like its the single byte thing... I tried adding: int flag = 1; if(setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(flag)) < 0) but did not have any effect. I also did the echo 1 > /proc/sys/net/ipv4/tcp_low_latency seems to have no effect also. Jerry