Internet extremely slow in Gutsy/Intrepid after upgrade

Bug #155393 reported by Rob Pasell on 2007-10-21
Affects Status Importance Assigned to Milestone
linux (Ubuntu)

Bug Description

I did an upgrade in place from Feisty to Gutsy. After the upgrade browsing the Internet ha become extremely slow. I use both Firefox, and Swiftweasel browsers. I have tried a few of the suggestions from the Forums, but none have worked. I disabled IPv6 in both browsers. I also disabled IPv6 in the operating system using this procedure:

1. IPv6 is supported by default in Ubuntu and can sometimes cause problems.
2. To disable it, open a Terminal (Applications > Accessories > Terminal) and type the command: gksudo gedit /etc/modprobe.d/aliases.
3. Find the line alias net-pf-10 ipv6 and change it to read alias net-pf-10 off.
4. Reboot Ubuntu.

I also switched from the standard Network Manager to WiCD, but that didn't help either.

Rob Pasell (robpasell) wrote :

I added the OpenDNS entries to my router, and the speed has increased dramatically. I DO NOT consider this a fix, but a temporary solution, and hope you will continue to work the problem. It should not be necessary to make OpenDNS entries at the router to have functioning Internet after an upgrade.

Thanks for the time.

Rob Pasell (robpasell) wrote :

After more testing, this has only "fixed" the problem for my wireless connection. My wired connection is still extremely slow. I modified the DNS settings on my ISPs router (Actiontec from Qwest), and that did not help. It should also be noted that while the performance increased on my wireless connection, sites like take upwards of 7 minutes to fully render, and while rendering locks the browser. My wireless router is a Linksys WRT54GL running DD-WRT v2.3 SP1.

I think it is a serious problem with Gutsy , i didn't expect to have it with a new version of Ubuntu , it should be solved soon.
Thanks for the reporter and the Ubuntu stuff for there efforts and time.

repustech (info-repustech) wrote :

I too am having problems with slow network on Gustsy 7.10 (fresh install). In my case, it is only the wireless. It is slow for internet and local network transfers. I have tried updating the router firmware but that did not help. For now I'll just wait it out. My connection is usable thankfully, just slow. Lets hope they get this fixed soon.

Eli L (flclfan) wrote :

I also have this problem with a clean gutsy install. I'm using a wired connection and it takes 20+ seconds to load a new page. This is the only problem that is keeping me from moving fully to ubuntu. Feisty worked fine though.

I hope this gets fixed sometime soon.

repustech (info-repustech) wrote :

Just wanted to post the related forum link. There are quite a few people with this problem.

Vorik (launchpad-gerapeldoorn) wrote :

I've got the same problem unfortunately. Please provide a fix soon! The local LAN is very slow as well.

I cannot browse the internet at all, after upgrading to gutsy. Disabling IPv6 at Firefox solved the problem for it. I still can't use apt-get or any other application that needs internet. There seems to be a DNS resolving problem between Gutsy and my Router (Telindus 1132 ADSL Router). I have done all the things mentioned in several threads at, like changing to static IP, changing /etc/modprobe.d/aliases, blacklisting ipv6, changing Network Manager's dns... Issuing the command ip a | grep inet6, returns no results, which means that IPv6 is disabled, but still no internet.
Then I tried a different Router (Speedtouch) and everything worked fine from the beginning! I need to mention that I was using my Telindus Router with Feisty having no problems at all.

Eli L (flclfan) wrote :

I just want to see if theres any commonalities here. Is everyone who is getting this problem using ADSL?

AtApogee (atapogee) wrote :

I am using Comcast cable (not ADSL) 8M down, 1.5M up, and an old SMC 11b wireless router. Every other computer works fine. My "Ubuntu" laptop works find when running in Vista (so sad...), but when running Gutsy... OMG! (not to be overly dramatic or anything) it is soooo slooooowwww!!! It took me 20 minutes just to be able to post this comment. I haven't tried a wired connection, just wireless. The best rate I've seen is about 70Kbps moving a file from one computer to another on my private LAN - not even internet. In desperation, I will try some of the previous suggestions (disable IPv6, etc.) but there is something seriously bad going on here.
BTW - OpenDNS - what's that? I wonder if I can make that fix on my router, too... (SMC Barricade)?
Thanks to everyone working so hard at fixing this. I'll buy a beer (maybe even two!) for the first person with a real fix. :-)

