--------------- FIDO MESSAGE AREA==> TOPIC: 259 HAYES MODEMS Ref: DBZ00000 Date: 07/25/96 From: JIM PALMER Time: 06:19pm \/To: PRESTON RENARD (Read 1 times) Subj: FACTORS AFFECTING THRUPUT In a message dated 07-23-96 PRESTON RENARD wrote to JOHN TYNDALL: PR> As I understand it there are 8 bits to each character. If one's thruput PR> is running at about 1000 characters per second (cps), this equates to PR> 8000 bits per second (bps). 1500 cps equates to 12,000 bps. Now, PR> achieving only 12K bps or less from a device rated at 14.4K bps seems PR> problematic to me. I understand there are various factors that can PR> impact thruput. But when I posed my original message, I was hoping PR> somone could help me understand either why my typical thruput of PR> 1300-1500 cps from a 14.4 Kbps is correct OR whether any measures could PR> be taken to make improvements. PR> Any takers? Here is my 'random scuttlebutt' answer, anyone can feel free to convince me I have my facts confused, but it is a start. If one is using an asyncronous serial port modem at faster than 110 bps (and I hope you all are!) then there 10 bits per byte; a start bit, (always a 1) 8 data bits, (or 7 data bit and a parity bit) and a stop bit (always a 0). besides providing syncronization as to where each byte starts, this allows us to divide the bps by 10 to get the cps. Without Error Correction a 14400 bps modem will have a theorectical top speed of 1440 cps. (those who where tricked into buying RPI modem are saying "Tell me about it!") In an effort to provide a more reliable modem, a company call Microcom started designing error correction algorythyms into it's modems. Those that worked were layered into a stack of routines, (thus a modem may run MNP2 through MNP 4, usually called MNP 4 but actually a hodge podge of ideas that work) but the one that interests us is MNP 4. If one took 256 bytes of data and encapulated it in a header and a trailer with error correction code in it, one could skip the start and stop bits as the whole 256 bytes would be sent as a single syncronous burst, rather than each character seperately. (this would also make a slow modems screen refresh appear jerky, as all 256 bytes pour down the serial port in a rush) One would need another 512 bytes of RAM in the modem (as well as more ROM for the code and a faster CPU to complete the routine in time) but as you need RAM for the S-Registers, 512 bytes more is cheap (one 256 buffer in each direction). If we assume 12 bytes of overhead for the header and trailer, we now send 268 8 bit bytes rather than 256 10 bit bytes, for a savings of 416 bits per 2560, or a 16% percent speedup! Now that we have a 256 byte buffer, the serial port speed can be different than the modem's line speed. Previous modems had to talk to the computer at the same speed as to the other modem, we can now 'lock' the modem to computer speed and not worry if we get a slow modem at the other end. This also solves the problem of what to do if the modem to modem speed is not a common serial port speed, 9600 was the last 'common' speed that both the line and computer would both go. Now that we coughed up a fast CPU and a buffer big enough to hold a couple of packets of data, we could design a compression routine and run it on one packet while transmitting the first. MNP5 can theoretically double the speed of previously uncompressed data. This is all wonderful if both ends of the phone line use Microcom modems, but they were slow to license and 'greedy' when they did, so the ITU (then the CCITT) devised a similar routine (can you say reverse engineering?) that was widely available, V.42 With the perfect vision of hindsight they abandoned all the seperate steps and cleaned up the code considerably, but also dropped the packet size down to 128 bytes to make it less jerky (and cheaper). Naturally, as they did this, we all switched to faster modems, so the screen jerkyness doesn't bother us but the higher overhead of smaller packets does. In theory, V.42 modems could negotiate packets upto 512 bytes in length, cutting the overhead by a fator of four, but I have never caught them doing so. :-( Meanwhile, the ITU v.42bis Data Compression is better than Microcom's MNP 5 in that it can compress data by a factor of 4 (I sometimes hear rumors of 8) and can detect data not to attempt to compress. Just goes to show they did get some stuff right. --- * TIMM 1.0.6 * If 640k has any special meaning, you have the wrong computer --- WILDMAIL!/WC v4.12 * Origin: The Privy Ledged BBS, Kearns, Utah (801) 966-6270 (1:311/5.0) --------------- FIDO MESSAGE AREA==> TOPIC: 259 HAYES MODEMS Ref: DBZ00001 Date: 07/25/96 From: JIM PALMER Time: 07:18pm \/To: PRESTON RENARD (Read 1 times) Subj: FACTORS AFFECTING THRUPUT In a message dated 07-23-96 PRESTON RENARD wrote to JIM PALMER: JP> fastest speed one could get, even in theory, is 1440 cps, but if you JP> enable error correction and 'over drive' the serial port by at least 20% JP> (19,200 would be more than enough for a 14400, 38,400 would be enough for JP> 28,800) you can, in theory, get 1750 cps from a 14400 modem. (1650 cps is JP> quite acheivable in practice, MNP 4 is slightly faster than V.42) PR> I typically set my COM port to 19.2. I get errors from most boards when PR> COM is set at 38.4. Can you tell me how to check the characteristics or PR> functions of my 14.4 fax/modem? How does one check error correction PR> status and how is it changed? I have no manual but I know I have an PR> internal Safari 14.4 fax/modem (AT&T). This is the sad part of the tale, 'Hayes compatable' is almost a meaningless term. Hayes did not want other companies to be compatable, resisted compatability, and no-one enforces a single set of rules about what is compatible. AT&T is VERY bad at it. Having used a AT&T Dataport, almost none of the commands I am used to on a PPI are the same. JP> If one also enables data compression (either V.42bis or MNP 5) then JP> further gains can be acheived on uncompressed data (text files or BBS JP> screens, for instance) Here, V.42bis is faster than MNP 5 and is a JP> smarter algorythym, PR> Can you tell me how to accomplish any of this? Not on a AT&T. If you cannot find any way to contact AT&T's modem division, (and the company recently split into 3 parts) I suggest an open plea for the relevent portion of the manual from an owner. --- * TIMM 1.0.6 * My computer is a Microsoft-free zone. --- WILDMAIL!/WC v4.12 * Origin: The Privy Ledged BBS, Kearns, Utah (801) 966-6270 (1:311/5.0) --------------- FIDO MESSAGE AREA==> TOPIC: 259 HAYES MODEMS Ref: DBZ00002 Date: 07/27/96 From: JIM PALMER Time: 07:04pm \/To: JOHN TYNDALL (Read 1 times) Subj: FACTORS AFFECTING THRUPUT In a message dated 07-25-96 JOHN TYNDALL wrote to JIM PALMER: JT> My modem is v32 and It won't do error correction and I don't use JT> commpresion 'cause everything I DL is all ready zipped. JP> So my advice would be to be sure you are overdriving the serial port and JP> have not disabled error correction, even if you decide to disable data JP> compression. (This bit is confusing as the acronyms are similar: V.42 vs JP> V.42bis or MNP 4 vs MNP 5) JT> I think I'm stuck with 'normal' as you missed where I said my modem JT> *won't* do error correction. Then you also do not have an option to do data compression as that is built on top of error correction. If data compression were an option on your modem, then it would have error correction. Meanwhile, if you followed the tread, you found out how come other 14.4 owners can get 1650 cps while you cannot. 14.4s without at least RPI error correction are rare, as they would need most of the parts (RAM buffer, seperate DYE and DCE speeds) to do error correction just to make a 14.4. --- * TIMM 1.0.6 * If 640k has any special meaning, you have the wrong computer --- WILDMAIL!/WC v4.12 * Origin: The Privy Ledged BBS, Kearns, Utah (801) 966-6270 (1:311/5.0) --------------- FIDO MESSAGE AREA==> TOPIC: 259 HAYES MODEMS Ref: DBZ00003 Date: 07/28/96 From: PRESTON RENARD Time: 12:13pm \/To: HAYES SUPPORT (Read 1 times) Subj: FACTORS AFFECTING THRUPUT HS> start bits off before the data is sent. Your throughput of 1300-1500 HS> cps is just a little slower than normal, but there are many factors that HS> can affect throughput: phone line noise, system speed on either end HS> (a heavily tasked cpu can slow things down), the type of UART in HS> the serial cards, the file transfer protocol being used, the type of HS> data being transferred (compressible or not), etc. etc. If you HS> are transferring fully compressed files under good conditions with a HS> full streaming file transfer protocol like Zmodem and with a port HS> speed set to at least 19,200 bit/s, 1600 cps is about average. Thank you very much for your reply. BTW...glad to see your firm making a comeback. I have one of your early 300 baud products in my attic. Is your BBS still working and what's the number? Always use ZMODEM and 19.2 on my COM port (run errors with "some" boards if I go higher). My UART is a 8250 according to MSD.EXE. Operating in DOS using DOS comm package Telemate v.4.20 (registered ). I use a 386SX/25 e/w co-processor. Regularly connect to 6/7 local and several 800 BBS numbers. Typically DL *.zip files. Do experience higher thru-put when DL/UL text files but I understand why. Live in a residential area supported by Bell Atlantic's eletronic switching capability. There's loads of fiber throughout this area. Do not 'hear' ground hum (60Hz), white noise or crosstalk on my telephone line. People I speak with via telephone do not complain of hearing anything either (except sometimes me ). However, I do have many extention telephone jacks throughout my house. About 1/3 of them do not have telephones connected to them. With that as a backdrop, I typically achieve only 1300-1500 CPS. The mid 1400s is very common for me. After reading your reply I think I'll try some house wiring elimination work. I'll start by disconnecting all unused extension wiring and go on from there. Perhaps there is some filtering going on that is affecting my thruput. I dread the thought of trying to talk to Bell Atlantic about a modem thruput problem. --- . SLMR 2.1a . Press any key to continue or any other key to quit * Origin: Fair Lawn, NJ (1:2604/405) --------------- FIDO MESSAGE AREA==> TOPIC: 259 HAYES MODEMS Ref: DBZ00004 Date: 07/28/96 From: PRESTON RENARD Time: 12:29pm \/To: DANNY WALTERS (Read 1 times) Subj: FACTORS AFFECTING THRUPUT DW>but won't speed up again if they improve. It could be that the modems are DW>staying at 14400 but having to resend packets in the error correction becaus DW>of line hits. Typically do not see errors on ZMODEM's error counter. It could be something as simple as a flaky cord between the DW>modem and the wall jack. Should see errors then...right?. If you're using the modem on a house extension, th DW>fact that there are other phones bridging the line can affect the line DW>impedance, which is very influential in line conditions. How much phone wir DW>is in your house can affect it as well - long lengths of wire are capacitive DW>and will shift impedance some. I plan to seriously look into this possibility. Could also be crosstalk in the lines. Don't hear any transmit or receive. If not, it may well be you have old copper in your DW>neighborhood. If you're out in the boonies, you may well be on one of those DW>rural multiplex carrier lines that are used to put more lines on less wire. No multiplexed carrier and I'm only several miles from the Telco office. BUT there is a rats nest of a connect box on a pole somewhere between here and Telco office. There have been problems at that point in the past. DW>Those "plug and play" modems can be sort of a black art sometimes. Most modems I've used work ok. I plug them in, cable them up and they work fine. The thruput questions came up as UL/DL files are getting larger and larger. I also seek to maximize capabilities of existing hardware as I can't afford to upgrade right now. --- . SLMR 2.1a . --T-A+G-L-I+N-E--+M-E-A+S-U-R+I-N-G+--G-A+U-G-E-- * Origin: Fair Lawn, NJ (1:2604/405) --------------- FIDO MESSAGE AREA==> TOPIC: 259 HAYES MODEMS Ref: DBZ00005 Date: 07/29/96 From: HAYES SUPPORT Time: 12:41pm \/To: STEVE PETERS (Read 1 times) Subj: UPGRADE 33.6 SP> in my New Hayes Accura SP> 288 external. SP> I had just bought a New USR Sportster 288/33.6 but had to return it. SP> I discovered it and many of USRs Sportsters have a bad chip called SP> the "pause bug". Loging into BBS's it (USR) will just stop after a few SP> min's. then statup again. SP> I think its great news about the 33.6 upgrade. I'm sure HAYES will let SP> us all know when it will be available, and how they will handle it. SP> My question is, what speed should I lock my 16550A ports at? SP> I'm useing PCBoard BBS that recommends the highest possible being 115200 SP> PCBoard has a PCBmodem setup to auto configure most any modem. How do I SP> know that they are the best strings and most current? SP> I have tried a few downloads (cross country FREQ) and the average SP> download speed is from 2300 to tops 2500 cps. I downloaded the "sysops SP> kit" from HAYES support BBS (small file) and it showed 3500cps! using SP> Hayes Smartcom for Win LE. set at 115200. SP> Steve SP> Steve, Yes, we'll let everyone know about the 33.6 upgrades as soon as we have ll the details. Keep an eye on http://www.hayes.com/336upg.htm because the info will be there first. As for the PCBMODEM settings for Hayes modems, I have found them to be right on the mark. I have run a PCBoard BBS using a Hayes modem (OPTIMA 288) for years using these settings. As for the port speed, I usually set mine to 38,400 bit/s, as you don't really need to go higher than that if you are just transferring compressed files, and I tend to operate the BBS under desqview and prefer to use a lower speed to avoid any problems under that multitasking environment. A higher port speed will make your menu screens and text come up faster, however. You will find that your download speeds will vary quite a bit depending on where you call and the specific phone line conditions between your modem and the modem you are calling into. Michael -- Hayes Online Services support@os.hayes.com --- FLAME v1.1 * Origin: Southern Star - V32b/V.FC/V.34/ISDN - 504-885-5928 - (1:396/1) --------------- FIDO MESSAGE AREA==> TOPIC: 259 HAYES MODEMS Ref: DBZ00006 Date: 07/28/96 From: TOM GALLAGHER Time: 09:18am \/To: HAYES SUPPORT (Read 1 times) Subj: FACTORS AFFECTING THRUPUT Meanwhile, back at the farm, Hayes Support said to Preston Renard: PR> JT> SB> With a 144 modem 13-1500 cps is about right. To get PR> JT> SB> faster PR> JT> AT> Actually you should be looking more towards 1600cps.. PR> JT>You guys are gettin' my goat.:-( PR> JT>I always average about 1365cps running 14.4 from a 33.6 PR> JT>and no matter what settings I play with, thats what I get. PR> PR> IMO this thread seems to point out how little most of us understand PR> about the virtually plug and play device called a modem. PR> PR> As I understand it there are 8 bits to each character. If one's thruput PR> is running at about 1000 characters per second (cps), this equates to PR> 8000 bits per second (bps). 1500 cps equates to 12,000 bps. Now, PR> achieving only 12K bps or less from a device rated at 14.4K bps seems PR> problematic to me. I understand there are various factors that can PR> impact thruput. But when I posed my original message, I was hoping PR> somone could help me understand either why my typical thruput of PR> 1300-1500 cps from a 14.4 Kbps is correct OR whether any measures could PR> be taken to make improvements. PR> PR> Any takers? PR> HS> There are 8 bits/character, but with a standard async HS> modem connection you'll be adding stop and start bits as HS> well to bring it up to 10 bits per character. This HS> really isn't a consideration though, since your error HS> correction protocol will most likely be stripping the stop HS> and start bits off before the data is sent. Your HS> throughput of 1300-1500 cps is just a little slower than HS> normal, but there are many factors that can affect HS> throughput: phone line noise, system speed on either end HS> (a heavily tasked cpu can slow things down), the type of HS> UART in the serial cards, the file transfer protocol HS> being used, the type of data being transferred HS> (compressible or not), etc. etc. If you are HS> transferring fully compressed files under good conditions HS> with a full streaming file transfer protocol like Zmodem HS> and with a port speed set to at least 19,200 bit/s, 1600 HS> cps is about average. Don't forget, if he has an internal, he must disconnect whichever com port he is using to stop a com port conflict. This can greatly affect the throughput. Tom Gallagher --- --------------- * Origin: (1:363/300) --------------- FIDO MESSAGE AREA==> TOPIC: 259 HAYES MODEMS Ref: DB^00000 Date: 07/30/96 From: HAYES SUPPORT Time: 11:34am \/To: PRESTON RENARD (Read 1 times) Subj: FACTORS AFFECTING THRUPUT PR> Thank you very much for your reply. BTW...glad to see your firm making PR> a comeback. I have one of your early 300 baud products in my attic. Is PR> your BBS still working and what's the number? PR> PR> Always use ZMODEM and 19.2 on my COM port (run errors with "some" boards PR> if I go higher). My UART is a 8250 according to MSD.EXE. Operating in PR> DOS using DOS comm package Telemate v.4.20 (registered ). I use a PR> 386SX/25 e/w co-processor. Regularly connect to 6/7 local and several PR> 800 BBS numbers. Typically DL *.zip files. Do experience higher thru-put PR> when DL/UL text files but I understand why. Live in a residential area PR> supported by Bell Atlantic's eletronic switching capability. There's PR> loads of fiber throughout this area. Do not 'hear' ground hum (60Hz), PR> white noise or crosstalk on my telephone line. People I speak with via PR> telephone do not complain of hearing anything either (except sometimes PR> me ). However, I do have many extention telephone jacks throughout my PR> house. About 1/3 of them do not have telephones connected to them. PR> PR> With that as a backdrop, I typically achieve only 1300-1500 CPS. The PR> mid 1400s is very common for me. After reading your reply I think I'll I may be mistaken but I believe I remember you stating that your modem id not support error correction..If that's the case, then 1440 cps would be the max, since error correction is responsible for stripping the stop and start bits and if no error correction, no data compression either. Also, for any port speeds higher than 9600 bit/s, you really need a 16550 UART, rather than the 8250 (or 16450) UART that you have. MSD does not distinguish between the 16450 and 8250, and will report both as '8250'. I was able to get some applications going strong with a 16450 with a port speed of 19,200 bit/s and a carrier of 14,400 bit/s, but many applications did not handle it well. Our BBS # is 770-446-6336 and is still going strong. We do get more traffic via our internet email address and web site now though. Michael -- Hayes Online Services support@os.hayes.com --- FLAME v1.1 * Origin: Southern Star - V32b/V.FC/V.34/ISDN - 504-885-5928 - (1:396/1) --------------- FIDO MESSAGE AREA==> TOPIC: 259 HAYES MODEMS Ref: DB^00001 Date: 07/30/96 From: HAYES SUPPORT Time: 11:28am \/To: TOM GALLAGHER (Read 1 times) Subj: FACTORS AFFECTING THRUPUT TG> HS> with a full streaming file transfer protocol like Zmodem TG> HS> and with a port speed set to at least 19,200 bit/s, 1600 TG> HS> cps is about average. TG> TG> Don't forget, if he has an internal, he must disconnect whichever com port he TG> is using to stop a com port conflict. This can greatly affect the throughput. TG> TG> Tom Gallagher TG> Tom, Yes, that's right. COM port and IRQ conflicts are the number 1 hurdle for internal modem installations. Michael -- Hayes Online Services --- FLAME v1.1 * Origin: Southern Star - V32b/V.FC/V.34/ISDN - 504-885-5928 - (1:396/1)