Re: Viele Sockets in "CLOSING", delayed_ack?

Also sprach Oliver Fromme (olli(at)dorifer.heim3.tu-clausthal.de):

> Wo ich grade dabei bin, noch eine Frage: In einer der Squid-
> FAQs wird empfohlen, sysctl net.inet.tcp.delayed_ack auf "0" zu
> setzen, leider ohne nähere Erklärung. Gibt es zufällig hier
> einen TCP/IP-Experten, der mir sagen kann, was das genau be-
> wirkt, warum das auf Null gesetzt werden sollte, und welche Ne-
> benwirkungen das haben kann? Der zugehörige Kernel-Source war
> nicht wirklich aufschlußreich.

delayed_ack bewirkt, dass er so 50-200 ms wartet, bevor er das ACK
zuruecksendet.

Das macht er, weil normal der Server ja direkt wieder was an den
Client zurueckschickt (als Antwort), und dann nicht zwei Pakete
vergurkt werden koennen - eins für's ACK und eins für die Daten,
sondern er setzt dann beides in ein Packet.

Bei einem Proxy-Server, der selber erst Fischen muss, also nicht
direkt antworten kann, ist das sicherlich nicht sinnvoll, der wuerde
sowieso immer nach 50-200 ms senden das
ACK dann schliesslich senden, weil die Daten sowieso noch länger
brauchen.
Wenn er die Sachen aus dem Cache nimtm und die Festplatte schnell
genug ist, wäre das dann allerdings doch sinnvoll.

Was ich nicht verstehe: Ich glaube, man kann das mit TCP_NODELAY als
socketoption pro Socket festlegen. Man muss das also nicht als sysctl
machen, sondern das kann Squid selber.

Oder ist TCP_NODELAY was anderes? (nur Nagle-Algorythmus, ohne
ACK-Kram?)

> gen hängen lange Zeit oder sind quälend langsam). Dagegen
> gibt es mit Ethernet oder FastEthernet keine solchen Probleme.
> Könnte das mit obigem (delayed_ack) zusammenhängen?

Kann ich mir nicht vorstellen, da delayed_ack eigentlich eher FUER
Performance ist. (IP-HEader-Overhead verschwindet, der sich ja abei
dial-ups dann doch auswirkt)
Vielleicht einfach mal ausprobieren.

Alex

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Sun 06 Feb 2000 - 11:50:55 CET