BitComet causing excessive ping times

Hello. New here (to this forum).

I've been a long time user of BitComet and I didn't have this issue before, but this issue is starting to happen more and more with the BitComet client.

 

Whenever I have the BitComet client running, I notice that the network will see ping times to google.com ranging anywhere from the 3544 ms to > 9000 ms mark with about a 3.8% packet loss.

 

I thought that maybe it was my older version of the client that was the issue, so now, I've updated to v1.91 (64-bit). Per the guides [here](/topic/410-bitcomet-speed-guide/) and [here](/topic/533-bitcomet-settings-guide/), I've executed the steps that are outlined in both of these guides already and I am still seeing this excessive ping time issue.

 

I've set the port per those guides as well, and the ports have been forwarded on my router.

 

My system that is running the client is also using a gigabit network (hard line) interface (i.e. not WiFi), and my fiber internet connection is tested at 250 Mbps up/250 Mbps down as well.

 

The speed in the client settings are set to unlimited and even just STARTING the client, with no tasks running, will produce said excessive ping times.

 

I've also read through [this thread](/topic/12801842-bitcomet-makes-my-internet-packet-loss/) already as well, and as a result of that, I've disabled my Torrent Exchange on my client completely and entirely as well, and I'm still seeing said excessive ping times.

 

Any help that you can provide in regards to what I should look at or what I should try to look into, would be greatly appreciated.

 

Thank you.

 

*edit*

Attached is the log file of the ping times from my Mac.



That logs the first 100 packets which goes through the start up process of the BitComet client and then immediately shutting it back down/quitting said BitComet application right away as well, without starting any of the torrent tasks.

 

You can see how the ping times will shoot up to over thousands of milliseconds per ping packet and when I close the client, it goes back to about the same ping times before the client was started.

BitComet ping times to google.com 2022-07-09_2302.txt

BitComet ping times to google.com 2022-07-09_2302.txt (6.22 KB)

BitComet ping times to google.com 2022-07-11_2026.txt (1.4 KB)

edit

The maximum ping time now to google.com is 11184.159 ms with the Bitcomet client running, with about an average of 1.3% packet drop rate (nominally).



Without it, it's in the sub-600 ms range (with anywhere between 0.0-0.1% packet drop rate).

Te ping time is, basically, the duration of a check transmission to and from an address. However, it really only works if there is no other activity online. Running any client that requires online transmit/receive will increase the time taken - be it a browser, upload/download mail, etc. Any torrent client, when working correctly, has a heavy transmit/receive load so increased ping time is normal

	14 minutes ago, Rhubarb said:



	

		Te ping time is, basically, the duration of a check transmission to and from an address.  However, it really only works if there is no other activity online. Running any client that requires online transmit/receive will increase the time taken - be it a browser, upload/download mail, etc. Any torrent client, when working correctly, has a heavy transmit/receive load so increased ping time is normal
	



I understand that.

 

But I have two other clients running Bittorrent clients running as well and starting up their respective applications do NOT cause an increase in the ping times from sub-600 ms to 4925.784 ms (absolute max, out of 300 packets), as shown in the attached file.

 

In fact, my previous, added comment which shows the maximum ping times of up to 11184.159 ms with a 1.3% packet drop rate ONLY happens when BitComet is running.

 

With the other two running in the background, out of 31330 packets, only 14 packets have been dropped which works out to be 0.0446856% packet drop rate and a round-trip min/avg/max/stddev = 7.595/11.074/497.846/12.356 ms without the Bitcomet client running vs. the 1.3% packet drop rate when BitComet is running and a round-trip min/avg/max/stddev = 8.287/1350.051/4925.784/1471.297 ms **with** the Bitcomet client running.

 

So, normally, I would be inclined to agree with you that an added load on the network will increase the latency, but when your average ping times goes from 11.074 ms without the Bitcomet client running to 1350.051 ms with the Bitcomet client running, (which is 121.9117753 TIMES higher), there is nothing that would explain THAT level of increase.

 

There is CLEARLY something wrong with the BitComet client that is producing this result.

 

And of course, if the BitComet client was only causing a slight or marginal increase, I probably wouldn't even notice.

 

But as it stands, and I'm still on indefinite work-from-home as a result of COVID, this level of interaction/intereference that is CLEARLY being caused by the BitComet client is making it such that my meetings are getting dropped as a result of this issue. If it weren't for this fact, again, I probably wouldn't have even noticed nor cared enough to bother investigating the root cause of the issue.

 

