Transmission hogging DNS lookup of Safari

[kanny]

Hello

In recent times, I have observed that Transmission slows-down internet based activities to a grinding halt. While transmission is running, if i try to surf the net using Safari, it seems the DNS lookup of a website is not completed and the progress bar stands still at the http:// prompt itself and mostly fails to load. Similar thing with iTunes podcast update, it results in "!" after a min of trying to get the IP address of the destination site. But when i quit Transmission, all the online activities move briskly without any problem.

Surprisingly all this while Transmission is neither downloading nor uploading anything virtually (1-4 kB/s). However, once in a while it kinda "cures" itself and everything comes to normal while Transmission is running full-throttle. So what's keeping ?

N.B. : I had written a nice and more elite description of the problem in a post, couldn't "save" or "submit" due to Transmission. It timed out and when reload, all my post was gone ! F****** freaks out. Please fix the "bug".

[Jordan]

There have been several changes in the nightly builds that should improve this behavior. Please download a nightly build and let us know if that makes things better, worse, or no change...

http://transmission.xpjets.com/

[stovelkor]

I have this problem too. While using Transmission (though this was happening a lot when I was using Azureus as well), I can't access websites or start any activity that requires an internet connection. It doesn't however affect an active connection that was established before I started D/U loading, like iChat.

[mezz]

I have this problem too. While using Transmission (though this was happening a lot when I was using Azureus as well), I can't access websites or start any activity that requires an internet connection. It doesn't however affect an active connection that was established before I started D/U loading, like iChat.

Did you read anything in here?

Beside of Transmission, since you are able to reproduce with Azureus. It's not a bug in Transmission. It's your internet connection, router or computer that can't handle the high load. You have to lower it.

[kanny]

I tried the latest Nightly r7019 today, but not any respite from the connection issue. Additionally i found this erroneous up/down load rates reporting:

While there is not any significant up/download going on as indicated by MenuMeters, the Transmission shows quite a bit. And i am aware of the "bug", where Transmission builds up the statistics and shows 0.0 kB/s for a while and then suddenly 50.0 kB/s and oscillating despite my capacity being 32kB/s which MenuMeters correctly reflects. In this particular instance, there was no such up/down going on but Transmission continuously shows wrong rates! May be a suggestion : there should be a time resolution preference over which to update the statistics instead of 1 sec default.

Now back to the original issue : My feeling is that Transmission is playing a kind of Gatekeeper to all ports of networking. So when it's busy it says "No, no mate, not now. Not until i am comfy. I am not gonna allow any of your ACKs out nor am i going to deliver ACKs coming in for you. So just chill out while i am busy with my business !"

That chilling means, Safari showing repeatedly "Page could not be found... because the server is not responding", iTunes podcasts update giving "exclamation marks" and Mail spinning around trying to send a mail but all failing. The wrong up/down load reported above could be one of the cause for Transmission to fool itself and the system to hog the networking resources.

The issue is mainly for getting the IP address as also reported by stovelkor. Once the connection is established, the up/down in Safari/iTunes/Mail goes fine so it is not that router is tired or something. And i don't think the tracker is involved in this either. Even the ISP bandwidth-shaping or so is not justified because once the connection is established it rocks. So dig deeper and figure out what's making this nice app into a nightmare ?

[Jordan]

I tried the latest Nightly r7019 today, but not any respite from the connection issue. Additionally i found this erroneous up/down load rates reporting:

While there is not any significant up/download going on as indicated by MenuMeters, the Transmission shows quite a bit.

This is because protocol overhead is now shown in that upper bar in the nightlies. Probably what's happening there is the peer is telling you that it's got a new piece available, or someone else is trying to handshake with you, etc. ... it's completely normal, so don't worry about it.

Now back to the original issue : My feeling is that Transmission is playing a kind of Gatekeeper to all ports of networking. So when it's busy it says "No, no mate, not now. Not until i am comfy. I am not gonna allow any of your ACKs out nor am i going to deliver ACKs coming in for you. So just chill out while i am busy with my business !"

