Cachefilling -> ~no Upload

[s8]

Heyho,

i've got a serious problem on my Server..

If the Download-Speed is over 8-14mb/s the cache fills (so far so good..), but the upload goes down simultaneously. When the cache is filled with more then approx. 60 mb, the upload goes down to (max.) 90 kb/s.

I tried several cache values and - settings, but the problem persists.

The Server is running on Dualcore 2,4 ghz AMD, 2 GB Ram, 600 GB HDD, 1000Mbit Ethernet. Utorrent Version 1.8 b.11564.

[Switeck]

Did you disable windows caching in uTorrent v1.8?

[s8]

Writes: YES

Reads: NO

As said before, i tried every option. Read Enabled/Disabled, Write Enabled Disabled.

It also depends on the size of the parts. If they only have 256, it writes way slower than with (eg.) 4mb parts.

To preserve the upload i have to throttle the download frequently - to values below 8500kb/s

[thelittlefire]

I'm hoping those are at least SATA II, probably SAS drives yes? You need a larger than 64 MiB cache at those speeds with slower hardware. Searching for related cases usually bring up lack-of-RAM simultaneously being a problem. If you look at the client while consistently up/down-loading... is there a bottleneck perhaps due to too-many running torrents/write jobs? What are your Queueing settings set to?

[Switeck]

A connection that fast (1 gigabit/second) is way beyond what most file systems can handle.

Only thing you might want to try is downloading/uploading from a ramdrive...that at least should be able to handle the random access nature of BitTorrent traffic.

[s8]

"is there a bottleneck perhaps due to too-many running torrents/write jobs? What are your Queueing settings set to?"

2 down simultaneously, unlimited uploads.

"A connection that fast (1 gigabit/second) is way beyond what most file systems can handle.

Only thing you might want to try is downloading/uploading from a ramdrive...that at least should be able to handle the random access nature of BitTorrent traffic."

Thats maybe the point..

Cache is 1000MB @ ram.

The system CAN evidently handle high speeds, I downloaded some Video-Files with 101,5 Mb/s.. without uploading that time ..

(I think it depends on the size of the parts (.rar / divided through utorrent-Torrent))

[Switeck]

If a piece of a torrent isn't in ram, speeds have to drop while pulling it into ram if the requests are random to the point of shotgun-pattern random.

Disk speeds are typically rated at continuous sequential speeds. Database chunk-reading rate (or something like that) is how many random chunks (of 64KB, 128KB, 256KB...4096KB sizes) can be loaded per second. I saw that on http://www.tomshardware.com/

[s8]

But: Continuous Reading or Writing is .. in my eyes and comprehension a better way to write data faster to disk (or for sure read it)

millions of 128kb chunks are certainly read slower than some thousands of 2048kb.

[DescentJS]

You're right about the speed aspect. However, that's not how the Bittorrent protocol works. One of it's core natures is that of random piece transfer: which = random data access.

[Switeck]

4th link in my signature suggests just how badly BitTorrent forced into a sequential access method would run.