I did some calculations on the issue of more open connections and faster
connection establishing (nio and sipv2 respectively)
This calculation is based upon this current data from my node (fast CPU
(XP 2200+), fast internet connection (5.0/0.75MBit) and lots of memory):
connectionLifeTime/Mean Value: 50 seconds
liveConnections/Mean Runtime count: Pretty much always
0.4*maximumThreads, for this example, lets say, 150 which probably are a
quite normal value given the available CPU and bandwidth
connectionRatio/Success Probablility: 66%
localQueryTraffic/Number of events: 15k / hour
connectingTime/Mean Value: 5 seconds
whereof socketTime/Mean Value: 1.3 seconds
and authorizeTime/Mean Value: 3 seconds
The first three numbers taken together gives that the node establishes 3
new connections each second (to be able to sustain 150 open
connections). 66% success ratio for connections gives that the node has
to try to establish ~4 connections each second. Each of the trials that
fails will in worst case take as long time to establish as a successful
connection (probably less, but in worst case and that is what I will use
for this calculation)
4 connections established each second gives 4*3600 = 14400 connections
established per hour
The local query hit rate is about 1k hits / hour which then gives that
14k of the 15k requests handled by the node are routed on to another
node. 14400 ~= 14k which means that on average my node establishes about
one connection per query for data which is not present in my DS
Since each connection takes about 5 seconds to establish I would say
that my node effectively delays a request that needs forwarding to a
un-connected node an average of 5 seconds. Assuming that my node is an
average node and that the mean HTL is 15 that would mean that a mean
request is always delayed by 15*5 = 75 seconds just by nodes having to
establish new connections very often....
Ok, what would happen if we introduced sipv2 then.. Assuming that most
connections established will be significantly faster to authorize using
sipv2 and also that the resulting reduced CPU load allows a machine to
respond to socket connections somewhat faster we could see a decrease or
connectingTime to, say, maybe 2 seconds or so. That alone would decrese
the average request chain time from 5*15 seconds to 2*15 seconds.
What would happen if we added nio instead then... Assuming that nio
enables an average node to increase its connection count by a factor of
two we could possibly see a factor of four less connection establishing
in the network (is squared right or would it be a linear effect?) which
would reduce the average time, consumed by connection establishing,
along a request-chain from 15*5 to 15*1.25 = 19 seconds..
Bringing both nio and sipv2 together therefore ought to decrease the
average time consumed by connection establishing along a request chain
from 75 seconds to 7.5 seconds or so.
Taken together I would say that nio and sipv2 might bring very, very
nice latency decreases and probably quite a bit lower CPU load for
nodes. If you then add ngRouting above this, which is theorized to allow
you to fetch the data you have found faster, things might start to look
quite a bit brighter... Then there also is the thing of connection
multiplexing to thing about which probably will decrease the number of
connections a node has to establish by a certain percentage (I actually
quite often see more than one connection to/from the same other node
from/to my node)
Caveats:
Probably most of the nodes in freenet have both less bandwidth
and less hardware. The equation for them would be a bit different but
the equation should stand for most 'higher-grade' nodes.
My estimations of the gain from each of the improvements
probably are a bit high (even though I tried to keep them as low as
possible), but even if they are modified to become more pessimistic we
could see a significant gain...
Bring out the axes.
/N
_______________________________________________
devl mailing list
devl at freenetproject.org
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
