Slashdot Mirror
Getting the most out of your USR Sportster in Debian
Larry asks: "I've got a USR Sportster 56K
INT modem, jumpered to be COM2. Under
Windows it gets 50,667cps, but only
31-33,600cps when I'm using Debian. What
is the correct script to
achieve faster downloads in Linux? The
default script is 'ATZ'" Ah, the days
of the AT command set...however I've never
seen a modem with well configured factory
defaults. Any suggestions?
Check out irqtune. On debian, it comes in the hwtools package.
A friend of mine just had a similar problem (using redhat). The UART speed was set to 115.2, he had a pentium II 350 -- no speed problems, so why was it so slow?
The answer: the interrupt priorities are not optimized for serial use. Try setting your modem interrupt to be the highest priority (using irqtune) and it should help a lot.
you would use pppd to set this not setserial.
if not you might want to do so. if you dont have your manual then you can head on over to http://www.usr.com/home/online/ and download a copy of it. read what it says and explicitly set the options you want, specifically the option to force it to try and connect using x2 or v.90 depending on your circumstances. documentations is a wonderfull thing isn't it?
If, having done this, you still think it's the init string, simply use the one from Windows. It should work equally well with Linux. If you want to know what it means, RTFM.
If (as one poster suggested) you've got an IRQ problem, it will show up in ifconfig as dropped packets or errors on recieve. If ifconfig reports zero or few (say, half a dozen mangled packets in an hour or two of use) it's probably fine to ignore. If it shows a large number of errors, look into using irqtune.
All USR modems have built in help. Just fire up
minicom and look for your parameters.. Use
AT$
and ATS$
to access the help system
AT$ being the main one.. you will see all the commands you can do.
This is the string that will do it
AT&F1
Then follow with
AT&D2&C1X4V1Q0S7=70&M4&B1&H1&R2
Remember internal modems do not use the serial cards uart. They have their own uart.
Remeber never buy a winmodem. Even if you can find a driver for your OS it steals cpu cycles to function.
Really, RTFM. When did a few simple modem commands become too complex to comprehend, and worthy of a /. story?
In additon to setting the serial port speed high,
you can extract the appropriate init string from windoze (I forget where it's AT, just poke around in the 'doze GUI until you find it). Plug the 'doze init string into ppp and you should be good to go.
I use this technique all the time to get the 2nd channel to dial on ISDN DSU/TAs who's manuals I can't read because they're in Japanese (harder than you think... every DSU/TA out there has it's own AT command for doing this).
If you're getting a connect above 33.6, but your measuring lower throughput, the probably may not be with linux or the modem or your connection. The problem could have to do with the remote access server you're connecting to on the other end. Most remote access server can't support the throughput required under a full load (it's bad enough that most ISP's over subscribe their bandwidth; I think it's criminal that companies like Ascend, Cisco and Livingston decided it was OK to under engineer their remote access servers with the assumption that bandwidth would be over subscribe anyway).
You haven't provided enough information to determine where the acutal problem lies. Please clarify a few points :
Is the difference between windoze and linux just what the little pop-up box in 'doze tells you, the connect report that you get from your modem, or are you actually measuring the throughput and if so, how "close" to you is the source of the data stream you're measuring?
On a comment to a previous poster I'd say that it's always a good idea to RTFM but unfortunately it's not always enough :-(
:-(
I've had very similar problems as the original poster and after reading all the fine print, I still haven't found a solution. (Oh, and BTW I'm not impressed with USR's documentation. Not at all ! - It's sparse and sometimes even incorrect).
I do use setserial spd_vhi, I get a 50.666 bps x2 connection when I dial up and even when downloading lots of stuff (many MBs) I don't see *any* errors or collisions (thus, it shouldn't be an irq problem). Yet the transfer rate is never above 3.5 Kb/s which is very disappointing
I've tried to update pppd to the latest version, but that didn't help either, so if anyone can claim that they actually get good performance out of their USR 56K modem I'd be happy to hear about their setup.
Rasmus
well you can do it that way but the generally prefered way of doing it is by using pppd. it is easyer and safer to just let pppd do it.
There's only One True Init String for USR modems:
AT&F1M0 (and tack on &K0&M0 if you have the sense to disable V42bis & LAPM)
If that acts slow, it's neither your modem or the init string at fault. At which point, you RTFM.
My USR v.90 cranks 4.2k/second without effort at all, no special configuration, no magic fairy dust. And given the line quality around here, that's impressive.
your computer can usually do a better job of compression and error correction in software than your modem. pppd does it. with your modeming attempting to compress it wont give you any speed increase. and could possible increase latency
Internal modems for PCs come with their own UART on the card. It is indistinguishable from the UART on the mobo at the driver level because the card's UART is of the same flavor (16550, on a proper modem) as those shipped on the mobo or serial card.
If you're writing a driver that does something special for a standard ISA internal modem, your driver is (or your assumptions are) wrong.
Ummm...but what if the somputer at the other end
doesn't support pppdeflate?
For instance (this is somewhat unrelated) the Windows95/98 dialup clients don't seem to support the pppdeflate on my dialup server.
Would it be prudent to keep V42bis active for
my dialin server?
Wow niffty trick thanks
USRs all come with very good documentation in a PDF file. Sorry you didn't bother looking for it.
AT&F1 should put any USR in "fastest possible" mode. If you can't get a V.90 connection, it's probably phone lines. (Moving to a new apartment solved my V.90 problems.)
Lumpy thoughput on a PPP connect is sometimes
a symptom of having a packet window size that's
too big. Consider adding this to your ip-up
script:
REMOTEIP=$5
route add -host $REMOTEIP window 4096
ATS32=66 for x2 fallback. Hopefully your ISP supports x2.
AT&F1
AT&W0
AT&W1
ATY0
... and leave your init string at ATZ.
I doubt it could be "line noise", I've tried it sitting about 10 feet away from our dialup server on an internal line and it does the exact same thing.
Posted by painmerchant:
There's a few init strings that are out there for the Sportsters, although I'm not sure if they need to be different for Linux than other platforms (excuse my ignorance here, I'm still learning). The main one is to set the floor and ceiling connects for the modem, and the string is AT&N14&U31 - you can fiddle with either numbers till it hooks up the way you want it to. The N is the floor and the U the ceiling, and I think those numbers are equivalent to 14=28.8 and 31=57.333... Hope that helps.
I've got a USR courier, upgraded to 56k. Lately I've been seen a lot of delays. for instatance a ping might return like this:
ping -i 5 ip
ip 64 bytes, 100.56ms (good)
ip 64 bytes, 30062.23ms
ip 64 bytes, 25071.43ms
ip 64 bytes, 20096.57ms
ip 64 bytes, 15101.48ms
ip 64 bytes, 10128.83ms
5131.43ms
ip 64 bytes, 131ms
Of course those numbers are made up, but they are typical, pinging my ISP's mail server (which should be a local subnet) or any other internet service. What is interesting is nothing at all gets through for 20 seconds, and then it all comes in one lump, and then nothing, with no data loss. This suggestes to me that it is a possibal modem problem, and while the modem trys to recover from some noise things back up. Except that 20 seconds is a long time.
I live in an area where noisy phone lines are a way of life (I see a lot of ppp rx errors), and I'm wondering if such delays are normal for bad phone lines, or if I should go through the effort of changing ISPs? Has anyone else seen this and traced it down?
They're at ae.pcd.usr.com. Does anyone have any USR speakerphone stuff working on Alpha Linux, by the way? It seems like it should be straightforward (in tcl/tk, for example), but I can't see anything on the net.
--
W.A.S.T.E.
W.A.S.T.E.
...you've got the serial port set to a slower baud rate. Set the bps to 57.6k or 115.2k (spd_hi or spd_vhi) with setserial.
--
Kyle R. Rose, MIT LCS
[ home ]
Since 3Com bought USR, they've stopped shipping manuals with their modems. Now you just get the irritating 'Insert the driver disk and type A:\SETUP.EXE' instructions.
In my /etc/wvdial.conf I have the init string of AT&U26&N30
U26 = Low connect speed of 33.6
N30 = High connect speed of 45333 - will always connect at that speed. (unless phone line/isp or other condition's are noisy/poor)
Sometimes I up it to N32 which is a nice 48000 connect speed, but my phone lines sometimes can't handle it.
This init string works great for the usr V.90 users we have on our system. If they have problems connecting we give em this string and 99% of em connect just fine.
.//Brian J.
You are correct, You need to get ahold of the command set for your modem (I think USR does have this online). If not, one of the dialers (wvdial) with debian will do a very nice autoconfigure of the modem, then you can use that string with pppconfig or whatever. (Note that I'm speaking from experience, I got a Jaton X2/v.90 card this summer, but I don't remember if I just DL'd the command set from somewhere or used wvdial). You might also be able to grab the best init string from the .inf file for your modem in Windows. That should do it.
MRSH-Recording device, corned beef sandwich with kraut, seafaring bird, and the foamy top of a beverage.
If you still have Wintendo installed, you can log all the commands sent to the modem while connecting (somewhere around modem configuration - advanced button). This way, you will see exactly what init string wintendo uses to setup modem.
Actually, I had a modem with manuals once, but Wintendo was using some undocumented AT commands (well, at least they were not listed in my copy of the manuals) that were essential for modem to work OK.
D.
internal modems _do_ use the computers' uarts. if you've ever written a low-level serial driver you'll know this. communication with an internal modem occurs at the speed set on the uart. Most modern computers (anything >= pentium class) have 16550 or better uarts capable of 115200 bps (a uart is really just a fifo).
:p), and you'll have a 16550.
Actually, the uart is going to be on the modem card. If you put an old 2400 in your pentium, you'll notice it's either got an 8250 or 16450 on it. Put your 56k in a 286(or 8088 if you can find an 8 bit 56k card I guess
you would use pppd to set this not setserial.
Actually, what I do is use setserial in my rc.local to set the 38400 speed (spd_vhi) on the UART to be 115K, then use pppd to select 38400, which really then gives me 115K. I dunno if this is the best way to do it, but it sure works fine.
internal modems _do_ use the computers' uarts. if you've ever written a low-level serial driver you'll know this.
Wrong. Internal modems supply their own UART, usually a 16550A equivalent of some sort. You can use an internal modem with a motherboard with no on-board UARTs and no add-in serial card. The only exception to this is the dread "Winmodem", which doesn't have, nor use a UART, but rather a "bit banger" approach. Avoid the "Winmodems" at all costs, even for Windows use they stink, because they steal processor power to do things real modems do in hardware.
ATS32=2 should enable v.90 on a USR 56K
Try setting the init string to AT&F that will put the modem to factory settings and use the speed that is determined through negotiation between the modems. You will know when you get a V.90 connection when you hear 2 pings(for a lack of a more descriptive name). Once you get the V.90 working you can set the init string to AT&FM0 to turn off the speaker if you so prefere.