Vorik (launchpad-gerapeldoorn) wrote :

Hi again, I'm not using ADSL on the computer with these troubles. In fact, I'm using it in a corporate environment which has several other Gutsy computers running smoothly. So this has probably something to do with my specific hardware and not the network components.
I'm working on a temporary laptop now in order to get any work done today... :S
I'll go try to boot using an older kernel or something; see if that helps.

Thanks again,

PS: If the Ubuntu-people want to contact me for troubleshooting or any further information, contact me trough email. (ubuntu at gerapeldoorn dot nl)

Vorik (launchpad-gerapeldoorn) wrote :

Hi again, I'm back at work and it seems to be working ok now. There were some other issues with the network that I was not aware of. It's likely that I'm not affected by this bug after all.

Sorry for the inconvenience.

I am using ADSL and a Telindus 1132 ADSL Router. Windows XP and Feisty are working fine with these.

repustech (info-repustech) wrote :

I have tried on Cable internet and DSL and they both seem to be slow. I think it is specific to the hardware on your system, probably not network related.

Thom Pischke (thom-pischke) wrote :

got bitten by this too. ADSL by Swisscom, Netopia Router. not sure which network card, since i'm not on that computer right now.

Network worked fine with feisty install, dirt-slow on gutsy. Disabling IPv6 everywhere fixed it.

Alex Feller (afeller) wrote :

Also on ADSL by Swisscom with Netopia Router. Disabling IPv6 helped only for the Web Browser. To get rid of the delays with other protocols like e.g. ssh I had to enter the two DNS servers used by the router (System-->Administration-->Network-->DNS)

I think there's enough people suffering from this that it can be made Confirmed in order to get someone looking at it. Even The Register has reported on it.

Can people with the problem please try and be as precise as possible with their descriptions. To help confirm DNS doesn't work with IPv6 follow test and try:

    dig AAAA
    dig A

at the command line. The first will time out if DNS IPv6 isn't working, the second should work fine. Is that what you're seeing?

Ralph Corderoy wrote:
> test and try:
> dig AAAA
> dig A
> at the command line. The first will time out if DNS IPv6 isn't working,
> the second should work fine. Is that what you're seeing?

No, both commands work without timing out. After trying this I
blacklisted ipv6 in /etc/modprobe.d/blacklist which solved the issue for
the webbrowser. But still delays when trying to establish connections
with ssh or sftp. To get this to work I had to reenter the DNS servers,
used by the router, in the network manager, as described in my last post.

Ralph Corderoy wrote:
> test and try:
> dig AAAA
> dig A
> at the command line. The first will time out if DNS IPv6 isn't working,
> the second should work fine. Is that what you're seeing?

Both commands worked fine on my computer.
I have a fresh installation of gutsy and haven't made any changes in any files or network configuration.
I have disabled IPv6 in Firefox (about:config), though, in order to keep in touch.

I also did what Matt Hartley suggests (blacklisting ipv6 and using OpenDNS) but neither worked. apt-get cannot resolve domain names.

I tried to ping some internet addresses and got some "interesting" results...

