BitComet causing excessive ping times

[gamma754293]

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 and here, 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 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

Edited July 10, 2022 by gamma754293 (see edit history)

[gamma754293]

*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).

Edited July 11, 2022 by gamma754293 (see edit history)

[Rhubarb]

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

[gamma754293]

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

[Rhubarb]

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.

[gamma754293]

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.

[Rhubarb]

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)

[gamma754293]

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.

[Rhubarb]

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

[gamma754293]

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.

Edited July 14, 2022 by gamma754293 (see edit history)

[Rhubarb]

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

[gamma754293]

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.

[Rhubarb]

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

[gamma754293]

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=---), 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)

 

(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)

 

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:

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: "

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.

[Rhubarb]

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

[gamma754293]

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.

 

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 and here. 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) 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:

 

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?)

 

[Rhubarb]

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

 

[gamma754293]

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.

Edited August 15, 2022 by gamma754293 (see edit history)

[Rhubarb]

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

[The UnUsual Suspect]

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. 

[gamma754293]

On 8/15/2022 at 3:34 AM, Rhubarb said:

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 don't know why you keep ignoring the data.

 

I am NOT the only person who is reporting it.

 

And frankly, I don't even know why you keep harping about that instead of ACTUALLY fixing the problem rather than bitching about that the problem exists.

 

You have consistently been more focused on the existence of the problem rather than actually fixing or even remotely attempting to fix the problem.

 

Stop bitching about the existence of the problem and/or the frequency of it.

 

This is a part of the reason why BitComet has gone to s***. Rather than fixing problems as they come up, you've spent significantly more time bitching about it instead of actually fixing it, or doing anything that's remotely close to trying to find the root cause of the issue at hand.

 

On 8/15/2022 at 3:34 AM, Rhubarb said:

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

As I said, that's absolutely stupid given that you cannot replicate every single hardware combination and every single software configuration in every single deployment environment.

 

Again, I don't know why you insist on being able to replicate an issue as a prerequisite to you being able to try and fix it. If the BitComet client is written so poorly that you haven't enabled the capability for the software to produce connection logs so that you would be able to "see" what the client is trying to do when it is trying to initiate a connection, then it's a piece-of-s*** software.

 

That's like BASIC debugging tools that you would allow for verbose logging so that you would be able to probe what is the software doing or trying to do when it is trying to establish a connection. It is neither my fault nor my responsibility that the BitComet client is a piece-of-s*** software that was developed so poorly that you literally cannot answer the question "what is the software doing or trying to do?" when it is trying to establish a connection.

 

It's a simple, basic question to ask, and it ought to be a basic, simple question that the software should be able to provide verbose logging data/information to answer that question.

 

Apparently, the BitComet client was NEVER developed to be able to answer BASIC questions about it's functions and operation.

 

That's just absolutely stupid and completely insane. What kind of a f****** dev wouldn't write that into the client so that if and/or when connection issues arise like this, that you would be able to enable verbose debug logging so that you can actually see what's going on with what the software is doing and/or trying to do?

 

I'm not a software developer and even I know that. That's pathetic.

 

On 8/15/2022 at 3:34 AM, Rhubarb said:

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

And yet, you have still failed to provide any data or evidence that would lead you to this conclusion.

 

You are just saying that because then you can ignore the problem that's been reported to you and rather than actually fixing it, you're going to blame it on the user instead.

 

This is the second part of the reason why the BitComet client has gone to s***.

 

So f****** dumb.

[gamma754293]

10 hours ago, The UnUsual Suspect said:

I haven't reviewed the full exchange yet, but from the discription offered I think you are overworking your computer or router.

Where is the evidence that you have which would even remotely point you to or suggest that?

 

I am running four routers, and they are load-balanced against each other in a 2x2 configuration (tier one is 2 routers that are load balanced between each other and tier 2 are the other two routers that are also load-balanced against each other).

 

The BitComet client runs on tier 2.

 

The ping time tests are measured on tier 1.

 

Whenever I start the BitComet client on tier 2, the measured ping times on tier 1 INCREASES by a factor of ~122x.

 

