Oswald Buddenhagen <[email protected]> writes: > On Sun, Oct 27, 2013 at 10:12:42AM +0800, Eric Abrahamsen wrote: >> as mbsync often doesn't return cleanly after a socket error. >> > hmm. i fixed some (ssl-related) socket error handling problems some > months ago in master. > however, what is still missing is timeout handling, so if the > conection simply gets stuck, there is nothing to terminate it. i think > we already talked about that?
Did we? Actually, now that I think about it I haven't seen a hang for a while, so maybe your fix took care of it. >> Can you elaborate a bit on PipelineDepth (what does that actually do?), >> > it simply limits how many imap commands are allowed to be "in flight" - > when you set it to 1, it will effectively operate synchronously. > that means that the line latency is used as a throttle. > >> or other possible solutions to this? Is there a way to "throttle" >> updates from my end, so that gmail doesn't freak out and cut me off? >> > nothing in mbsync so far, and not knowing google's precise limitations, > it would be somewhat hard to create something really effective. you may > want to experiment with a kernel-based (outgoing) traffic shaper to > simply limit the bandwitdh. Okay, thanks for the tips. Kernal traffic shaping would be new territory for me, but maybe it wouldn't hurt to learn! Eric ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk _______________________________________________ isync-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/isync-devel
