Jump to content
Comet Forums

Tin Ching

  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Tin Ching

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yup, I let it auto choose cache size.
  2. Hi TripleThreat, I think definitely you need to increase the disk cache size! This is the most crucial setting for torrenting. You should set it as high as possible that your RAM can handle, but let it auto shrink when your RAM is below a certain number, then you are utilizing your RAM fully. If RAM is not used fully, it's wasted RAM, this is the most valuable resource your computer have, not the disk though. The auto shrink feature is very nice, when your programs or OS need to use more RAM, BitComet will reduce the cache size to let room for other stuff that needs RAM. I suggest you install this program https://dennisbabkin.com/ctm/ , it's a system tray icon that shows the usage of your system resources, e.g. RAM, CPU, disk. You will then see how much your disk is stressed at. I am using my OS SSD to be used for BitComet (windows & Bitcomet on the same disk). Therefore, if BitComet settings is not set correctly, you can easily crash Windows. If you are thrashing the OS disk at 100%, I don't think Windows can last more than half hour, and it will die. But if you have the files in another drive rather than the OS drive, it should be fine and Windows won't die. But with that 1GB cache size, you won't be able to download/upload in high speed, as the disk may be stressed out. I have 16GB RAM, set the disk cache size 10GB, shrink when it is below 750MB. My SSD is able to be kept at 50% less disk usage, and the temperature of the disk is maxed at 37 degrees celcius. With setting like this, you won't stress your disk at 100%. In my screenshot attached, you can see my RAM usage is at 93%, CPU 9%, OS disk 37%. If you want your computer not die for a long time, you need to aim for the disk usage as low as possible by leveraging your RAM. The best would be of course have all the sharing files sitting in a different SSD (not the Windows SSD), but it's not cheap.
  3. By the way, how many GBs did you allocate to your disk cache?
  4. Hi, I also have some crashes with BitComet [Bluescreen (memory management) + hard disk freeze (reset to device error) + complete freeze], especially when I increase the number of concurrent tasks. From what I found so far, Bluescreen & reset to device error is tightly related to the below setting: This is what I found on my machine in the event logs: Reset to device on raid port 0, issued by istorahci , something like that A lot of of the crashes BSOD (Blue Screen of Death), hard disk device reset can be fixed by lowering the IO priority of BitComet, I've tested this when I run many concurrent tasks, and install some other programs which requires intensive IO as well, it will crash my machine. But if I lower the IO priority of bitcomet, Windows will automatically slow down BitComet's IO request and let the other program utilize IO in higher priority. Windows has many scheduled tasks that will suddenly require intensive IO requests, so this setting is very handy. If nothing is using IO, BitComet will use full bandwidth, but as soon as other programs needs IO requests, BitComet immediately drops the bandwidth usage by Windows. For the sudden OS freeze, I'm still investigating, will let you know what i find in the upcoming days.
  5. There is a chance your files are hashing due to an improper exit of the program, i havent upgrade to 1.68 so not sure 1.68 has an issue. If theres no hashing, i cant explain why it will slow just starting a task. If this is the case, u need start one by one as hashing do intensive reads.
  6. Also, you may want to set this to a lower number, as the default (1000) is way to high! Setting this too high will jam your Internet connection.
  7. If all your files are on an SSD drive, way to go! There shouldn't be any more hang.
  8. It has nothing to do with the RAM and CPU, we are on top end machines with heaps of RAM and CPU. You can try this option, I've managed to solve the hang issue. Go to Advanced settings, and set this to true. No more hanging on my machine, and the XML files each is less than 1MB as it will only save those peer IPs that is connected to you. With SSD and heaps of RAM, it won't even cause my machine a sweat.
  9. Just tried v1.67, still have freeze when it writes the current tasks into the xml files. I saw the changelog some other torrent history xml file got migrated to sqlite, I wonder if they can do the same for the current active tasks as it may help to remove the freeze.
  10. Nah, I think this is a software issue, not hardware, particularly relates to the algorithm/architecture of how these XML files get read / written. The UI freeze is when the program started triggering the xml writes (but hasnt actually started writing to disk yet). During this time its busy doing something else which I'm not sure what it is, could be busy gathering all the peer IPs and writing to memory. I would say if this issue gets fixed, most of the UI hang bug tickets in the past would be solved.
  11. Attached below is screenshot of 2 large xml files causing UI to freeze at regular intervals.
  12. Yeah, even we have a very powerful machine, but the current architecture of BitComet is not scalable. The xml config file writes is killing it.
  13. More details: - A lot of users in the past has mentioned the UI freeze every 5 minutes, this coincides the every 5 minute writes for the task xml config files - Users also mentioned they get the freeze if you have enabled DHT, this is because you will find a lot more peers if you enabled DHT, and this will bloat up the xml config files In my opinion, this is the most critical performance issue for BitComet. Why? BitComet writes these files every 5 minutes, but it doesn't write them all at the same time, it writes one by one. As time goes on, the time gap of each write of file increases and spread to different times. Imaging you have 5 torrent files like this and evenly spread across, on average you will get a GUI freeze every minute. If you have 10 files like this, you will get a freeze every 30 seconds on average. This will make the program hardly usable. During the time it freezes, all uploads/downloads will be jammed/halted (goes to 0) Possible solutions: I do not think writing these xml files is time critical. - Write these xml files in it's own thread separate from the GUI, or - Maybe have an advanced option where we can adjust the auto save frequency? or even have the option to only save these files upon closing the program.
  14. BitComet UI not responding A lot of users has already brought this up, but I think so far no one has located the root cause of the issue. I personally experience this issue and have dig deep into the root cause of the issue. Some user may not have experienced this and it really depends on how "popular" your torrent file is. The torrent file I download has 15,000+ users in the network. Every 5 minutes exactly, BitComet writes xml configuration files for the tasks into the AppData folder. Two of my files in my download list has 15,000+ users and this is where BitComet UI freeze up during the time it starts writing these gigantic xml files (each 150MB+ in size). This causes the UI freeze for 30+ seconds. Can these config file writes to be put into a background thread so that it doesn't freeze the UI? Same applies to program startup, BitComet reads all these xml files which makes the program unresponsive. I can also confirm that the freeze is not coming from a disk bottleneck, as my hard disk is an SSD drive and disk activity is very low, I suspect the UI freeze happens when the program writes the XML data into memory OR it's busy gathering all the info for the task (e.g. peer IPs etc) I hope this helps the community, and the info I have provided should allow the issue to be easily reproduced.
  • Create New...