I can't think of any circumstance where this should a) be happening and b) should be ALLOWED to happen, can you?

 

10 hours ago, The UnUsual Suspect said:

You can disable all the aditional functions and make it just a bittorrent client

I've done that and this issue still exists.

 

10 hours ago, The UnUsual Suspect said:

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've disabled long term seeding (or as much as the software will let me) and the issue (which should have never existed in the first place) still persists.

 

10 hours ago, The UnUsual Suspect said:

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. 

I'm running it on an AMD Ryzen 9 5900HX so there should be no limitations from the CPU.

 

There's no throttling set up/configured/defined. It is allowed to run at full, line speed.

 

This isn't a bandwidth issue.

 

This increase in ping times occurs IMMEDIATELY, with NO traffic going through BitComet.

 

I've tested it with no tasks listed and it still increases the ping times from without the BitComet client running to with the BitComet client running by a factor of ~122x.

 

That's just insanity.

 

@Rhubarb says that he would expect there to be an increase in network load as a result of running the BitComet client. But when I asked him whether he should expect a ~122x increase, he refuses to answer that question.

 

I can't understand, for the life of me, why anybody would allow any program to increase their ping times by a factor of ~122x.

 

10 hours ago, The UnUsual Suspect said:

Check what it can do when you give it all the resources it needs.

Already did that.

 

If BitComet is such a resource hog, that would be just another reason as to why people shouldn't use the BitComet client anymore.

 

