Jump to content
Comet Forums

Lin Lin

Members
  • Content Count

    2
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Lin Lin

  • Rank
    peer
  • Birthday 05/12/2002

Contact Methods

  • Website URL
    rinrin2002.github.io
  1. This issue has been acknowledged by the developer and fixed in the latest build. [1.64 beta2 - 20200110] @Rhubarb How to add [SOLVED] to the OP title? It's not possible to edit after 30 minutes.
  2. [Synopsis] As BitComet downloads, it produces disk read activity at the same speed as download speed at that time. [Setup] BitCometBeta 20191225 [Steps to reproduce] 1. Set upload speed limit to a very low value such as 10KiB/s; 2. Download a popular torrent with BitComet; 3. Observe disk activity with any monitoring tool, such as perfmon or HWiNFO; 4. Repeat the above steps with qBitorrrent 4.1.9.1 and uTorrent 2.2.1. [Actual behaviour] As BitComet downloads, it produces disk read activity at the same speed as download speed at that time. As shown in the perfmon screenshot below, the red line(Disk Read Bytes/sec) is almost overlapping with the yellow line(Disk Write Bytes/sec) [Expected behaviour] BitComet should not produce disk read activity at the same speed as download speed. The disk I/O rate graph should look like this: (qBittorrent 4.1.9.1) Notice that the the red line(Disk Read Bytes/sec) stays near the bottom. Or this: (uTorrent 2.2.1) Notice that the the red line(Disk Read Bytes/sec) stays near the bottom. [Uneducated guesses] uTorrent has an advanced option named diskio.smart_hash enabling piece hash calculation from cache before a finished piece is written to disk, thus avoiding re-reading the same piece back from the disk. I wonder if it's related or not? If BitComet does not possess a similar feature it would most probably cause the above described behaviour. Thank in advance!
×
×
  • Create New...