The fact that once I exit and terminate the BitComet client application/process, and I can get to sub-500 to sub-600 ms ping times, with SIGNIFICANTLY lower packet drop rates and this is with TWO other Bittorrent clients running at the same time, provides enough data to tell me that it is the BitComet client that is causing the issue. And the fact that even with disabling the DHT trackers, and the DHT Torrent Exchange altogether, STILL doesn't resolve this issue, provides further data/evidence that there is something else that's clearly wrong here with the BitComet client given the fact that the impact is HIGHLY visible that I can measure when I have started and am using the BitComet client/application vs. when I'm not, JUST by looking at the ping time statistics alone. I would be INCREDIBLY surprised if an increase in ping times **TWO ORDERS OF MAGNITUDE** would be within the realm of your expected value, pursuant to your statement/explanation about.

 

If you tell me that you **EXPECT** the ping times to increase by **two orders of magnitude**, then I'll believe you.

BitComet ping times to google.com 2022-07-11_2026.txt

My response from google.com is 17 mS - I’d suggest you check on anything else that may be running (this can increase with VPN running)

BC is running at 411kB/s upload and 4 kB/s download.
	5 hours ago, Rhubarb said:



	

		My response from google.com is 17 mS - I'd suggest you check on anything else that may be running (this can increase with VPN running)
	

	

		BC is running at 411kB/s upload and 4 kB/s download.
	



But again, everything else is already running the way the system has been set up.

 

As I have shown, in the previous ping time logs which show what happens when the BitComet client is starting up, there is LITERALLY a measurable increase in the ping times.

 

The ping times CAN be thousands of milliseconds nominally -- that's actually LESS of problem.

 

The PROBLEM is the fact, as shown with the ping time data/results that it **INCREASES by TWO ORDERS of MAGNITUDE**. That's a BIG part of the problem.

 

As I mentioned before, if the E(X) is log_10(121) = 2.08...., then fine. The fact that everything else is a common variable and that the starting and the stopping of the BitComet client is the MEASURABLE cause of the increases in ping times, tells me that there is something wrong with the BitComet client. Starting and stopping BOTH of my other Bittorrent clients does NOT produce this effect.

 

(When I started getting dropped from my meetings, I had to go through the process of disabling and enabling each piece of my network one by one, so I've already ran that review/exercise. If the issue wasn't MEASURABLY tied to the BitComet client, I would be posting on the respective source of problem's forum instead of here.)

 

You mentioned that you expect there to be more traffic as a result of the BitComet client running, and therefore; resulting in an increase in ping times.

 

What you haven't been able to address though, is why the ping times have increased by **TWO ORDERS OF MAGNITUDE** as a result of starting and stopping the BitComet client.

 

I've already ran wireshark on my network and the BitComet client is what it points to as the program that's responsible for my being dropped from my meetings.

 

Again, the effect is so severe that I can literally measure it and it will show up on the ping times within 300 packets, as shown in the attachments of the ping times that I've posted above.

 

Believe me, if this wasn't an issue, I wouldn't (need) to be here.

Your problem can’t be duplicated. My machine is creaking at the seams (I’ve a new motherboard/CPU/DDRAM4 upgrade waiting for despatch) and I am NOT able to duplicate the issue.

As I don't know what may (or may not) be installed on your machine, all I can do is point out that I do not get that long ping time that you mention.

Having said that, what sort of transfer rates are you getting? Pinging google isn't always the best test of a system - transfer rates are more useful. Are you getting close to your rated speed (as per your ISP)? If so, then worrying about a ping time is pointless. On the other hand, if your rates can't come close to the 'maximum' (and please note that ISPs tend to measure in bits per second and not bytes)  and they alway quote the 'maximum' possible rate (and point out that they don't guarantee you'll get that - all they really say is you won't get any faster)
	1 hour ago, Rhubarb said:



	

		Your problem can't be duplicated. My machine is creaking at the seams (I've a new motherboard/CPU/DDRAM4 upgrade waiting for despatch) and I am NOT able to duplicate the issue.
	



 


	Okay. That's fine (that you can't duplicate my issue). I mean, I wouldn't expect you to be able to duplicate my issue.


 

Aren't there like client connection logs that might provide some insight or maybe some kind of diagnostic that I can run to be able to see more debug/diagnostic information as to why whenever I start up the client, it causes the ping times to increase by **TWO ORDERS of MAGNITUDE**?
	1 hour ago, Rhubarb said:



	

		Pinging google isn't always the best test of a system - transfer rates are more useful. Are you getting close to your rated speed (as per your ISP)?
	



