LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)
-   -   Can't figure out why my dialup is so slow in Linux (https://www.linuxquestions.org/questions/linux-newbie-8/cant-figure-out-why-my-dialup-is-so-slow-in-linux-641229/)

jacatone 05-10-2008 01:27 AM

Can't figure out why my dialup is so slow in Linux
 
I have a WinXP Pro machine as well a Linux box running Kubuntu 7.10 with a U.S. Robotics serial modem. I'm using the same dialup account for both machines. The connection on my XP machine that's using a built in PCI internal 56k modem is quite fast. Whereas the Linux connection seems to be painfully slow. I'm using KPPP to connect, and I'm using the same login numbers and so on. Anyone have any suggestions on how I might remedy this? Thanks.

GrapefruiTgirl 05-10-2008 08:45 AM

For the record, I find the exact opposite situation here at my home: The WinXP machine connects to our dialup account at the same reported rate as my Linux machine, but the actual connection functions faster and better on my Linux machine. When we share the connection, my roommate, who uses the WinXP machine, says that "the penguins are hogging all the bandwidth" :D

Anyhow, I guess the place to look would be your kppp configuration, first of all. Check the options, connection speed setting, etc., and see if anything is set up less than ideally. Maybe the max connection speed on the Linux machine is set too low?

Are the modems comparable, in terms of speed (ie they are both 56k modems?) and also, are you using the correct driver for the serial modem (I don't have a serial modem, but from what I have read, there isn't much involved in serial modem drivers, but check into that too.)

Maybe give us the make/modem of the US Robotics modem, and someone may be able to advise better than I can, from their experience.

Check the Linux HCL here on LQ (link to the right) and look for your modem; maybe there is a report from another user about how their modem works, what driver, etc..

Sorry I can't be of more help; best of luck :)

SVA

salasi 05-10-2008 03:30 PM

Sorry, when I first read this, I misunderstood the problem; you are not using the same modem in XP as you are in Linux? Is this because it is a 'winmodem'? If so, there might be the chance of getting it working under Linux. Check the 'linmodems' site (if my memory serves correctly).

Quote:

Originally Posted by jacatone (Post 3148894)
Anyone have any suggestions on how I might remedy this? Thanks.

Well, first off lets start with the palliative measures (not fixes for what might be 'broken', but things that might help it feel at little less bad, and might be useful even when you have a fix for whatever is wrong):

i) Use caching. Either ensure that the cache settings for your browser are optimal (at a guess, try double what is set as the default) or use an external caching program (squid, polipo). I'm not convinced that there is a big gain to had from caching in normal circumstances, but you might as well try for a small gain.

ii) Use a faster browser. I've always found Opera to be at the fast end of the spectrum, but Firefox 3 is said to have appreciable speed-ups applied. Or you could try Dillo or one of the non-graphical browsers (links/lynx), if you can countenance that.

iii) Cache name look-ups. You could use Bind (but that's a maximum flexibility/maximum complexity solution) or Dnsmasq/Maradns/Djbdns, which are probably more suitable. And the squid config file seems to imply that there is some capability to cache name look-ups in squid, but as there are no configurable oarameters for that, I'm not sure...

and

iv) Change your browsing technique. While you are reading one web page, have another one loading up. Your browser needs to have good support for tabs, but then...

Well, none of that was really satisfactory (and is that so different from dial-up generally? Up to you.) so lets get on to faults and fault finding.

i) Check the speed of the serial line to the modem. This should be fast enough so that data from the modem is in no danger of saturating it (so with a 56k modem, 76.8k or 115.2k should be fine, but 9600 would be a real problem).

ii) There shouldn't be any problem with drivers. AFAIK, all external serial modems are 'Hayes compatible' and have the same set of instructions so there is only one driver.

iii) can you use the same modem under windows and is that satisfactory? If so, there shouldn't be any problem with modem settings. Some of the settings can have an influence on speed, but if you can use exactly the same modem satisfactorily (well, better, anyway) under Windows you should be able to do at least that under linux. Unless windows does something evil like messing up the settings that it uses when it leaves. This shouldn't be a possibility...

iv) You might want to try fiddling with the MTU; I'm not completely convinced about this either, but it is claimed that lower MTU (max transmission unit - the biggest size that a block of data can have) is better for 'interactive' use and larger values can be better for downloads. Given that this can only ever be a compromise, I'm not convinced that you will ever find a value that you find is clearly better, overall, but feel free to try.

v) Check whether name look ups are 'broken' or at least partially broken. Something that is surprisingly common is to have the nameservices configured such that the first name service used does not actually exist and therefore all name look ups wait for the first service to time out before anything actually happens. This obviously hits average dowload rates. If you can look at the flow of data in a download and it shows a characteristic 'picket fence' pattern, there is a good chance that this is what you've got.

vi) Another, slightly more distant, possibilty for 'picket fences' is poorly configured flow control. There are two ways of doing flow control on an RS 232 serial link; hardware (wires in the interface cable) or software (sometimes called XON/Xoff, or control S / control Q). Firstly, you should have a maximum of one of the two methods, and you might even get way with, at least as an experiment, none of the two methods, although expect occasional screw-ups if you decide to do without. Secondly, both ends should agree which of the two methods is in use. Thirdly, if it is hardware, you need the right cable, as it is quite common to 'fake out' flow control in the cable. If there is any possibility of this you might have to ask again, as this can get involved.

salasi 05-11-2008 02:07 AM

What I also ought to have included was that the worth of caching nameserver lookups is directly dependant on your ISP doing a bad job with nameserving. If they do a good job, there won't be that much to gain.
If the ISPs nameservers are fast and reliable, then there probably is no point in spending much time on caching, using alternate nameservers, etc.
If the ISPs nameservers are either unreliable or slow, then that area deserves attention.
Roughly, if you can get ping response times consistently less than 200mS from a nameserver, it is probably doing its job ok. You could also try tracerouting to it, to see whether it is the nameserver that is bad or one of the other boxes in the way, but that information is of minimal value to you (it might be useful to the ISP, but your isp probably won't listen...).

You should also try 'dig' to see what the response, overall, of your name look up set up is.

From what I remember (and it is quite a while ago) using kde's utilities in a straightforward way gave you the possibility of entering two IPs for nameservers. As the ISP probably gives you two, if you want to use a third-party nameserver, you either have to sacrifice one of the ISP's nameservers, or do something more complex.

Sacrificing one of the ISP's nameservers isn't necessarily a big issue if they both go slow at the same time, but if you notice that one is good while the other is bad, you'll probably want to keep both. (Partly it depends on what the ISP has messed up - I was once with an ISP whose understanding of networking was so superficial that they put their primary and secondary on the same subnet, and when that subnet became slow, they both went bad; at that point having a backup nameserver is not useful!)

Something more complex is to run your own name look up cache. An advantage here is that you can cache values from more than two sources. There is no point in going mad on this and adding as many as you can find, as the ones lower down the list only come in to play after the ones further up the list have timed out. So your tenth choice is always going to imply a long wait. OTOH, this is a more complex solution.

(In referring to a list, some choices always use your list in just the order that you have given them; some will dynamically order the list based on responses times.)

Just to summarise:
Nameserving can be a cause of slowness, and you can do stuff about it, but it probably isn't worth doing if nameserving isn't your cause of slowness. (If the difference between windows and linux was responsible for this, it would kind-of assume that under windows there is some level of caching 'automagically' - I don't know enough about windows to know whether that is true.)

Oh, and also: Broadband is good!


All times are GMT -5. The time now is 07:45 PM.