(There is absolutely NO reason why BitComet needs an entire AMD Ryzen 9 5900HX 8-core, 16-thread CPU with 64 GB of DDR4-3200 unbuffered, unregistered RAM all to itself. That's insanity.)

 

If the BitComet client needs an 8-core/16-thread CPU that has an all core-boost of upto ~4.3 GHz, and 64 GB of RAM just to download torrents, then it's a piece-of-s*** software.

 

I have high-performance computing (HPC) applications that I use and run that doesn't even require that many system resources to run and it is doing work that's probably a LOT more complex and more complicated than downloading bittorrents.

 

To be able to give BitComet more resources than that would be to give it an AMD EPYC server CPU with 64-cores and 4 TB of registered, ECC RAM.

 

That's insane.

 

10 hours ago, The UnUsual Suspect said:

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. 

Again, already tried that.

 

It has no impact on the observed behaviour of the client on startup with respect to increasing ping times (or persistently causing ping times to skyrocket).

 

Again, I am running two other different clients on different systems and NEITHER of those two other clients causes this problem.

 

The BitComet client is the ONLY one that causes this client.

And before you ask, yes, I have already tested this by shutting down the other two bittorrent clients as well and the BitComet client STILL produces the same result of an increase in ping times by a factor of ~122x.

 

Running with the other two clients and without the BitComet client, this problem doesn't happen/exist.

 

This problem exists ONLY when the BitComet client is starting up and/or running.

Edited August 21, 2022 by gamma754293 (see edit history)

[Rhubarb]

Why do you keep insisting that others have the problem? NO-ONE ELSE HAS POSTED A 'ME TOO' on this thread

You are demanding 'proof' that I can't replicate the problem. Are you calling me a liar?

I repeat YO U are the only person having this issue but you can't seem to see that it's more than probable that it's an issue on YOUR system - not sitting in your chair I can't say what it is. I've tried on two different computers to replicate - I can't

Obviously you are going to  continue worrying this like a dog with a bone - however, I do have a life to live so I simply will ignore any more posts here

[The UnUsual Suspect]

If we could reproduce your problem we would prepare a report for development. Unfortunately we cannot, nor is anyone being paid to do this for you. Of course you can contact development directly, they may or may not respond. It would probably help if you are fluent in Mandarin, but even if they do decide to investigate they would also need to reproduce the problem. 

Perhaps you can discover what is triggering this behavior you report? if you can find  whatever causes it to happen and provide the data so development can reproduce we will put our weight behind it, but until we can provide them some useful info we need more than a single report that bitcomet has slow response times when coexisting with two other clients on the same machine. 

Keep in mind this is freeware and the only support available is from users who volunteer. Please be sure to thank anyone who helped or attempted to help. 

[gamma754293]

22 hours ago, Rhubarb said:

Why do you keep insisting that others have the problem? NO-ONE ELSE HAS POSTED A 'ME TOO' on this thread

...as you ignore the other threads that I've already cited, which is how I found this forum in the first place, when I googled this issue. (How do you think I found this forum in the first place?)

lol....

 

 

22 hours ago, Rhubarb said:

You are demanding 'proof' that I can't replicate the problem. Are you calling me a liar?

You've already explicitly stated that you can't replicate this problem here:


 

On 8/15/2022 at 3:34 AM, Rhubarb said:

I have tried (and failed) to replicate it

I don't need to call you a liar. You've explicitly stated that you can't replicate the problem.

 

It's a simple question that the software should be able to answer: "when you start up the BitComet client and it tries to initiate a connection, what happens? What does the software do or tries to do?"

 

Right now, there is no option for verbose logging information that will be able to provide enough data to answer that question (because if there was, you would have already told me how to put the BitComet client into that mode, so that it will generate the logs necessary, and then ask me to send you those logs so that you would be able to parse through them to see what's going on , when the BitComet client is starting up and as it is trying to make said connection).

 

If the software already had the capabilities to answer this very simple, basic question, you would've already told me about it by now.

 

Given the fact that you haven't, therefore; I can only conclude that the software does not have this capability built into it, which is just absolutely ridiculous.

 

Just about every piece of software I've ever used has some kind of super secret software debug mode that you can put the software into because the devs used it when they were developing the software to begin with, and they used that for the dev's own internal purposes and then not tell anybody that said debug mode exists when they release the software publicly, unless someone's experiencing a problem with it, as it is the case here.

 

22 hours ago, Rhubarb said:

I repeat YO U are the only person having this issue but you can't seem to see that it's more than probable that it's an issue on YOUR system - not sitting in your chair I can't say what it is. I've tried on two different computers to replicate - I can't

Obviously you are going to  continue worrying this like a dog with a bone - however, I do have a life to live so I simply will ignore any more posts here

And as I've said, it's stupid that you think that being able to replicate a problem is a prerequisite to be able to solve/fix it. Just because something isn't happening to you, doesn't mean that it isn't happening to someone else. That's such a stupid way to deal with problems.

 

Is that how you handle problems in life? If you can't replicate it, then therefore; according to you, that problem doesn't exist??? So f****** dumb.

 

20 hours ago, The UnUsual Suspect said:

Perhaps you can discover what is triggering this behavior you report? if you can find  whatever causes it to happen and provide the data so development can reproduce we will put our weight behind it, but until we can provide them some useful info we need more than a single report that bitcomet has slow response times when coexisting with two other clients on the same machine. 

1) I've tried putting the BitComet client into the like "advanced" or "expert" mode with verbose logging information enabled (at least through the GUI) and it doesn't really say much other than that it's trying to initiate a connection, but then wouldn't provide any details about how it is trying to go about, initiating said connection.

 

2) I've ran the test WITHOUT the other clients running as well, and the absence or existence of the other two clients has no bearing on BitComet's behaviours as measured by the ping times between BEFORE I started said BitComet client vs. whilst the BitComet client was starting vs. after the BitComet client had started.

 

The ping times is my "dumb", "idiots" way of measuring what happens without having to bust out Wireshark.

 

I came here trying to see if there was some other "advanced advanced" debugging/logging information that the software might be otherwise capable of, so that I can try and get as much information about how the BitComet client is trying to make a connection (that will result in the ping times increasing by ~122x). As I mentioned, thanks to no help from @Rhubarb, I managed to google how to put the BitComet client into that mode myself (given the fact that throughout this entire thread, he has just continually denied that the problem that I can prove, based on the ping data that has already been provided as the observed, resulting behaviour, which is what starts the root-cause analysis), so that I can try and see if I would actually be able to get/make the BitComet client write out or dump out more debugging/verbose logging information than would otherwise be normally available, to try and perform said root-cause analysis.

 