When my connection isn't getting dropped as a result of said excessive ping times, yes.
	1 hour ago, Rhubarb said:



	

		If so, then worrying about a ping time is pointless.
	



I disagree.

 

As I have already told you, the BitComet client is causing disconnects from my work-from-home meetings, so with all due respect, I think the fact that I can pinpoint and isolate the source of the problem to the BitComet client is a HUGE problem, and therefore; NOT pointless as you have stated here.
	1 hour ago, Rhubarb said:



	

		On the other hand, if your rates can't come close to the 'maximum' (and please note that ISPs tend to measure in bits per second and not bytes)  and they alway quote the 'maximum' possible rate (and point out that they don't guarantee you'll get that - all they really say is you won't get any faster)
	



The transfer rate is not the problem.

 

The problem is that the ping times have increased by **TWO ORDERS OF MAGNITUDE** as a direct, and measurable result of using the BitComet client.

 

Thank you for your help anyways.

 

I appreciate you taking your time to try and help me with this issue that I am seeing/experiencing with said BitComet client.

 

Thank you.

You realise I trust that if this was a problem with Bitcomet, this thread would be full of ‘me too’ posts.

As I said, I run BC and I don't have anything like the problem you are experiencing which would suggest there is a vast difference between the settings on the two computers. Did you try with BC running in 'devault' mode? Try a clean install (perhaps try Revo uninstaller in moderate mode after saving your database) and re-installing. If the problem is still there (no uploads or downloads running) then the problem lies elsewhere. If it doesn't re-occur,check your settings
	11 hours ago, Rhubarb said:



	

		You realise I trust that if this was a problem with Bitcomet, this thread would be full of 'me too' posts.
	



Yes, I know, because this is what you wrote on in the other thread about the SAME topic as well. In other words, this **IS** the "me too" post and your response to said "me too" post is literally a circular reference/statement that you also posted on the other thread as well.

 

I bet that this is how you deal with ALL criticisms and ALL problems that people are reporting about the BitComet client.

 

This type of response is a denialism about the actual, MEASURABLE problem that the BitComet client causes that you are completely ignoring and not even remotely attempting to help in any meaningful way at all.

 

You're trying to tell me that the BitComet client offers NO debug information or verbose logging information that provides developers with debug information in regards to HOW said BitComet client is making its connections?

 

I find that INCREDIBLY difficult to believe or that the BitComet client just sucks in regards to the fact that there are NO debugging/verbose logging information in order to help the developers diagnose connection issues related to the BitComet client.

 

That's just pure, utter stupidity.

 

This is further compounded by the fact that the proposed solutions that you are offering: a) depends SOLELY on your ability to replicate the problem (which is a statistical impossibility, by your own admission, because you're not running the EXACT same hardware/software/networking stack in the SAME geophysical manner with the SAME geophysical constraints and limitations that regional differences may have, provide, or create). That is, again sheer, utter stupidity because you will probably NEVER be able to replicate 99% of the problems that **other** people encounter, and if your solution **depends** on your ability to replicate the issue, then you will **never** be able to solve said 99% of the problems with the BitComet client. The fact that you haven't built in a mechanism to be able to help **other** people diagnose their problems with debugging information and/or verbose logging is a **massive** oversight on the part of the developers. b) You have thrown out ideas and all of the ideas LITERALLY ignore the actual data that I have provided to you.



You argue that the use of a Bittorrent client such as BitComet will increase the network load (which I don't disagree with), and then you argue that the ping times would be expected to increase.



However, I have provided the data and the evidence which shows that the ping times increased by a little over **TWO ORDERS of MAGNITUDE**, and then when I explicitly asked you as to whether this was your E(X), you have refused to answer this question. And rather than actually trying to help me put the BitComet client into a debug mode or launch it from the command line with verbose logging information, you instead, then argue that looking at ping times is "pointless" and instead ask about the data rates/bandwidth speed of the connection instead.

 

But here's the thing about that - the data rates/bandwidth speed of the connection ISN'T the problem. The problem that the BitComet client is causing is that the increase in the ping times is a measure of the fact that packets are taking significantly longer to exit out of and return back to my network, which, as I've told you, is causing temporary connection issues on my work-from-home meetings that I am conducting.

 

NONE of your proposed solutions even remotely come close to addressing the problem that I am reporting to you, nor have you actually bothered to attempt to do so.

 

You keep throwing out solution proposals, hoping that one would eventually "stick" rather than actually systematically analysing the data in order to try and figure out WHY the ping times are MEASURABLY increasing by **TWO ORDERS of MAGNITUDE**.
	11 hours ago, Rhubarb said:



	

		As I said, I run BC and I don't have anything like the problem you are experiencing which would suggest there is a vast difference between the settings on the two computers
	



See (a) above.
	11 hours ago, Rhubarb said:



	

		Did you try with BC running in 'devault' mode?
	



Yes, already tried that. I'm always running in "default" mode.
	11 hours ago, Rhubarb said:



	

		Try a clean install (perhaps try Revo uninstaller in moderate mode after saving your database) and re-installing.
	



Already did that as well when the client was updated from version 1.77 to the latest 1.91.
	11 hours ago, Rhubarb said:



	

		If the problem is still there (no uploads or downloads running) then the problem lies elsewhere.
	



It lies with the BitComet client itself (and how it makes its connection) or at least that's what the problem looks like, on the surface, without addition logging information.

 

No other Bittorrent that I am currently running has this issue that I am seeing. Only the BitComet client has this issue.

 

Thanks.

two or three do not a ‘me too’ thread make. It’s when it starts to reach double figures that occurs.

When I suggested a clean install, I did mean remove everything using Revo first to take out all registry entries. Most 'uninstall' commands in a program leave bits behind.

Again, all I can say is that I can NOT duplicate your problem which suggests that there is a problem somewhere on your computer. It could well be a remnant of the original installation is still in the registry which is why I suggested using Revo
	On 7/14/2022 at 6:46 AM, Rhubarb said:



	

		two or three do not a 'me too' thread make. It's when it starts to reach double figures that occurs.
	



I understand the statistics, but I still think that you're missing the question here.
	On 7/14/2022 at 6:46 AM, Rhubarb said:



	

		When I suggested a clean install, I did mean remove everything using Revo first to take out all registry entries. Most 'uninstall' commands in a program leave bits behind.
	



I can certainly try that.
	On 7/14/2022 at 6:46 AM, Rhubarb said:



	

		Again, all I can say is that I can NOT duplicate your problem which suggests that there is a problem somewhere on your computer
	



...OR the client itself given that no one (you) really seems to know how the client makes its connections, which is why it shows up in the statistics, which results in the problem.

 

If you depend on being able to replicate a problem, there are a LOT of problems that you CAN'T replicate in the world, and yet, that doesn't mean that you can't solve it/find solutions for it neither.

 

This is where debugging and/or verbose logging information is supposed to be designed such that it will provide you with the information you need to help decipher what's going on, but it would appear that no one really seems to be able to tell me how to enable verbose logging information for when the client makes its connection; and there is a real possibility that this verbose logging information might not even be available/possible with the BitComet client, which seems really silly to me.

 

I'll try using Revo to completely uninstall the client and then install it again and see if this problem still exists or not.

 

Thanks.

There is no ‘bug’ to be debugged. - No-one else seems to have the problem.

Bugs affect EVERYONE and are either caught in beta testing or, if missed, with a plethora of posts complaining about it. So far, you are the only one affected

You could also try reducing your transfer rates and see if that makes a difference. Also try pinging a different address
	On 7/17/2022 at 1:33 AM, Rhubarb said:



	

		There is no 'bug' to be debugged. - No-one else seems to have the problem.
	



That's patently false.

 

I literally found this forum because of the other thread.

 

I don't know why you insist on ignoring the data that's being presented to you, but that's precisely what you're doing.
	On 7/17/2022 at 1:33 AM, Rhubarb said:



	

		Bugs affect EVERYONE and are either caught in beta testing or, if missed, with a plethora of posts complaining about it.
	



Also patently false.

 

If you literally open ANY bug tracker (e.g. [https://bugzilla.kernel.org/buglist.cgi?component=Network&product=Drivers&resolution=---](https://bugzilla.kernel.org/buglist.cgi?component=Network&product=Drivers&resolution=---)), you can LITERALLY see that the bug reports does NOT need to be replicated by OTHER PEOPLE, all it asks for is "steps to reproduce the error/bug" when you file said bug report. (Take this random example for instance: [https://bugzilla.kernel.org/show_bug.cgi?id=42856)](https://bugzilla.kernel.org/show_bug.cgi?id=42856)

 

(In the instance shown above, only TWO people reported said bug, and it was fixed by a commit posted by a Broadcom developer here: [https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5250def1935443f4bbddce101281e0aaf2e66838)](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5250def1935443f4bbddce101281e0aaf2e66838)

 

You are the ONLY person here that PERSONALLY requests to be able to replicate every single issue before you would even consider it to be a bug and/or that you are looking for large sample size statistics and anything below that, you literally just ignore the problem and the data associated with the problem.

 

That's just sheer insanity.
	On 7/17/2022 at 1:33 AM, Rhubarb said:



	

		So far, you are the only one affected
	



Patently false.

 

See here:

/topic/12801842-bitcomet-makes-my-internet-packet-loss/?do=embed" style=“height:394px;max-width:502px;”>

You are LITERALLY, EXPLICITLY told here that as a result of the BitComet client, my work-from-home meetings are getting dropped and this is also further supported by the ACTUAL ping time data (which, again, you're electing to completely ignore) which shows a MEASURABLE increase in the number of packets dropped without the BitComet client running and WITH said BitComet client running, which again, you're also COMPLETELY ignoring.

 

In fact, in DIRECT contravention to your statement that I am the only person with this problem, user amarsi LITERALLY wrote this: "

/topic/12801842-bitcomet-makes-my-internet-packet-loss/?do=embed&comment=83387&embedComment=83387&embedDo=findComment" style=“height:298px;max-width:502px;”>

to which, your response was literally: "It's obviously not a common issue (or this thread would be full of 'me too' posts). "

 

In other words, I already KNEW that this was how you handled problems even BEFORE posting and reporting my issue/bug here.

 

You denial doesn't change the facts, whether it is mine, amarsi's, nor nam2lenh's.

 

Furthermore, trihard7 also wrote this in the other thread: "It's definitely problem with DHT, since i updated from 1.64 to 1.74. ( Never had this problem before, on the older version ) "

 

Therefore; your claims about how I'm the only one who has this problem is LITERALLY patently false, and yet, you continue to ignore/deny the fact that there are THREE  people who have already reported this issue to you previously and you ignored them EXACTLY *ad simile* to the way that you're trying to ignore me and my report of this issue, and at the end of the last thread, you didn't even bother responding to the last comment/reply that trihard7 wrote.
	On 7/17/2022 at 1:33 AM, Rhubarb said:



	

		You could also try reducing your transfer rates and see if that makes a difference.
	



No difference because the BitComet client is running with no active data transfers on the torrents themselves. 0 bytes in/0 bytes out.

 

You've already been told that it's NOT a bandwidth issue, but again, since you're ignoring everything else that you've been told anyways, I'm not surprised that you're ignoring this as well.
	On 7/17/2022 at 1:33 AM, Rhubarb said:



	

		Also try pinging a different address
	



Tried that as well. Same result.

 

If you're not going to even try to help the report of at least FOUR people (who actually took our time to report the bug to you), then why do you even bother having this forum in the first place?

 

If you're just going to ignore the data that I/we are presenting to you, then why bother responding to any of the forum posts at all?

 

BitComet used to be awesome. I've probably been using BitComet since at least ca. 2005 or so. (My rank is 96098.)

 

Now with the issues, and more importantly, with the way that you're responding to the reported issues and how you've completely botched the handling of said issues, it's complete rubbish. Time to move on to using some other client instead and ditch the BitComet client altogether.

You are referring to a post that was over a year old and was using, even then, an out of date version (1.71). One had a problem with LAN configuration and the other had a tracker problem. Neither of the two came back to report that the fault still existed

It is NOT the same problem - one refers to download speed and the other to an intermittent connection - NOT ping times

The number of BC users is over 100,000 - not half a dozen so it is obvious that BitComet is NOT the problem - the problem is in your settings. A 'me too' thread normally is well into double figures and all close together in dates and using the same version - not a handful from over a year ago using a different version.

Oh and if you are tossing round 'rank' - mine is 2466
	On 7/18/2022 at 5:39 AM, Rhubarb said:



	

		You are referring to a post that was over a year old and was using, even then, an out of date version (1.71). One had a problem with LAN configuration and the other had a tracker problem. Neither of the two came back to report that the fault still existed
	



That **doesn't** answer my point.

 

You stated, quote "No-one else seems to have the problem."

 

And yet, when I googled this issue, those were LITERALLY the threads that google found which is what brought me to this forum in the first place.

 

I don't know why you are CONSTANTLY living in denialism when, in fact, you are EXPLICITLY told that the BitComet client **has problems** **with connectivity**, which IS this issue.

 

If you want to live in denial whereby you are literally told, **explicitly** that the BitComet client has a problem, and you want to **ignore** the data, as you have already shown that that's your *modi operandi*, that's your business. But it is patently and **explicitly** false to say that no one else has issues with said BitComet client.

 

A simple search on your own forums for this taxonomy of issue reveals **multiple** threads talking about connectivity issues with said BitComet client and you have repeatedly try to make excuses for them rather than actually trying to fix or solve said issues.

 

This **is** the reality and the truth of the situation.

 

In fact, I *found* the expert/advanced mode with no help and no thanks to you.

 

Again, you're clearly **not** interested in fixing the problem nor solving the issue.

 

Every one of those threads is denial, denial, denial.

 

And at least in one of those three additional threads that I have cited, your response to the report of an issue is LITERALLY identical to your response here:

(paraphrase) "If this was an issue, there would be lots of "me too" threads about it." As if that's supposed to be some kind of a metric for you to hit before you would actually do something about it.
	On 7/18/2022 at 5:39 AM, Rhubarb said:



	

		and the other to an intermittent connection - NOT ping times
	



I have again, **explicitly** TOLD you about the BitComet client CAUSING intermittent connection issues [here](/topic/12802501-bitcomet-causing-excessive-ping-times/?do=findComment&comment=84885).

 

And the reason why I KNOW that the BitComet client is the root cause of the problem is provided in the ping data that you have **continued to ignore** rather than analyze/process [here](/topic/12802501-bitcomet-causing-excessive-ping-times/?do=findComment&comment=84872) and [here](/topic/12802501-bitcomet-causing-excessive-ping-times/?do=findComment&comment=84885). And I KNOW that you have been ignoring the data because the forums here provides a download counter for how many times the attachments have been downloaded and I KNOW for a **fact** that you have download the second ping time file **ZERO times**.

 

In other words, given the sum of all of the data and the evidence that I have presented to you, the data and analytics and information that this forum provides, also further provides additional data/evidence which confirms my hypothesis that once again, you are more interested in bitching about reports of problems (as shown above) rather than actually **fixing** it. Prove me wrong.

 

You can't.
	On 7/18/2022 at 5:39 AM, Rhubarb said:



	

		The number of BC users is over 100,000 - not half a dozen so it is obvious that BitComet is NOT the problem - the problem is in your settings. A 'me too' thread normally is well into double figures and all close together in dates and using the same version - not a handful from over a year ago using a different version.
	



Your claim is that a "me too" thread **doesn't exist**.

 

And as I have proved, it most certainly **does** exist.

 

Your denialism doesn't change that fact.

 

Think about it: how the f*** do you think that I found out that the BitComet client was causing a problem in the first place?

 

I measure the ping times continuously in order to be able to define and measure and analyze (which are the first three steps in [six sigma statistics](https://en.wikipedia.org/wiki/Six_Sigma#Methodologies)) in order to be able to not only conclusively and repeatedly demonstrate that the BitComet client is the cause of the problem, but also the nature and the severity of the problem.

 

You have attempted to argue or make excuses for the BitComet client behaviour quite literally for the past month now, by arguing that using the client will increase network load. But when I interrogated you as to whether you should **expect** an almost **122x** increase, you have **repeatedly and continuously refused** to answer this question, and rather, chose to ignore it.

 

You can b**** all you want about this report of this problem with the BitComet client just like you did in the other thread where you similarly complained about the **lack** of "me too" threads, as if that's supposed to be some kind of a metric that you are **actually** aiming for before you'll actually work on addressing problem. What's your threshold? 1,000 me-too threads? 10,000? 100,000???

 

You again, claim that the BitComet client is **not** the problem, and yet, based on the data that you have **never bothered to look at**, it definitively and conclusively shows that the Bitcomet client **is** the problem.

 

You claim that the Bitcomet Client is **not** the problem. How would you even know that if you've **never** bothered to look at the data?

 

And I can also further prove that the BitComet client **is** the problem because ever since I posted this thread and your **refusal** to actually try and help solve the problem (given the fact that you don't even recognise that it's a problem in the first place), I've stopped using the BitComet client completely and I've been using something else instead and so far, I've had **zero** dropped or missed calls/meetings as a result of running my new Bittorrent client that **isn't** the BitComet client.

 

That tells me that this issue **is** caused by the BitComet client, which again, you have **contiuously refused to acknowledge that there's even a problem**, despite the fact that MULTIPLE people have **told** you about it.

 

Your claim was that the "me too" threads **don't exist**.

 

And as I have proven, **they most certainly exist.**

 

And instead of fixing the issue, you spend your time **bitching** about the existence of those threads or try and argue how these are related/connected when that's literally **how** I found this forum via a google search of the same, in the first place. (which, oh by the way, if you search these forums for **ping times**, that's how I found those other threads as well). Even your own forum system tells you that there's a problem because you can **literally** run a search against the term "ping times" and those are the threads that **your own forum** will report back in the search results. How do you think I found those other threads?
	On 7/18/2022 at 5:39 AM, Rhubarb said:



	

		Oh and if you are tossing round 'rank' - mine is 2466
	



The point of the rank is to show that I have been a long time user of the BitComet client, but clearly, you don't give a f*** about that.

 

Like I said, the conclusion that I am left to draw here are:



1) You have no interest in helping people fix the problems that they are experiencing with the BitComet client.

 

2) You continue to deny and argue against data that you refuse to download, and analyze anyways whilst citing all sorts of logical fallacies ranging from *ad hominem* attacks to* **strawman* logical fallacies, to your employment of the ancedotal logical fallacy, etc., etc. etc.

 

3) You argue that the increase in traffic is to be expected. When asked if the increase should be on the order of about 2.08 magnitude increase (i.e. almost 122x, you have refused to answer that question).

 

4) You have NEVER bothered to download the data that has been provided to you in order for you to actually look at, and investigate to try and help resolve this problem.

 

5) You can't explain how the BitComet client actually connects to the DHT network and/or if that may play a role in why these connectivity issues exist.

 

