hi there, today i've tried the new 5090 build and i'd like to share my experiences 
with you.

first of, i've run into the 'too big seednodes' problem, too.... cutting the seednodes 
into half and throwing away one of these halves helped, as well as the suggestion to 
strip the file of every 'estimator' line, which 
worked very well too (dunno if it breaks something either, but nevertheless all the 
noderefs seem to show up in the RT)

one of the first times i started my node, it had about ~30 connections to other nodes 
after not quite 1 hour. then i restarted the node (because i needed full network 
bandwidth). the next node start provided me 
ONE connection to another node in the first 20 minutes. even after 2h of uptime i've 
come to only 20 live connections. that's weird and very depressing :-/ as you can 
imagine the node was never really useable as 
it was constantly backed off by all nodes it had connections to.

what i've discovered then is the main reason why i write this mail.
at the time my node had this only one connection to the other node i was able to track 
the type of the messages which got passed between the two nodes.
interesting was, that the foreign node (i will now call it 'node B') was quite 
"gentle" to my node ('A') as it routed some DataRequests and later some StoreDatas 
into my direction. so one can say that node B tried to 
integrate my node into the network and thus began to route some things into my 
direction. not too many, but what i'd like to call "just right", means something like 
around 1 message per 1 minute. (hm, i suppose it 
could be more)

after some time the passed message types shown at the ocm connections page looked like 

Accepted        3/1     
DataNotFound    0/1     
QueryRejected   3/0     
DataRequest     1/3     

he send 3 DataRequests, i sent 3 Accepted, and now it comes.. my node responded 
immediately with 3 QueryRejecteds! (all numbers were always equal when reloading the 
page, 2=2=2, 4=4=4, ...)
the question is: why did my node reject the query?
see the following stats:

Current routingTime     0ms     
Current messageSendTimeRequest  0ms     
Pooled threads running jobs     47 (39,2%)      
Pooled threads which are idle   7       
Current upstream bandwidth usage        76 bytes/second (1,9%)  
Current estimated load for QueryReject purposes 39%     
Current estimated load for rate limiting        39,2%   
Reason for load:        Load due to thread limit = 39,2%
Load due to routingTime = 10% = 100ms / 1000ms <= overloadLow (100%)
Load due to messageSendTimeRequest = 20% = 100ms / 500ms <= overloadLow 
Load due to output bandwidth limiting = 2,3% because outputBytes(4589) <= 
limit (196608,003 ) = outLimitCutoff (0,8) * outputBandwidthLimit (4096) * 
Load due to expected inbound transfers: 0,5% because: 1000.0 req/hr * 
9.950189371914758E-4 (pTransfer) * 86016.0 bytes = 85587 bytes/hr expected 
from current requests, but maxInputBytes/minute = 245760 (set input limit) * 
60 * 1.1 = 16220160 bytes/hr target
Load due to expected outbound transfers: 4,2% because: 5046.5665649684115 
req/hr * 9.970089730807576E-4(2 0s, 0 1s, 2 total) (pTransfer) * 86016.0 
bytes = 432787 bytes/hr expected from current requests, but 
maxInputBytes/minute = 172032 * 60 * 0.8 = 10321920 bytes/hr target 

my node was *never* overloaded  --okay, the first few seconds after node startup the 
messageSTR was huge--  but after that the node was constantly around 20-40% load; bw 
was nearly unused (i set bw to poor 
4kb/s up and down, but that was even never reached. a later removal of the limit did 
not help, either), cpu usage was very low too as nothing happened on the node.

----> why should the node answer with a QR? i don't get it.

of course the other node will be disppointed by my node's performance and decide to 
route somewhere else (or it ignores the QR and hammers regardless earning even more 

maybe there's a nasty bug somewhere which leads to the massive QR diplomacy we can see 
all around freenettown hindering everything as nearly all nodes are backed off.


Support mailing list
Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support

Reply via email to