On Tue, 16 Jul 2002, Christopher William Turner wrote:
> > > Also, looking it over, it looks like the ThrottledInputStream will block > > The bandwidth limiting bits will no longer block one thread for too long. Max > 4 seconds, even if no bandwidth. > > > locking ThrottledInputStream is implemented, it MUST have some way of > > obeying tcpConnection.setSoTimeout(). > > The throttling is just a filter on the underlying socket so any socket > operations will be respected. > > > When bandwidth limiting kicked in > > on hawk, it managed to grow by 100 threads in 10 minutes because it kept > > accepting connections but was not able to destroy any (presumably > > because they were all locked waiting for bandwidth.) > > New throttled stream creation now competes for bandwidth along with use so > the stream creation thread should no longer outpace existing threads. > Also no throttled stream should block for more than 4 seconds at a time. > Hi. I have written a simple test program for bandwidth limit. It tests max wait time on a read operation for a thread. There are three parameters number of threads, bandwidth limit and packet size( number of bytes read in a single read operation). The test shows that the maxWait time is exactly 1000*threadCount*packetSize/bandwidth seconds. For example with limit 20000B/s, packet size 4000B and 50 threads the max wait time is 10s. I do not know how many threads are usualy fighting for bandwidth, and I do not know what is the average packet size used. Roman Bednarek _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