6) No thanks to you, I was the one who was able to find how to put the BitComet client into the advanced/expert mode, and to enable verbose logging so that maybe, there might be additional connection diagnostic information that would be echoed into the logs so that I can try and send that to you to help me figure out what's going on with the BitComet client. But once again, you're not interested in actually helping people fix the problems with the BitComet client. You are, instead, only interested in bitching about people who report bugs about the BitComet client, as you have **explicitly** demonstrated above.

 

7) You argue: "if this was a problem with Bitcomet, this thread would be full of 'me too' posts. " and yet, I have LITERALLY proven to you of the existence of said "me too" threads, and the type of a response is LITERALLY identical to the response that you gave here:

/topic/12801842-bitcomet-makes-my-internet-packet-loss/?do=embed&comment=83388&embedComment=83388&embedDo=findComment" style=“height:298px;max-width:502px;”>

So, given the above, the natural conclusion that I can draw, based on the data that has been presented is that the BitComet client has gone to s*** and should be decommissioned immediately.

 

It's f****** garbage software, and what's even worse, is that the support that you've "given"/"provided" is what **actually** makes it worse cuz you **clearly** don't give a f*** if people are using the BitComet client or not.

 

If you want to piss away your user base like that, that's fine.

 

If you want to piss off your users so that people will no longer want to use the BitComet client anymore in favour of something else that's better, or at least have better support -- that's fine.

 

Again, then what the f*** are you doing here if that's the case (if you're just here to b****, rather than offer any, meaningful help/assistance cuz you clearly don't give a f*** about trying to fix problems. So what the f*** **are** you here for besides just to b**** and practice your denialism?)

You7 ijnhsist on flogging a dead horse. THERE IS NO BUG

YOU are having a problem - if others were having it then THIS thread would have more than yourself posting to it. You have dragegd up very old posts (all two of them) from other versions and are not even the same problem.

Any support person will try to duplicate a reported fault to find out how serious it is. If they can NOT duplicate it, then the problem lies elsewhere. For your information, I have tried various permutations in the app 'options' in an effort v to replicate yuor issue - NOT ONE OF THOSE CAUSED A PROBLEM EVEN REMOTELY SIMILAR

The ONLY conclusion is that the problem is NOT in BitComet but something in your computer settings
	On 8/12/2022 at 5:35 AM, Rhubarb said:



	

		You7 ijnhsist on flogging a dead horse. THERE IS NO BUG
	



You LITERALLY have no data nor evidence to prove that.
	On 8/12/2022 at 5:35 AM, Rhubarb said:



	

		YOU are having a problem - if others were having it then THIS thread would have more than yourself posting to it.
	



They did.



You are choosing to ignore it and/or you are responding to it in EXACTLY the same manner as you did in the other posts/threads, which is to say, denial.

