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).
Originally Posted by jacatone
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...
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.