Author Topic: Stable Build 5096  (Read 2160 times)

0 Members and 1 Guest are viewing this topic.

Offline Nemo

  • Global Moderator
  • Elite
  • *****
  • Posts: 1303
  • Karma: +27/-0
    • View Profile
Stable Build 5096
« on: September 26, 2004, 04:25:15 PM »

From: Toad <toad@...>
 Subject: Stable build 5096
 Date: Fri, 24 Sep 2004 19:53:55 +0100
Freenet stable build 5096 is now available. The snapshots have been
updated. Please upgrade to 5096, test it, and report any bugs that you
find. You can do this by using the update utility on windows (on the
start menu), or by running in linux, or by downloading the new
jar from Either
way, it's probably a good idea to shut down the node before doing so
(and turn it back on afterwards!).

There are many changes in this build, here are some of them:
- 5095 is now mandatory. Queueing wasn't really working adequately until
  5095. However the overwhelming majority of nodes at least in my RT are
  5095, so there is hopefully no problem here...
- Lots of work on timeouts, in response to recent problems with inserts.
  It is likely that the recent insert problems have been caused by
  insert timeouts being wrong, partly by not taking queueing into account.
- A major routing bugfix in the estimator smoothing code. This is used
  mostly when a node is relatively young.
- New, optional, but enabled by default, super-fast routing estimators.
  These are slightly lower precision than the original estimators, and
  were developed as part of the recent simulation efforts. These are
  based on double precision arithmetic (64 bits, 53 of which are
  "mantissa" i.e. actual value, we can use), which is accelerated in
  hardware by most modern CPUs, instead of 160-bit BigIntegers. We
  believe that doubles provide sufficient precision; the simulations
  suggest there are no serious bugs in the changeover of this particular
  code. 53 bits should be enough even for a very large network... In any
  case the new code is 3-4x faster (in terms of CPU usage, not routing
  effectiveness or how fast it learns). This is a big part of freenet's
  overall CPU usage, so expect improvements, especially on low end
  machines. Turn this off by setting useFastEstimators=false in
- Also you can use doEstimatorSmoothing to enable or disable estimator
  smoothing; the results from the simulations on estimator smoothing are
  unclear at present.
- Transfer failures are handled better by Fproxy, there is now a proper
  error message instead of the unfriendly exception messages we have
  been seeing reported on devl and support recently.
- Much improved Current Downloads page thanks to Iakin (Niklas Bergh).
  And related bugfixes.
- Partial fixes and workarounds for the "Too high probability" bug. I
  don't think we have finally fixed the cause of this bug, but at least
  it will be recovered from virtually instantly. We may have fixed it
  completely however.
- We now have a histogram of the versions of only connected nodes, as
  well as the histogram of versions of all nodes in the routing table.
- Added some missing images for the "simple" theme
- Lots of routing refactoring by Thelema (Edgar Friendly).
- Workaround for an infinite loop bug in queueing that I haven't been
  able to reproduce and fix yet. Will log an error if it happens.
- Workaround for a bug in some Sun JVMs, that causes
  BigInteger.toString(16) to cause an NPE. We now use our own code to
  dump BigIntegers.
- Fix a rare NPE in MuxConnectionHandler
- Extra checks for invalid MRIs
- Added a method to AutoRequestor to calculate the CHK we would get if
  inserting a file, given a specific content type, by Vesa Salento. I
  think this may make freenet.client.cli.Main computechk work correctly,
  but I haven't tested this.
- Paranoia to ensure we never send an HTL over our limit. I don't think
  current builds do this; I know some older ones did.
- was still not setting LD_ASSUME_KERNEL for some
  systems. Fixed it.
- Many other minor fixes.
Matthew J Toseland - toad@...
Freenet Project Official Codemonkey -
ICTHUS - Nothing is impossible. Our Boss says so.

Support mailing list
Unsubscribe at
Or mailto:support-request@...?subject=unsubscribe