Even THEY have presented to you data and evidence that supports the fact that there IS a problem with the BitComet client whereas you have provided ZERO data and ZERO evidence to support your rebuttal/claims.
	On 8/12/2022 at 5:35 AM, Rhubarb said:



	

		Any support person will try to duplicate a reported fault to find out how serious it is. If they can NOT duplicate it, then the problem lies elsewhere. For your information, I have tried various permutations in the app 'options' in an effort v to replicate yuor issue - NOT ONE OF THOSE CAUSED A PROBLEM EVEN REMOTELY SIMILAR
	



OOORRRR......you will enable verbose debug logging in the client, so that you can parse the logs to see what's going on with the client when it is trying to make a connection, so that it will provide developers with the information about what the client is doing.

 

How do you think that bugzilla.kernel.org works???

 

It's idiotic to REQUIRE that you would need to be able to REPLICATE the issue with EXACTLY the same hardware and EXACTLY the same settings in order for you to be able to diagnose and/or solve an issue.

 

To date, you have not told me how to enable verbose logging which will show additional debugging information as to what EXACTLY happens when the BitComet client tries to initiate a connection and/or connect to the DHT network.

 

Even in Expert/Advanced mode, all it will say is that it is trying to made a connection (to the DHT network), but it doesn't tell you HOW it is trying to do that, and therefore; if there are problems during that part of the connecting process, you would never know, because the BitComet client itself CANNOT provide verbose debugging information like EVERY. OTHER. PROGRAM is able to.

 

