Opened 4 years ago

Closed 4 years ago

#2136 closed defect (not a bug)

I2PSnark / Streaming Regression 0.9.32-20

Reported by: Obscuratus Owned by:
Priority: minor Milestone: undecided
Component: streaming Version: 0.9.32
Keywords: I2PSnark, Streaming Cc:
Parent Tickets: Sensitive: no


I've been testing 0.9.32-20 on my I2P testing network. I run a ~100 MB torrent across 8 I2PSnark instances (3 routers on version 0.9.32-20, 4 routers on regular 0.9.32, 1 router on 0.9.30). The testing network has 2 additional java-based I2P routers as well as 22 I2PD routers (they're very memory efficient).

The seeding router is running the testing version 0.9.32-20.

As shown in the attachments, torrent seeding in I2PSnark seems like it's regressed. Based on discussion in IRC, I'm attributing this to the streaming component.

I'm attaching some charts and screenshots that show the problem.

The first attachment (i2psnarkBWChart-0.9.32.jpg) shows the bandwidth used by the seeding router (as collected from the router console tunnels page) while the router is running regular version 0.9.32.

The second attachment (i2psnarkBWChart-0.9.32-20.jpg) shows the bandwidth for the seeding router while running the testing version 0.9.32-20.

I'm also attaching screen shots of I2PSnark for both cases (i2psnark-0.9.32.jpg is running regular 0.9.32, i2psnark-0.9.32-20.jpg is running testing version 0.9.32-20).

When running regular 0.9.32, I2PSnark evenly distributes allowed bandwidth across the peers.

When running testing version 0.9.32-20, I2PSnark is choking most peers, and typically only allowing one or two peers. However, as can be seen from the bandwidth chart for 0.9.32-20, it's difficult to capture a single representative screen shot for I2PSnark under 0.9.32-20. But this one gives you an idea.


Attachments (4)

i2psnarkBWChart-0.9.32.jpg (59.7 KB) - added by Obscuratus 4 years ago.
I2PSnark Seeding BW (regular 0.9.32)
i2psnarkBWChart-0.9.32-20.jpg (120.4 KB) - added by Obscuratus 4 years ago.
I2PSnark Seeding BW testing version 0.9.32-20
i2psnark-0.9.32.jpg (145.2 KB) - added by Obscuratus 4 years ago.
I2PSnark Screenshot (regular version 0.9.32)
i2psnark-0.9.32-20.jpg (136.6 KB) - added by Obscuratus 4 years ago.
I2PSnark screen shot (testing version 0.9.32-20)

Download all attachments as: .zip

Change History (9)

Changed 4 years ago by Obscuratus

Attachment: i2psnarkBWChart-0.9.32.jpg added

I2PSnark Seeding BW (regular 0.9.32)

Changed 4 years ago by Obscuratus

I2PSnark Seeding BW testing version 0.9.32-20

Changed 4 years ago by Obscuratus

Attachment: i2psnark-0.9.32.jpg added

I2PSnark Screenshot (regular version 0.9.32)

Changed 4 years ago by Obscuratus

Attachment: i2psnark-0.9.32-20.jpg added

I2PSnark screen shot (testing version 0.9.32-20)

comment:1 Changed 4 years ago by zzz

Great data, thanks.

  • Is this the only torrent actively sending out data on the seeder?
  • What's the i2psnark up bandwidth limit on the seeder?

comment:2 Changed 4 years ago by Obscuratus

This is the only torrent being processed. I start with one seeder, and seven leachers.

All eight i2psnark clients have bandwidth limit set at 16 KB/sec. This value was arbitrarily selected. It provides a reproducible test to highlight differences across revisions.

comment:3 Changed 4 years ago by zzz

OK. So the seeder is -20, four leeches are -0 and three are -20.

Do you see a difference in the performance of the -0 vs. -20 leeches? Does one have higher peak download speed than the other, or is one choked more than the other? Which one downloads faster overall, over a long period?

comment:4 Changed 4 years ago by Obscuratus

All the leechers finish at approximately the same time (both the -20 leechers and -0 leechers).

The -20 leechers also show behavior problems similar to the seeder. The peak rates of all the -20 peers (both seeders and leechers) will intermittently spike above the bandwidth limits I've set.

But there is a lot of noise whenever I'm testing a version affected by this issue, which makes it tricky to draw conclusions.

Right now, I'm in the process of trying to bisect the issue, and identify when the problem first emerged.

comment:5 Changed 4 years ago by zzz

Resolution: not a bug
Status: newclosed

As discussed on IRC:

The test setup is very low-latency, high-bandwidth, and thus is similar to a "loopback" setup.

The 0.9.32-0 setup showed that all leechers were running at a very low bandwidth. This was caused by the loopback streaming bugs in #1939 fixed in 0.9.32-10. With the fixes, you see that a single leech quickly hits the very low 16KBps bandwidth limit and is choked. As a single peer is sufficient to max out the bandwidth, multiple peers will never be unchoked at once.

This setup exposes what's the true bug or design flaw, that i2psnark does not have robust outbound rate limiting. It enforces rate limits first by dropping packets and then by choking. Neither technique will result in a smooth graph or optimal bandwidth usage. While this behavior is seen on the real net, and is a problem that needs fixing, it doesn't result in the pathological graphs displayed here.

So the results attached here are evidence that the streaming fix is working, not that a new bug appeared. Closing this not-a-bug, but have bumped the snark rewrite up on my todo list.

Thanks to the OP for running the test setup and posting great results here.

Note: See TracTickets for help on using tickets.