 |
 |
Hi Andy, Am 24.07.21 um 07:08 schrieb Andrew Hanushevsky: > Hi Oliver, > > Hmmm, could be I worded the doc Badly.... no worries: Reading your explanation in this mail, it also matches with the documentation. I think it's hard to find an unambiguous wording, especially when you are the developer who wrote the code and have the correct meaning in mind, so it won't be ambiguous to yourself ;-). > On Sat, 24 Jul 2021, Oliver Freyermuth wrote: > >> Since the XRootD defaults are: >> xrd.timeout hail 30 idle 0 kill 3 read 5 >> this slightly increases the kill and read timeouts. >> >> I _think_ that we increased these since we had seen timeouts waiting for replies / connections from some slower sites. > Likely, yes, but these parameters do not controll that. It is strictly in the client's hands. > >> To my understanding from the documentation, "kill" is the timeout before XRootD force-closes a connection in case the other end does not respond to an end-session command, > Not quite. This is the amount of time the server will wait for the connection cleanup to occur. If the cleanup does not occur in this window, the client is told to wait and try again "read" (adjusted) seconds later. Yes, I should have chosen better keywords. Thanks, that helps :-). > >> while "read" is the timeout in which the initial protocol identification has to arrive. > Actually that has to do with "kill". To increase thewindow of the initial protocol identification, you should set "hail". > >> So increasing these makes XRootD less sensitive if the other end is slow (e.g. in case it is overwhelmed), but may accumulate more connections if there are many slow connections incoming. > Well, unless you change "hail" the other two parameters merely control how long the server will tolerate connection cleanup. Understood. > >> This may not be needed anymore at all, and you may be better off with the XRootD defaults especially for busy sites to prevent many connections from piling up. >> Since we added this before any smoke tests or real TPC testing was done, I've now put this on our list of settings we should try to get rid of (and observe if there are any adverse effects), > I would agree. I have removed that config line from all our machines just now. Nowadays, I also check the code (or ask) if in doubt, in 2018 I did more trial and error. In the unlikely case I see any effect from removing that line, I'll report back, but I don't expect anything to change :-). cheers and thanks, Oliver > > Andy > >> Cheers, >> Oliver >> >>> >>> regards, >>> -- >>> Wei Yang | [log in to unmask] | 650-926-3338(O) >>> >>> >>> ######################################################################## >>> Use REPLY-ALL to reply to list >>> >>> To unsubscribe from the XROOTD-L list, click the following link: >>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1 >>> >> >> >> -- >> Oliver Freyermuth >> Universität Bonn >> Physikalisches Institut, Raum 1.047 >> Nußallee 12 >> 53115 Bonn >> -- >> Tel.: +49 228 73 2367 >> Fax: +49 228 73 7869 >> -- >> >> ######################################################################## >> Use REPLY-ALL to reply to list >> >> To unsubscribe from the XROOTD-L list, click the following link: >> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1 >> -- Oliver Freyermuth Universität Bonn Physikalisches Institut, Raum 1.047 Nußallee 12 53115 Bonn -- Tel.: +49 228 73 2367 Fax: +49 228 73 7869 -- ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1