It's completely idiotic to be able to assume that you would have IDENTICAL hardware and software settings/environment to be able to REPLICATE issues that are reported to the dev team. That's a moronic assumption to make, because the number of hardware/software/environment combinations would be impractical to replicate EVERY SINGLE combination that can exist, out in the wild.

 

That's just dumb.
	On 8/12/2022 at 5:35 AM, Rhubarb said:



	

		The ONLY conclusion is that the problem is NOT in BitComet but something in your computer settings
	



You literally have NO data to prove this.

 

Whereas, I have already provided the data which PROVES the opposite - I don't have the BitComet client running, my average ping times are in the sub-11 ms range.

 

With the BitComet client running, that average ping times INCREASES to around 1350 ms.

 

You said that you would expect the ping times to increase with a higher network load.

 

What you have FAILED to answer for is whether your E(X) is almost ONE HUNDRED AND TWENTY-TWO **TIMES higher** with the BitComet client running vs. without.

 

So far, you continue to argue that it has something to do with my computer settings, but you haven't been able to provide and proof of that.

 

NO other application does this with my combination of hardware/software/environment settings.

 

The ONLY piece of software that has a problem with it is the BitComet client.

 

If there was another software that exhibits the same problem, I would be inclined to agree with you.

 

But the fact of the matter is that I can LITERALLY **measure** the effects of BitComet starting up, on my network, vs. when I *don't* have BitComet running.

 

Therefore; unless you can actually provide the proof that it's in the settings, and NOT BitComet, the proof that I have supplied, still points to BitComet being the problem. You have FAILED to explain provide the proof to support your claims that BitComet ISN'T the problem whereas I have already supplied the proof that BitComet ***is*** the problem.

 

You can argue with me all you want, but you can't argue with the data that you STILL haven't bothered to download nor look at. It's all in the data if you had actually *bothered* to look at the data, which to date, you still haven't.

 

How stupid do you have to be to try and argue against data when you have presented none? LOL.....

 

You want to argue that it something to do with my computer settings (which literally NO other application has been affected), and it has NOTHING to do with the BitComet client?

 

Prove it then.

 

Show me your data.

There is no point in continuing this. Youb are adamant thgat the fault just HAS to be BitComet, despite the fact that OU are the only one suffering this mysterious problem of a ping time; NO-ONE ELSE IS REPORTING IT

I have tried (and failed) to replicate it - I can't provide 'ptroof' as there is NO evidence of a fault

The ONLY inference is that there is a bug in **YOUR **system causing it

I haven’t reviewed the full exchange yet, but from the discription offered I think you are overworking your computer or router. Bitcomet is a lot more than just a bittorrent client and you are running 3 clients each of which with hundreds or thousands of connection each cycle, then you also have the other functions available only in bitcomet. You can disable all the aditional functions and make it just a bittorrent client, it would be as good as any other client, but not exceptional but the choice is yours. Just keep in mind that some of bitcomet’s advanced features like Long Term seedingare coded to not use bandwidth when resources are low so this could be it’s designed function. I suggest try running bitcomet by itself, it will use more cpu time if it’s not forced to throttle, but won’t use more than is available. Same with bandwidth.

Check what it can do when you give it all the resources it needs. You may find a torrent that has been dead for a long time finally finishes for everyone because you joined with bitcomet. You may also see high speed servers to help you speed up the torrent for other users. Or if you want it to run with less processes and less connections then disable the items in "services" category and it will do only bittorrent.