Ah, I didn't realize that it only affects the transmit end - so I am guessing it is similar to what ALTQ does? BTW, I didn't mean to imply that it was an idle link - I saturated the link with a download in the background while testing. I am also running an MTU of 576 already. Note that I could get the effect I want with Dummynet and introduce probability packet loss on traffic other than interactive traffic but it completely kill performance on everything else (not necessarily a bad thing). One of my colleagues use Dummynet and allocate 1kb/s to ssh and that seems to strive a somewhat better balance. He only turns it on when he's downloading something though - where I'd like to find a scenario where I can leave it on permanently. It would be nice for us lowly dial-up users to allow some sort of transfer on the background and still have a reasonable interactive performance - with reasonable total throughput to boot. Maybe it's easier to get that DSL connection (I would have already, if I don't hate our ILEC so much). Thanks, Tim On Sun, Jul 15, 2001 at 09:57:05AM -0700, Matt Dillon wrote: > > : > :Cool! We were just commenting that it's too bad dummynet/ALTQ really > :couldn't help the interactive response for us dial-up users. Anyway, I > :just tried this on my dial-up connection on a fresh -STABLE but don't > :really notice any appreciable difference. > : > :net.inet.tcp.tcp_send_dynamic_enable: 1 > :net.inet.tcp.tcp_send_dynamic_min: 1024 (tried it with default 4096 too) > : > :My ssh response is still about 3 or 4 seconds behind my typing. What > :should a dial-up user expect? > : > :Thanks! > : > :Tim > > Well, what this code does is manage the case where you are streaming > data in the transmit direction *and* trying to type at the same time > over another connection. It will not improve latency on an idle > connection that you are typing over. Even in the streaming case with > this algorithm the minimum window is two t_maxseg packets and that > will have a noticeable effect on latency over a dialup no matter what. > What this protocol is supposed to save you from, at least insofar as a > dialup goes, is that it should prevent an upload from killing terminal > performance entirely (e.g. it should prevent 10-20 second latency on > keystrokes). > > 3-4 seconds of latency over an idle dialup is really bad. I still > get sub-second responsiveness when I run ssh over a dialup. I always > use compression over dialups (ssh -C ...) and it makes a big > difference. > > This protocol also tends to devolve into a degenerate small-buffer > case (which is what it is supposed to do) when the connection is > running over a low bandwidth high latency link. It only takes a two > or three packet window to fill the link in such cases and the minimum > is two packets. > > You might be able to improve performance by negotiating a smaller MTU > (if this is a PPP connection), but no matter what you will never do > better then the normal typing performance on an idle link that > you already get. > > -Matt > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
