Opened 3 years ago

Closed 3 years ago

#2357 closed defect (fixed)

I2PAnark shows alternating high downloads and crashing to super low downloads. Running two different downloaders does not show the smae pattern.

Reported by: YesYesYes well maybe Owned by: zzz
Priority: major Milestone: undecided
Component: apps/i2psnark Version: 0.9.37
Keywords: out of memory, slow torrent download Cc:
Parent Tickets: Sensitive: no


I have much better and more "consistent" torrent downloads running I2PSnark and BiglyBT at the same time.

There's a bug somewhere. If I run I2PSark alone I get these periods of 12KBps or less frequently. Very frequently. This even with java,exe set to 2GB in wrapper.config. Raising the number of tunnels in I2Psnark doesn't do the same thing as running both torrent downloaders at the same time so I don't see tunnels as the problem. Lots of data on what I tried here,


Here's where I noted running both I2Psnark and BiglyBT at the same time.


I've also run I2Pd with BiglyBT and while I don't get stellar speeds they don't fall as low. It seems to consistently do medium speeds well.

Something about running I2PSnark alone makes the downloads almost halt at times. A lot. It's also using a vast amount of memory. I'm running up on and sometimes using all the 2GB allocated for java.exe

I'm not the only one that's noticed this. Here




Someone that understands and is able to monitor this situation would be much better placed to understand what's going on than I would. There's only so much I can do.

Maybe running both I2Psnark and BiglyBT at the same time would show what the difference is???

I could be wrong but I think it likely that this started showing up after zzz fixed the timer problem that caused I2PSnark to slowly grind down to very low downloads unless you restrated. In this case restarting doesn't help. Others have noted it started happening around 0.9.33 and I agree but I have no proof.


I2P version: 0.9.37-0

Java version: Oracle Corporation 1.8.0_181 (Java™ SE Runtime Environment 1.8.0_181-b13)
Wrapper version: none
Server version: 9.2.25.v20180606
Servlet version: Jasper JSP 2.3 Engine
JSTL version: standard-taglib 1.2.0
Platform: Windows 7 x86 6.1
Processor: Phenom II / Opteron Gen 3 (Shanghai/Deneb/Heka/Callisto?, 45 nm) (k10)
JBigI status: Locally optimized library jbigi-windows-k10.dll loaded from file
GMP version: 6.0.0
JBigI version: 3
JCpuId version: 3
Encoding: Cp1252
Charset: windows-1252
Built By: zzz


Change History (6)

comment:1 Changed 3 years ago by YesYesYes well maybe

I notice that like the other person that I linked to


that I'm not uploading much at all to anyone else. It's not like my bandwidth is restricting this. I want to upload to others. I can see that there's also lots of seeds or people who have a lot of the files I need and they are uploading to me a minuscule amount. Maybe instead of me having problems downloading it's everyone has problems uploading to others.

comment:2 Changed 3 years ago by YesYesYes well maybe

I found a concrete example I can give you. I've been running I2PSnark and BiglyBT at the same time to see what's going on. BigllyBT has a lot more information than I2PSnark to look at. There's a TV series I've been downloading for months. Veerrryyy ssslllooowwllly. I started using BiglyBT in parallel, (I start I2PSnark, wait til it is fully started before starting Bigly BT and make sure BT writes it's downloads to a different folder.) I made a perfect copy of all my torrent downloads into another folder and then directed BiglyBT downloads to it. Some finished, some a little and some very little. A mix of completion. The BiglyBt? TV series torrent is at 98% and the I2PSnark is at 85%. I was going to say the BT is not downloading to the Snark, it wasn't, until I started writing this. It is now doing so but the difference in files is quite great. How come it took so long, hours and hours, and possibly days to start downloading the larger BT to the smaller Snark? I have restarted and it ran 88 minutes before it started transferring files to the smaller(Snark) and before I restarted it ran for hours and made no effort to balance the difference. The difference is about 860MB. That's a large difference. Most importantly I can see both servers the BT in Snark and the Snark in BT. So they know of each others existence and in BT I can even see what parts the Snark has yet they will not equalize.(They both could see each other and not equalizing has been over more than one day hence the difference in file size). We're talking slow downloads here of 1.2KBps or so over days for a 8GB file of which I only want the last seasons, maybe 6GB.

I don't know if it matters but I don't want all the files in the torrent. I have the first seasons of the torrent so I canceled the first seasons in both BT and Snark.

Setting up something like this and watching carefully what is going on when this happens might be a clue to what I and others have been complaining about. They and I say that there is no seeding done when there is opportunity to do so. echelon is saying that the little downloads add up. I agree but the little downloads are not happening at all in some cases.

I also lowered the number of tunnels BiglyBT was using in,

It had 6 Client tunnels for BiglyBT: DHT Pure and I think 3 Client tunnels for BiglyBT: DHT Mixed. I lowered to 3 and 2 respectively.

Adding while writing this it started equalizing the two servers but it stopped again as I was writing this with BT at 98.6% and Snark at 85% still. I'll restate to be perfectly clear. Over many days time two I2P servers running on the same I2P, I2PSnark and BiglyBT will not stay synced even though I can see the I2PSnark server and it's values in BiglyBT and I can see the BiglyBT in I2PSanrk. Why will they not equalize? Now if this was an hour, a few hours, maybe it could be ignored but not over days such that, even at very slow download rates, the two become 860MB different.

Last edited 3 years ago by YesYesYes well maybe (previous) (diff)

comment:3 Changed 3 years ago by YesYesYes well maybe

Arrgh. My apologies. I may be wrong. The "BT at 98.6% and Snark at 85%" may be because BT counts percentages as what you "wish" to download and Snark counts percentages as what you "actually" download. So if I refuse to download some it would skew the results. I will see tomorrow when I hope they will have finished what I selected to download then I will know for sure. This of course, [might], kill my "concrete case" that downloading is not always taking advantage of opportunities to download files available. I'll have to watch the files that are 100% downloaded and see if they are equal tomorrow. Sigh.

comment:4 Changed 3 years ago by YesYesYes well maybe

[Yes it was the difference between BT and Snark measured completeness]

comment:5 Changed 3 years ago by YesYesYes well maybe

Status: newtesting

Ok this is actually solved. echelon solved it, he said,

"…it is not a matter of time in your data, it is the situation of the net and your connection which are important.
Time is irrelevant.
No use for 2 weeks, 10 weeks or 100 weeks data…
no matter how long ago a situation is…And as long as those situation behind your ISP are changing every minute, you get more or less worthless data, even if you collect 10 years…"


comment #12

So in actuality any and all statistics over no or any amount of time that you measure have no value in I2P. It's the "I2P uncertainly principle" where you can never know what is going on therefore it can never be changed for the better or worse. It just is. I'm really glad this has been all cleared up for my befuddled mind. I feel so much better.

I changed action to "resolve as fixed but leave open for testing" because…well testing is always good. Especially if it's something that can't possibly be tested.

comment:6 Changed 3 years ago by zzz

Resolution: fixed
Status: testingclosed
Note: See TracTickets for help on using tickets.