On Thu, 4 Mar 2004, Shachar Shemesh wrote: > That is not the case here. TCP/IP assumes that packets do not get > corrupted along the way(1). It therefor assumes that, if a packet is > lost, it's beause of congestion. As such, the rate at which ACKs arrive > is tightly bound into the TCP/IP rate limiting algorithm. This means > that your assumption is wrong for the case at hand, as a saturated > connection is going to be losing lots and lots of packets. Guy's > assertation that using a single TCP connection for both directions > seems, to me, like a correct one, as the ACKs for one direction > piggyback on the data for the other.
this is indeed exactly what i'm trying to achieve here. i'll re-iterate: - i'm talking about slow links - so i want a minimal protocol overhead - not in terms of processing time, but rather in terms of added data overhead (how much extra _data_ does ssh's encryption send along with the original data it delivers? same for scp?). - i don't want to use compression at all here, since i want to do this for measurement of raw transfer rate. this, in order to be able to test raw transfer speed over a link, when it is loaded - so i need something that manages to use the full bandwidth available - hence the need to avoid artificial delaying of ACKs in one direction, by data which is sent over the other direction. and hence the need for the application to show me the temporary transfer rates in "real time". > That aside, there is a TCP option called "Delayed ACK", but it is aimed > at something completely else. If Guy manages to find a client that does > what he's looking for, it will be a good idea to turn it on, however. delayed ACKs don't _realy_ interest me, since an empty ACK packet is about 40 bytes long. assuming an MTU of around 1500 bytes, then each 1500 bytes of data (actually 1460 bytes of data) will cause 40 bytes in the other direction to be sent - which is within the expected error range for measurements (it's about 2.7% of the 'usefull' bandwidth). the same goes for selective ACKs. thus, the only reason that the ACKs worry me, is beacuse they can only piggyback the same TCP connection for which they are ACKing. if there are other active TCP connections, which fill the router's queue, then cause the transfer to be slowed down. from what i see so far, there's no ready-made solution for this - i'll see if i manage to get something done with scp over ssh... thanks, -- guy "For world domination - press 1, or dial 0, and please hold, for the creator." -- nob o. dy ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