I looked at the advanced logs. It just says that it is going to try and make a connection, but it doesn't tell me how it attempts to do so.

 

If I can at least gleen that, then maybe I can start figuring out if there is some kind of a conflict between the software, how it is configured, and/or how the routers have been configured (especially given the two layers/tiers of load balancing that's running in between them). But neither router should be overloaded any more than any other. If the DHT is causing that, then it should probably be investigated as to why or what happened that caused the DHT to increase the network load by 2.08 orders of magnitude.

 

20 hours ago, The UnUsual Suspect said:

Please be sure to thank anyone who helped or attempted to help. 

Well, that's the key, operative phrase: attempted to help.

 

Denialism is not an attempt to help.

 

Having put in place the prerequisite that he needs to be able to replicate the issue before being able to start the root-cause analysis is not really an attempt to help neither (because if he can't replicate the issue, then he won't be able to help, which is precisely what happened here.) It doesn't make the problem go away. It just means that in order for people to be able to help, they have this prerequisite that they need to be able to replicate any and all issues first before being able to try to attempt to help. I will never understand why that is a pre-req given the fact that it is literally impossible to replicate every software/hardware combination that has been deployed in every single environment where it's been deployed. There's no way to be able to do that.

 

Therefore; the next, logical best thing would be to ask the software, when it is starting up: "what are you doing and/or trying to do?"

 

And have the software tell you the answer to that question, step-by-step:

 

"okay, I'm going to try and do this now."

 

"okay, that works (or it doesn't). Now I am going to try and do this other thing instead."

 

If we can't see what, and especially how the software is trying to establish a connection, then we will never be able to successfully conduct the root cause analysis because the software can't tell me what it is doing at, during, and after start-up.

 

And if I can't get the software to dump out that kind of a debugging/verbose logging information, then I won't be able to answer your remark:

20 hours ago, The UnUsual Suspect said:

if you can find  whatever causes it to happen

This is what I've been trying to do, or at least trying to find a fix for the apparent issue.

 

Sometimes, what I see as the end user (i.e. increase in ping times) might be caused by something that's entirely different.

 

But to an end user who's not a developer nor am I intimately involved with the development of the BitComet client software, there'd be no way for an end user to know what or how the software is doing what it is supposed to be doing.

 

And that's when I would first try to google the issue to see if: 1) someone else has experienced a similar problem before and 2) what did they do or attempt to do to try and fix/address said issue/problem?

 

And that's what I've tried from the forum posts that I found via google that are all threads from elsewhere on this forum.

 

And if nothing else seems to work, that's when I wrote this thread, only for it to be met with denialism by @Rhubarb or the demand that he places on it by imposing the prerequisite that he needs to be able to replicate the issue before he can try and help with it; vs. instructing me to tell me how to put the BitComet client into debug mode, and have it dump out extra verbose logging information so that @Rhubarb would be able to help parse the verbose logging information and be like "ahhh...okay. There is your issue, right there. You see on line...." (or he would be able to parse the debug logs and be like "I don't see anything that jumps out at me as being something wrong. After trying to strip down the setup, (which I've also tried where that's the ONLY thing that was running on my network and it was STILL producing this effect/observed behaviour), try this and see if that works for you.")

 

But that's not what he did/his general approach to problem solving. His approach is evident in the other forum posts as well, so his presentation of this approach isn't even a "one-off". This is how he solves problems: denial and/or imposing an impossible prerequisite.

 

That's like if your check engine light is on in your car, you take your car to a mechanic, and after asking them "why is my check engine light on?", they respond with "your check engine light is on" rather than the mechanic saying "plug in the code reader into the ODB-II port and tell me what it says" so that they can then look up the code to find out what it means, and therefore; what the mechanic should do about it.

 

From what I can gather, my BitComet client "put the check engine light on and threw a code", but the BitComet client lacks the tool and/or the ability to be able to plug the tool/code reader into it, so that we would be able to read what is the error/diagnostic message/code that the BitComet client is producing, and there's no "table" which tells you what that "code" means, and/or how to fix it.

 

That's what I'm gathering from this exchange.