Transmission doesn't have any means of acting as a gatekeeper. I'm not sure where you get the idea that it does, or can, do this.

[kanny]

One more thing. When i press Command-Q to quit Transmission, it is taking a lot of time to quit though there were no up/down load going on. My feeling is that it has a hard time to retract its tentacles spread over the networking resources ! Jordan, don't take it personally, it is just the feeling of frustration.

I quit Transmission to write the previous post to not lose the content again. And it got submitted like a splash. Then i started the Transmission and tried to log out of the forum, and as expected it timed out! But this post is submitted also in a splash while Transmission is running...

[pea]

I tried the latest Nightly r7019 today, but not any respite from the connection issue. Additionally i found this erroneous up/down load rates reporting:

While there is not any significant up/download going on as indicated by MenuMeters, the Transmission shows quite a bit.

This is because protocol overhead is now shown in that upper bar in the nightlies. Probably what's happening there is the peer is telling you that it's got a new piece available, or someone else is trying to handshake with you, etc. ... it's completely normal, so don't worry about it.

the bandwidth used by T (with or without protocol overhead, not matter) is subset of total (that's what Menumeter shows),
it can't be bigger than total..

the reasons for abovementioned behaviour can be:
a) MenuMeters lies (very unlikely - old and approved app)
b) MenuMeters is listening on other NIC than used by T (that can affirm or deny by OP)
c) T lies
d) may be there can be more reasons, I just cant' imagine them right now..

[Jordan]

Hi pea_,

How large is MenuMeters' window? Transmission is showing the average over the last two seconds, with snapshots taken at intervals of a quarter-second.

[pea]

Menumeters have 2s default interval for network activity
and it is adjustable from 0.5 to 20s

probably kanny can tell what is used in his case


(I'm not sure if Menumeters uses the same sample interval as its window size or is it smaller)

this is how that tools interface looks like:
(JFYI)

[kanny]

I have set MenuMeters' Network display to update every 5 sec for a smoothing over possible spikes so in this case it is pretty much not up/down loading anything.

a) MenuMeters lies (very unlikely - old and approved app)

I have never found MenuMeters lying ... infact it has helped me catch 'thieves' like SoftwareUpdate or large Flash ads on reuters webpage in the past.

b) MenuMeters is listening on other NIC than used by T (that can affirm or deny by OP)

A distant possibility but highly unlikely.

c) T lies

This is because protocol overhead is now shown in that upper bar in the nightlies. Probably what's happening there is the peer is telling you that it's got a new piece available, or someone else is trying to handshake with you, etc. ...

I do not expect such a high protocol overload though that could be the reason for the overall network hogging. But T is definitely showing much more volatility in rates and probably a stretch too much for extrapolation from quarter sec observation ... So T lies probably. QED!

Btw i hope this gets posted even when T is going full-throttle right now to build the ratio

NB: preview took quite a bit of time..
NB2: submit didn't succeed .. lets try again ...

[pea]

b) MenuMeters is listening on other NIC than used by T (that can affirm or deny by OP)

A distant possibility but highly unlikely.

you can easily check it out from menu -
if you are unsure, just use "Display primary interface" (under the interface name submenu) as the safest way

I do not expect such a high protocol overload though that could be the reason for the overall network hogging.

that's not matter at all..
If we do suppose that MenuMeters shows correct values (and we have good reason to do so),
then any app separately can't use more than is the overall sum in NIC
(measured by MenuMeters in your case)

(there is absolutely no matter if app (like T) is including some overhead in calculations or whatsoever)

[pisselpasslet]

Apparently my first attempt didn't work, here we go again:

I had the same problem: when starting transmission all other internet applications just frooze. I fixed it by going into the broadband modems
setting (scientific atlanta something) and unchecked "IP flooding detection". I guess transmission creates a lot of "small traffic" which in its self isn´t
even close to your broadband limitations but causes this feature to strangle the traffic at some point.
Transmission is now back to the high data rates which I had before moving and changing internet provider, jipiiee!