 |
 |
Sorry for taking so long to getting back to this but we do have a lot of other issues to address. The proposal to allow separate limits for each activity is a good one but I think needs to be a bit more flexible. So, I would suggest something like: xfrmax <xfrmax> in <inmin> out <outmin> The <inmin> value is the number of transfer threads that must be reserved to handle traffic for in and <outmin> the same for out activity. The sum <inmin>+<outmin> may not exceed <xfrmax> and usually should be less than <xfrmax>. This allows load shifting from in to out activity depending on what work is queued but also reserves threads to exclusively handle a particular activity, leavng <xfrmax>-<inmin>-<outmin> to handle either activity. Now, all that said, the current implementation round robins across all the queues, picking the oldest request if it has a choice within a queue. So, while migrations compete against staging they compete on an equal level and neither activity should be starved, though not necessarily in a fair way if the queue is suddenly filled with one type of request. However, you could argue that's OK as we are trying to empty the queues as fast as possible, assuming that neither activity is more important than the other. That is a naive assumption for certain workflows but seems to work in most cases. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/issues/617#issuecomment-397251996 ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1