~$ping -c 3
PING ( 56(84) bytes of data.
64 bytes from ( icmp_seq=1 ttl=42 time=79.0 ms
64 bytes from ( icmp_seq=2 ttl=42 time=78.8 ms
64 bytes from ( icmp_seq=3 ttl=42 time=82.1 ms

--- ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 78.875/80.016/82.128/1.495 ms

~$ ping -c 3
PING ( 56(84) bytes of data.
64 bytes from ( icmp_seq=1 ttl=42 time=83.8 ms
64 bytes from ( icmp_seq=2 ttl=42 time=79.7 ms
64 bytes from ( icmp_seq=3 ttl=42 time=83.5 ms

--- ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 79.768/82.390/83.868/1.873 ms

~$ ping -c 3
PING ( 56(84) bytes of data.

--- ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2009ms

1) While I can ping and normally, I can't ping!!!

2) Why Synaptic Package Manager cannot download from the repositories, while I CAN ping

Sorry, but the last line of my previous post should be "..., while I CAN ping"

Michael, can you run tcpdump to display the network traffic on your outgoing interface and then attempt a ping to a never-tried-before host. E.g., my interface is ppp0 so `sudo tcpdump -i ppp0 -n' in one window and then `ping -c 3 -n' in another. The output should only be a few lines; the DNS request, the answer, and the ping echo and replies. Of course, if you haven't already got package tcpdump installed, this may be a bit of a problem.

Ralph, this is what I got from tcpdump:

s# sudo tcpdump -i eth0 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
12:26:38.709492 IP > R 3870392194:3870392194(0) ack 2423321366 win 0
12:26:38.722132 IP > R 985327083:985327083(0) ack 3398403930 win 0
12:26:43.701759 arp who-has tell
12:26:43.701832 arp reply is-at 00:c0:df:e3:7e:4b
12:27:12.175823 IP > 61781+ A? (32)
12:27:12.620649 IP > 61781 2/2/2 CNAME, (145)
12:27:12.621417 IP > ICMP echo request, id 19483, seq 1, length 64
12:27:12.794212 IP > ICMP echo reply, id 19483, seq 1, length 64
12:27:13.629662 IP > ICMP echo request, id 19483, seq 2, length 64
12:27:13.797589 IP > ICMP echo reply, id 19483, seq 2, length 64
12:27:14.628646 IP > ICMP echo request, id 19483, seq 3, length 64
12:27:14.798151 IP > ICMP echo reply, id 19483, seq 3, length 64

12 packets captured
12 packets received by filter
0 packets dropped by kernel

I think it worked fine. But hear this...
I changed the repositories, in order to download packages from only and it worked.
I changed the server from MAIN to GREEK Server and Package Manager (PM) couldn't resolve the address
Then I rolled back to MAIN Server. After that I CAN ping AND AND
After working with it for about an hour I downloaded updates normally from all repositories, although sometimes it freezes for a while and when I ping it resolves to again but only for a while.

My network is as simple as it gets, just a computer wired directly to my ADSL Router. So I can't imagine where all that mess comes from...

Michael, I assume you mean since doesn't exist for me either.

  $ host is an alias for has address

when I change to "Server for Greece" in the Software Sources window it starts looking up for addresses like
and when I try to ping sometimes it works sometimes it'not.

As I said before, my internet connection seemed to work perfectly, so I decided to do a Restart...
After that I am back to my previous state...
That is, while I CAN ping, e.t.c. I CAN'T download any packages!

> That is, while I CAN ping,
> e.t.c. I CAN'T download any packages!

All I can suggest for the moment is to see if tcpdump sheds any light on
what's going on, e.g. are the DNS replies not coming back, or are the
requests going to an odd address, whilst trying some of these things
that fail.

I tried 'sudo tcpdump -i eth0 -n' and at the same time I run Synaptic PM and hit the Reload button.
The attached tcpdump file shows the reply I got. It started at 22:18:01 and ended 2 minutes later by pressing the Cancel button, because the procedure couldn't go on.
The message I got from Synaptic PM, after canceling, is the usual:
Could not download all repository indexes

The repository might be no longer available or could not be contacted because of network problems. If available an older version of the failed index will be used. Otherwise the repository will be ignored. Check your network connection and the correct writing of the repository address in the preferences.

I hope all these comments make sense to you, coz I am lost!
I believe someone from Canonical needs to pay attention to this bug, as more and more persons seems to be affected, according to forums.

Alex Feller (afeller) on 2007-10-26
description: updated

Michael, thanks, that helps. You machine is issueing IPv6 AAAA address
queries and is sometimes getting back as an answer. It then
tries to contact this incorrect address. It's almost certainly the poor
implementation of a DNS server in your router not coping well with IPv6.
It has been triggered again by a regression in 7.10. See bug #156720
for where they think they've fixed it for 7.10 and for some notes
on how to get the fix.

I think that fix did the work. I just updated gutsy and seems to work fine.

Remind me to buy you an "Ouzo" when you come to Greece! :-)

Ohhh, I was wondering, is there any other way to install a fix other than update, because some people might not be able to fix such bugs as they don't have internet connection... because of the bug!
For example, I had to wait for a period to get my internet connection working in order to update.

Thanks again...

Thanks for the Ouzo!

> Ohhh, I was wondering, is there any other way to install a fix other
> than update, because some people might not be able to fix such bugs as
> they don't have internet connection... because of the bug! For example,
> I had to wait for a period to get my internet connection working in
> order to update.

I suppose what I'd try is to make sure /etc/host.conf includes "order
hosts,bind" which means /etc/hosts is searched before resorting to DNS
and then temporarily append the required hostnames and their IP
addresses to /etc/hosts, e.g.

However, I'm not running Gutsy and don't suffer the problem so I've not
tried this. Shouldn't do any harm though, and the lines can just be
deleted afterwards so DNS is used for them again.

Unfortunately the problem isn't solved in any case by upgrading the glib6 nor by disabling the IPV6 protocol I think.

I have access to two different ADSL networks, a slow (512 Kbps down/128 Kbps up) and a faster (8196 Kbps down/512Kbps up). On the faster there seems to be no problem at all, and on the slow the problem seems to exist. I use the same 2 laptops, with different Wireless NICs on both networks, and have used dual boot for testpurposes on both. On Gutsy the problem exists, but on the second operating system no problem is present, on any of the two networks.

On the slow network, using adept upgrading/downloading packages seems okay at first, but after a short time speed drops from 40-50 to nearly zero Kilo Bytes per second, and stayes there for a long time. Sometime the speed returnes to the high values (30-50 KBps) for a while again, but drops down again (1-3 KBps). Returning the computers to the faster network, every thing is okay again.

Under a upgrade, I've used <dig> to resolve Internet hostnames not resolved in the session before (between reboots), an this isn't an issue on neither of the two networks.

Using a Internet speedtester (HTTP down/upload to a ISP server) seems to have same result in Gutsy on the slow network as with the adept upgrade, works but seems unstable (speed-jumping) the first time, and a following second test the speed drops to nearly nothing. But on the secondary OS the test is okay five or more times in a row.

I've submittet a tcpdump from the slow network on a okay but unstable first downloadtest, and a dump from the following test with near to zero download speed. (What seems odd is that upload is all okay every single time, no matter the downloadspeed).

Christiansen (happylinux) wrote :

And the tcp dump with the highest (40-50 KBps) speed.

Hi Christiansen, I see nothing in the two tcpdump outputs to explain the difference in speed. The DNS-releated problems that we think have been fixed by bug #156720 show themselves when trying to establish connections. You've a long running connection to a web server where you're downloading lots of data so I don't think it's the same cause. Plus, your dig lookups work fine all the time. So, although the symptoms are similar to this bug's title, I'd suggest it's a different cause and you'd be better off opening a new bug or trying to find an existing one, ask on the Ubuntu forums, etc. Does the speed change during the same connection, i.e. does `wget http://some.big.file' flicker between two download rates? Sorry not to be more help, but it's easy if each bug can be tied to one cause even if the symptoms are similar.

wired4u (wired4u) wrote :
Download full text (21.7 KiB)


My internet connection speed is still very slow. I have tried all of the suggested fixes, I disabled ipv6, used open dns and have done all the proposed updates for gusty yet my connection will not go over 200k tops when I was getting 700-800k in edgy. from doing an lspci, My current wireless card is
RaLink RT2500 802.11g Cardbus/mini-PCI (rev 01)

I have included a tcp dump from my wireless card (saw that it was requested) Could anyone assist me?

  (6), length 92) > P 209:261(52) ack 45 524 win 63492
16:00:10.023924 IP (tos 0x20, ttl 116, id 23634, offset 0, flags [DF], proto TCP (6), length 40) > ., cksum 0xe51d (cor rect), ack 46208 win 64860
16:00:10.023940 IP (tos 0x10, ttl 64, id 35172, offset 0, flags [DF], proto TCP (6), length 724) > P 47980:48664(684) a ck 261 win 8576
16:00:10.024038 IP (tos 0x10, ttl 64, id 35173, offset 0, flags [DF], proto TCP (6), length 268) > P 48664:48892(228) a ck 261 win 8576
16:00:10.034508 IP (tos 0x20, ttl 116, id 23635, offset 0, flags [DF], proto TCP (6), length 40) > ., cksum 0xe51d (cor rect), ack 46664 win 64404
16:00:10.034526 IP (tos 0x10, ttl 64, id 35174, offset 0, flags [DF], proto TCP (6), length 496) > P 48892:49348(456) a ck 261 win 8576
16:00:10.034625 IP (tos 0x10, ttl 64, id 35175, offset 0, flags [DF], proto TCP (6), length 268) > P 49348:49576(228) a ck 261 win 8576
16:00:10.040193 IP (tos 0x20, ttl 116, id 23636, offset 0, flags [DF], proto TCP (6), length 40) > ., cksum 0xe51d (cor rect), ack 47120 win 63948
16:00:10.040210 IP (tos 0x10, ttl 64, id 35176, offset 0, flags [DF], proto TCP (6), length 496) > P 49576:50032(456) a ck 261 win 8576
16:00:10.040299 IP (tos 0x10, ttl 64, id 35177, offset 0, flags [DF], proto TCP (6), leng...

cwoodward (csjwoodward) wrote :

Just my pennyworth - I've been experiencing this problem for 5 days to a week - but been using Gutsy since RC5.

Basically the speed of my connection drops the longer I am on the net - but as I couldn't get any updates earlier today I booted into recovery mode, and updated from there. Worked like a charm. I then downloaded a 150mb file (which I had been trying to get for some days) - no speed problems - worked like a charm.

Booted into normal mode - had great difficulty getting any internet connection at all - and eventually managed a very slow connection. If my gut feel is right the problem is not with the network, but with the internal workings in the Ubuntu Desktop?

repustech (info-repustech) wrote :

I would have to agree with that. It seems hardware would be ruled out in this case. It must be a software problem.

repustech (info-repustech) wrote :

I couldn't wait any longer so I installed ndiswrapper instead of using the built-in fwcutter (restricted drivers manager). This solved my problem, so I assume it's a software problem with fwcutter. Just wanted to let everyone know. I have always had better luck with ndiswrapper anyways.

jamouneau (craiglarcom) wrote :

Haven't checked out if this helps wireless as I just have a wired connection on my Dell Inspiron 8200. This did make Firefox work with my connection and allowed me to also connect to my OpenBSD Samba shares. Both of those were inop before the changes. I went through all the ipv6 suggestions without any effect. This worked for me.

sudo gedit /etc/sysctl.conf

change the following parameters to 0: (they are already in the list and you only need to change from "1" to "0")

net.ipv4.tcp_sack = 0
net.ipv4.tcp_window_scaling = 0

save file, reboot

cwoodward (csjwoodward) wrote :

Now that I've been able to use my other connection to get to the internet, I have found something that seems to solve my problem.

It is mentioned in one of the threads - basically you have to edit a file :

the file is /etc/dhcp3/dhclient.conf

within this file you will see a commented out line (~prepend )

add the following line :

prepend domain-name-servers,;

Then restart the network or reboot -

Cedric (lrxzt4zsam) wrote :

I had a similar problem. After upgrading from Feisty to Gutsy Firefox would not load many websites, or would load them after extreme delays. The workaround of setting network.dns.disableIPv6 in Firefox's about:config to true made all pages load quickly. Instructions for the workaround with pictures are here:

My internet service is Qwest DSL to MSN, Actiontec GT701-WG, firmware

# generated by NetworkManager, do not edit!
search domain.actdsltmp

The router's DNS server uses and

I've included the results of dig AAAA for examples of things that just worked and things that didn't work at all. There's no pattern, the results all look the same (no answer). Does anyone want me to sniff the actual Firefox DNS traffic with IPv6 dns enabled again, or any other sort of test or possible actual fix?

Update manager seems to work, and I haven't had any trouble with email, but that's on a domain that worked fine in Firefox.

ikus060 (ikus060-renamed) wrote :

It's could be related to this thread

> It's could be related to this thread

An alternative to editing files and making the change suggested there
permanent is to use

    sysctl net.ipv4.tcp_{window_scaling,timestamps,sack}

to display their current values, they're presumably all 1, and

    sudo sysctl -w net.ipv4.tcp_{window_scaling,timestamps,sack}=0

to change all of them to 0.

I have similar problems but disabling IPV6 does not help. My Wireless does work but with different speeds and sometimes in a middle of a download it just freeze.
Sadly i must say that this does not happen on Windows, any way i will stick with Ubuntu maybe Ubuntu will fix this issue or i will come up with something.

Cedric (lrxzt4zsam) wrote :

My experience was definitely a different bug than this one (since it went away by disabling ipv6), and was fixed by issue 156720. Sorry for adding to the confusion.

At this point the easiest way to distinguish between that bug (156720) and other problems is to upgrade to libc6 2.6.1-1ubuntu10 from gutsy-updates for your platform. If update manager / synaptic, etc can't download these files, the ones you need for a default i686 installation are:

Andrew (adhenry) wrote :

I experience that web browsing is noticeably slower in Gutsy then Feisty, but I also have another issue that is probably just another symptom... Firefox seems to get halfway through loading a page, then 'hangs' on one item (not always the same item) and Firefox then turns gray for several seconds up to several minutes before continuing. Half of the time, Firefox eventually loads the entire page, but sometimes it hangs indefinitely. This is on amd64

I had to install 32-bit Firefox to get Java 1.6 and I have not yet experienced any hangs whilst browsing. Is this an amd64 issue?

Beebock (richard-theraefamily) wrote :


I have tried this with the liveCD for both Unbuntu and Kunbutu and can reproduce the issue in both cases.

I have also tried the update to libc6 and that has not help further then giving me a few more minutes in between crashed.

It may well be a hardware issue. I'm running

Product Name: SpeedTouch 780
Software Release:

RT2561/RT61 rev B 802.11g
Ratlink (MSI issued)

Hopefully this will help.


Rob Pasell (robpasell) wrote :

Well, I reinstalled my / partition and now it works fine wired, haven't tried wireless yet.

sampattuzzi (sam-pattuzzi) wrote :

This happened to me on my laptop. I had to reinstall feisty. Im going to download the hardy heron alpha1 so that this bug doesnt happen again.

bluewurm (bluewurm) wrote :

I had this problem with Gutsy and I tried the fixes above IPv6 and openDNS and etc and they helped reduce the page load somewhat, but the load time was still unbearable. So I did what Andrew Henry posted previously and installed Firefox 32 bit version and the pages are running fast now like when I was using Fiesty. When you install Firefox through Synaptic, I think it auto detects your 64 bit system and installs 64 bit Firefox. You can check Firefox version while it's up by going to the Help and then About Mozilla Firefox. If you are having trouble installing the 32 bit version, you can use this link.

Christiansen (happylinux) wrote :

 jamouneau wrote on 2007-11-02

sudo gedit /etc/sysctl.conf
  change the following parameters to 0: (they are already in the list and you only need to change from "1" to "0")
net.ipv4.tcp_sack = 0
net.ipv4.tcp_window_scaling = 0
  save file, reboot

And Ralph Corderoy rewrote this later to this simple command :

sudo sysctl -w net.ipv4.tcp_{window_scaling,timestamps,sack}=0

Thank both, this solved my problem described earlier in this tread immediately, on both Gutsy and Hardy Alpha2 and even without reboot. Clean installations and no fiddling with DNS nor IPv6. I'm now back on the high Internet performance i used to have with Edgy (NetworkMananger didn't work for me in Feisty, so this was a no go)

Can't help wondering what this excactly does ?. But if is it a bug in the default configuration of a out of the box installation of K/Ubuntu, I certainly hope this will be corrected before the final release of Hardy.....

BTW Testet on wireless access

Rob Pasell, thank you for reporting this bug to Ubuntu. Gutsy reached EOL on April 18th, 2009.
See this document for currently supported Ubuntu releases:

Is this an issue in a supported release? If so, could you please execute the following command, as it will automatically gather debugging information, in a terminal:
apport-collect 155393

affects: ubuntu → linux (Ubuntu)
Changed in linux (Ubuntu):
importance: Undecided → Low
status: Confirmed → Incomplete
Launchpad Janitor (janitor) wrote :

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

Changed in linux (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers