Dial-Up Modem Questions
in [Linux Networking]
|
Prev: When does skb fragmentation happen ?
Next: How to capture tcpdump data to simulate connections from multiple IPs?
From: dpdoughe on 18 Jun 2006 00:32 1) I have a USR 56K v.92 Modem. I've noticed that it speed really slows if it has been on for more than an hour. A quick disconnect-reconnect seems to improve speed temporarily for example and then it slows down again after a bit. The modem is hot to the touch so I'm wondering if it is a heat issue. Has anyone had any similar experience? Is there a cooling system recommended? 2) Some ISP's offer 5X web acceleration. My understanding is that they all require Windows or Mac to run the software although my understanding is that they are just doing compression before the send and the software does the decompression. Simple enough. Are their any ISP's offering a Linux compatible speed-up? Thanks!
From: Moe Trin on 18 Jun 2006 16:39 On 17 Jun 2006, in the Usenet newsgroup comp.os.linux.networking, in article <1150605156.756041.325170(a)r2g2000cwb.googlegroups.com>, dpdoughe(a)allvantage.com wrote: >1) I have a USR 56K v.92 Modem. I've noticed that it speed really >slows if it has been on for more than an hour. A quick >disconnect-reconnect seems to improve speed temporarily for example and >then it slows down again after a bit. You are posting from a Level 3 address (Level 3 is a presence provider in major US cities), and they do no filtering, so you could be seeing bandwidth loss due to skript-kiddiez and windoze messenger spam (UDP to ports 1025-1050 or so). One of my ISPs has a access number from Level 3, and I avoid using it as much as practical. >The modem is hot to the touch so I'm wondering if it is a heat issue. In Detroit??? I've no idea what your room temperatures are like, but as I write this, it's 104F/40C on the patio outside this room. Inside, it's 77F/25C, thanks to 7 Tons of central air-conditioning. None of my hardware is running hot. >Has anyone had any similar experience? Is there a cooling system >recommended? That _shouldn't_ be a problem, though I suppose you could try as a temporary measure directing a fan at the modem to see if that is a problem. I'd also look at the modem setup. First, see that you are using an appropriate init string. Most dialin helper tools use some bizarre string that the author visualized while on a really bad acid trip - the manual probably is suggesting 'AT&F1'. Next, fire up something like minicom or seyon after configuring that tool to NOT initialize or reset the modem, and send the command to get the modem stats (perhaps 'ATI6' - that's ati6) and look at the 'Retrains Requested' and 'Speed' parameters. (If you don't have a manual, see the built in help that's available with 'at$', 'at&$' and 'ats$'.) Is the link speed starting high, and retraining down? Another thing to look at _during_ the connection is the '/sbin/ifconfig ppp0' stats, paying attention to the error counts. The values should stay very close to zero - as these typically indicate a problem getting past the modem error correction, and possibly caused by local configuration issues. Something more than three or four errors in an hour (the count is cumulative for the duration of the call) is cause for concern. >2) Some ISP's offer 5X web acceleration. My understanding is that they >all require Windows or Mac to run the software although my >understanding is that they are just doing compression before the send >and the software does the decompression. Snake-oil. There are three forms of data compression. There is the link compression that your modem may negotiate with the peer - you'll see this in the CONNECT stanza if you are logging it, as something like 'CONNECT 53333 V42BIS' with the V42BIS being hardware data compression. This is less common than it once was, because of the added CPU cycles needed on the ISP end to do the data compression (they aren't using the same analog modem you are), but typically results in a 2:1 to 4:1 improvement in speed (subject to the typical RS-232 hardware speed limit of 115200 BPS). The second form is associated with the ppp protocol. I suspect this isn't working for you (you'd have to use the debug option to pppd, and set your syslogd daemon to log appropriately to find out), as there are several algorithms, and they aren't compatible, AND windoze defaults to using a proprietary method, while ANU ppp that you are using can't use that because of license problems. This would show up in the logs as a CCP ConfAcq line, indicating success, and a CCP ConfRej, CCP TermReq or LCP ProtRej in the debug log output indicating failure. The third form depends on the data you are downloading. If the stuff you are downloading is already compressed - mpegs, jpegs, stuff where the filename ends with .zip, .Z, .tgz, .gz, or .bzip2 - compression of any other kind isn't going to help, and actually could _reduce_ the transfer speed trying to compress the incompressible. Old guy
From: dpdoughe on 20 Jun 2006 23:40 Thanks Mr. painkiller, Turns out that it was indeed the initialization string. I had originally left blank in the configuration. Since I did not know what the appropriate one for a USR 5686 was I did a web search and from http://www.burk.com/support/knowledgebase/R19ZZ005.html found that it should be ATB1S0=1 I entered that in the appropriate place using /usr/bin/system-control-network. I have not noticed the hanging anymore so I assume that was the cause. Question, if it was the initialization string, what diagnotic(s) would/should demonstrate a measurable change? The output from /sbin/ifconfig looks the same -- always shows 1 error Moe Trin wrote: > On 17 Jun 2006, in the Usenet newsgroup comp.os.linux.networking, in article > <1150605156.756041.325170(a)r2g2000cwb.googlegroups.com>, > dpdoughe(a)allvantage.com wrote: > > >1) I have a USR 56K v.92 Modem. I've noticed that it speed really > >slows if it has been on for more than an hour. A quick > >disconnect-reconnect seems to improve speed temporarily for example and > >then it slows down again after a bit. > > You are posting from a Level 3 address (Level 3 is a presence provider in > major US cities), and they do no filtering, so you could be seeing > bandwidth loss due to skript-kiddiez and windoze messenger spam (UDP to > ports 1025-1050 or so). One of my ISPs has a access number from Level 3, > and I avoid using it as much as practical. > > >The modem is hot to the touch so I'm wondering if it is a heat issue. > > In Detroit??? I've no idea what your room temperatures are like, but > as I write this, it's 104F/40C on the patio outside this room. Inside, > it's 77F/25C, thanks to 7 Tons of central air-conditioning. None of my > hardware is running hot. > > >Has anyone had any similar experience? Is there a cooling system > >recommended? > > That _shouldn't_ be a problem, though I suppose you could try as > a temporary measure directing a fan at the modem to see if that is a > problem. I'd also look at the modem setup. First, see that you are > using an appropriate init string. Most dialin helper tools use some > bizarre string that the author visualized while on a really bad acid > trip - the manual probably is suggesting 'AT&F1'. Next, fire up something > like minicom or seyon after configuring that tool to NOT initialize or > reset the modem, and send the command to get the modem stats (perhaps > 'ATI6' - that's ati6) and look at the 'Retrains Requested' and 'Speed' > parameters. (If you don't have a manual, see the built in help that's > available with 'at$', 'at&$' and 'ats$'.) Is the link speed starting > high, and retraining down? > > Another thing to look at _during_ the connection is the '/sbin/ifconfig > ppp0' stats, paying attention to the error counts. The values should > stay very close to zero - as these typically indicate a problem getting > past the modem error correction, and possibly caused by local configuration > issues. Something more than three or four errors in an hour (the count is > cumulative for the duration of the call) is cause for concern. > > >2) Some ISP's offer 5X web acceleration. My understanding is that they > >all require Windows or Mac to run the software although my > >understanding is that they are just doing compression before the send > >and the software does the decompression. > > Snake-oil. There are three forms of data compression. There is the > link compression that your modem may negotiate with the peer - you'll > see this in the CONNECT stanza if you are logging it, as something like > 'CONNECT 53333 V42BIS' with the V42BIS being hardware data compression. > This is less common than it once was, because of the added CPU cycles > needed on the ISP end to do the data compression (they aren't using > the same analog modem you are), but typically results in a 2:1 to 4:1 > improvement in speed (subject to the typical RS-232 hardware speed > limit of 115200 BPS). > > The second form is associated with the ppp protocol. I suspect this isn't > working for you (you'd have to use the debug option to pppd, and set your > syslogd daemon to log appropriately to find out), as there are several > algorithms, and they aren't compatible, AND windoze defaults to using a > proprietary method, while ANU ppp that you are using can't use that > because of license problems. This would show up in the logs as a CCP > ConfAcq line, indicating success, and a CCP ConfRej, CCP TermReq or LCP > ProtRej in the debug log output indicating failure. > > The third form depends on the data you are downloading. If the stuff you > are downloading is already compressed - mpegs, jpegs, stuff where the > filename ends with .zip, .Z, .tgz, .gz, or .bzip2 - compression of any > other kind isn't going to help, and actually could _reduce_ the transfer > speed trying to compress the incompressible. > > Old guy
From: dpdoughe on 21 Jun 2006 00:14 Interestingly, I do have a USR 5686E (v.92) modem but when I use the initialization string given for that model AT&B0&N2&S0=1 , I can't connect at all (just screeches and wails and then drops after while). So I imagine I am still running my modem at v.90 but from what I've read in this group that may be a better place to be overall performace wise anyway.
From: Moe Trin on 21 Jun 2006 22:04
On 20 Jun 2006, in the Usenet newsgroup comp.os.linux.networking, in article <1150861216.119080.141920(a)m73g2000cwd.googlegroups.com>, dpdoughe(a)allvantage.com wrote: >Turns out that it was indeed the initialization string. I had >originally left blank in the configuration. Since I did not know what >the appropriate one for a USR 5686 was I did a web search and from >http://www.burk.com/support/knowledgebase/R19ZZ005.html > >found that it should be ATB1S0=1 That sounds SEVERELY incorrect... I have _NO_ idea how that would work. Break it down: AT Hayes Command prefix B1 Bell Answer Seq S0=1 Ring to Answer ON No, that's to set up the modem for it to answer the phone when someone is dialing in. Definitely not what you want when dialing out. I suspect you need to hit google again, and see if it will dig up the USR manual for that modem. As a general rule, USRs want exactly one thing "AT&F1" From the built-in help on the modem (AT&?), I get &Fn n=0 Load Factory 0, no FC n=1 Load Factory 1, HW FC n=2 Load Factory 2, SW FC FC is Flow Control, with HW being HardWare (the RTS/CTS wires in the cable) as opposed to SW being SoftWare (the XON/XOFF sequence rarely used any more). >Question, if it was the initialization string, what diagnotic(s) >would/should demonstrate a measurable change? The output from >/sbin/ifconfig looks the same -- always shows 1 error Look at the manual if you have it, or 'AT?' to call up the built-in help. In n=0 Product Code n=1 Checksum n=2 RAM Test n=3 Product ID string n=4 Current Settings n=5 NVRAM Settings n=6 Link Diagnostics n=7 Product Configuration This happens to be an old 5687 (internal), but you should see something similar. The 'Link Diagnostics' should tell a lot. Additionally, you have to understand the whole reset sequence. If you look on the back or side or bottom of the modem, you should see a DIP switch - probably has 7 to 10 settings. _ONE_ of those controls how the modem configures itself on power-up (whether it uses NVRAM, or the factory defaults). NVRAM _MAY_ be OK and it may not - depends if/what you have set using the AT&Wn command. Unless you know what you are doing, I always recommend setting it to the factory default mode (I don't have a 5686E, so I can't tell you which switch is which - that's why you need that manual). When the modem powers up, it reads that DIP switch, and configures the modem accordingly. Later, you decide to dial in, and your dialing program (hmmm, you didn't mention which one that is - never mind which distribution or release) is going to send some string to the modem to intiate things before dialing. Most such tools choose really strange values, some of which the poor modem never heard of before. The result is some combination of what the power-on reset did, and the modem init string you used. How else does it show up? In some cases, you may not even be able to talk to the modem. (The old 5687 I have here has 46 commands, and 42 S-registers that may effect how those commands work. See the size of the problem?) Or if may "partially" work, in some strange way. Oh, I should point out that in my initial response to you, I stated ] send the command to get the modem stats (perhaps 'ATI6' - that's ati6) ] and look at the 'Retrains Requested' and 'Speed' parameters. (If you ] don't have a manual, see the built in help that's available with 'at$', ] 'at&$' and 'ats$'.) Is the link speed starting high, and retraining down? Retraining down (reducing link speed to tolerate high error rates) is automatic depending on settings in one (or more) S-registers. Retraining _up_ happens less often and may be disabled with S-register settings. Old guy |