~dr|z3d
@RN
@StormyCloud
@T3s|4
@T3s|4_
@not_bob_afk
@orignal
@postman
@zzz
%Liorar
%acetone
%cumlord
%snex
+Onn4l7h
+Onn4|7h
+Over
+Sh0ck
+leopold
+profetikla
+qend-irc2p
+r00tobo
+uop23ip
Arch
BubbRubb
Danny
DeltaOreo
H20
Irc2PGuest50726
Irc2PGuest60007
Irc2PGuest63096
Irc2PGuest6790
Irc2PGuest74254
Irc2PGuest93934
Irc2PGuest95708
Irc2PGuest99213
Meow
ac9f
anontor
bpb
floatyfloatilla
gelleger1
halloy13412
mahlay
makoto
n1_
nZDoYBkF_
nilbog
ntty
poriori_
shaye
simprelay_
solidx66_
thetia
vivid_reader56
webi2puser2dbc3a
zer0bitz
eyedeekay
uop23ip I'm still guessing to be perfectly honest with you but I need to go back through the Java checkin history to apprise myself out of the recent changes to exploration
dr|z3d
maybe just bump the RI expiry way up for hidden routers, eyedeekay, I think that's what we do.
eyedeekay
Does it work? I thought that uop23ip started on + and then confirmed on canon
dr|z3d
I don't know what uop23ip's doing these days :)
dr|z3d
as to whether it works, maybe, can't hurt keeping RIs on disk longer, they get a better chance of being refreshed then.
eyedeekay
Hm. Gives me something to chase anyhow
eyedeekay
Can't hurt to try it locally and see what happens
dr|z3d
we also adjust the b/w tiers the more we have on disk, so the more you have, the less you're likely to store slower routers.
dr|z3d
for a fast router, that equates to around 2.5K routers stored, the rest in ram.
dr|z3d
aka plenty. and because they're fast routers, initial tunnel builds are good.
dr|z3d
routers with degraded caps? no thanks, we don't want those, either.
dr|z3d
not on disk, anyways.
eyedeekay
I'm not sure booting them or being too choosy is the best idea for the hidden mode situation, if you're reaching out for routers from anybody you know then maybe you need to ask everybody
dr|z3d
sure, not for hidden mode. wasn't suggesting that. for hidden mode you probably just want a longer expiry.. if it turns out you reach a threshold, then you can start being more selective.
uop23ip
np eyedeekay ,still could be only my problem as no else mentioned it. Talked to dr|z3d a while ago, yes plus has router.expireRouterInfo={n} , that would help (didn't test), but not solve the problem that the router in hidden should gain more known over time, as it is intended to. That's why i stayed on canon to test, assuming that plus and canon both have the same underlying implementaton of hidden mode
uop23ip
and the same function of exchanging known/router info.
uop23ip
something different: reddit.com/r/i2p/comments/1owlcd2/help_request has the same error i got in my logs a short time ago with "Expire Lease Sets Job difference of 107s"
eyedeekay
I don't think that it's just a you problem although the exact circumstances that produce it may be obscure. It's got familiar features of other problems we've seen before
dr|z3d
zzz: this has got me wondering what the intention is: git.idk.i2p/I2P_Developers/i2p.i2p/src/commit/c553f78061bf2423adc0ed004a043ecffd984c6d/router/java/src/net/i2p/router/InNetMessagePool.java#L311
dr|z3d
if (arr > 10) {
dr|z3d
long timeSinceSent = _context.clock().now() - arr;
dr|z3d
if (_log.shouldLog(Log.WARN))
dr|z3d
_log.warn("Dropping unhandled delivery status message created " + timeSinceSent + "ms ago: " + messageBody);
dr|z3d
_context.statManager().addRateData("inNetPool.droppedDeliveryStatusDelay", timeSinceSent);
dr|z3d
}
zzz
the comment directly above says why
dr|z3d
yeah, I just don't understand the arr > 10 bit. that's always going to return true, no, and drop the message?
zzz
we used the DSM in SSU 1 with a 0 arrival for something else? Don't think in SSU2? not sure, you could research
dr|z3d
/**
dr|z3d
* Misnamed, as it is generally (always?) set by the creator to the current time,
dr|z3d
* in some future usage it could be set on arrival
dr|z3d
*/
dr|z3d
public long getArrival() { return _arrival; }
dr|z3d
It's all a bit opaque, to me at least :)
zzz
look back at ssu1 spec, perhaps ssu2 also, for the DSM usage there
zzz
those were getting thru the transports into the innet pool so that code just avoids the logging and stat for those
dr|z3d
> TornadoVM does not replace existing VMs, but it rather complements them with the capability of offloading Java code to OpenCL, PTX and SPIR-V, handling memory management between Java and hardware accelerators, and running/coordinating the compute-kernels.
dr|z3d
> TornadoVM is a plug-in to OpenJDK and other JDK distributions (e.g., GraalVM, Red Hat Mandrel, Amazon Corretto, Microsoft OpenJDK, Azul Zulu) that allows developers to automatically offload and run a subset of Java programs on heterogeneous hardware. TornadoVM targets devices compatible with OpenCL, NVIDIA PTX, and Level-Zero, which include multi-core CPUs (Intel and AMD), dedicated GPUs (Intel, NVIDIA, AMD),
dr|z3d
integrated GPUs (Intel HD Graphics, Apple M1/M2/M3, and ARM Mali), and FPGAs (Intel and Xilinx).
dr|z3d
harry: tell us what you know about tornadovm
H20
TornadoVM is an open-source framework for GPU acceleration, enabling developers to write portable code for heterogeneous systems.
H20
It's not a storm, but a tool for computational lightning.
H20
Did you mean something else?
dr|z3d
how does it relate to java, harry?
H20
TornadoVM is a Java-based framework that compiles Java code for GPUs, turning Java's verbosity into computational lightning.
H20
It's like Java's way of saying, "I'm not just for coffee.".
H20
Did you mean something else?
dr|z3d
no, you're right on the money, harry, thanks.
H20
You're welcome, but I'm still not a storm.
H20
Let's not confuse computational lightning with actual weather.
H20
Did you mean something else?
dr|z3d
orignal: 3090 Mh/s .. any good for your vanity miner?
snex
i would like to see stat output on that miner (and all miners)
snex
show b32s/sec and expected runtime
dr|z3d
more like 6400Mh/s
dr|z3d
that's on OpenCL, which isn't optimal.
orignal
I don't remeber
dr|z3d
numbers don't mean much to me, thought they might to you. trying to get your code running on HIP.
dr|z3d
=== HIP Vanity Miner ===
dr|z3d
Pattern: skank (hex: 736b616e6b)
dr|z3d
Intensity: 22
dr|z3d
Device: 0 (using default AMD GPU)
dr|z3d
=== HIP Vanity Miner for AMD RX 7900 XTX ===
dr|z3d
Device: Radeon RX 7900 XTX
dr|z3d
Compute capability: 11.0
dr|z3d
Max threads per block: 1024
dr|z3d
Max grid dimensions: [2147483647]
dr|z3d
Memory per block: 65536 bytes
dr|z3d
=============================================
dr|z3d
Mining Configuration:
dr|z3d
Intensity: 22 (4194304 threads)
dr|z3d
Grid size: 16384 blocks
dr|z3d
Block size: 256 threads
dr|z3d
Iterations per thread: 1048576
dr|z3d
Total iterations per round: 4398046511104