On Tue, Jun 11 2019, Olga Kornievskaia wrote: > > Neil, > > What's your experience with providing "nosharedtransport" option to > the SLE customers? Were you are having customers coming back and > complain about the multiple connections issues? Never had customers come back at all. Every major SLE release saw a request that we preserve this non-upstream functionality, but we got very little information about how it was being used, and how well it performed. > > When the connection is having issues, because we have to retransmit > from the same port, there isn't anything to be done but wait for the > new connection to be established and add to the latency of the > operation over the bad connection. There could be smarts added to the > (new) scheduler to grade the connections and if connection is having > issues not assign tasks to it until it recovers but all that are > additional improvement and I don't think we should restrict > connections right of the bet. This is an option that allows for 8, 10, > 16 (32) connections but it doesn't mean customer have to set such high > value and we can recommend for low values. The current load-balancing code will stop adding new tasks to any connection that already has more than the average number of tasks pending. So if a connection breaks (which would require lots of packet loss I think), then it will soon be ignored by new tasks. Those tasks which have been assigned to it will just have to wait for the reconnect. In terms of a maximum number of connections, I don't think it is our place to stop people shooting themselves in the foot. Given the limit of 1024 reserved ports, I can justify enforcing a limit of (say) 256. Forcing a limit lower than that might just stop people from experimenting, and I think we want people to experiment. NeilBrown
Attachment:
signature.asc
Description: PGP signature
