| Do you stay current? |
Absolutely. We have been backporting our
improvements to I2P for years and will update within days
after new I2P source comes out. We will publish a full
package then. In between we may publish small updates, once
they are stable. See changelog
and update procedure on frontpage. Email us if you want to
see source in between. |
| Starting is so slow! |
After changing versions I2P might generate a
new router identity. See event log. Will take 48 hours to
fully integrate into the network. If it stays idle for
minutes, try a restart. |
| How compatible is I2Speed? |
100%. There is no change to cryptography or
communication protocols. You can always revert by installing
the i2pupdate.zip from the stock I2P distribution. For
certain machines we even use longer keys now. |
| Is I2Speed safe? |
100%. You do not need to download any
prebuilt stuff. Our full source is available for review or
for building your own install. |
| When will your improvements appear in the I2P
standard release? |
We do not know. Some issues adressed by us
were first discussed by a guy called zab (the MuWire dev)
years ago and no skillful dev cared. Especially our UDP
stuff is a major overhaul, very diffent from changing some
statics there as they did in the last releases. We hope some
I2P dev comes around and also sees value in our work. Steal
our code! |
| What about GraalVM? |
We consider this an exciting technology, but
it offers no direct benefit for I2P. We install it for
occasional use of JVisualVM (easier to use but not as
functional as the tools included with the JDK). If you use a
lot of Java apps it saves you repeatedly typing:
"-XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler" |
| What are your minimum requirements? |
We build for Java 11+ because of better
memory management, performance enhancements, Graal JIT (if
you run 64 bit) and default G1 GC. You may build for Android
or Java 8 by downgrading the Java version in
"build.properties". Do not try to build and run for single
core ARM. |
| What do I lose? |
Actually, not much. We took full stats and
message time-stamping out of the UDP transport. These rarely
used debug functions themselves do not eat much CPU when not
debugging, but cause endless calls to the system clock.
Debug logging is unchanged wherever possible. |
| What is "rtr:" ? |
Wow, you are debugging our stuff. "rtr:" is
the number of messages currently being retransmitted to this
peer. Easier to see if you go to /peers, last item in the
CWND column. |
| TCP or UDP? |
You will always need some dozen UDP
connections for reliable address detection and network
integration. Shutting off the NTCP transport takes some
burden off the network, but can cost you up to one third of
throughput. Even with I2Speed processing a message over UDP
takes a bit more CPU (but will use less on the entire path
to the final destination including your internet gateway).
That said there is a reason why I2P defaults to less TCP
than UDP connections. Many internet routers bog down under a
high number of TCP connections (well below listed specs). We
have seen packet loss and heat problems due to a high number
of TCP connections through consumer grade equipment. |
| How many CPU cores do you support? |
Any number your JVM recognizes. We take off
1/4 from that on X64 because of hyper-threading for sizing
thread pools. However our specialized thread pools are
limited to 16 threads. Sorry for you Threadripper fans.
Practically on low end 32bit ARM we max out 7 cores during
startup and 6 cores running 5000 tunnels and lots of local
traffic. But you always can add any number of Snark
instances and start scanning torrents with them and go as
high as you like. |
| IPv4 or IPv6? |
Use IPv4 only, if bandwidth is limited,
because it has 20 bytes less overhead / 16 bytes more
payload per packet. Using both will give best speed. If you
know how to perfectly configure IPv6 (OS specific,
advertised address must match ouside address), you will get
lots of traffic. IPv6 only will get you near 0 participating
traffic. |
| Do you provide enhancements for Snark? |
Snark benefits from any improvement to router
functions. In our view Snark is a leeching tool that works
for that purpose most of the time. We prefer BiglyBT. It
supports everything people have demanded from Snark in
discussions over the last years. |