In message <002201c28492$b6cd6180$4e0d4818@ip78>, Robert Carroll <[EMAIL PROTECTED]> writes
I just want to spout off about my node's performance, or lack of it.�
I'm running a permanent node on a server that has other things to do
besides spend every cpu cycle on a java app.� Also, like alot of node
operators, I don't use the machine directly, but instead access fproxy
and fcp from another machine.� Sometimes it can take SEVERAL minutes
just to call up the web interface!� Even when I do finally get through,
alot of content is simply not found, no doubt due to overloaded�permanent nodes.� Here are some suggestions for the developers:
As a matter of interest, our your other machines on private or routeable IP addresses? I gather the bandwidth limits do not now apply to machines on the same private subnet. This does not help those of us using routeable IP addresses, and I wondered if the speed of contacting fproxy was increased in practice. Lynx on the Freenet server certainly seems to work faster, but it is less than useful for graphics, obviously.




�
Transient nodes should be your lowest priority right now.� Attention
should be shifted to the permanent nodes because the health of the
network depends on them.� That means that CPU utilization needs to be
reduced drastically.� Performance for FCP and FProxy need to get the
HIGHEST priority when the node is processing.� If that means that other
transactions have to be put on hold in order to process a local
request, then so be it.� Permanent node operators should not be
penalized for serving the Freenet community.�
See above, we need to know if bandwidth limiting is a major factor in Fproxy performance.
Do you have the strange problem that my permanent node has, that it loses all the contacts from its routeing table because it cannot successfully contact them, although a transient node close by can easily contact the same nodes > 50% of the time? If there is a solution to this that does not severely impact on incoming requests (or even if it does!) it would make running a permanent node less frustrating.




More should be done to encourage people to run permanent nodes.�
Requests could be prioritized by each node according to the requesters
responsiveness and availability to that node.� Of course some minimum
level of resources need to be dedicated to slower nodes to prevent the
network from fragmenting.� To help those who are firewalled or using
NAT (who have trouble receiving inbound connections, but not
establishing outbound connections), nodes with a permanent IP could
also serve as helpers, by listening on behalf of a firewalled or NAT
node.� This would only be required for establishing connections, NOT
for acting as a proxy for the data.� Bandwidth requirements would be
minor and would allow alot of people to become permanent nodes.
Sounds interesting, the firewalled node would maintain a permanent connection to the "helper" node?
--
Roger Hayter

_______________________________________________
support mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/support


Reply via email to